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