> Date: Sat, 6 Apr 2024 13:05:43 +0200
> From: Theo Buehler <tb@theobuehler.org>
> 
> > -----BEGIN CERTIFICATE-----
> > MIICPjCCAeSgAwIBAgIJAOy1+v/+I2WIMAoGCCqGSM49BAMCMDkxCzAJBgNVBAYT
> > Ak5MMRQwEgYDVQQKDAtQaGlsaXBzIEh1ZTEUMBIGA1UEAwwLcm9vdC1icmlkZ2Uw
> > IhgPMjAxNzAxMDEwMDAwMDBaGA8yMDM4MDExOTAzMTQwN1owPjELMAkGA1UEBhMC
> > TkwxFDASBgNVBAoMC1BoaWxpcHMgSHVlMRkwFwYDVQQDDBBlY2I1ZmFmZmZlMjM2
> > NTg4MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEAQMY8V0BUIhXtQfAwMPwqH+2
> > EyYnNCo9QhpPN93bJIWjppu0DyVUBzXY6rCyMD506mtSN4EsqH/3SHSPKnKD8KOB
> > yzCByDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggr
> > BgEFBQcDATAdBgNVHQ4EFgQU1s7ZbOFXYZSJLKhsXrPY072icg4wdAYDVR0jBG0w
> > a4AUZ2ONTFrDT6o8ItRnKfqWKnHFGmShPaQ7MDkxCzAJBgNVBAYTAk5MMRQwEgYD
> > VQQKDAtQaGlsaXBzIEh1ZTEUMBIGA1UEAwwLcm9vdC1icmlkZ2WCFDuxUi22sYpL
> > lwJY81Wrqy11phcOMAoGCCqGSM49BAMCA0gAMEUCIQCdQ2Sfn2t+OBGzDkB59OQO
> > 6YWwvJ66Q/VZoOyQaCsd3QIgNxpIOEJK3Tk3NTTfCkQOB+vTm285dgGNQ+5Ps3EL
> > Ni4=
> > -----END CERTIFICATE-----
> 
> This cert is malformed (as is the CA cert that sthen dug up).
> The notBefore and notAfter are before 2050:
> 
> $ openssl x509 -in /tmp/ku.pem -dates -noout
> notBefore=Jan  1 00:00:00 2017 GMT
> notAfter=Jan 19 03:14:07 2038 GMT
> 
> This means they should be encoded as UTCTime per RFC 5280. However,
> they are encoded as a GeneralizedTime:
> 
> $ openssl asn1parse -i -in /tmp/ku.pem | grep GEN
>    97:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20170101000000Z
>   114:d=3  hl=2 l=  15 prim:    GENERALIZEDTIME   :20380119031407Z

To quote RFC5280:

  CAs conforming to this profile MUST always encode certificate
  validity dates through the year 2049 as UTCTime; certificate validity
  dates in 2050 or later MUST be encoded as GeneralizedTime.
  Conforming applications MUST be able to process validity dates that
  are encoded in either UTCTime or GeneralizedTime.

One possible interpretation of this is that while certs are required
to use UTCTime in this case, the application is still required to
accept GeneralizedTime.

I can certainly see the benefits of such an approach when phasing in a
new construction like GeneralizedTime as it allows new certs to
continue to work with old implementations that are not able to process
validaty dates that are encoded in GeneralizedTime.  And therefore
totally accept that this was the intent of this contradictory language
in the RFC.

So I think that unless there are good reasons not to, LibreSSL should
accept GeneralizedTime in this context.