3.94 KB, text/x-vhdl
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.
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
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.