Opened 4 years ago

Last modified 3 years ago

#717 assigned Feature Wish

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

Reported by: gp! Owned by:
Priority: major Milestone:
Component: Certificates Version: OpenVPN 2.3.10 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

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.

Change History (3)

comment:1 Changed 3 years ago by Gert Döring

Component: Generic / unclassifiedCertificates
Owner: set to Eric Crist
Type: Bug / DefectFeature Wish

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...

comment:2 Changed 3 years ago by Gert Döring

Owner: Eric Crist deleted
Status: newassigned

comment:3 Changed 3 years ago by 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.

Note: See TracTickets for help on using tickets.