💾 Archived View for thrig.me › tech › ssl › verification.gmi captured on 2024-08-18 at 19:15:41. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
Once generated, SSL certificates can be verified in various ways. Typically for the web there is a certificate authority, a chain of certificates, and some software magic that results in an okay symbol or an error. Other questions may remain, such as can the certificate authority be trusted, or should it be trusted? There are other ways to verify certificates that do not involve potentially problematic certificate authorities.
The X.509 details can be inspected. This is useful on newly generated certificates to ensure that various fields look sane, such as the notBefore or notAfter dates. One might expect that a certificate that lasts for a year would expire in roughly a year, for instance.
While final root cause analysis is in progress, this issue appears to be due to a time calculation that was incorrect for the leap year
https://www.zdnet.com/article/microsofts-azure-cloud-leap-day-meltdown/
Whoops.
Anyways, certificates have two dates; the notAfter or "expiration" is most relevant, though a notBefore check could fail if a system clock is screwed up--maybe NTP isn't setup right, or the system booted up four years in the future. Something like that.
$ openssl x509 -noout -dates < host.cert
notBefore=Apr 8 01:37:03 2023 GMT
notAfter=Jul 16 01:37:03 2023 GMT
Yes, I have seen a system boot up four years into the future, and NTP was broken on it for unrelated reasons. Rare, but not impossible.
It may be good then to inspect the X.509 details, especially on new certificates generated by new systems, but also now and then to see if any of the metadata is different, or even broken. It can help to get a sense of what a normal certificate looks like. Or there may be a typo in some field, or a Signature Algorithm that is too weak, to compare certificates generated by different systems or software, etc.
Automated checks can be made that certificate expiration dates are valid; this usually falls under the term of monitoring. Smaller sites might ignore this, or wait for their customers to complain. Others will favor more proactive checks, e.g. a warning that a certificate is due to expire in under a week. Assuming that the certificate automation isn't broken is a good way to end up with a broken system when the automation does break.
https://github.com/timewasted/go-check-certs
One method is to use the self-signed certificate as the sole Certificate Authority (CA) for the purposes of verification. This will scale poorly if there are many systems with many certificates, but can work for a tunnel between only two systems.
Another method of verification is to extract some sort of fingerprint from a certificate, and to trust connections with a certificate that matches a known fingerprint. This might be used by a gemini server to trust particular clients, or by a SMTP server to allow relaying from remote systems. Only systems or clients with a known fingerprint will be allowed. Again, this will not scale if there are many systems; in such a case it is likely more sensible to trust certificates signed by a trusted CA. For SMTP this would likely be a local CA, not one that anyone can use.
Gemini clients use TOFU, or Trust On First Use, generally by saving a fingerprint of a server's certificate and then trusting that known certificate if it is seen again in the future. Gemini clients can also use the usual certificate verification to also support for example Let's Encrypt certificates, or only TOFU, or might do no verification at all. Various methods can be found in various gemini client software--amfora, gg, gmitool.
https://github.com/makeworld-the-better-one/amfora
https://github.com/omar-polo/gmid
https://thrig.me/src/Net-Gemini.git
This is the usual method for a web browser, using various builtin certificates, or perhaps those from an operating system directory such as /etc/ssl or a specific file that contains the CA certificates. The main problem here is how much one can trust the certificate authorities, which are human institutions that suffer from the usual vices--blackmail, exploitation, bribery, patriotism. Anyone, bad actors included, can sign up for free certificates.
DNS Certification Authority Authorization (CAA) can be used to limit what CA are authorized to issue certificates for, though bad actors may ignore this. Also, DNS is usually by no means secure.
A typical customization would be to configure systems to only trust a local certificate authority. This is good for internal needs, but not so good where random third party clients need to connect. For external facing systems a public CA such as Let's Encrypt or a self-signed certificate (for a gemini server) would make more sense.