💾 Archived View for rawtext.club › ~sloum › geminilist › 002391.gmi captured on 2020-10-31 at 14:30:50. Gemini links have been rewritten to link to archived content

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

Go 1.15 requires changes to TLS code for Gemini!

colecmac at protonmail.com colecmac at protonmail.com

Wed Aug 12 15:05:45 BST 2020

- - - - - - - - - - - - - - - - - - -

Hello gophers,

If you have written (or are planning on writing) a Gemini application in Gothat validates the server/client cert, you will have to change your code.Part of validation is validating the hostname, and this has changed inGo 1.15.

The deprecated, legacy behavior of treating the CommonName field on X.509

certificates as a host name when no Subject Alternative Names are present

is now disabled by default. It can be temporarily re-enabled by adding the

value x509ignoreCN=0 to the GODEBUG environment variable.

https://golang.org/doc/go1.15#commonname

Apparently using CN without a SAN is deprecated by RFC, at least forthe web. I did not know that! So using cert.VerifyHostname will no longerwork on the majority of Gemini certs that just specify a CN and nothing else.

The solution is to check the CN manually, and then use VerifyHostname if thatfails. If both fail, then the cert is not valid.

If I have an x509.Certificate with the name `cert`, and a hostname called`hostname`, I can do this to check:

if cert.Subject.CommonName == hostname || cert.VerifyHostname(hostname) == nil { // Do something}

or of course:

if cert.Subject.CommonName != hostname && cert.VerifyHostname(hostname) != nil { // Exit, return an error, etc}

Hope this helps! I will be implementing this in go-gemini (and thereforegemget and Amfora), but until then do not compile them with Go 1.15.

Cheers,makeworld