💾 Archived View for gemi.dev › gemini-mailing-list › 000429.gmi captured on 2024-08-19 at 00:39:32. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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 had to fix this in my go-gemini library. I don't think telling people to not use CommonName is a good solution, and I don't really see the issue with it anyway. When I made the fix, I posted about it on the mailing list: gemini://gemi.dev/gemini-mailing-list/messages/002391.gmi Cheers, makeworld
On Mon Nov 2, 2020 at 9:04 PM EST, wrote: > When I made the fix, I posted about it on the mailing list: > > gemini://gemi.dev/gemini-mailing-list/messages/002391.gmi Using `==` to compare the common name with the domain name doesn't handle all cases though. The common name could contain a wildcard hostname. To resolve this I simply vendored in the parts of crypto/tls responsible for hostname verification, and removed the GODEBUG variable check. You can find the code here: https://git.sr.ht/~adnano/go-gemini/tree/master/vendor.go
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
---