While this is a valid date, it's not a proper format per RFC 5280:
Both notBefore and notAfter may be encoded as UTCTime or
GeneralizedTime.
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.
Changing the certificate generation to UTCTIME resolves the issue.
Issue observed during #48 .
The generated certificates for attestation don't validate with OpenSSL, due to a malformed notBefore field.
The issue is the use of GeneralizedTime for the NotBefore field, and is present from 2.8.3 to 3.3.3.
While this is a valid date, it's not a proper format per RFC 5280:
Changing the certificate generation to UTCTIME resolves the issue.