💾 Archived View for gemi.dev › gemini-mailing-list › 000429.gmi captured on 2023-11-04 at 12:48:31. Gemini links have been rewritten to link to archived content

View Raw

More Information

➡️ Next capture (2023-12-28)

-=-=-=-=-=-=-

Using Common Name in certificates

Adnan Maolood <me (a) adnano.co>

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.

Link to individual message.

colecmac@protonmail.com <colecmac (a) protonmail.com>

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:

https://lists.orbitalfox.eu/archives/gemini/2020/002391.html


Cheers,
makeworld

Link to individual message.

Adnan Maolood <me (a) adnano.co>

On Mon Nov 2, 2020 at 9:04 PM EST,  wrote:
> When I made the fix, I posted about it on the mailing list:
>
> https://lists.orbitalfox.eu/archives/gemini/2020/002391.html

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

Link to individual message.

khuxkm@tilde.team <khuxkm (a) tilde.team>

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

Link to individual message.

---

Previous Thread: Licensing content for your capsule

Next Thread: Torture test 0026