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-bounces at 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+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: 
>> 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<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 
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