1085238 - sec_error_expired_certificate when notAfter/notBefore times have timezone encoded as anything other than "Z"

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Strauss]

Attachment: (Error) Firefox-OpenSSL-with-StartDate,EndDate.png

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2188.2 Safari/537.36

Steps to reproduce:

Running an internal PKI (2-tier each of RSA/SHA1, ECC, RSA/SHA2); 
Generated the root certificates and subordinate certificates with OpenSSL and LibreSSL (prerelease) and the signing command similar to:
openssl ca -config etc/rsa-root-ca.conf -notext -in certs/csr/rsa-server.example.com.spectime.csr -out certs/rsa-server.example.com.spectime.crt -extensions server_ext -startdate 20141020085854+0200 -enddate 20151021085854+0200 


Actual results:

The following error is displayed:
The certificate will not be valid until 20/10/2014 08:58. The current time is 20/10/2014 09:11. (Error code: sec_error_expired_certificate)


Expected results:

The same as when -starttime and -enddate are omitted: Firefox should trust validate the certificate and not claim a date is not within the validity period of the certificate.

This seems to be an issue all the way up through nightly builds.

Comment 1

[Strauss]

Attachment: (Working) Firefox-OpenSSL-without-StartDate,EndDate.png

Comment 2

[Strauss]

This may well be an OpenSSL-rooted issue: If I drop the time-zone and convert to Zulu Time manually (as seems to be suggested in RFC 5280 {S} 4.1.2.5), the generated certificate(s) validate correctly. My suspicion is that the generated certificate has an invalid encoding for notBefore and notAfter if startdate and enddate are used with a time zone (ref: OpenSSL bug #2990).

Thus the Steps to Reproduce becomes:

openssl ca -config etc/rsa-root-ca.conf -notext -in certs/csr/rsa-server.example.com.spectime.csr -out certs/rsa-server.example.com.spectime.crt -extensions server_ext -startdate 20141020065854Z -enddate 20151021065854Z 

which works fine.

I'll see if I can find an ASN.1 raw parser, so I can extract the raw values from the certificates, to confirm this. I expect that this bug may be marked INVALID, but any second pair of eyes to confirm that would be appreciated.

Comment 3

[Strauss]

Indeed, `openssl asn1parse < bad_cert.crt` shows great variation depending on how the certificate was generated.

[noSDED: parameters omitted; YYSDED: specified as YYMM...(no zone); CCYYSDED+0200: specified as  CCYY...+0200]

		Works	DateFormat	Zone
noSDED		1	UTCTime		Z(ulu)
YYSDED		0	UTCTime		(none)
CCYYSDED	1	GeneralizedTime	Z(ulu)
YYSDED+0200	0	UTCTime		+0200
CCYYSDED+0200	0	GeneralizedTime	+0200

Most interestingly, the YYMM StartDate and EndDate generates a certificate which shows blank dates in the error message and certificate viewer, so this must be a certificate generation error. It shows similar validation errors in Chrome Unstable (v40) on Linux, but Windows 7 x64 (using CryptoAPI) validates the certificate fine under IE11 and Chrome (with intended dates showing correctly).

I'm happy for this bug to be closed, though I would request the error message could just be revised to mention an unparseable certificate (as a "WOW-feature", showing dubously parsed fields in the Certificate Viewer), since this took quite a while to pin down to the openssl command used to generate the signature over the root certificate. 

I will be figuring out the OpenBSD bug reporting system next (for LibreSSL). :)

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Now mozilla::pkix enforces the requirement that the timezone always be specified as "Z":

   For the purposes of this profile, UTCTime values MUST be expressed in
   Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are
   YYMMDDHHMMSSZ), even where the number of seconds is zero.

   [...]

   For the purposes of this profile, GeneralizedTime values MUST be
   expressed in Greenwich Mean Time (Zulu) and MUST include seconds
   (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds
   is zero.  GeneralizedTime values MUST NOT include fractional seconds.

Comment 5

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Thanks for the excellent bug reporting and investigation. You are exactly right. Because we're not getting a lot of compatibility bug reports about this, and because you seem to have worked out a solution, I'm going to resolve this as INVALID, which means "works as intended." Thanks for the bug report, and if you notice other issues, please report them! Too many bug reports is better than not enough!