💾 Archived View for thrig.me › tech › gemini › tofu.gmi captured on 2024-05-10 at 12:35:24. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-04-19)
-=-=-=-=-=-=-
gemini://makeworld.space/gemlog/2020-07-03-tofu-rec.gmi
amfora only shows that a certificate expires (and when); additional details must be gleaned with some other tool. A decent tool for this purpose is gnutls-cli, and not so much the openssl(1) utility.
$ pkglocate bin/gnutls-cli
gnutls-3.7.7:security/gnutls:/usr/local/bin/gnutls-cli
...
$ gnutls-cli -p 1965 kwiecien.us </dev/null
...
- Certificate[0] info:
- subject `CN=kwiecien.us', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x033b9e205bd0577bf59f02d6f9d474681c17, RSA key 2048 bits, signed using RSA-SHA256, activated `2023-03-02 15:02:39 UTC', expires `2023-05-31 15:02:38 UTC', pin-sha256="KYnGmZ4DbGpSpS/TeGzJbubsP+2bVU1zTmJSRDb1DGA="
...
The important detail is that kwiecien.us here uses what I call "lettuce encrypt" or "Let's Encrypt" if you prefer, as the chain of certificates shows. These certificates expire periodically, so gemini clients will periodically have an alert or refresh or something. It is probably good to check on these details, especially if you are unfamiliar with the site. The downside of "Let's Encrypt" is that anyone can use it, so it could be a certificate generated by a friendly, or by someone malicious, though malicious people could also generate their own self-signed certificate, or corrupt other certificate authority providers in various ways. Trusting trust can be a tricky thing.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
Software from various companies, Apple and Google come to mind, may refuse to accept certificates that last for too long, more than a year or so. These softwares may not intersect with gemini, though.
There is also a certexp.go under my scripts repository that shows the certificate or certificate chain for a given host.
https://thrig.me/src/scripts.git
$ certexp thrig.me:1965
Subject CN=thrig.me
Issuer CN=thrig.me
notBefore 2022-12-20 19:35:58 +0000 UTC
notAfter 2296-10-03 19:35:58 +0000 UTC
certID 8E45637224E2FD37B21EA39CBC94FFB135AB25D1445CFAA6A7359BA5E2BE2398
This is a self-signed certificate set to last for a while. The upside is that the certificate does not change periodically--unless I have to generate a new certificate, for some reason--but there could be downsides, especially if there is no "forward secrecy" going on.
The advantage of a custom tool (besides the cost of implementing it) is that the output can show exactly what you want; the output is likely less verbose than that of a generic tool, and the certID here is the same as used by the amfora client.
Server operators may want to monitor their systems to confirm that the certificate has not expired or that the gemini server is actually running, so that someone can be notified to fix the problem. If you have actual users, you might let them yell at you on IRC or by email (or twitter or some other horrible modern protocol, if you prefer). Why monitor? The lettuce encryption scripts may break, or maybe the filesystem fills up and new certificates cannot be written, stuff broke after a rare reboot--all sorts of things can go wrong.
If you are using "let's encrypt" do make sure that the gemini server is getting the new certificate; this may require a restart of the gemini server either on some schedule or perhaps the "let's encrypt" software you are using can trigger actions on certificate change.