From: Jan Klemkow <jan@openbsd.org>
Subject: Re: [diff] httpd: pass through dn from tls client cert to fcgi
To: Jack Burton <jack@saosce.com.au>
Cc: tech@openbsd.org
Date: Wed, 29 Apr 2026 21:49:29 +0200

On Wed, Apr 29, 2026 at 04:54:12PM +0930, Jack Burton wrote:
> Quick ping.
> 
> Any further thoughts on this?

I also like this feature and also thought about it in the past.

But, I guess a certificate where the subject is NULL, may crash the
httpd?

tls_peer_cert_subject() can return NULL and fcgi_add_param() does an
unchecked memcpy(3) with it.  So, you have to check for a NULL before
calling fcgi_add_param().

bye,
Jan

> On Sun, 1 Mar 2026 00:21:14 +1030
> Jack Burton <jack@saosce.com.au> wrote:
> 
> > Expose the client cert DN (as TLS_PEER_SUBJECT) to fastcgi responders,
> > so that TLS client certs can be used for authorisation (not just for
> > authentication).
> > 
> > This is a scaled-down version of a patch I proposed some years ago[1].
> > That version also passed through the {issuer,serial} tuple (that
> > identifies any certificate uniquely), which made it rather more
> > intrusive ... and I assume that's why it wasn't accepted at the time.
> > 
> > All the recent activity in httpd reminded me that I should really
> > get around to having another go at getting it in the tree.
> > 
> > Today's version passes through only the DN, which I'm hoping makes it
> > unobtrusive enough to consider.  That's the bare minimum to make TLS
> > clients certs usable by fastcgi responders for authorisation purposes
> > and will suffice in most scenarios, as it identifies the entity to
> > whom the certificate was issued.
> > 
> > It does *not* differentiate between multiple valid client certs issued
> > to the same entity (whereas the patch in [1] did) ... but in the real
> > world the proportion of authorisation processes that genuinely need to
> > care about such things is fairly low (identifying the entity is
> > usually enough to make an authorisation decision).
> > 
> > Thoughts?
> > 
> > [1] https://marc.info/?l=openbsd-tech&m=153112641425436&w=2
> > 
> > Index: usr.sbin/httpd/httpd.conf.5
> > ===================================================================
> > RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
> > diff -u -p -r1.129 httpd.conf.5
> > --- usr.sbin/httpd/httpd.conf.5	18 Jan 2026 16:38:02
> > -0000	1.129 +++ usr.sbin/httpd/httpd.conf.5	28 Feb 2026
> > 12:52:15 -0000 @@ -453,6 +453,11 @@ The revision of the HTTP
> > specification u .It Ic SERVER_SOFTWARE
> >  The server software name of
> >  .Xr httpd 8 .
> > +.It Ic TLS_PEER_SUBJECT
> > +The subject
> > +.Pq distinguished name
> > +of the TLS client certficate
> > +.Pq omitted when TLS client verification is not in use .
> >  .It Ic TLS_PEER_VERIFY
> >  A variable that is set to a comma separated list of TLS client
> > verification features in use
> > Index: usr.sbin/httpd/server_fcgi.c
> > ===================================================================
> > RCS file: /cvs/src/usr.sbin/httpd/server_fcgi.c,v
> > diff -u -p -r1.99 server_fcgi.c
> > --- usr.sbin/httpd/server_fcgi.c	2 Jan 2026 08:45:16
> > -0000	1.99 +++ usr.sbin/httpd/server_fcgi.c	28 Feb 2026
> > 12:52:15 -0000 @@ -34,6 +34,8 @@
> >  #include <event.h>
> >  #include <unistd.h>
> >  
> > +#include <tls.h>
> > +
> >  #include "httpd.h"
> >  #include "http.h"
> >  
> > @@ -269,6 +271,12 @@ server_fcgi(struct httpd *env, struct cl
> >  		if (srv_conf->tls_flags != 0 &&
> > fcgi_add_param(&param, "TLS_PEER_VERIFY",
> > printb_flags(srv_conf->tls_flags, TLSFLAG_BITS), clt) == -1) {
> > +			errstr = "failed to encode param";
> > +			goto fail;
> > +		}
> > +		if (tls_peer_cert_provided(clt->clt_tls_ctx) &&
> > +		    fcgi_add_param(&param, "TLS_PEER_SUBJECT",
> > +		    tls_peer_cert_subject(clt->clt_tls_ctx), clt) ==
> > -1) { errstr = "failed to encode param";
> >  			goto fail;
> >  		}
>