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
