💾 Archived View for gemi.dev › gemini-mailing-list › 000321.gmi captured on 2023-12-28 at 15:45:17. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
Hello gophers,
If you have written (or are planning on writing) a Gemini application in Go
that validates the server/client cert, you will have to change your code.
Part of validation is validating the hostname, and this has changed in
Go 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 for
the web. I did not know that! So using cert.VerifyHostname will no longer
work 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 that
fails. 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 therefore
gemget and Amfora), but until then do not compile them with Go 1.15.
Cheers,
makeworld
---
Previous Thread: Lovell - a Gemini server written for Node.js