💾 Archived View for thrig.me › blog › 2023 › 02 › 20 › random-SSL-things.gmi captured on 2024-07-09 at 00:58:16. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-14)
-=-=-=-=-=-=-
One is that we're supposed to call it TLS; apparently Microsoft had too much pride to take a knee and use a Netscape protocol, and so SSL had to be renamed.
"And even set to an acoustic guitar accompaniment, the story of Microsoft as a greedy beast that secretly eavesdrops on others is hard to sing along to." -- Michael Eskenazi, "Why Redmond Meanies Shouldn't Have Called Netscape 'Weenies'", 2000-04-14
Some things never change.
Anyways, LibreSSL does not actually support anything SSL, only TLS. In a sane universe TLS 1.0 would have been called SSL 3.1 and so forth, but the GM didn't roll up that universe.
So the actual recent question on #gemini was how to, from the command line, show the certificate details of a site, or the expiration date in particular. A lot of this will depend on exactly what you have installed, can install, or can compile.
gnutls-cli is pretty cromulent.
gnutls-cli -p 1965 example.org
openssl is, uh, less cromulent. Maybe there's a better set of flags that could be used? I mean it sort of works, if it's all you've got...but two commands and a pipeline isn't ideal for anything beyond a quick one-off test.
</dev/null openssl s_client -showcerts -connect example.org:1965 |
openssl x509 -noout -dates
(On the unix sh trivia front, yes, the </dev/null can come first, and yes, a bare | can be used to continue a line.)
There are other SSL libraries that may also have command line tools, or not. I recall that the Java keystore documentation ran along the lines of "Oh, you want to extract the keys from the keystore? You'll need to write a Java program to do that". Thanks, but, no thanks? I instead shuttered the jabber service (which almost nobody used) and told everyone to use Google Talk (which almost nobody used). That whole episode very much had shades of XKCD 979.
If you know the package name, there are usually package tools to show what files belong to that, and therefore what utilities to poke at, e.g. on OpenBSD one might use:
$ pkg_info -L gnutls | fgrep bin/
/usr/local/bin/certtool
/usr/local/bin/danetool
/usr/local/bin/gnutls-cli
/usr/local/bin/gnutls-cli-debug
/usr/local/bin/gnutls-serv
/usr/local/bin/ocsptool
/usr/local/bin/p11tool
/usr/local/bin/psktool
/usr/local/bin/srptool
Otherwise you may need to write (or find and adapt) code, which is usually educational, or could cause loss of sanity points--this universe is indeed Lovecraftian in various respects. For instance you may eventually learn that there are a pair of dates in a certificate, and there may be a chain of certificates (probably uncommon in gemini, but very relevant to the legacy web) each of which has a pair of dates that may cause verification to fail. Usually the "not before" date does not cause problems, unless you've generated a certificate that starts in the future (whoops?), or more likely your system's clock is set...poorly...and you are trying to use a recently generated certificate. The lesson here is to get the system clock right, then work on any remaining SSL problems. One of these years I'll take a job where I do not have to setup or fix NTP...
The code can quickly get into the weeds, especially if you want to add support for, say, client certificates that may come in different encoding forms and might be password protected, and if you're starting from scratch with a huge SSL API. And maybe you want to support both standalone gemini certificates and verified chains of certificates. And maybe you need to specify a custom certificate authority to use? One method would be to adapt existing code, probably not something gnarly like openssl(1) but rather maybe gg(1) of the gmid daemon:
--- gg.c
+++ gg.c
@@ -230,6 +230,15 @@ get(const char *r)
}
}
+ time_t tim;
+ struct tm tminfo;
+ tim = tls_peer_cert_notbefore(ctx);
+ strftime(buf, sizeof(buf), "%Y%m%d %H:%M:%S", localtime_r(&tim, &tminfo));
+ fprintf(stderr, "notbefore %s\n", buf);
+ tim = tls_peer_cert_notafter(ctx);
+ strftime(buf, sizeof(buf), "%Y%m%d %H:%M:%S", localtime_r(&tim, &tminfo));
+ fprintf(stderr, "notafter %s\n", buf);
+
doreq(ctx, req);
for (;;) {
which gives us:
gg gemini://example.org >/dev/null
and might be nice to add to gg(1) via some flag to show more about the certificate metadata? But that could also embiggen gg with mostly needless code.
Otherwise the old OpenSSL API is pretty terrible; one might be better served by copying from gg(1) or using some other library. After some searching the Go API does not seem too bad, does not have terrible compile times, and does give access to the full certificate chain, if you want to know about the dates of some intermediate certificate:
$ 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
$ certexp -v thrig.me:443
Subject CN=thrig.me
Issuer CN=R3,O=Let's Encrypt,C=US
notBefore 2023-02-03 01:17:09 +0000 UTC
notAfter 2023-05-04 01:17:08 +0000 UTC
...
certexp.go can be found in my woefully large scripts repository.
https://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html
https://content.time.com/time/magazine/article/0,9171,43102,00.html
ircs://irc.tilde.chat:6697/#gemini
http://man.openbsd.org/man3/tls_conn_version.3
https://github.com/omar-polo/gmid
https://thrig.me/src/scripts.git
tags #ssl #gemini