From: Jack Burton Subject: Re: [diff] httpd: pass through dn from tls client cert to fcgi To: Lloyd Cc: Rafael Sadowski , tech@openbsd.org Date: Sun, 1 Mar 2026 15:30:07 +1030 On Sat, 28 Feb 2026 23:59:41 +0000 Lloyd wrote: > Would it make sense to also expose the cert fingerprint? I doubt it. Can you think of a situation where the DN alone is not enough to make an authorisation decision, but a hash of the cert is? As I see it there are only two scenarios (from an authorisation perspective, in both cases assuming client cert authentication has been done first, just as httpd does already when the "tls client ca" directive is given without the "optional" option): 1. (the most common). Decision can be made purely on the basis of which entity the cert was issued to (so we don't need to differentiate between multiple valid certs issued to the same entity). The DN is sufficient for that. This is the approach that my most recent patch takes. 2. (much rarer but they do arise occasionally). Decision requires identifying the specific cert (not just the entity) uniquely. Minimum required to do this is the {issuer,serial} tuple (in fact in this case we can ignore the DN altogether for authorisation ... but it's handy to have anyway). That (providing all three) is the approach that my July 2018 patch took. In scenario #2, you could use tls_peer_cert_hash(3) as a *proxy* for {issuer,serial}, but that risks a hash collision (extremely unlikely, but not altogether impossible). In the rare situations where #2 is actually needed, that's probably less desirable than maintaining a site-local patch to provide {issuer,serial}. I'm happy to go back to {issuer,serial,subject} if that's what others want too (in fact it'd be easier for me: then I'd have no sites at all left with local httpd patches to maintain, instead of just one if we go with the DN-only approach). But there didn't seem to be much interest last time I proposed that approach, which is why I've suggested passing through just the DN this time. Even if we do end up going back to the {issuer,serial,subject} approach, I'd still suggest going with the subject-only patch first, as it satisfies most cases. With the benefit of hindsight I now believe that the serial extraction code I originally suggested adding to server_fcgi() would be better done by implementing a tls_peer_cert_serial() in libtls first, so that it can be used elsewhere too; after which having httpd pass through {issuer,serial} to fcgi would be trivial (happy to follow up with those patches for libtls & httpd if there's interest).