On Mon, Sep 12, 2016 at 10:47 AM, George Lane <gla...@thinkingguy.com> wrote: ... > Running a verify on either a server cert (whose key and CSR were > generated on OpenBSD, and cert signed on the Debian server) produces an > error about the notAfter field: > > $ openssl verify -CAfile root-ca.crt server.crt > server.crt: C = US, ST = Georgia, L = Atlanta, O = George Lane, CN = Ge > orge Lane Certificate Authority > error 14 at 1 depth lookup:format error in certificate's notAfter field ... > The root cert has an expiration date of Dec 31 23:59:59 2035 GMT. > Is there some reasons that this would not be an acceptable value?
That value is acceptable...when encoded as required. > If it helps, feel free to download a copy of my root cert here: > http://crt.thinkingguy.com/thinkingguy.com.crt : corwin; openssl asn1parse -in /tmp/thinkingguy.com.crt | grep -C1 TIME 148:d=2 hl=2 l= 32 cons: SEQUENCE 150:d=3 hl=2 l= 13 prim: UTCTIME :150815013107Z 165:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :20351231235959Z 182:d=2 hl=2 l= 115 cons: SEQUENCE : corwin; Note that the second time there, the "notAfter" value, is encoded as a GENERALIZEDTIME instead of a UTCTIME. We then turn to RFC 5280, section 4.1.2.5 where we find: 4.1.2.5. Validity The certificate validity period is the time interval during which the CA warrants that it will maintain information about the status of the-----BEGIN CERTIFICATE----- MIICpTCCAY2gAwIBAgIQAQeWnEdmlQvOdG3q61/ONDANBgkqhkiG9w0BAQsFADAP MQ0wCwYDVQQDDARteWNhMB4XDTE2MDkxMjE4Mzk0NloXDTM1MTIzMTE4Mzk0Nlow FjEUMBIGA1UEAwwLZXhwaXJlIHRlc3QwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBANl781Zxn+ifLNx/aBZl8K6Ep9MLdWdvnUinaxaZUl/zWC9jXuboJBXluJ9r cldyHaowG4GXBT6i2A+j/8qbEK88rzO/OTgvuePVTQoJA+UXvYueG0JvXBJdzZhb 5GYhqQaLwutVZK9ac31DRSD6eWG1amc53GIWU/iST0JsQ56PAgMBAAGjejB4MAkG A1UdEwQCMAAwCwYDVR0PBAQDAgWgMBEGCWCGSAGG+EIBAQQEAwIGwDAdBgNVHSUE FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwLAYDVR0RBCUwI4IbemVudm0wODgubGFi LnByb29mcG9pbnQuY29thwQKFjxYMA0GCSqGSIb3DQEBCwUAA4IBAQBj6gUfWEnO 7TrTki0EhsvLA01G04na4pQ+QHP1hBKnRv/bqs/afnDm5JVZh39MQV0tO4LtpF7F iAz20mJWsSF+yJvvm5RIQoUAn/JDF4lQEUyDV6wALLNMC3nEJAhpSscqRcZht4qW UDAieJk5A7Pv6TJX+zxi2/vR2JH7XpsoNhiErCMleJU2pPNzEr2MeBxDxvmUT/zH pcXypyT9fb95pVu1VCaV7AI4MM1lTivQNFW4uTqnNW3aRNMRMMAymWcHHsQUPu4T 2ndnB/w7xf8973nOLshboJLEGdMVxHVkvTcPsUppuphiNwDJJ5bfvRlKrPqFTPVF yJmxy+1yk41u -----END CERTIFICATE----- certificate. The field is represented as a SEQUENCE of two dates: the date on which the certificate validity period begins (notBefore) and the date on which the certificate validity period ends (notAfter). 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. The notAfter time is before 2050, so it MUST be encoded as a UTCTIME, but it isn't. You need to fix your CA software to generate RFC-compliant certificates when signing them. Philip Guenther
