TLS and CNs - golang 1.15

[vjanelle]

Golang 1.15 depreciated CAs which are created without SANs - this is something that was depreciated 20 years ago.

Currently we have (at least) one test CA in our test suite which was created this way - IIRC this was because the CA could've been made with puppet?

Is this behavior in the current versions of puppet? If so, when was that changed?

[vjanelle]

Grabbing the latest puppetserver image, looks like it doesn't create CAs with a SAN >.<

[ripienaar]

Yup :( and even if recent ones did we would have like years more of this dumb things as most old certs are this way and certs can be valid for 5 years

little choice but to write our own validation code that gets called only for certs without them

[vjanelle]

Yup - the "ignoreCN" variable is created at runtime, so unfortunately the only thing we could do is to ensure the variable is set before we start the process.

[ripienaar]

1.16 removes that variable. Will need to code own validation

[vjanelle]

Hmm, when I looked at the source it was still there.. https://github.com/golang/go/blob/master/src/crypto/x509/verify.go#L22

[ripienaar]

Not sure where I saw it’s targeted, anyway we can’t expect it to be there long nor can we ensure it’s set for CLI interactions :(

[vjanelle]

choria-io/go-choria#1057

Here's a potential hack - if a SAN doesn't exist, create one and shove the common name into it. Should probably be hidden behind a configuration flag (that defaults to on..)

[ripienaar]

If it works I am all for it :)

[marc-brou]

Hey guys,
I have been trying to setup the latest version of Choria in a new environment and I seem to be hitting a lot of Cert missing SAN issues, I have seen Issue#1060 and tried setting plugin.security.support_legacy_certificates to true, but it didn't seem to have any effects, altho I did not find how to set this with Hiera so I added manually to all the conf files under /etc/choria and also added a plugin.d/security.cfg file with support_legacy_certificates = true inside. Would appreciate info on correct way to add this setting so it doesn't get removed by puppet.

I can get nodes to connect to the network broker fine, however the federated broker gives this error:
{"cluster":"phxl","component":"federation","connection":"choria_nats_ingest","level":"warning","msg":"Initial connection to the Broker failed on try 22790: x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0","time":"2021-03-11T03:45:27-05:00","worker":"choria_nats_ingest","worker_instance":2}

and client seems to have issues too, for example:
$ choria ping
WARN[0000] Initial connection to the Broker failed on try 1: x509: certificate is not valid for any names, but wanted to match component=client connection=myuser.mcollective-9745691595a94dffaac2783022172293-receiver2

I am no Certificate Expert but you are talking about the CA cert not having a SAN, which seems weird to me, I understand for normal certs, but why would a root CA need a SAN? would my intermediate CA that puppet uses having a SAN fix the issues?

[ripienaar]

Hmm. I have to limit this code only to the clients but I guess I have a bug where I don’t handle the federation clients.

I agree it’s weird and unnecessary but this is a change in tbe Go language that cannot be opted out and that is unbelievably stupid. So we are just trying to work around this idiocy as best we can :(

[ripienaar]

@marc-brou you are using Puppet CA? its weird you get this for normal client too

[marc-brou]

I am already setting choria::srvdomain: in hiera, is there a different setting affecting the client.conf ?

[marc-brou]

ok, got it to add srv to client.conf by adding in hiera:

mcollective::client_config:
    plugin.choria.srv_domain: choria

and commenting out: #plugin.choria.federation.collectives from the client.conf that was probably there from my test with the federation stuff which seems was causing the nodes to not reply.
Seems to all be working fine without the federation enabled now :)
Thanks again for the help!

[ripienaar]

cool, srvdomain vs srv_domain and setting this once only is high on the list of things to fix as we work to simplify the modules

glad its sorted now

[ripienaar]

Tomorrows nightly build will probably also fix federation if you wanted to test things

[marc-brou]

Yup, Federation seems to work fine with the nightly build. Thanks again!