sec_error_expired_certificate while certificate dates are valid

RESOLVED INVALID

Status

()

Core
General
RESOLVED INVALID
4 years ago
4 years ago

People

(Reporter: mdn, Unassigned)

Tracking

33 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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 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.

Comment 1

4 years ago
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...
(Reporter)

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
(Reporter)

Comment 3

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