Regression in OpenVPNGui 2.4.7: format error in certificate's notAfter field

wknauf

I observe this error when connecting to a customers vpn server:

Thu Feb 28 08:48:50 2019 VERIFY ERROR: depth=0, error=format error in certificate's notAfter field: C=de, L=Dortmund, O=Versatel, CN=ASG_1, emailAddress=...

The certificate has those fields:
Validity
Not Before: Oct 22 13:28:29 2009 GMT
Not After : Mar 8 13:28:29 2037 GMT
(which is before the 2038 bug...)

It works with OpenVPNGui 2.4.6, so I assume this is a regression.

My machine is Win10x64.

Best regards

Wolfgang

plaisthos

This is probably newer OpenSSL that is more strict than the old one. Also if you can test this by copying the old ssl libraries from 2.4.6 to the new 2.4.7 dir.

If you can/posting the pem of the server or trying to see if openssl x509 -in also complains is a good step.

TinCanTech

This may be helpful:
https://github.com/libressl-portable/portable/issues/472#issuecomment-447563254

wknauf

It worked after replacing openssl.exe, libssl-1_1-x64.dll, libpkcs11-helper-1.dll, libcrypto-1_1-x64.dll. I replaced them step by step, and it started working after replacing libcrypto-1_1-x64.dll. It seems I have to replace the previous three files first, otherwise a dll load error will raise.

The certificate which seems to cause the trouble was given to us from the customers IT and we had to place it in the OpenVPNGui\config directory, So I am not sure whether it is smart to post it here ;-).
In the client config, we have three files: "...ca.crt", "...user.crt" and "...user.key".

A call to "openssl.exe x509 -in ..\config\...ca.crt" prints the "-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----" block. Same for the "...user.crt" file.

Please ask me for more information if needed...

Wolfgang

plaisthos

Are you running with the new openssl.exe from 2.4.7?

you might also add -text to the openssl output to get human readable output.

But in summary this confirm was I suspected. The certificate gets rejected by OpenSSL. So either the certificate needs to be fixed or there might be a bug in OpenSSL. This is not really an OpenVPN bug.

wknauf

Yes, I used the openssl.exe from 2.4.7.

"-text" just prints the full certificate content.

Do you have a link to some OpenSSL forum where I could ask the same?

The Johan

I'm not plaisthos, but, simply looking around a bit seems to suggest you might be able to try here to report your issue:
https://github.com/openssl/openssl/issues

You *might* also be able to fix the certificate by using openssl (the version that works) to read the certificate, and then output it again. Running it through openssl this way might repair defects in the certificate. See instructions on the internet on how to do this.

plaisthos

But note that https://github.com/openssl/openssl/issues is not a help forum but a developer, in there you probably have to provide a server.pem+server.key and reproduce the problem with s_server/s_client.

Even if we (Openvpn) should look into this more closely we would also need some server.pem/server.key that can reproduce the behaviour.

Reading/outputting will not help in this case as notValidAfter is in the signed part which alterning would break the CA signature.

wknauf

Thanks, I asked this on the OpenSSL mailing list: https://mta.openssl.org/pipermail/openssl-users/2019-March/010013.html

Wolfgang

wknauf

It turned out to be a problem with the server certificate:

openssl asn1parse -in server.crt | grep UTC
157:d=3 hl=2 l= 13 prim: UTCTIME :091022132829Z
172:d=3 hl=2 l= 17 prim: UTCTIME :370308132808+0000

==>the second UTC time is invalid.

Thanks for your help!

The Johan

Great to hear, and to have this information on record in the forum.

janjust

For the record: OpenSSL 1.0.x grokked the invalid certificate time. OpenSSL 1.1+ does not. This can be considered a bug in OpenSSL < 1.1.

plaisthos

I got a similar report (also with the 'format error in certificate's notAfter field" error) when I upgraded my app from OpenSSL 1.1.1 to OpenSSL 1.1.1a. So this might be an intended change in OpenSSL.