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+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.
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
