On Sat, 28 Feb 2026 23:59:41 +0000
Lloyd <ng2d68@proton.me> 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).