1.74 KB, text/plain
1.25 KB, text/plain
3.28 KB, text/plain
2.46 KB, text/plain
2.67 KB, text/plain
848 bytes, text/plain
816 bytes, patch
|Details | Diff | Splinter Review|
2.10 KB, patch
|Details | Diff | Splinter Review|
URL: https://www.colissimo.fr/affranchissementenligne/ (important French shipping service) Result: sec_error_ca_cert_invalid Maybe TE bug.
The cert error page says unknown issuer, but if you go to add an exception it shows me a chain back to a built-in Verisign root with a 1024-bit key. I thought we were removing those roots. Are we instead leaving them in and taking away their trust bits? If that is the problem the site needs to contact Verisign for support on getting a replacement cert.
Same thing here since FF32 on https://www.colissimo.fr/affranchissementenligne/ To Daniel Veditz : there's no " add an exception " option for me on this page, there's no way to access. The page is OK on Chrome, IE and older Firefox versions.
Curiously, I'm seeing different behavior in Release (32) vs. Beta (33) vs. Nightly (35). Release/32 shows sec_error_ca_cert_invalid, and no option to override. Beta/33 and Nightly/35 shows sec_error_unknown_issuer, and allows override. So maybe this is already fixed in 33?
Same bug on Linux. With Nightly I can see the exception page that I can't see on 32. The error message on 32 is: Issuer certificate is invalid. While on Nightly the message is: The certificate is not trusted because the issuer certificate is unknown As a side note, the error message looks unlocalized while a search in our translation memory shows that the segments are translated on the release channel, so that's a bit strange.
OS: Windows 7 → All
The issuing certificate is also a 1024bits one. This can't be changed, the subscriber certificate needs to be renewed.
We can't add an exception, sa that's clearly a bug Erwann, nothing to do with the 1024bits thing. Colissimo.fr is the biggest french post service, they won't change their certificat because of a Firefox bug ;)
It may or may not be a bug... You can't add an exception for a revoked certificate, and that's not a bug. Being unable to set an exception for a 512bits key (clearly insecure) wouldn't be illogical. Same goes for 768bits. Where could such a limit be set? Anyway, their certificate will expire at the end of september, they should already have received renewal warnings, and their next certificate will be issued under a 2048bits chain. Working for a french CA, I have no problem asking a big customer to renew his cert if there's a security risk.
Let's investigate this quickly, if the server is about the change. This host is a good way to reproduce the issue (I've failed to manually recreate certificates that show the error, so we need to investigate what's special here). I'm able to see this with Firefox 31, which is a long term support branch, and I think it needs to fixed on FF 31.
Severity: normal → major
Hardware: x86_64 → All
Version: 32 Branch → 31 Branch
Summary: sec_error_ca_cert_invalid at https://www.colissimo.fr/ since Firefox 32 → sec_error_ca_cert_invalid since Firefox 31 at https://www.colissimo.fr/ and certain routers with built in certificates
comparing this certificate, sent by a router, which produced the same error message, we can already rule out some potential reasons: - expiration doesn't matter. (this one expired, collismo still valid) - key size doesn't matter (this one 1024, collismo 2048) - it doesn't seem to matter if other servers (crl, ocsp) can be reached or not (only the router was reachable in the router test scenario, but everything can be reached in the collismo scenario) Both scenarios use a server certificate from the same issuer: O=VeriSign Trust Network OU=VeriSign, Inc. OU=VeriSign International Server CA - Class 3 OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
Summary: sec_error_ca_cert_invalid since Firefox 31 at https://www.colissimo.fr/ and certain routers with built in certificates → mozilla::pkix, cannot override sec_error_ca_cert_invalid since Firefox 31 at https://www.colissimo.fr/ and certain routers with built in certificates
I suspect the issue might be caused by this old root CA certificate. Issuer/Subject: C=US O=VeriSign, Inc. OU=Class 3 Public Primary Certification Authority Signature Algorithm: md2WithRSAEncryption When looking at this certificate in certificate viewer, an error message is shown about a disabled algorithm. Although this root CA cert is to be phased out soon, and we recently disabled trust for web sites, it's still included and still trusted for email certificates. The signature algorithm for the self-signed signature should be ignored on root CA certificates. I suspect that mozilla::pkix rejects the MD2 signature, and incorrectly prohibits it from being overriden.
(In reply to Kai Engert (:kaie) from comment #15) > I suspect that mozilla::pkix rejects the MD2 signature, and incorrectly > prohibits it from being overriden. The rejection of root certificates signed by MD5 and MD2 is bug 1058812. But, that bug only affects Firefox 33 and later. The issue regarding sec_error_ca_cert_invalid in Firefox 31 and later is different from that bug. There are multiple bugs regarding sec_error_ca_cert_invalid and we should try to DUPE them into one bug.
(In reply to Richard Barnes [:rbarnes] from comment #3) > Release/32 shows sec_error_ca_cert_invalid, and no option to > override. This is almost certainly a duplicate of one of the other bugs that mention sec_error_ca_cert_invalid. > Beta/33 and Nightly/35 shows sec_error_unknown_issuer, and allows > override. My guess is that the 1024-bit root it chains to was probably removed in the NSS update for Firefox 33. I suggest moving this bug to Tech Evangelism and assigning this to a Verisign representative, because the end-entity certificate was issued by a 1024-bit intermediate. The website needs a new certificate.
Firefox 32: still cannot override Firefox 33: can override So apprently there's a bugfix in Firefox 33 that should be backported to Firefox 31 ESR branch?
I have contacted Symantec, asking them to work with their customer to update their SSL cert, which expires on 9/28 anyways.
(In reply to Kathleen Wilson from comment #19) > I have contacted Symantec, asking them to work with their customer to update > their SSL cert, which expires on 9/28 anyways. Thanks, but that doesn't solve the issue. The issue is much broader, because there are apparently many router devices that are affected by this bug. This is a blocker for rolling out Firefox 31 ESR into enterprise environment. (In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #17) > My guess is that the 1024-bit root it chains to was probably removed in the > NSS update for Firefox 33. No, the root is still shipped with Firefox 33. > I suggest moving this bug to Tech Evangelism and assigning this to a > Verisign representative, because the end-entity certificate was issued by a > 1024-bit intermediate. The website needs a new certificate. Disagree, insufficient for routers, need ability to override. Not being able to override is a regression.
So far it's only a suspicion that the MD2 self-signature is responsible for the failure. So far I've been unable to reproduce using similar certificates created by myself.
(In reply to Kai Engert (:kaie) from comment #21) > So far it's only a suspicion that the MD2 self-signature is responsible for > the failure. Any relation to Bug #1058812 ?
(In reply to Kathleen Wilson from comment #19) > I have contacted Symantec, asking them to work with their customer to update > their SSL cert, which expires on 9/28 anyways. I wanted to try to debug the issue, my debug build is now ready, but it seems colissimo has already replaced their cert, and I currently don't have access to any other site showing this specific issue :-(
(In reply to Kai Engert (:kaie) from comment #23) > (In reply to Kathleen Wilson from comment #19) > > I have contacted Symantec, asking them to work with their customer to update > > their SSL cert, which expires on 9/28 anyways. > > I wanted to try to debug the issue, my debug build is now ready, but it > seems colissimo has already replaced their cert, and I currently don't have > access to any other site showing this specific issue :-( Oh, I was wrong, sorry. Trying to analyze now :-)
I found the explanation. It's the missing basic constraint extension. I can reproduce the issue with a local server and locally generated certificates, if the CA certificate lacks it.
Summary: mozilla::pkix, cannot override sec_error_ca_cert_invalid since Firefox 31 at https://www.colissimo.fr/ and certain routers with built in certificates → mozilla::pkix, FF31, cannot override bad cert if issuer CA lacks basic constraint ext. (sec_error_ca_cert_invalid, e.g. routers, https://www.colissimo.fr )
(In reply to Kathleen Wilson from comment #22) > Any relation to Bug #1058812 ? Unrelated as I've just learned, because MD2 isn't the cause of the non-overridable issue.
(In reply to Kai Engert (:kaie) from comment #18) > So apprently there's a bugfix in Firefox 33 that should be backported to > Firefox 31 ESR branch? The code in mozilla::pkix, in particular security/pkix/lib/pkixcheck.cpp, function CheckBasicConstraints(), has changed between 31 and 33, I guess the different behaviour is a side effect of the changes. This is the only place inside libpkix that produces error ca_cert_invalid.
Suggestion: Both this bug and bug 1042889 show scenarios the produce error code ca_cert_invalid, although the causes are different. I suggest to fix both bugs by adding error code ca_cert_invalid to the list of codes that classify as a "bad cert" that are allowed to be overriden by the user.
I'll request review after I was able to verify the patch works.
Comment on attachment 8486475 [details] [diff] [review] p-esr31-override-ca-cert-invalid Test succeeded, can override for both bugs. With patch applied, the "technical details" of the error page reports "Issuer certificate is invalid. / Error code: sec_error_ca_cert_invalid", and allows to override.
Attachment #8486475 - Flags: review?(dkeeler)
test site: https://kuix.de:9451/ test build of ESR-31 branch with patch v1 included: https://firstname.lastname@example.org/
Comment on attachment 8486475 [details] [diff] [review] p-esr31-override-ca-cert-invalid Review of attachment 8486475 [details] [diff] [review]: ----------------------------------------------------------------- Kai, there's actually two ways to encounter the error SEC_ERROR_CA_CERT_INVALID in 31 with mozilla::pkix: one is if an issuer certificate doesn't have basicConstraints: cA: TRUE, and the other is if the end-entity certificate does have basicConstraints: cA: TRUE. The slight complication is with built-in x509v1 roots that (naturally) don't have v3 extensions. For those, mozilla::pkix basically pretends they have basicConstraints: cA: TRUE if they're trusted. Long story short, I don't think it's a good idea to allow overrides for both of these cases. In fact, in 34 (and hopefully soon 33 - see bug 1034124), it is possible to add an override for the second case but not the first. We may be able to backport that to ESR31, but I'm skeptical. The good news is that mozilla::pkix can be disabled in ESR31, so if organizations find it problematic, they can disable it.
Attachment #8486475 - Flags: review?(dkeeler) → review-
If I understand your explanation correctly, you don't want to allow an override, if the issueing CA cert is v3 but doesn't contain a basic constraint extension at all. That means you want to mark this bug as wontfix? In my opinion any bad cert should be allowed to override. The whole point of overrides is to allow to get to machines that are badly configured and MUST be used anyway.
(In reply to Kai Engert (:kaie) from comment #33) > In my opinion any bad cert should be allowed to override. I assume you mean "... except revoked and actively-distrusted certificates." > The whole point of overrides is to allow to get to machines that > are badly configured and MUST be used anyway. I am not sure there is consensus on why we allow cert error overrides. It seems as much about inertia as anything else. Also, I think cert error overrides are more for making up for a the deficiencies of the *client* (i.e. Firefox) than a poorly-configured *server*. The case of an issuer certificate without basicConstraints.cA set is an egregious violation of the specification and a strong sign of a misused certificate (as opposed to an accidental misconfiguration of the server). I agree with David, and I think this bug should can be resolved as INVALID (meaning "works as intended").
We can debate about correctness all day long, but that isn't the issue here. It's a fact that Verisign had made this mistake (issued a v3 cert without basic constraint ext), and it's a fact that there are physical devices out there that cannot be accessed any longer. If corporate admins or private users can no longer access their hardware, they will use other browsers. Go ahead and mark it invalid, if that's what you want.
ok, I take that back, sorry, it was a v1 cert that verisign had issued.
So, if David's explanation means, he agrees that v1 certs without basic constraints can be overriden, then we're good. If I understand correctly, this fix is already in the later Firefox, and will therefore be contained in Firefox 38 ESR. It would be good to port it to 31 ESR, too.
www.colissimo.fr has fixed its cerf, it works normally now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
This is a test build with attachment 8500613 [details] [diff] [review] from comment 40 applied. https://email@example.com/
You need to log in before you can comment on or make changes to this bug.