1104259 - sec_error_expired_certificate while certificate dates are valid

Status: RESOLVED INVALID

(Core :: General, defect)

Description

[Marc0]

Attachment: 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

[[:philipp]]

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

Comment 2

[Marc0]

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.

Comment 3

[Marc0]

Certificates with complete timestamp (including seconds) are validated as expected.
@philipp: Thank you for your hint.