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@xxxxxxxxxxx] 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
