Closed Bug 1104259 Opened 10 years ago Closed 10 years ago

sec_error_expired_certificate while certificate dates are valid

Categories

(Core :: General, defect)

33 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mdn, Unassigned)

Details

Attachments

(1 file)

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 https://www.marcoschumann.de/ (or https://www.vvmev.de/ or https://www.espeh.de/) a "This Connection is Untrusted" page appears.
The same procedure with e.g. https://pilz.espeh.de/ 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.
this report might be the same as bug 1085238

the regression range for this issue is https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7075808c3306&tochange=38ecfc3922b8, so it's likely bug 1019770 orignally causing it...
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
Certificates with complete timestamp (including seconds) are validated as expected.
@philipp: Thank you for your hint.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: