Closed Bug 403220 Opened 17 years ago Closed 8 years ago

Cannot add exception for SSL certificates with sec_error_bad_signature

Categories

(Core Graveyard :: Security: UI, defect, P2)

x86
Windows XP

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: tomwpryor, Unassigned)

References

()

Details

(Whiteboard: [no "me too" comments please, we all agree it's a problem, it's simply very difficult to fix][psm-cert-exceptions])

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110703 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b1) Gecko/2007110703 Firefox/3.0b1

Hello,

I am unable to access Plesk (Server control panel software) using Mozilla Firefox 3 BETA. Plesk works in internet explorer and previous versions of the browser.

Error:

Secure Connection Failed

      

      
      
      

      
        
        

          

An error occurred during a connection to 75.127.66.155:8443.

Peer's certificate has an invalid signature.

(Error code: sec_error_bad_signature)

        


        
        


    *   This could be a problem with the server's configuration, or it could be
      someone trying to impersonate the server.

    *   If you have connected to this server successfully in the past, the error may
      be temporary, and you can try again later.

Also I am unable to create a exception for the site, I just get the error listed above.

Reproducible: Always

Steps to Reproduce:
1. Visit Website
2.
3.
Actual Results:  
Error produced

Expected Results:  
Allowed me to create a exception, but warn me about the risk.
I'm seeing a similar issue with self-signed certificates in a development application.  If I try to create a connection for the site, you just get the error mentioned above.  Makes Firefox 3 unusable for development work.
Oops - I meant "exception" rather than "connection" in comment #1.
Flags: blocking-firefox3?
The problem is not that the certificate is self-signed but that it apparently also has a bad signature. This error breaks the add-exception dialog on mac leaving a broken dialog that you cannot close and you have to force quite firefox.
Summary: Self-signed SSL certificates generated by Plesk control panel make the webpage inaccessible. → Cannot add exception for SSL certificates with sec_error_bad_signature
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yeah, that's all the way broken, alright.  Clearly something about bad signatures is sending us into a tailspin, bit it's also pretty surprising that we would find a signature broken that other common SSL stacks confirm.  In either event, this dialog is PSM code, so moving to Core:Security UI
Assignee: nobody → kengert
Component: General → Security: UI
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → ui
Version: unspecified → Trunk
Flags: blocking1.9?
I'm seeing something similar to this; however, the invalid cert that I see is rejected with sec_error_ca_cert_invalid. Also, I'm able to cancel the "Add Exception" dialog box with the cancel button. Is this likely the same issue?
(In reply to comment #5)
> I'm seeing something similar to this; however, the invalid cert that I see is
> rejected with sec_error_ca_cert_invalid. Also, I'm able to cancel the "Add
> Exception" dialog box with the cancel button. Is this likely the same issue?

Blake, are you saying that you, too, cannot add the exception?  If so, is anything logged to the error console?  Tom's report seems to be brokenness around our signature verification code, but sec_error_ca_cert_invalid is one of the cases that are well-anticipated, and has been successfully tested in the past, so you might be onto something subtle...
(In reply to comment #6)
> Blake, are you saying that you, too, cannot add the exception?  If so, is
> anything logged to the error console?

The answers to those questions are yes and no, respectively. The certificate is almost certainly invalid as both Firefox 2.0 and Safari both complain about it. Only, when I try to add https://1.1.1.1/?foo=bar as a security exception, clicking "add exception" does not do anything.
sec_error_bad_signature is treated as a "protocol error".
I confirm, I get this error message with https://75.127.66.155:8443/
and conclude the cert is really broken.
(Please provide more evidence should you believe that the cert is not broken and that we are incorrectly reporting this error)

The SSL implementation is not willing/able to proceed when such technical inconsistencies are found. Therefore it's by design to reject the cert and not allow you to add an exception and would make the original request invalid.


Regarding comment 3, that's a usability bug on our side that we should fix.
(In reply to comment #8)
> 
> Regarding comment 3, that's a usability bug on our side that we should fix.


I tried to reproduce the scenario that required you to force quit Firefox.
I can't.
I go to https://75.127.66.155:8443/
I get a popup with the error code.
I dismiss the error code box with OK.
I'm back at the add exception dialog.
I can use cancel just fine.

This was Linux.

I see your report was about Mac.
I tried the same on a Mac OSX 10.4.11 box with the latest Firefox nightly trunk build. Works exactly the same for me, I can't see a bug here.

If you still can reproduce this "need to force quit on ssl protocol error", please file a separate bug report with more detailed steps to reproduce.

(In reply to comment #5)
> I'm seeing something similar to this; however, the invalid cert that I see is
> rejected with sec_error_ca_cert_invalid.


(In reply to comment #7)
> when I try to add https://1.1.1.1/?foo=bar as a security exception,
> clicking "add exception" does not do anything.


I don't understand, can you please be more detailed in your steps to reproduce?

Here is my understanding:
- you go to https://1.1.1.1/?foo=bar
- you get an error page with sec_error_ca_cert_invalid

right?

at this point you should be able to use "page info" to view the cert.
if you're able to view it, you should also be able to export it (using the export button on the cert details tab).
Could you please export it as a full chain and attach it?

(In reply to comment #8)

Note that in both Firefox 2.0 and IE 7.0, you can view the certificate from https://75.127.66.155:8443/ without seeing any error message indicating that the certificate is broken:

For Firefox 2.0:
1. Enter URL https://75.127.66.155:8443/.
2. Click "Examine Certificate..." on pop up box.
3. Note that you are able to examine the certificate.

For IE7:
1. Enter URL https://75.127.66.155:8443/.
2. Click "Continue to this website (not recommended)".
3. Left-click on "Certificate Error" (next to URL bar).
4. Click "View certificates".

I'm not sure how you conclude that the certificate is really broken (on the basis that Firefox 3.0 can't parse it - though IE and Firefox 2.0 apparently can).
Depends on: 405966
(In reply to comment #11)
> 
> For Firefox 2.0:
> 1. Enter URL https://75.127.66.155:8443/.
> 2. Click "Examine Certificate..." on pop up box.
> 3. Note that you are able to examine the certificate.

Thanks for pointing this out.
I didn't see that, because I was testing Firefox 2 with newer NSS 3.12, which shows the same behavior as Firefox 3.

I filed bug 405966 to analyze whether this is a regression in NSS.
Note that the trunk SeaMonkey is also unable to add an exception for this 
error.  The error dialog appears when you try to fetch the cert using the 
cert manager, with the result that you cannot view the cert or add the 
exception.  I don't know why SM behaves differently than FF this way.
When I try to view page info for the invalid cert page, I get the following in my error console:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIX509Cert.issuerName]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://browser/content/pageinfo/security.js :: anonymous :: line 41"  data: no]

I was able to access the cert through the exception box; however, and I'll attach the export in a second. I really do think the cert is invalid. It's only used on the page that verifies wireless credentials at my school, so I don't think anybody put too much thought into making it valid.
Attached file Invalid certificate
This is what I get when I click "export."
(In reply to comment #13)
> Note that the trunk SeaMonkey is also unable to add an exception for this 
> error.  The error dialog appears when you try to fetch the cert using the 
> cert manager, with the result that you cannot view the cert or add the 
> exception.  

That's exactly what happens with Firefox trunk, too.


> I don't know why SM behaves differently than FF this way.

I think we confused you.
As I understand it, Firefox trunk and SeaMonkey trunk behave identically.

It's Firefox 2.0 which behaves differently.


Firefox 2 uses NSS 3.11 - works

Firefox trunk uses NSS 3.12 - broken

SeaMonkey trunk uses NSS 3.12 - broken


When I did my initial tests, I used a non standard configuration, Firefox 2 with NSS 3.12, which is broken, too.
I think this bug probably has the same cause as bug 405399. 
Perhaps they should be combined.

Perhaps we should revisit the list of error codes for which cert exceptions
can be made.  Given that the new cert exception feature does not bestow the
same broad level of trust on the cert as the old method did, it may be 
reasonable to allow exceptions for certs that have errors that would have
made them ineligible for receiving a trust flag.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
It seems this is now WORKSFORME.
Did you change the server cert?
Or did we fix some code?

In particular, NSS complains the cert has "!invalid AVA!" for both issuer and subject names.
The subject and issuer names in this cert are irrelevant to the error reported.
Erroneous reports of sec_error_bad_signature are the subject of bug 405966
which is now fixed on the trunk (but not yet taken in FF).  
Bug legitimate sec_error_bad_signature errors can and still do occur.
This bug should be seen an an issue about whether exceptions can be added for 
certs that exhibit that error (regardless of whether the error is accurate or 
erroneous).
Flags: tracking1.9+ → wanted-next+
Hi, I'm having the same problem as Blake, in that when the wireless network at my school redirects me to its authentication page I get the sec_error_ca_cert_invalid error and I can't add the security exception. In the exception dialog box, I can get the certificate, but clicking the "Confirm Security Exception" button does nothing. (It isn't grayed out, but nothing at all happens when I click it.)

Unfortunately, this prevents me from using the wireless network without using an older version of firefox or another browser for authentication.

I'm using ff 3 beta 5 with linux.
Caleb, the version you are testing is outdated and does not yet have the fix.
You may get and test the newer Firefox 3 RC1.
Great, thanks for fixing this.
Assignee: kaie → nobody
Whiteboard: [psm-cert-exceptions]
same issue here.
(In reply to SIRavecavec from comment #26)


You shouldn't get this error on bugzilla.mozilla.org, which is using a good cert.

Can you reproduce on a different computer?
Are you suffering from a man-in-the-middle attack or is your network connection unreliable (corrupted data transfer)?
I'm currently seeing this issue with Firefox Nightly on a Mac.  There is no way to add an exception so Firefox is just unusable for getting to the site I'm trying to go to (a HP iLO web UI).
Eric, you might experience this because we recently changed Firefox to reject insecure MD5 signatures (bug 650355). The site probably uses an certificate with a MD5 signature. Would you be willing to share the link of the site (either in private to me, or in that bug 650355). Maybe we should open a new evangelism bug to track sites that need to upgrade?
It's the out of band management interface for HP servers so upgrading the site would require HP to publish new firmware.  It's only internally accessible within Mozilla so would you be able to get to it?
Eric, it's highly discouraged to use MD5, because it's no longer secure. But if your environment absolutely requires you to work with MD5 signatures, you can toggle the preference mentioned in bug 650355.
My hardware requires it (and it's quite common hardware so sysadmins around the world will need to know about this setting until HP catches up with modern encryption).  I'll give security.enable_md5_signatures a try, thanks so much!
FWIW I get this message in *both* Firefox 15.0 (MS Windows) and 3.6.28 (Linux) for an internal website signed by my company's own certificate.

Both Chrome and IE8 accept the certificate.  (All browsers have my company's certificates installed for authority).

Bits of info from those two browsers' view of the certificates:

IE:
   Version:                    V3
   Signature Algorithm:        sha1RSA
   Valid from:                 30 August 2012 13:56:57
   Valid to:                   30 August 2017 13:56:57
   Public key:                 RSA (1024 bits)


Chrome:
   .... is encrypted with 128-bit encryption

   The connection uses TLS 1.0

   The connection is encrypted using RC4_128, with SHA1 for message
   authentication and ECDHE_RSA as the key exchange mechanism.

(Today isn't the first time I've hit this - just that I hit it again today with a new certificate - I usually use 

The website is run by a tomcat server which has this just this key in, along with the relevant company certificate, added via keytool as -trustedcacerts

As this is internal you can't all have a look, but it does show that:

a) Firefox does reject certificates which other browsers accept
b) When it does so you are completely stuck, as their is *no way to view that web site at all* in Firefox.
c) The error message isn't helpful, as you can't see *why* FF thinks the signature is bad (although that might be inevitable...)
  "I usually use "

was meant to continue with "4096-bit certs, as they seem to be OK".

The one with the problem is a 2048-bit one.
This continues to be a *serious* problem (for me).

I can't use Firefox 17.0.1 (on Windows *or* Linux) to connect to sites with certs signed with  my company's internal 2048-bit signing authority certificate.  (The 4096-bit ones are OK, but most sites don't use those...)

IE, Chrome and wget all work with the same signing certificate when I connect to same sites.

And Firefox doesn't give me *ANY* way to override this!!!  So Firefox is stuffed!!
I have to confirm, that this problem is a really serious one for me too. Although that issue seems to be fixed in Firefox 18, an upgrade to this version is no practical way due to the much more higher cpu-usage especially while many tabs are opened.

So either Mozilla get the problem with the certificates fixed soon, or they make the new version v18 cpu-friendly. But at the moment, I have to say with tearful eyes: Firefox is getting worse with any new major-release...
Whiteboard: [psm-cert-exceptions] → [no "me too" comments please, we all agree it's a problem, it's simply very difficult to fix][psm-cert-exceptions]
This issue persists for me (18.0.1).  It has been an issue with *all* versions of Firebox for the last 3+ years (at least).

Not sure why there is a problem in allowing an override, given that it is done elsewhere, but I suppose there might be a difference between accepting a certificate that looks OK, but you can't validate to a know source, and one that you can't make sense of at all.

And if you don;t want "me too" posts it would help to say what people *should* do if they are suffering the same issue.

Vote for it?
Add themself as a cc?

(there are far more ccc's than votes on this one).
It seems that this issue is not interesting for the dev team.
3 years and the problem still persist in version 20.0.
It's incredible that you cannot add an exception where both Safari and Internet Explorer has no problem to do this.
It seems that developers thinks that you have to buy a commercial certificate even when you are in development with your app ... incredible!
Of course it's UNUSABLE for DEVELOPMENT!
Some info for my case.

Where I work we have 4 internal CA roots, for 1024-, 2048-, 3072- and 4098-bit certificates signings.
So the 4 public CA root certificates need to be loaded into Firefox so that it will accept certificates signed by them - which I do.

But now Firefox refuse to accept any 2048-bit signed certificates - and also refuses to let me add any exceptions for them.  It *is* happy with 1024- and 4096-bit ones.

HOWEVER, if I removed the 3072-bit root CA from Firefox it will now *accept* the 2048-bit signed certificates!!

And, in case anyone is listening, it was still a problem at FF 22.0.
Some more info here.  Which might be significant?

It runs out that those 4 root CAs have some Subject fields with a trailing space on.
But the 2k-bit and 3k-bit ones share the same space-oddity.

So it appears that I have two different certificates for the same root CA - a 2k-bit and a 3k-bit one, and Firefox is only checking the 3k one?

It is certainly only checking the 3k one, as I've tracked that down to the code in pk11obj.c in PK11_VerifyRecover that calls C_VerifyRecover.  Unfortunately at that point I'm stuck, as
   o C_VerifyRecover is a function call lookup in a array, and I can't see what actually gets called
   o I'm having problems tracking backwards to find out where the original call to CERT_VerifyCertChain came from.

However - some questions;
   o is it legal to have different types of root CA with the same "Subject" (bear in mind that IE and Chrome seem to handle these same root CAs OK).
   o is Firefox set up to handle this if it exists?
I am having the same issue, my chain is like this (from leaf to root):

1: 2048 bit (SHA256 signature) SSL server certificate
2: 2048 bit (SHA256 signature) intermediary CA
3: 4096 bit (SHA1 signature) intermediary CA
4: 1024 bit (SHA1 signature) root CA

If I try to open the site I get the sec_error_bad_signature page. Now, if I add the CAs to the Authorities list and set the 4096 bit one to full trust, I can access the website. In my view, there seems to be some issue with 4096 bit CAs.
Gordon, Paul: Thank you for reporting your experience with this issue.

Could you please attach all the relevant certificates (end-entity, intermediates, and roots) to this bug using the "add attachment" interface in this bug? If you don't want to share them publicly, there will be checkbox in the "add attachment" interface for making the attachment private. Alternatively, please add the certificates as attachments to an email to cviecco@mozilla.com; dkeeler@mozilla.com; brian@briansmith.org.

If you have certificates with the same or similar subject names or trailing spaces or whatnot, please include all variants of them that you think might be relevant.

Thanks in advance.
Flags: needinfo?(paul)
Flags: needinfo?(gordon.lack)
Brian,

I've just sent an E-Mail to the addresses you listed with an example certificate chain that exhibits this problem.  If you guys don't receive that properly, feel free to let me know through Bugzilla.  I realize I wasn't one of those you requested info from, but hopefully it will still be useful.

It's worth noting that much like Paul, we have an intermediate cert with a 4096 bit signature.  So there's a good chance that's where the problem lies.
I've attached info in a mail message
Flags: needinfo?(gordon.lack)
I am having the same issue with https://www.google.com or gmail behind an enterprise proxy zscaler.
Using FF 25.0.1 under Mac OSX 10.6.8 without proxy configured I can reach gmail without problem.
Configuring proxy it fails with FF with error "Code d'erreur : sec_error_bad_signature", while it works with Google Chrome and Safari.

Issue seems to have appeared with 25.0.1 (worked before)
Attached file badsig.zip
I've had this problem a few times. Today I had the problem when I connected to a Fiddler web debugging proxy on a remote box. I already had a Fiddler CA certificate trusted on the local box and I suspect not being able to differentiate between the two might have something to do with this problem.

I've made a small example. Attached are two CA certificates and I signed a certificate for localhost with each of them:

box1.FiddlerRoot.cer
box1.localhost.pem

box2.FiddlerRoot.cer
box2.localhost.pem

I used makecert in the Fiddler directory to make the localhost certificates:
makecert.exe -pe -ss my -n "CN=localhost, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com" -sky exchange -in DO_NOT_TRUST_FiddlerRoot -is my -eku 1.3.6.1.5.5.7.3.1 -cy end -a sha1 -m 132 -b 03/27/2013

As long as the box they come from is the same everything is fine in Firefox but if I trust a different box CA than the one that's signed the presented certificate I get sec_error_bad_signature with no option for an exception.

box1.FiddlerRoot.cer
box2.localhost.pem

box2.FiddlerRoot.cer
box1.localhost.pem

To reproduce create a new Firefox profile and trust box1 or box2, for example box2.FiddlerRoot.cer:
Options > Advanced > Certificates > View Certificates > Authorities > Import

Now start a server with the key from the other box (box1 in this example):
socat openssl-listen:4433,reuseaddr,cert=box1.localhost.pem,verify=0,fork -

In Firefox (tested in Firefox 24 ESR) go to https://localhost:4433/

An error occurred during a connection to localhost:4433. Peer's certificate has an invalid signature. (Error code: sec_error_bad_signature)

In the past as a workaround for sec_error_bad_signature I've removed cert8.db. If you do that you'll lose everything but the hard coded NSS CA certificates. I've since been using certutil to add certificates to a cert8.db for default profiles so for now I guess I can reset to that cert8.db or trust all Fiddler certificates by manually adding them to cert8.db which will probably look something like this:

certutil -A -n "DO_NOT_TRUST_FiddlerRoot - DO_NOT_TRUST" -t "CT,c,c" -i FiddlerRoot.cer -d ./
certutil -A -n "DO_NOT_TRUST_FiddlerRoot - DO_NOT_TRUST #2" -t "CT,c,c" -i FiddlerRoot2.cer -d ./
certutil -A -n "DO_NOT_TRUST_FiddlerRoot - DO_NOT_TRUST #3" -t "CT,c,c" -i FiddlerRoot3.cer -d ./
etc etc
I have same problem but with one note:
If i install certificate signed by my self-signed CA certificate on IIS or linux Zimbra(8.0.6) - it works fine.
But if i put private key, certificate and CA certificate to apache (using mod_ssl or mod_gnutls, version 2.2.14) or to webmin the Firefox shows me "sec_error_ca_cert_invalid" and doesn't allow add exception.
Chrome, IE, .Net(System.Web.HttpUtility) work fine.
My CA certificate is installed both in Windows registry and Firefox.
Additional note:
if i extract certificate with key out from zimbra and put it to apache - problem disappear.
So problem in certificates.
Differences in certificates:
Version: Invalid= V3, Valid= V1
Serial: Invalid=28, Valid=00 8c 23 ce f8 63 47 b9 4a
Subject: Invalid - Additionally contain e-mail
Other: Invalid certificate contains few additional fields: X509v3 Subject Alternative Name, X509v3 Subject Key Identifier, X509v3 Authority Key Identifier, X509v3 Basic Constraints (CA:TRUE)
As of last week, I still had this problem on FF versions 25 through 28, and as I recall, prior versions of FF. Which made me sigh and get frustrated and consume a lot of research time. 

I believe the issue of this report has WORKAROUND/TEMPORARY SOLUTION (I hope for all or most), until FF is patched, at the following article:  So, a How-To Fix article has been published for it at http://technotes.whw1.com/computer-related/software/firefox/30-firefox-fix-to-no-exception-button-showing-when-invalid-ssl-certificate  

If you know how or got authority to modify top section of this report and have it reference to this comment or article as a temporary fix, please feel free to do so.  It should help save people the frustration and higher blood pressure I experienced.  

If the article helps you resolve this problem but you got a different error screen message than the few displayed at the article site, then let me know or attach image to this ticket so I can add it as an additional example.

Note that I think maybe report of bug 443972 is a duplicate, and other reports of bug 659736, bug 545606, and bug 660749 are related some how, but not duplicates.
(In reply to Tech Notes from comment #49)
> As of last week, I still had this problem on FF versions 25 through 28, and
> as I recall, prior versions of FF. Which made me sigh and get frustrated and
> consume a lot of research time. 
> 
> I believe the issue of this report has WORKAROUND/TEMPORARY SOLUTION (I hope
> for all or most), until FF is patched, at the following article:  So, a
> How-To Fix article has been published for it at
> http://technotes.whw1.com/computer-related/software/firefox/30-firefox-fix-
> to-no-exception-button-showing-when-invalid-ssl-certificate  
> 
> If you know how or got authority to modify top section of this report and
> have it reference to this comment or article as a temporary fix, please feel
> free to do so.  It should help save people the frustration and higher blood
> pressure I experienced.  
> 
> If the article helps you resolve this problem but you got a different error
> screen message than the few displayed at the article site, then let me know
> or attach image to this ticket so I can add it as an additional example.
> 
> Note that I think maybe report of bug 443972 is a duplicate, and other
> reports of bug 659736, bug 545606, and bug 660749 are related some how, but
> not duplicates.

This workaround work with certificates that don't have corresponding CA certificate in Firefox database or with self-signed server certificates.
If i remove/rename cert8.db i get database clean of previously installed certificates. I can save certificate of new site as trusted and access this site.
But if i install CA certificate of some group of sites that sites becomes completely untrusted with no possibility to override it (depending on conditions i've described before). Following uninstall of CA certificate resolve problem. /Nightly 31.0a1/
> I believe the issue of this report has WORKAROUND/TEMPORARY SOLUTION (I hope
> for all or most), until FF is patched, at the following article:  So, a
> How-To Fix article has been published for it at
> http://technotes.whw1.com/computer-related/software/firefox/30-firefox-fix-
> to-no-exception-button-showing-when-invalid-ssl-certificate 

I have tried this workaround in Mac (Mavericks) and didn't worked. 
1) There is no cert_override.txt file.
2) The file is being auto generated after deleting it / renaming it.

This is getting annoying to do development in Mozzila, is there another known workaround or temp. fix ?
Please check Bug 1042889
As i think it is one side of bug described here.
The same problem with self-signed certificates, and it is even increasing.
Started after upgrade to 31. On Windows 7, mostly.
Deleting them (internal certificates) helped for a week (we were able to confirm security exception), but then, week later, the very same problem appeared again, on the same computers; it affects whole company and people are beginning to distrust Firefox, what is really really sad :-((
Please, fix it somehow...
Yup, "bad for business" is all I know.
No way to get through to site with Firefox. All avenues blocked.
With chrome there I am without a murmur.
Bug 1227777.
This bug isn't particularly useful as-is. If anyone is having issues like this, please file a new bug in the product Core / component Security: PSM and include the error you're seeing, the site you're connecting to (if it's publicly-accessible), and the certificate chain the server is sending.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(paul)
Resolution: --- → INCOMPLETE
(In reply to David Keeler [:keeler] (use needinfo?) from comment #55)
> ...include the error you're seeing, the site you're connecting to (if it's
> publicly-accessible), and the certificate chain the server is sending.

Isn't that what I did in Comment 44?
(In reply to Gordon Lack from comment #56)
> (In reply to David Keeler [:keeler] (use needinfo?) from comment #55)
> > ...include the error you're seeing, the site you're connecting to (if it's
> > publicly-accessible), and the certificate chain the server is sending.
> 
> Isn't that what I did in Comment 44?

I didn't receive the email mentioned in comment 44. Brian isn't involved as much in Mozilla these days, so I think the fastest route would be for you to file a new bug or to email me if you would rather the certificate chain not be public. Thanks.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #57)
>  
> I didn't receive the email mentioned in comment 44. Brian isn't involved as
> much in Mozilla these days, so I think the fastest route would be for you to
> file a new bug or to email me if you would rather the certificate chain not
> be public. Thanks.

I've been retired for 2.5 years so can no longer check things out on my employer's internal Web sites.
I did do some debugging on this though, and post #40 explains as far as I got, before getting lost in a maze of object method calls where I couldn't figure out where the objects were coming from.

Note that there was no chain. This was an internal certificate authority. You got a key+certificate (?)  for your web server, and all company browsers had the internal CA root installed in them.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: