Closed
Bug 1104259
Opened 10 years ago
Closed 10 years ago
sec_error_expired_certificate while certificate dates are valid
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: mdn, Unassigned)
Details
Attachments
(1 file)
3.94 KB,
text/x-vhdl
|
Details |
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•10 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...
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.
Description
•