An observation about client certificates
Sean Conner
sean at conman.org
Mon May 11 10:21:01 BST 2020
It was thus said that the Great solderpunk once stated:
>
> Anyway, at some point yesterday I got tired of filling out `openssl`s
> prompts when making new certs and just gave blank answers to everything,
> which would be the requests you noticed. Are you quite sure that your
> server handled them just fine as the logs indicate?
If it doesn't, I have bigger issues. But I was unable to reproduce what I
was seeing, but I didn't actually get around to producing a certificate
with an empty issuer and subject field.
> If I remember
> rightly the SSL handshake seemed to fail when I did this so I quickly
> reverted to putting something non-zero in there.
Well, I told the TLS layer that I didn't want *it* to verify the
certificate, and the only validation *I* do prior to request specific
checks, is to check the date. And for my "/private" subdirectory, all I do
is return 'true'---I don't bother checking the actual certificate.
> We should talk about logging formats some time. Molly Brown keeps logs
> too (I keep meaning to make a nice graph showing the wave of traffice
> that came in after we hit HN), in an ad-hoc format that doesn't match
> yours below at all (unsurprisingly). Having a standard format would
> facilitate tools to monitor/visualise logs.
I log via syslog(), which handles the timestamps for me (and log rotation,
and a whole bunch of other stuff related to logging). I place the name of
the fields to make later processing a bit easier, but as far as I can tell,
the only thing I log that you don't is the issuer and subject from any
certificates presented, and that was to satisfy my own curiousity (and to
potentially troubleshoot any issues).
But there's really not much to log, other than remote address, request,
status, and potentially the issuer/subject of any given certificate (and
even that might be optional).
-spc
More information about the Gemini
mailing list