khuxkm at tilde.team khuxkm at tilde.team
Tue Nov 3 12:56:31 GMT 2020
- - - - - - - - - - - - - - - - - - -
November 2, 2020 8:47 PM, "Adnan Maolood" <me at adnano.co> wrote:
The documentation for the Go crypto/tls package has this to say about
using the Common Name field in certificates:
The legacy Common Name field is ignored unless it's a valid hostname,
the certificate doesn't have any Subject Alternative Names, and the
GODEBUG environment variable is set to "x509ignoreCN=0". Support for
Common Name is deprecated will be entirely removed in the future.
https://golang.org/pkg/crypto/x509/#Certificate.VerifyHostname
In light of this, should Gemini servers avoid using the Common Name for
certificates, or at least provide a Subject Alternative Name as well?
For go-gemini I had to vendor in the hostname verification code from
crypto/tls and modify it to accept common names without setting the
GODEBUG environment variable.
I recently started work on my own Gemini server (still a work in progress), and I needed a certificate to test my server. So I fired up ye olde DuckDuckGo and searched "create self signed certificate openssl" and found:
It's important to put DNS name in the SAN and not the CN, because both the IETF and the CA/Browser Forums specify the practice. They also specify that DNS names in the CN are deprecated (but not prohibited). If you put a DNS name in the CN, then it must be included in the SAN under the CA/B policies. So you can't avoid using the Subject Alternate Name.
Now, of course, this doesn't have to apply to Gemini, but I wanted something that was as future-proof as I could make it, so I found a command to put names in the SAN without creating a config file, which got me:
openssl req -x509 -newkey rsa:4096 -sha256 -days 365 -nodes \
-keyout localhost.key -out localhost.crt -subj "/CN=7f000001.nip.io" \
-addext "subjectAltName=DNS:7f000001.nip.io"
(I was testing localhost, so I used 7f000001.nip.io, which points to 127.0.0.1. RSA is fine enough security as is.)
This actually isn't that hard to do; I'm not sure what the equivalent would be in other SSL libraries, but at least in OpenSSL it's pretty simple. We don't necessarily have to say "don't use the CN", but people should configure their certificates so that clients don't have to mess around with stdlib code just to accept them.
Just my two cents,Robert "khuxkm" Miles