Closed Bug 153232 Opened 23 years ago Closed 19 years ago

Can't load certificate, error code -8182

Categories

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

1.0 Branch
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: alain, Assigned: KaiE)

References

()

Details

(Keywords: fixed1.8.1)

Attachments

(1 file, 1 obsolete file)

I'm using the debian cvs snapshot made on 19 Jun 2002, I've been experiencing this problem for a while: When I try to get https://www.floc.net/ I got this error in mozilla: Could not establish an encrypted connection because certificate presented by www.floc.net is invalid or corrupted. Error code: -8182 I think it's a problem from mozilla and not my certificate because I can connect with Konqueror, Links, Lynx, wget and w3m (some display a warning saying it's a self-signed certificate) The names of the server matches, it's always www.floc.net as show by openssl s_client -connect www.floc.net:443 -showcerts It's a self-signed certificate The error I have in the ssl server logs is: [20/Jun/2002 16:39:39 03919] [trace] OpenSSL: Read: SSLv3 read client certificate A [20/Jun/2002 16:39:39 03919] [trace] OpenSSL: Exit: failed in SSLv3 read client certificate A [20/Jun/2002 16:39:39 03919] [error] SSL handshake failed (server www.floc.net:443, client 81.65.108.164) (OpenSSL library error follows) [20/Jun/2002 16:39:39 03919] [error] OpenSSL: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate [Hint: Subject CN in certificate not server name or identical to CA!?]
-> PSM
Assignee: darin → ssaux
Component: Networking: HTTP → Client Library
Product: Browser → PSM
QA Contact: tever → junruh
Version: other → unspecified
Can you try turning off FIPS? Edit>Prefs>Privacy>Certs>Manage Devices>Disable FIPS.
After more testing, this site does not load with FIPS disabled, or with Navigator 4.7X or IE6. I think the webmaster of floc.net should fix the site.
Assignee: ssaux → momoi
Component: Client Library → The Americas
Product: PSM → Tech Evangelism
QA Contact: junruh → jonrubin
..so no Evang, just Web-Trash working nowhere
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Reopening. Looking at this site more, I do not think it is a server problem. While neither latest Mozilla nor Communicator 4.7x is able to connect to that site, I was able to connect using a command line client. I used SSL enabled "curl" (using OpenSSL), which is a command line program to download URLs. Using that tool, I was successfully able to retrieve https://www.floc.net/ Is it possible www.floc.net uses a communication protocol we do not understand? Maybe a currently unsupported crypto cipher?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
There is nothing weird in the certificate, I followed the mod_ssl instructions like a monkey Konqueror says the cipher is: RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 [08/Jul/2002 10:17:13 31835] [info] Connection to child 2 established (server www.floc.net:443, client 81.65.108.164) [08/Jul/2002 10:17:13 31835] [info] Seeding PRNG with 23177 bytes of entropy [08/Jul/2002 10:17:13 31835] [info] Connection: Client IP: 81.65.108.164, Protocol: SSLv3, Cipher: RC4-MD5 (128/128 bits) [08/Jul/2002 10:17:13 31835] [info] Initial (No.1) HTTPS request received for child 2 (server www.floc.net:443) [08/Jul/2002 10:17:13 31835] [info] Connection to child 2 closed with standard shutdown (server www.floc.net:443, client 81.65.108.164) And with Mozilla : [08/Jul/2002 10:17:36 31836] [info] Connection to child 3 established (server www.floc.net:443, client 81.65.108.164) [08/Jul/2002 10:17:36 31836] [info] Seeding PRNG with 23177 bytes of entropy [08/Jul/2002 10:17:37 31836] [error] SSL handshake failed (server www.floc.net:443, client 81.65.108.164) (OpenSSL library error follows) [08/Jul/2002 10:17:37 31836] [error] OpenSSL: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate [Hint: Subject CN in certificate not server name or identical to CA!?] [08/Jul/2002 10:17:37 31232] [info] Connection to child 8 established (server www.floc.net:443, client 81.65.108.164) [08/Jul/2002 10:17:37 31232] [info] Seeding PRNG with 23177 bytes of entropy [08/Jul/2002 10:17:38 31232] [error] SSL handshake failed (server www.floc.net:443, client 81.65.108.164) (OpenSSL library error follows) [08/Jul/2002 10:17:38 31232] [error] OpenSSL: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate [Hint: Subject CN in certificate not server name or identical to CA!?] There is probably something wrong in the certificate, I'll try again, but anyway I think Mozilla should display a more meaningful message than the error code if possible, and not display it three times in a row.
When the signature given in the cert is decrypted with the public key given in the same cert, the result does not appear to be a properly formated PKCS#1 v1.5 signature block. That is the immediate cause of the error. However, even if that problem were fixed, I believe there would also be other problems with this cert, such as being issued by an unknown and/or untrusted issuer. Mozilla DID display a more meaningful message than just the error number. The submittor even quoted it. It said "Could not establish an encrypted connection because certificate presented by www.floc.net is invalid or corrupted." However, I agree that this message is not as meaningful as it could be. The error -8182 means the server cert has an invalid signature. Communicator 4.x reports that the server's cert has an invalid signature, and I see no reason for mozilla's error message to be more vague than that. On my Win2K box, IE 5.5 cannot open the page either. After two connections and two attempted SSL3 handshakes, it displays an error message that (oddly) is the same as the one it displays when DNS lookups fail. I expected a security error of some kind, but got the DNS failure message instead. Using an NSS test program, an SSL client program that allows me to override all cert problems, I was able to fetch the page from the flot.net URL above. So, I'd say the cert really is bad. Mozilla is behaving correctly in reporting it. The error message could be less vague, but that is the only problem with mozilla I see reported in this bug. I'd guess that the other client products mentioned above (that were also able to retrieve the page from the URL cited above) don't verify the signature on the server cert, or that it came from a trusted issuer. Without those checks, the security offered by SSL is illusory at best. There's little value in having a secure pipe to an unknown party -- the party could be a man-in-the-middle attacker intercepting the plain traffic! That is one reason why we don't always accept claims that "so-and-so's SSL client works with this server but PSM doesn't" as proof that PSM/NSS are behaving incorrectly. I leave it to kaie and ssaux to decide whether to close this bug as invalid or to change it to a bug about the vagueness of the error message for error code -8182, or some other disposition. If you think this is still an evangelism bug, please record here who should be evangelized and what gospel they should receive.
Attached patch Patch v1 (checked in 2002-07-15) (obsolete) — Splinter Review
This patch adds a better error message for -8182. It will say: Could not establish an encrypted connection because certificate presented by %S has an invalid signature. Where %S will be replaced with the name of the server. The error number -8182 will no longer be included in the message to the user.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: patch, review
Summary: - this bug is somewhat evangelistic, because the web site is using a bad certificate - however, not much hope in evangelize people, let's just display a better error message Changing component to PSM. -> me
Assignee: momoi → ssaux
Component: The Americas → Client Library
Product: Tech Evangelism → PSM
QA Contact: jonrubin → junruh
-> me Javi, can you please review? Sean, is the wording "Could not establish an encrypted connection because certificate presented by %S has an invalid signature." ok?
Assignee: ssaux → kaie
wording looks fine to me.
Comment on attachment 91034 [details] [diff] [review] Patch v1 (checked in 2002-07-15) r=javi
Alec, can you please review?
Status: NEW → ASSIGNED
Comment on attachment 91034 [details] [diff] [review] Patch v1 (checked in 2002-07-15) sr=alecf would be nice to see the other errors displayed in a nicer way at some point :)
Attachment #91034 - Flags: superreview+
Comment on attachment 91034 [details] [diff] [review] Patch v1 (checked in 2002-07-15) a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
Attachment #91034 - Flags: approval+
I think the new error message is missing an indefinite article of speech. I think it should say "... because a certificate ..."
Enhanced error message checked in to trunk. There's nothing more we can do for this problem, servers showing this error need to get fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Oops, I saw Nelson's comment too late. Sean, do you think all PSM's error messages should be changed to include "a" as in "... because a certificate ..."?
If an article is to be added, I think it should be "the" not "a," since presumably it's a single certificate that's being presented (not one of several possibilities): "Could not establish an encrypted connection because the certificate presented by %S has an invalid signature." While the more telegraphic style without the article is common in these kinds of messages--and in my opinion just as clear--it's certainly friendlier to include the article. It would be best to consider this kind of change case-by-case rather than making a blanket change across all strings. But I don't think we should hold anything up for this, since it doesn't affect the meaning.
Sean wrote: > presumably it's a single certificate that's being presented (not one of > several possibilities): Alas, no. The server sends a chain of certificates to the client. If any of the certs in the chain has an invalid signature, you get this error. The error does not tell you which of the certs in the chain had the invalid signature. That's why I suggested the indefinite article.
My mistake. Nelson's right, it should be "a certificate" here.
Reopening. Comments 19-21 show that the word "a" should be inserted after the word "because" into the line "PeersCertBadSignature=Could not establish an encrypted connection because certificate presented by %S has an invalid signature." As of the 7/17 trunk build, the "a" is not included.
Status: RESOLVED → REOPENED
Keywords: nsbeta1
OS: Linux → All
Priority: -- → P3
Hardware: PC → All
Resolution: FIXED → ---
Version: unspecified → 2.3
PeersCertBadSignature=Could not establish an encrypted connection because %S presented a certificate with an invalid signature perhaps? but um.. is there an alternative to establish?
How about "could not connect securely"? I know we try to avoid the word secure, and its various forms, because it's ambiguous. In the case of this error message, I think we want to be precise about the cause (invalid signature), but I don't think we need to be too precise about what it is that we cannot do because of that error.
What's wrong with "Could not establish an encrypted connection . . ." ? Nelson is right that in general we've been trying to use more precise terms than "secure" elsewhere in the interface. I don't see any good reason not to do so here too. Encryption is not a particularly esoteric concept--any Star Trek fan knows (more or less) what it is, for example.
I have almost the exact same problem, except I'm not using a self signed certificate. I have created a certificate authority and signed my web server certificate with that CA. I load the ca.crt as a trusted CA and go to the web server. I got the -8182 error code. However, this works in Netscape 4.7, Mozilla 9.7 and IE 5. It does not work, however, in Mozilla 1.0. Looking at comment #6, the problem seems to be that the CN is the same for both my certificate authority and my web server. I have only one computer, so I didn't really have a choice. If you want to test my setup, here's the info public ca.crt to import http://superfluid.caltech.edu/~chatto/ca.crt web site that won't work https://superfluid.caltech.edu/~chatto/login.php
There is some confusion about the status of this bug. The patch attached to this bug has been checked in a long time ago, see comment 17 from 2002-07-15. I closed the bug on that date, and John reopened the bug two days later: The status is now: - Suggestions have been made to improve the wording - there is not yet a patch that imlements the new wording My intention was the discussion of the improved wording is still in progress. If the discussion is finished, can you please summarize what change should now be made in addition? Thanks
Comment on attachment 91034 [details] [diff] [review] Patch v1 (checked in 2002-07-15) Marking patch as obsolete, since it has been checked in already.
Attachment #91034 - Attachment description: Patch v1 → Patch v1 (checked in 2002-07-15)
Attachment #91034 - Attachment is obsolete: true
Instead of "my intention was" I wanted to say "my impression was the discussion is still in progress".
Should I open a new bug then (per comment #26)? My setup is completely fine, as far as I can tell. It loads in Netscape 4.7X and IE and old Mozilla builds. It is a trusted certificate, but it gets the 8182 error because the CN is the same for the certificate authority and the certificate. (I'm guessing about the last part.) This is pretty much the same bug, but if you want to keep this one for fixing the error message and open a new one for this problem...
Chatto, you said: "the problem seems to be that the CN is the same for both my certificate authority and my web server. I have only one computer, so I didn't really have a choice." The requirement to use a computer's name as the CN for the certificate only applies to the server certificate. There is not requirement for the CN of the CA. As in your situation using the machine name as the CN for the CA certificate is actually causing problems, you really shouldn't do it. I suggest you fix the problem by setting up a new personal CA and use any other CN like "chatto's CA".
I'm seeing this same error (-8182) when I use Netscape 7.0 to try to sign into my.screenname.aol.com. This works in IE and Netscape 4.7. I had problems in Netscape 6.x, but never got any error message! Can only assume it is related since Mozilla is what these two releases have in common. I am accessing through a firewall, but this shouldn't cause a problem -- works fine under IE and 4.7 even behind the firewall. FYI, my HTTP networking settings (http1.1 versus 1.0 and keep alive) don't seem to matter (in case that is relevant). Thanks in advance, Scott
John, can you reproduce the problem mentioned in the previous comment? Scott, could you describe in more detail at which step your problem is happening?
The best I can do is this: 1) go to my.netscape.com 2) click "Sign In" 3) Fill in my userid and password 4) Click "sign in" button. I now see a number of alerts that say: "Could not establish an encrypted connection because certificate presented by my.screenname.aol.com is invalid or correupted. Error Code: -8182" When I tested this just now, the first time, I saw 4 of these alerts in sequence. Then, when I clicked "sign in" again to count them for sure, I only saw two of them. It appears to be 4 alerts when I restart the browser, but only 2 alerts after that. Even if I open a new browser window, and try the sequence again, I only get 2 alerts. As an end-user (not looking at the mozilla code), that is the best I can tell. LMK if there is some way for me to get further debug, and I'll be glad to try it out... Thanks, Scott
I have no problem signing into my.screenname.aol.com. Mr. Gibson, can you try again with a new profile?
Turns out that a new profile fixes the problem, so there is apparently something in my user prefs.js file that is causing problems for Mozilla. I'll investigate further and if I can find a specific setting, will let you know. If you have a guess at where I should start looking, please LMK! Thanks, Scott
You can check on the OCSP settings and whether or not FIPS is enabled. Probably though, one of your *.db files was corrupted.
Thank you for your help. The file "secmod.db" was the one that was corrupt because it is the only one I copied from my new profile to my real profile, and it works!
Marking works for me.
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → WORKSFORME
Version: 2.3 → 2.4
Verified.
Status: RESOLVED → VERIFIED
Product: PSM → Core
I'm reopening because someone using ChatZilla got the exact same error message that was supposed to have gone away after applying this patch. It seems the patch is missing a break; after establishing the error message, which means the user still gets the old message? Kai, am I making sense, or am I missing something?
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
QA Contact: junruh
I agree the patch and existing code are somewhat broken, because of the missing "break", the code following this section will get executed. I don't understand why you get error message "can't load certificate". You should get "Could not establish an encrypted connection because certificate presented by %S is invalid or corrupted. Error Code: %S" We should add the "break" to complete the original patch. After doing so you will get error message "Could not establish an encrypted connection because certificate presented by %S has an invalid signature."
I didn't say I got that error message - that's just the thing that's in the summary, which I didn't change (to my knowledge). The person who told me this (I'm just the messenger here) got the error message you describe. I'll try to get a patch up tonight, but I have some uni homework to finish first.
Patch, I hope.
Attachment #219310 - Flags: superreview?(kengert)
Attachment #219310 - Flags: review?(kengert)
Attachment #219310 - Flags: superreview?(kengert)
Attachment #219310 - Flags: superreview+
Attachment #219310 - Flags: review?(kengert)
Attachment #219310 - Flags: review+
Attachment #219310 - Flags: approval-branch-1.8.1+
Checked in --> FIXED
Status: NEW → RESOLVED
Closed: 22 years ago19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Keywords: fixed1.8fixed1.8.1
Version: psm2.4 → 1.0 Branch
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: