sec_error_expired_certificate while certificate dates are valid




4 years ago
4 years ago


(Reporter: mdn, Unassigned)


33 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



4 years ago
Created attachment 8527879 [details]
Server certificate (top) and CA certificate (bottom)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141013200110

Steps to reproduce:

I had CSRs signed with my CA and e.g. these dates:

            Not Before: Oct 12 22:00:00 2013 GMT
            Not After : Dec 31 23:00:00 2015 GMT

like so: openssl ca -config openssl.cnf -name ServerCerts -in sever.csr -out server.crt -startdate 131012230000Z -enddate 151231230000Z

and installed these certificates on my server host.

When I go to (or or a "This Connection is Untrusted" page appears.
The same procedure with e.g. does NOT show this behaviour.

Actual results:

I receive a "Error code: sec_error_expired_certificate" and an error message "The certificate will not be valid until 13.10.2013 00:00. The current time is 24.11.2014 21:08." on different machines, all running x86_64 Ubuntu 14.04 or Windows 7 (version 33.1).

I am not exactly sure, but these certificates were verified correctly up to Firefox version 32 or 31. At least these certificates did work for a longer period of time.

Expected results:

The certificate should have been validated as other certificates issued by the same CA.

Comment 1

4 years ago
this report might be the same as bug 1085238

the regression range for this issue is, so it's likely bug 1019770 orignally causing it...

Comment 2

4 years ago
Is currently not verified:
$ openssl asn1parse -in server1.crt -i | grep -Fw UTCTIME
  200:d=3  hl=2 l=  11 prim:    UTCTIME           :1310122200Z
  213:d=3  hl=2 l=  13 prim:    UTCTIME           :151231230000Z

IS verified correctly:
$ openssl asn1parse -in server2.crt -i | grep -Fw UTCTIME
  200:d=3  hl=2 l=  13 prim:    UTCTIME           :141123070000Z
  215:d=3  hl=2 l=  13 prim:    UTCTIME           :151231230000Z

This looks strange, I'll create a new cert tonight and tell you if this fixed the problem.
Thanks for this hint.
OS: Linux → All
Hardware: x86 → All

Comment 3

4 years ago
Certificates with complete timestamp (including seconds) are validated as expected.
@philipp: Thank you for your hint.
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.