OpenVPNGui 2.4.7 fails: format error in certificate's notAfter field

Thu Mar 7 10:35:10 UTC 2019

Bonjour,

Here, reject the certificate is the correct behaviour, IMO.

UTCTime/GeneralizedTime are defined in X.680.

UTCTime:
 - can have no timezone information, or have Z, of have a timezone offset (with hours and minutes)
 - can be precise up to the second, or be precise up to the minute
 - cannot have fractional seconds or minutes
 - cannot have second 60 (think of leap seconds) 
 - is not subject to ISO8601 rules

GeneralizedTime:
 - can have no timezone information, or have Z, of have a timezone offset (either hours, or hours and minutes)
 - can be precise up to the second with optional fractional seconds, or be precise up to the minute and have fractional minutes, or be precise up to the hour and have fractional hours (any number of decimal places)
 - shall follow ISO8601 rules (including leap seconds)
 - cannot support the "midnight at end of day" (240000)

DER encoding (X.690) of these elements have of course stricter requirements:
 - the timezone shall be present and consist of Zulu time (Z), for UTC
 - the date/time shall be precise up to the second
 - if any fractional second is present, any trailing zero shall be omitted, and if there is no more decimal place, the trailing dot shall also be omitted

So in this case, the UTCTIME element containing "370308132808+0000" is not a valid DER encoding. That's not an RFC5280/X.509 difference.

There was a debate wether the tbsCertificate shall always be DER encoded or can be BER encoded and have the signature match the DER encoding, but it was closed from the ITU-T point of view in 1997 and first edition of X.509v3, by defining the SIGNED{} and SIGNATURE{} parameterized types and have additional text describing precisely the behaviour to adopt as a sender and receiver (first in clause 9, then moved to clause 6.1 in 2000, and clause 6.4 in 2012).
RFC5280 is far from being that clear.

OpenSSL added some checks on GeneralizedTime/UTCTime, by enforcing RFC5280 rules. I haven't followed the source code to see if these checks also apply to data types other than RFC5280 certificates (RFC5652 CMS signingTime attribute, RFC3161 timestamps, RFC6960 OCSP responses, ...). I remember having debated regarding the support of leap seconds on GitHub, and it seems that second 60 is not supported at all (even if for a certified/qualiied timestamping service, that second can exist and is supposed to be produced).

Cordialement,
Erwann Abalea

Le 06/03/2019 16:38, « openssl-users au nom de Jakob Bohm via openssl-users » <openssl-users-bounces at openssl.org au nom de openssl-users at openssl.org> a écrit :

    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.

    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