OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field
Jan Just Keijser
janjust at nikhef.nl
Wed Mar 6 09:52:44 UTC 2019
Hi all,
On 04/03/19 10:01, Richard Levitte wrote:
> The format error refers to how the numbers are encoded in the
> certificate. The best way to see for ourselves is if you can run
> 'openssl asn1parse' on the certificate and show us the sequence that
> contains the notBefore and notAfter time-stamps. The are seen
> together between the issuer name and the subject name.
>
> As an example, here's the 'openssl asn1parse' output for
> test/testx509.pem:
>
> : ; openssl asn1parse -i -in test/testx509.pem
> 0:d=0 hl=4 l= 347 cons: SEQUENCE
> 4:d=1 hl=4 l= 262 cons: SEQUENCE
> 8:d=2 hl=2 l= 1 prim: INTEGER :18
> 11:d=2 hl=2 l= 13 cons: SEQUENCE
> 13:d=3 hl=2 l= 9 prim: OBJECT :md5WithRSAEncryption
> 24:d=3 hl=2 l= 0 prim: NULL
> 26:d=2 hl=2 l= 56 cons: SEQUENCE
> 28:d=3 hl=2 l= 11 cons: SET
> 30:d=4 hl=2 l= 9 cons: SEQUENCE
> 32:d=5 hl=2 l= 3 prim: OBJECT :countryName
> 37:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU
> 41:d=3 hl=2 l= 12 cons: SET
> 43:d=4 hl=2 l= 10 cons: SEQUENCE
> 45:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
> 50:d=5 hl=2 l= 3 prim: PRINTABLESTRING :QLD
> 55:d=3 hl=2 l= 27 cons: SET
> 57:d=4 hl=2 l= 25 cons: SEQUENCE
> 59:d=5 hl=2 l= 3 prim: OBJECT :commonName
> 64:d=5 hl=2 l= 18 prim: PRINTABLESTRING :SSLeay/rsa test CA
> 84:d=2 hl=2 l= 30 cons: SEQUENCE
> 86:d=3 hl=2 l= 13 prim: UTCTIME :950619233312Z
> 101:d=3 hl=2 l= 13 prim: UTCTIME :950717233312Z
> 116:d=2 hl=2 l= 58 cons: SEQUENCE
> 118:d=3 hl=2 l= 11 cons: SET
> 120:d=4 hl=2 l= 9 cons: SEQUENCE
> 122:d=5 hl=2 l= 3 prim: OBJECT :countryName
> 127:d=5 hl=2 l= 2 prim: PRINTABLESTRING :AU
> 131:d=3 hl=2 l= 12 cons: SET
> 133:d=4 hl=2 l= 10 cons: SEQUENCE
> 135:d=5 hl=2 l= 3 prim: OBJECT :stateOrProvinceName
> 140:d=5 hl=2 l= 3 prim: PRINTABLESTRING :QLD
> 145:d=3 hl=2 l= 29 cons: SET
> 147:d=4 hl=2 l= 27 cons: SEQUENCE
> 149:d=5 hl=2 l= 3 prim: OBJECT :commonName
> 154:d=5 hl=2 l= 20 prim: PRINTABLESTRING :SSLeay/rsa test cert
> 176:d=2 hl=2 l= 92 cons: SEQUENCE
> 178:d=3 hl=2 l= 13 cons: SEQUENCE
> 180:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption
> 191:d=4 hl=2 l= 0 prim: NULL
> 193:d=3 hl=2 l= 75 prim: BIT STRING
> 270:d=1 hl=2 l= 12 cons: SEQUENCE
> 272:d=2 hl=2 l= 8 prim: OBJECT :md5
> 282:d=2 hl=2 l= 0 prim: NULL
> 284:d=1 hl=2 l= 65 prim: BIT STRING
>
> Here, the notBefore and notAfter are the following lines:
>
> 84:d=2 hl=2 l= 30 cons: SEQUENCE
> 86:d=3 hl=2 l= 13 prim: UTCTIME :950619233312Z
> 101:d=3 hl=2 l= 13 prim: UTCTIME :950717233312Z
>
> For visualization, this is the text form output of the same:
>
> : ; openssl x509 -in test/testx509.pem -dates -noout
> notBefore=Jun 19 23:33:12 1995 GMT
> notAfter=Jul 17 23:33:12 1995 GMT
>
> So now, for the encoding, RFC5280 has a few things to say
> (https://tools.ietf.org/html/rfc5280#section-4.1.2.5). However, for
> the dates you display, it should be easy, the should be the following:
>
> UTCTIME :091022132829Z
> UTCTIME :370308132829Z
>
> If you see something violently different (such as GeneralizedTime
> instead of UTCTIME), or the number of digits being wrong (12 for
> UTCTIME, 14 for GeneralizedTime), or there being something other than
> 'Z' at the end, then you know why you get that error.
>
> (I encoded those numbers manually, so I hope I got them right)
>
> Cheers,
> Richard
>
> On Mon, 04 Mar 2019 09:08:30 +0100,
> Wolfgang Knauf wrote:
>>
>> Hi,
>>
>> I first asked this question in the OpenVPNGui forum, and they redirected me to here: OpenVPNGui
>> 2.4.6 works with a customers server certificate, but it fails when using 2.4.7.
>>
>> Here is the thread in the OpenVPNGui forum: https://forums.openvpn.net/viewtopic.php?f=24&t=27976
>>
>> The error is:
>>
>> 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
>>
>> The customer provided us with a „…..ca.crt“ file, a „….user.crt“ file and a „user.key“ file. But I
>> fear it is not smart to post those files in the internet ;-).
>>
>>
as a follow-up: Richard's analysis/suspicion was spot on.
However, it was the *server* side certificate that was causing the
error, and the server certificate does indeed contain a poorly formatted
date:
$ 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
OpenSSL 1.0.x groks this, 1.1+ does not.
cheers,
JJK / Jan Just Keijser
More information about the openssl-users
mailing list