auth-user-pass-verify script cannot verify username belogs to certificate unless matches common name

[gp!]

The auth-user-pass-verify script does not have access to the complete client certificate or the client certificate san data. when the username is listed in the san and not the common name the script cannot verify the certificate has permission to the username.

So, it would be beneficial for the auth-user-pass-verify to have the peer_cert environment variable. It might also be nice for the san to be parsed and provided like X509_{n}_{subject_field}. Something like X509_SAN_0_DNS or X509_SAN_0_UPN. But access to the raw data would be just as nice or maybe better as it is less restrictive.

[Gert Döring]

Does it work if you use --x509-username-field SAN0DNS (or however the field is really called, never heard of SAN before)?

Man page says

       --x509-username-field [ext:]fieldname
              Field in the X.509 certificate subject to be used as  the  user-
              name  (default=CN).   Typically,  this  option is specified with
              fieldname as either of the following:

              --x509-username-field emailAddress
              --x509-username-field ext:subjectAltName

              The first example uses the value of the "emailAddress" attribute
              in  the certificate's Subject field as the username.  The second
              example uses the ext: prefix to signify that the X.509 extension
              fieldname "subjectAltName" be searched for an rfc822Name (email)
              field to be used as the username.  In cases where there are mul-
              tiple  email  addresses in ext:fieldname, the last occurrence is
              chosen.

(I'm not sure if this is then actually exported to the scripts, or just used internally for --verify-x509-name )

There is also

       --x509-track attribute
              Save peer X509 attribute value in environment for use by plugins
              and  management  interface.   Prepend a '+' to attribute to save
              values  from  full  cert  chain.   Values  will  be  encoded  as
              X509_<depth>_<attribute>=<value>.  Multiple --x509-track options
              can be defined to track multiple attributes.

sounds even more fitting...

[David Sommerseth]

I believe you have access to the complete certificate, through the $peer_cert env variable.

From the man-page:

       --tls-export-cert directory
              Store the certificates the clients uses upon connection to this
              directory. This will be done  before  --tls-verify  is  called.
              The  certificates will use a temporary name and will be deleted
              when the tls-verify script returns.  The file name used for the
              certificate  is  available  via the peer_cert environment vari‐
              able.

But that is via --tls-verify and not --auth-user-pass-verify. But a --tls-verify script could just copy the temp file to a "in progress" directory with a unique key --auth-user-pass-verify can create based upon the variable names available ($tls_digest_0 ?). And then --auth-user-pass-verify removes that file again when no longer needed.

Otherwise, cron2 is right, --x509-track is also a reasonable way to extract specific information. But I'm not sure if SAN attributes are covered by that approach.

[Gert Döring]

So we never heard back on whether --x509-track will solve the problem or not, so I claim it does, and proceed to close the ticket.