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 <michael.woj...@microfocus.com> 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. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > >
smime.p7s
Description: S/MIME cryptographic signature
