Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi Erwann,

On 07/03/19 11:35, Erwann Abalea via openssl-users wrote:

Bonjour,

Here, reject the certificate is the correct behaviour, IMO.

UTCTime/GeneralizedTime are defined in X.680.

UTCTime:
  - can have no timezone information, or have Z, of have a timezone offset 
(with hours and minutes)
  - can be precise up to the second, or be precise up to the minute
  - cannot have fractional seconds or minutes
  - cannot have second 60 (think of leap seconds)
  - is not subject to ISO8601 rules

GeneralizedTime:
  - can have no timezone information, or have Z, of have a timezone offset 
(either hours, or hours and minutes)
  - can be precise up to the second with optional fractional seconds, or be 
precise up to the minute and have fractional minutes, or be precise up to the 
hour and have fractional hours (any number of decimal places)
  - shall follow ISO8601 rules (including leap seconds)
  - cannot support the "midnight at end of day" (24)



thanks for the clarification and note that either way it's fine with me 
- I just wanted to know what message to tell to OpenVPN users who run 
into this issue. The 'correct' answer seems to be:


"Your certificate is invalid and was always invalid, but up til now 
OpenSSL grokked it.  OpenSSL (and therefore OpenVPN) no longer likes 
your cert, so get a new one"


cheers,

JJK / Jan Just Keijser

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Erwann Abalea via openssl-users]

Bonjour,

Here, reject the certificate is the correct behaviour, IMO.

UTCTime/GeneralizedTime are defined in X.680.

UTCTime:
 - can have no timezone information, or have Z, of have a timezone offset (with 
hours and minutes)
 - can be precise up to the second, or be precise up to the minute
 - cannot have fractional seconds or minutes
 - cannot have second 60 (think of leap seconds) 
 - is not subject to ISO8601 rules

GeneralizedTime:
 - can have no timezone information, or have Z, of have a timezone offset 
(either hours, or hours and minutes)
 - can be precise up to the second with optional fractional seconds, or be 
precise up to the minute and have fractional minutes, or be precise up to the 
hour and have fractional hours (any number of decimal places)
 - shall follow ISO8601 rules (including leap seconds)
 - cannot support the "midnight at end of day" (24)


DER encoding (X.690) of these elements have of course stricter requirements:
 - the timezone shall be present and consist of Zulu time (Z), for UTC
 - the date/time shall be precise up to the second
 - if any fractional second is present, any trailing zero shall be omitted, and 
if there is no more decimal place, the trailing dot shall also be omitted

So in this case, the UTCTIME element containing "370308132808+" is not a 
valid DER encoding. That's not an RFC5280/X.509 difference.

There was a debate wether the tbsCertificate shall always be DER encoded or can 
be BER encoded and have the signature match the DER encoding, but it was closed 
from the ITU-T point of view in 1997 and first edition of X.509v3, by defining 
the SIGNED{} and SIGNATURE{} parameterized types and have additional text 
describing precisely the behaviour to adopt as a sender and receiver (first in 
clause 9, then moved to clause 6.1 in 2000, and clause 6.4 in 2012).
RFC5280 is far from being that clear.


OpenSSL added some checks on GeneralizedTime/UTCTime, by enforcing RFC5280 
rules. I haven't followed the source code to see if these checks also apply to 
data types other than RFC5280 certificates (RFC5652 CMS signingTime attribute, 
RFC3161 timestamps, RFC6960 OCSP responses, ...). I remember having debated 
regarding the support of leap seconds on GitHub, and it seems that second 60 is 
not supported at all (even if for a certified/qualiied timestamping service, 
that second can exist and is supposed to be produced).


Cordialement,
Erwann Abalea

Le 06/03/2019 16:38, « openssl-users au nom de Jakob Bohm via openssl-users » 
 a écrit 
:

On 06/03/2019 16:17, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf 
Of
>> Richard Levitte
>> Sent: Wednesday, March 06, 2019 03:07
>>
>> On Wed, 06 Mar 2019 10:52:44 +0100,
>> Jan Just Keijser wrote:
>>> 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+
>> I'm glad I could help find the answer.
>>
>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>> Yup, 1.1+ is stricter regarding these things.
> I would have expected 1.0.2p and later to have rejected this as well, 
since the RFC 5280 restrictions on validity date attributes were included in 
that release. There was some discussion about it on the OpenSSL lists, with 
some people suggesting that a change to insist on the letter of the standard 
which broke compatibility with certificates generated by some other 
implementations was not a great idea. (I am sympathetic to this argument 
myself, and feel there should at least be an option to relax these 
restrictions.)
>
> See for example: 
https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
>
> It's interesting to note that back in 2009 when GeneralizedTime support 
for X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 
is only a profile of X.509, and X.509 itself allows timezone offsets and 
fracttional seconds, and so arguably OpenSSL ought to allow them too 
(presumably for use by non-TLS X.509 applications). (See e.g. 
http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.)
 Personally, I find that argument persuasive too, and think that it would be 
appropriate to have a mechanism to disable the 5280 checks.
>
> Maybe I'll put together a PR, though I don't know if it has much chance 
of being accepted.
>

RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
can't be for SSL versions before it), only for the publicly
trusted certificates used on the global Internet.  So arguably,
it should 

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi all,

On 06/03/19 16:36, Jakob Bohm via openssl-users wrote:

On 06/03/2019 16:17, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On 
Behalf Of

Richard Levitte
Sent: Wednesday, March 06, 2019 03:07

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:

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+

I'm glad I could help find the answer.


OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.
I would have expected 1.0.2p and later to have rejected this as well, 
since the RFC 5280 restrictions on validity date attributes were 
included in that release. There was some discussion about it on the 
OpenSSL lists, with some people suggesting that a change to insist on 
the letter of the standard which broke compatibility with 
certificates generated by some other implementations was not a great 
idea. (I am sympathetic to this argument myself, and feel there 
should at least be an option to relax these restrictions.)


See for example: 
https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html


It's interesting to note that back in 2009 when GeneralizedTime 
support for X.509 dates was added to OpenSSL, Erwann Abalea pointed 
out that RFC 5280 is only a profile of X.509, and X.509 itself allows 
timezone offsets and fracttional seconds, and so arguably OpenSSL 
ought to allow them too (presumably for use by non-TLS X.509 
applications). (See e.g. 
http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.) 
Personally, I find that argument persuasive too, and think that it 
would be appropriate to have a mechanism to disable the 5280 checks.


Maybe I'll put together a PR, though I don't know if it has much 
chance of being accepted.




RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
can't be for SSL versions before it), only for the publicly
trusted certificates used on the global Internet.  So arguably,
it should not apply to running TLS between closely related
parties (as is the traditional use case for something
like OpenVPN).

Running a private protocol over TLS between my server in one
building and my server in another building doesn't involve
the WebPKI.

It is of cause prudent for libraries to produce RFC5280
compliant certificates by default, and for test tools
(such as the "openssl x509" and "openssl validate"
commands) to warn when a certificate is outside the
standards for public certificates.


so to recapitulate:
- OpenSSL 1.1+ (and possible 1.0.2) introduced stricter RFC5280 
checks when doing certificate validation
- This causes certificates that contain fields that are not fully 
RFC5280 compliant to fail validation
- However, as Jakob states, there is no requirement in TLS for RFC5280 
compliance


Should this be considered a bug in OpenSSL then? If this is not 
considered a bug, shouldn't OpenSSL then state this as a requirement for 
certificate creaton?


Of course, the easy solution is to tell people to create and use RFC5280 
compliant certificates, but what if someone has a legitimate use case 
for not being able or wanting to do so?
Is there a way to loosen the verification checks (apart from writing a 
custom verify_callback) ?


thanks for any advice,

JJK / Jan Just Keijser

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jakob Bohm via openssl-users]

On 06/03/2019 16:17, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Richard Levitte
Sent: Wednesday, March 06, 2019 03:07

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:

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+

I'm glad I could help find the answer.


OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.

I would have expected 1.0.2p and later to have rejected this as well, since the 
RFC 5280 restrictions on validity date attributes were included in that 
release. There was some discussion about it on the OpenSSL lists, with some 
people suggesting that a change to insist on the letter of the standard which 
broke compatibility with certificates generated by some other implementations 
was not a great idea. (I am sympathetic to this argument myself, and feel there 
should at least be an option to relax these restrictions.)

See for example: 
https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html

It's interesting to note that back in 2009 when GeneralizedTime support for 
X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is 
only a profile of X.509, and X.509 itself allows timezone offsets and 
fracttional seconds, and so arguably OpenSSL ought to allow them too 
(presumably for use by non-TLS X.509 applications). (See e.g. 
http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.)
 Personally, I find that argument persuasive too, and think that it would be 
appropriate to have a mechanism to disable the 5280 checks.

Maybe I'll put together a PR, though I don't know if it has much chance of 
being accepted.



RFC5280 etc. is not even a requirement for SSL/TLS (it certainly
can't be for SSL versions before it), only for the publicly
trusted certificates used on the global Internet.  So arguably,
it should not apply to running TLS between closely related
parties (as is the traditional use case for something
like OpenVPN).

Running a private protocol over TLS between my server in one
building and my server in another building doesn't involve
the WebPKI.

It is of cause prudent for libraries to produce RFC5280
compliant certificates by default, and for test tools
(such as the "openssl x509" and "openssl validate"
commands) to warn when a certificate is outside the
standards for public certificates.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Blumenthal, Uri - 0553 - MITLL]

Since OpenSSL is more than just a TLS implementation, I agree with Michael and 
support relaxing these checks when appropriate.

Regards,
Uri

Sent from my iPhone

On Mar 6, 2019, at 10:22, Michael Wojcik  wrote:

>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Richard Levitte
>> Sent: Wednesday, March 06, 2019 03:07
>> 
>> On Wed, 06 Mar 2019 10:52:44 +0100,
>> Jan Just Keijser wrote:
>>> 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+
>> 
>> I'm glad I could help find the answer.
>> 
>>> OpenSSL 1.0.x groks this, 1.1+ does not.
>> 
>> Yup, 1.1+ is stricter regarding these things.
> 
> I would have expected 1.0.2p and later to have rejected this as well, since 
> the RFC 5280 restrictions on validity date attributes were included in that 
> release. There was some discussion about it on the OpenSSL lists, with some 
> people suggesting that a change to insist on the letter of the standard which 
> broke compatibility with certificates generated by some other implementations 
> was not a great idea. (I am sympathetic to this argument myself, and feel 
> there should at least be an option to relax these restrictions.)
> 
> See for example: 
> https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html
> 
> It's interesting to note that back in 2009 when GeneralizedTime support for 
> X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is 
> only a profile of X.509, and X.509 itself allows timezone offsets and 
> fracttional seconds, and so arguably OpenSSL ought to allow them too 
> (presumably for use by non-TLS X.509 applications). (See e.g. 
> http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.)
>  Personally, I find that argument persuasive too, and think that it would be 
> appropriate to have a mechanism to disable the 5280 checks.
> 
> Maybe I'll put together a PR, though I don't know if it has much chance of 
> being accepted.
> 
> -- 
> Michael Wojcik 
> Distinguished Engineer, Micro Focus 
> 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

RE: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Richard Levitte
> Sent: Wednesday, March 06, 2019 03:07
> 
> On Wed, 06 Mar 2019 10:52:44 +0100,
> Jan Just Keijser wrote:
> > 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+
> 
> I'm glad I could help find the answer.
> 
> > OpenSSL 1.0.x groks this, 1.1+ does not.
> 
> Yup, 1.1+ is stricter regarding these things.

I would have expected 1.0.2p and later to have rejected this as well, since the 
RFC 5280 restrictions on validity date attributes were included in that 
release. There was some discussion about it on the OpenSSL lists, with some 
people suggesting that a change to insist on the letter of the standard which 
broke compatibility with certificates generated by some other implementations 
was not a great idea. (I am sympathetic to this argument myself, and feel there 
should at least be an option to relax these restrictions.)

See for example: 
https://mta.openssl.org/pipermail/openssl-project/2018-August/000984.html

It's interesting to note that back in 2009 when GeneralizedTime support for 
X.509 dates was added to OpenSSL, Erwann Abalea pointed out that RFC 5280 is 
only a profile of X.509, and X.509 itself allows timezone offsets and 
fracttional seconds, and so arguably OpenSSL ought to allow them too 
(presumably for use by non-TLS X.509 applications). (See e.g. 
http://openssl.6102.n7.nabble.com/openssl-org-1854-GeneralizedTime-support-in-openssl-ca-td38848.html.)
 Personally, I find that argument persuasive too, and think that it would be 
appropriate to have a mechanism to disable the 5280 checks.

Maybe I'll put together a PR, though I don't know if it has much chance of 
being accepted.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 

AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Wolfgang Knauf]

Many thanks to all of you for your help! Sorry for posting those basic 
questions, but I was helpless - I am just a VPN client user, with not much 
knowledge of SSL :-(.

I forwarded the problem to our customer. Hopefully, they have more knowledge 
than me about certificates ;-).

Best regards

Wolfgang

-Ursprüngliche Nachricht-
Von: openssl-users  Im Auftrag von Richard 
Levitte
Gesendet: Mittwoch, 6. März 2019 11:07
An: openssl-users@openssl.org
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter 
field

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
> 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+

I'm glad I could help find the answer.

> OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Richard Levitte]

On Wed, 06 Mar 2019 10:52:44 +0100,
Jan Just Keijser wrote:
> 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+

I'm glad I could help find the answer.

> OpenSSL 1.0.x groks this, 1.1+ does not.

Yup, 1.1+ is stricter regarding these things.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

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

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Hubert Kario]

On Monday, 4 March 2019 15:20:36 CET Jan Just Keijser wrote:
> Hi Matt,
> 
> On 04/03/19 14:24, Matt Caswell wrote:
> > On 04/03/2019 13:16, Jan Just Keijser wrote:
> >> On 04/03/19 10:21, Wolfgang Knauf wrote:
> >>> Hi,
> >>> 
> >>> the output is this:
> >>> 
> >>> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
> >>> ..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.
> >>> crt
> >>> Error: offset too large
> >>> 
> >>> Would it be OK if I send the crt file to only your mail adress? I don't
> >>> feel save by posting it to the mailing list ;-)?
> >> 
> >> I ran into the "offset too large" problem myself with my own certs as
> >> well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the
> >> parts starting with --BEGIN CERTIFICATE--
> > 
> > asn1parse will expect PEM by default but is perfectly capable of
> > processing raw DER too. Just use the "-inform DER" option.
> 
> 100% true but that is not what I was referring to; my certs usually look
> like this:
> 
> Certificate:
>  Data:
>  Version: 3 (0x2)
>  Serial Number: 5338 (0x14da)
>  Signature Algorithm: sha256WithRSAEncryption
> [...]
> -BEGIN CERTIFICATE-
> MIIEmjCCA4KgAwIBAgICFNowDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx
> 
> 
> it's that part *before* the --BEGIN CERTIFICATE--  on which the
> asn1parse command chokes. You can feed it either a DER file or a PEM
> blob - but not a certificate file with the certificate info listed in it.

ah, yes, that's https://github.com/openssl/openssl/issues/7317

that should be possible to workaround with -strictpem option

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi Matt,

On 04/03/19 14:24, Matt Caswell wrote:


On 04/03/2019 13:16, Jan Just Keijser wrote:

On 04/03/19 10:21, Wolfgang Knauf wrote:

Hi,

the output is this:

C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.crt
Error: offset too large

Would it be OK if I send the crt file to only your mail adress? I don't feel
save by posting it to the mailing list ;-)?



I ran into the "offset too large" problem myself with my own certs as well. It
turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting
with --BEGIN CERTIFICATE--

asn1parse will expect PEM by default but is perfectly capable of processing raw
DER too. Just use the "-inform DER" option.


100% true but that is not what I was referring to; my certs usually look 
like this:


Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number: 5338 (0x14da)
    Signature Algorithm: sha256WithRSAEncryption
[...]
-BEGIN CERTIFICATE-
MIIEmjCCA4KgAwIBAgICFNowDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCTkwx


it's that part *before* the --BEGIN CERTIFICATE--  on which the 
asn1parse command chokes. You can feed it either a DER file or a PEM 
blob - but not a certificate file with the certificate info listed in it.


JJK

AW: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Wolfgang Knauf]

Might the reason for this error be some server certificate that I don't have 
locally but that is downloaded/checked during the OpenVPNGui connection?

Sorry is this is a dumb questions, but I am just a user of OpenVPNGui and don't 
have knowledge about the internals...

Wolfgang

-Ursprüngliche Nachricht-
Von: Jan Just Keijser  
Gesendet: Montag, 4. März 2019 14:16
An: Wolfgang Knauf ; openssl-users@openssl.org
Betreff: Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter 
field

On 04/03/19 10:21, Wolfgang Knauf wrote:
> Hi,
>
> the output is this:
>
> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in 
> ..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.use
> r.crt
> Error: offset too large
>
> Would it be OK if I send the crt file to only your mail adress? I don't feel 
> save by posting it to the mailing list ;-)?
>
>
I ran into the "offset too large" problem myself with my own certs as well. It 
turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting 
with --BEGIN CERTIFICATE--

You can use
   openssl x509 -in l1139218.vt-security.de.user.crt -out | openssl ans1parse 
to work around this.
For your certificates this results in

     0:d=0  hl=4 l= 942 cons: SEQUENCE
     4:d=1  hl=4 l= 791 cons: SEQUENCE
     8:d=2  hl=2 l=   3 cons: cont [ 0 ]
    10:d=3  hl=2 l=   1 prim: INTEGER   :02
    13:d=2  hl=2 l=   9 prim: INTEGER   :C604316CD0321FA1
    24:d=2  hl=2 l=  13 cons: SEQUENCE
    26:d=3  hl=2 l=   9 prim: OBJECT :sha256WithRSAEncryption
    37:d=3  hl=2 l=   0 prim: NULL
[...]
   155:d=2  hl=2 l=  30 cons: SEQUENCE
   157:d=3  hl=2 l=  13 prim: UTCTIME   :160418140054Z
   172:d=3  hl=2 l=  13 prim: UTCTIME   :370308132808Z
   187:d=2  hl=2 l=  88 cons: SEQUENCE
   189:d=3  hl=2 l=  11 cons: SET
   191:d=4  hl=2 l=   9 cons: SEQUENCE
   193:d=5  hl=2 l=   3 prim: OBJECT    :countryName
   198:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :de

In other words, the dates look OK to me.
Also, I've thrown my own verification code against the certificate and 
everything checks out OK.
I'll see if I can reproduce the issue in my own OpenVPN setup.

HTH,

JJK / Jan Just Keijser

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Matt Caswell]

On 04/03/2019 13:16, Jan Just Keijser wrote:
> On 04/03/19 10:21, Wolfgang Knauf wrote:
>> Hi,
>>
>> the output is this:
>>
>> C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in
>> ..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.crt
>> Error: offset too large
>>
>> Would it be OK if I send the crt file to only your mail adress? I don't feel
>> save by posting it to the mailing list ;-)?
>>
>>
> I ran into the "offset too large" problem myself with my own certs as well. It
> turns out the 'asn1parse' util only likes PEM blobs, i.e. the parts starting
> with --BEGIN CERTIFICATE--

asn1parse will expect PEM by default but is perfectly capable of processing raw
DER too. Just use the "-inform DER" option.

Matt

Re: AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

On 04/03/19 10:21, Wolfgang Knauf wrote:

Hi,

the output is this:

C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in 
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.crt
Error: offset too large

Would it be OK if I send the crt file to only your mail adress? I don't feel 
save by posting it to the mailing list ;-)?


I ran into the "offset too large" problem myself with my own certs as 
well. It turns out the 'asn1parse' util only likes PEM blobs, i.e. the 
parts starting with --BEGIN CERTIFICATE--


You can use
  openssl x509 -in l1139218.vt-security.de.user.crt -out | openssl 
ans1parse

to work around this.
For your certificates this results in

    0:d=0  hl=4 l= 942 cons: SEQUENCE
    4:d=1  hl=4 l= 791 cons: SEQUENCE
    8:d=2  hl=2 l=   3 cons: cont [ 0 ]
   10:d=3  hl=2 l=   1 prim: INTEGER   :02
   13:d=2  hl=2 l=   9 prim: INTEGER   :C604316CD0321FA1
   24:d=2  hl=2 l=  13 cons: SEQUENCE
   26:d=3  hl=2 l=   9 prim: OBJECT :sha256WithRSAEncryption
   37:d=3  hl=2 l=   0 prim: NULL
[...]
  155:d=2  hl=2 l=  30 cons: SEQUENCE
  157:d=3  hl=2 l=  13 prim: UTCTIME   :160418140054Z
  172:d=3  hl=2 l=  13 prim: UTCTIME   :370308132808Z
  187:d=2  hl=2 l=  88 cons: SEQUENCE
  189:d=3  hl=2 l=  11 cons: SET
  191:d=4  hl=2 l=   9 cons: SEQUENCE
  193:d=5  hl=2 l=   3 prim: OBJECT    :countryName
  198:d=5  hl=2 l=   2 prim: PRINTABLESTRING   :de

In other words, the dates look OK to me.
Also, I've thrown my own verification code against the certificate and 
everything checks out OK.

I'll see if I can reproduce the issue in my own OpenVPN setup.

HTH,

JJK / Jan Just Keijser

AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Wolfgang Knauf]

Here is the output:

C:\Program Files\OpenVPN\bin>openssl.exe verify -trusted 
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.ca.crt 
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.crt
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.crt: OK

But it seems I don't have the root certificate, just the CA certificate?

I will send both certificate files in another mail.

Wolfgang

-Ursprüngliche Nachricht-
Von: openssl-users  Im Auftrag von Jan Just 
Keijser
Gesendet: Montag, 4. März 2019 10:36
An: Richard Levitte ; openssl-users@openssl.org
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter 
field

Hi Richard,

On 04/03/19 10:27, Richard Levitte wrote:
> On Mon, 04 Mar 2019 10:06:54 +0100,
> Jan Just Keijser wrote:
> ...
>> Having said that, I just created a certificate set to expire on Mar 9 
>> 2037 and it passed the following command:
>>    c:\program files\openvpn\bin\openssl x509 -dates -subject -noout 
>> -in mycert.crt
>>
>> can you run the same command on the failing certificate?
> That's a poor test.  'openssl x509' doesn't verify the certificate, 
> and the error comes up during verification.  To verify, use 'openssl 
> verify'.  Here's an example with OpenSSL test files:
>
>  openssl verify -trusted test/certs/root-cert.pem 
> test/certs/ca-cert.pem
>
> So in Wolfgang's case, I suspect something like this would say more:
>
>  openssl verify -trusted .ca.crt .user.crt
>

you were one step ahead of me :)
I fully agree that it is a poor test, I was just wondering if there was an 
encoding error in the cert itself, esp as the EndDate approaches the 32bit 
epoch...

Wolfgang, can you send me both the client cert and the CA cert that goes with 
it? both are public info.

cheers,

JJK / Jan Just Keijser

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi Richard,

On 04/03/19 10:27, Richard Levitte wrote:

On Mon, 04 Mar 2019 10:06:54 +0100,
Jan Just Keijser wrote:
...

Having said that, I just created a certificate set to expire on Mar 9 2037 and 
it passed the
following command:
   c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in 
mycert.crt

can you run the same command on the failing certificate?

That's a poor test.  'openssl x509' doesn't verify the certificate,
and the error comes up during verification.  To verify, use 'openssl
verify'.  Here's an example with OpenSSL test files:

 openssl verify -trusted test/certs/root-cert.pem test/certs/ca-cert.pem

So in Wolfgang's case, I suspect something like this would say more:

 openssl verify -trusted .ca.crt .user.crt



you were one step ahead of me :)
I fully agree that it is a poor test, I was just wondering if there was 
an encoding error in the cert itself, esp as the EndDate approaches the 
32bit epoch...


Wolfgang, can you send me both the client cert and the CA cert that goes 
with it? both are public info.


cheers,

JJK / Jan Just Keijser

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Richard Levitte]

On Mon, 04 Mar 2019 10:06:54 +0100,
Jan Just Keijser wrote:
...
> Having said that, I just created a certificate set to expire on Mar 9 2037 
> and it passed the
> following command:
>   c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in 
> mycert.crt
> 
> can you run the same command on the failing certificate?

That's a poor test.  'openssl x509' doesn't verify the certificate,
and the error comes up during verification.  To verify, use 'openssl
verify'.  Here's an example with OpenSSL test files:

openssl verify -trusted test/certs/root-cert.pem test/certs/ca-cert.pem 

So in Wolfgang's case, I suspect something like this would say more:

openssl verify -trusted .ca.crt .user.crt

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Wolfgang Knauf]

Hi,

this is the output of "-dates":

C:\Program Files\OpenVPN\bin>openssl.exe x509 -dates -subject -noout -in 
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.ca.crt
notBefore=Oct 22 13:28:29 2009 GMT
notAfter=Mar  8 13:28:29 2037 GMT
subject=C = de, L = Dortmund, O = Versatel, CN = Versatel VPN CA, emailAddress 
= ad...@vt-security.de


Would it be OK if I send the crt file to only your mail adress? I don't feel 
save by posting it to the mailing list ;-)?

Best regards

Wolfgang

Von: Jan Just Keijser 
Gesendet: Montag, 4. März 2019 10:07
An: Wolfgang Knauf ; openssl-users@openssl.org
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter 
field

Hi,

On 04/03/19 09:08, 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=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 
;-).


you can safely post the client.crt file - it is public info and useless without 
the key file.

Having said that, I just created a certificate set to expire on Mar 9 2037 and 
it passed the following command:
  c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in 
mycert.crt

can you run the same command on the failing certificate?

HTH,

JJK / Jan Just Keijser

AW: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Wolfgang Knauf]

Hi,

the output is this:

C:\Program Files\OpenVPN\bin>openssl.exe asn1parse -i -in 
..\config\ssl_h...@l1139218.vt-security.de\l1139218.vt-security.de.user.crt
Error: offset too large

Would it be OK if I send the crt file to only your mail adress? I don't feel 
save by posting it to the mailing list ;-)?

I did not try to convert the date - still have the hope that it is an OpenSSL 
issue and can be fixed there ;-).

Best regards

Wolfgang

 
-Ursprüngliche Nachricht-
Von: openssl-users  Im Auftrag von Richard 
Levitte
Gesendet: Montag, 4. März 2019 10:02
An: openssl-users@openssl.org
Betreff: Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter 
field

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 
> 

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Jan Just Keijser]

Hi,

On 04/03/19 09:08, 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=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 ;-).




you can safely post the client.crt file - it is public info and useless without 
the key file.

Having said that, I just created a certificate set to expire on Mar 9 2037 and 
it passed the following command:
  c:\program files\openvpn\bin\openssl x509 -dates -subject -noout -in 
mycert.crt

can you run the same command on the failing certificate?

HTH,

JJK / Jan Just Keijser

Re: OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

[Richard Levitte]

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

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

[Wolfgang Knauf]

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=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 
;-).

Best regards

Wolfgang