Closed Bug 153232 Opened 19 years ago Closed 15 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: 19 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: 19 years ago19 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: 19 years ago18 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: 18 years ago15 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.