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

Jan Just Keijser janjust at
Thu Mar 7 07:29:59 UTC 2019

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-bounces at] 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+0000
>>> 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: 
>> 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. 
>> 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<X>) 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 

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

More information about the openssl-users mailing list