Closed Bug 1067440 Opened 10 years ago Closed 10 years ago

sec_error_ca_cert_invalid can't be clicked through anymore

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Version:
32 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1042889

People

(Reporter: dustin, Unassigned)

Details

Attachments

(4 files, 1 obsolete file)

chain.txt
2.32 KB, text/plain
Details
Self-signed certificate informations
3.53 KB, text/plain
Details
issuer-cert.txt
2.65 KB, text/plain
Details
HP-fixed.pem
1.38 KB, text/plain
Details 
Hi -- I manage the hosts that build Firefox.  Their out-of-band interfaces run on small, crappy proprietary BMC's that try but fail to do SSL.  It sucks, but I need to get work done, so I'm happy to proceed fully aware that the connection is not actually secure in any way, shape, or form.

That appears not to be possible with Firefox 32.  My only option from the sec_error_ca_cert_invalid error screen is "Try Again", which not surprisingly doesn't help.

All of these thousands of hosts have their own CA's, so there's no real hope of adding each CA to my profile.

I tried the konami code, but it didn't unlock anything.  So I've fallen back to using Chrome.

I can provide temporary access to a host that triggers the error, if that helps.
I imagine this is fixed by bug 1034124 - Dustin, can you try with a recent Nightly or Aurora? (It'll be in Beta soon, as well.)
Flags: needinfo?(dustin)
Doesn't look like it, actually.  I downloaded Aurora, built from
  https://hg.mozilla.org/releases/mozilla-aurora/rev/7546fedad918
and it shows the same screen.

The title of that patch is
  bug 1034124 - allow overrides when a CA cert is used as an end-entity cert
and
  +    case MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY:
so it seems to apply to a different error than I'm seeing.
Flags: needinfo?(dustin)
Can you attach a copy of a certificate chain one of these servers is sending? Also, were you ever able to override the 'sec_error_ca_cert_invalid' error code?
Attached file chain.txt — 
Here's the openssl s_client output, including the cert.

No, I haven't been able to work around it with Firefox.
Dustin, that output only shows one certificate, and I don't see any problems with it. It's more likely the certificate that issued that certificate is the problem. Can you post a copy of that? Alternatively, try with a new profile.
Hi, 
 I think I'm hitting the same problem, with a self-signed cert. I'm trying with the current Nightly on Linux x86_64. On the error page I get there is no possibility to add an exception:

<<Secure Connection Failed

An error occurred during a connection to XXXX:PPPP. Issuer certificate is invalid. (Error code: sec_error_ca_cert_invalid)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.>>

Trying to add an exception manually does'n help, either, it says: "Unable to obtain identification status for the given site"

I attach the output from openssl s_client -connect and openssl x509.
It's definitely the issuer cert that's problematic, as it's self-signed.  I'm not sure how to extract the issuer certificate using s_connect -- any tips?  Anyway, this should be replicable by making your own self-signed CA cert, then signing a child cert with it, and trying to access a site that uses that child cert.

And to be clear about the bug, I know that self-signed certs shouldn't be trusted, etc. etc.  I'm happy to click through a number of "I am a terrible person and I know that puppies cry when I do this, but I want to do it anyway" buttons -- it's the removal of those buttons that triggered this bug report.
Does this give more output?

openssl s_client -connect host:port -showcerts
Indeed, here's the issuer cert (which may be different than that in attachment 8489547 [details] - I forgot which host I was connecting to in that case; this is for hp1-mgmt.inband.releng.scl3.mozilla.com, which has the same behavior)
Attached file HP.pem (obsolete) — 
Here's what looks like is going on:

The issuing certificate is a v1 certificate without any extensions (which is at least consistent). x509v1 certificates are essentially deprecated, since (for example) without extensions, you can't distinguish between an end-entity certificate that isn't allowed to issue other certificates and a CA certificate that is. Indeed, in general, mozilla::pkix doesn't allow certificates without a basic constraints extension identifying them as CAs to act as CAs. The assumption is that if this situation is ever encountered, it is probably an attack.

However, I think there's actually a way around this. If mozilla::pkix can find another potential issuer that results in a different error, it will probably return UNKNOWN_ISSUER, which is overridable. Try importing this certificate as an authority (but don't actually trust it).
That didn't help :(

Even if that worked, there are thousands of these certificates in our infrastructure.  I can't manually import all of them!
(didn't help = same error)
Attached file HP-fixed.pem — 
Hmmm - maybe try this one? (it seems there was an encoding issue)
Attachment #8496089 - Attachment is obsolete: true
Ah, that led me to the "This Connection is Untrusted" page where I can add an exception.  However, it claims the issuer certificate is untrusted, yet it's the same issuer certificate that I just added to the certificate manager.

Also, note that the issuer certificate was generated today, when I first accessed the site.  I suspect these are regenerated fairly frequently :(
(In reply to Dustin J. Mitchell [:dustin] from comment #16)
> Ah, that led me to the "This Connection is Untrusted" page where I can add
> an exception.  However, it claims the issuer certificate is untrusted, yet
> it's the same issuer certificate that I just added to the certificate
> manager.

That's expected - the issuer certificate you just added didn't actually issue that certificate. It's basically there to make mozilla::pkix think there's potentially another path to a trusted root. Since there isn't, and since neither error it encounters is prioritized over the other, it just returns a generic "I couldn't find a trusted path" error.

> Also, note that the issuer certificate was generated today, when I first
> accessed the site.  I suspect these are regenerated fairly frequently :(

As long as the issuer is the same ('C=US, ST=TX, L=Houston, O=Hewlett-Packard Company, OU=ISS, CN=iLO Default Issuer (Do not trust)') this should continue to work.
My problem seems to be quite wired in this context. I'm receiving this error message for two devices I'm using, but not the same time:

1. A router when I try to configure it (it's done with a Ethernet cable by using a local and internal IP).
2. A HP 8600 multifunction printer when trying to access the configuration and control menu.

No proposed solution really solved the issue:
Trying to rename cert8.db did not help at all and toggling the config setting "security.use_mozillapkix_verification" to "false" toggles the access to the printer configuration. Now it seems that I have to choose which device to access and that's somehow crazy.

If it's true what I found in the Mozilla Help Forum that it is planned to lock even this entry with the upcoming versions it's time considering going over to Chrome - even if I don't really want to...
(In reply to Axel.B. from comment #18)
Actually, after fiddling about an hour and more all of sudden the access to both devices seems to work now with the default settings "security.use_mozillapkix_verification" = "true". Please don't ask what I specifically did.
However, I think the bug remains a severe one in my opinion.
Dupe of bug 1042889?
Flags: needinfo?(dkeeler)
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #20)
> Dupe of bug 1042889?

Looks like it, yes.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(dkeeler)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: