Bug 11424 - OpenVPN, problem uploading clients certificates with some legacy x.509 attributes
Summary: OpenVPN, problem uploading clients certificates with some legacy x.509 attrib...
Status: ASSIGNED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: all All
: Will affect almost no one Crash
Assignee: Erik Kapfer
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-10 18:38 UTC by Scrasa
Modified: 2020-04-10 11:03 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Scrasa 2017-07-10 18:38:36 UTC
For OpenVPN, problem uploading clients certificats with some legacy x.509 attributes

I'm using an external CA soft to create certs (root, server cert, client cert ...). Actually I'm using XCA (xca.sf.net), but the same problem exists with old certs I had generated with easy-rsa (debian package). I'm using IPFire 2.19 (x86_64) - Core Update 111.

I configured openvpn in ipfire, uploading with success via web console the PKCS#12 chain with RootCert-ServerCert, the DH parameter file, the CRL file (sent via ssh). The openvpn start successfully.


* First problem, upload client cert

The problem come when trying to upload client cert via the web console. I got an "Internal Server Error".

In the http error log I have :

[error] [client x.x.x.x] Unable to create clientconfigfile No such file or directory at /srv/web/ipfire/cgi-bin/ovpnmain.cgi line 4357., referer: https://firewall3:444/cgi-bin/
[error] [client x.x.x.x] Premature end of script headers: ovpnmain.cgi, referer: https://firewall3:444/cgi-bin/ovpnmain.cgi

The problem come from the CN of my client cert. I generated it with an email field and name field (with easy-rsa, but same problem with XCA if using on the "Subject" tab the "emailAddress" field with something). Looking with "openssl x509 -in ... -text -noout" (same command used in ovpnmain.cgi to get the x.509 content of the upload cert). The Subject of my client cert is in the form :

C=CH, L=MyCity, O=MyCompany, CN=myusername/name=Myfirstname Mylastname/emailAddress=user@mydomain.com

searching in the RFC I find that embeding some attributes on the CN, is deprecated but supported (seams easy-rsa et xca are using it when using the emailAddress in the subject, not the "correct" one on the alternate subject). See RFC 5830 quote :

"4.1.2.6.  Subject
...
Legacy implementations exist where an electronic mail address is
embedded in the subject distinguished name as an emailAddress
attribute [RFC2985].
...
Conforming implementations generating new certificates with
electronic mail addresses MUST use the rfc822Name in the subject
alternative name extension (Section 4.2.1.6) to describe such
identities.  Simultaneous inclusion of the emailAddress attribute in
the subject distinguished name to support legacy implementations is
deprecated but permitted."

So "legacy" but permitted.

The problem is the "/name ..." (or same thing with only a /emailAdress field) when creating the ccd file with the CERT_NAME
the "/" is seen as folder separation and creation cannot be done.
(line 4357 of ovpnmain.cgi)

I temporary fixed the problem in /srv/web/ipfire/cgi-bin/ovpnmain.cgi, with code like :

              my $cleaned_certname = $confighash{$key}[2];
              $cleaned_certname =~ s/\/.*//;
              if ( -e "${General::swroot}/ovpn/ccd/$cleaned_certname"){
                       unlink "${General::swroot}/ovpn/ccd/$cgiparams{'CERT_NAME'}";
              }
              open ( CCDRWCONF,'>',"${General::swroot}/ovpn/ccd/$cleaned_certname") or die "Unable to create clientconfigfile $!";

Than the upload of client cert with such "legacy" attributes embedded in CN is ok, and the ccd is correctly created, with a name only containing the main part of the CN (without attribute). I tested, openvpn seems to work well with ccd name equal of CN without such legacy attributes embeded on CN.

Reading the code, the problem seems to be the same for Certificate Request (CSR) upload, but I don't tested.


* Second problem, the "verify" script

With such certif with "legacy attributes", the connection doesn't work. The problem came from the verify script (/usr/lib/openvpn/verify). It as called with second parameter with content of subject. I traced what the script receive in the variable and I got :

C=CH, L=MyCity, O=MyCompany, CN=myusername, name=Myfirstname Mylastname, emailAddress=user@mydomain.com

I tested different parameter for "openssl x509" and I found that if using all displaying (-text) or only subject (-subject) the output is not the same ... with "-text" (used in ovpnmain.cgi) legacy attributes are separated with "/", but with "-subject" legacy attributes are separated with ", ". It seems that openvpn is using "-subject" to output the subject name given on the 2nd parameter of the verify script ?

so on the verify script the :

$CN =~ /(\/|,\ )CN=(.*)$/i;

Doesn't work, because the legacy attributes received on the parameter of the openvpn script (with ", ") are not the same than legacy attributes stored on the /var/ipfire/ovpn/ovpnconfig, (with "/") because of the "-text" parameter used by ovpnmain.cgi.

So I temporary fixed the problem of /usr/lib/openvpn/verify-new, adding some :

$CN =~ s/, /\//g;


=>
With such 2 temporary fixes, everything seems to work, upload, connection and verify success of my client cert with such "legacy attributes" (but seems wide used with differents CA software for "email" field).
Comment 1 Peter Müller 2020-04-10 11:03:51 UTC
What is the status of this bug?