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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: alain, Assigned: KaiE)
References
()
Details
(Keywords: fixed1.8.1)
Attachments
(1 file, 1 obsolete file)
941 bytes,
patch
|
KaiE
:
review+
KaiE
:
superreview+
KaiE
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
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!?]
Comment 1•23 years ago
|
||
-> PSM
Assignee: darin → ssaux
Component: Networking: HTTP → Client Library
Product: Browser → PSM
QA Contact: tever → junruh
Version: other → unspecified
Comment 2•23 years ago
|
||
Can you try turning off FIPS? Edit>Prefs>Privacy>Certs>Manage Devices>Disable
FIPS.
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
..so no Evang, just Web-Trash working nowhere
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 5•23 years ago
|
||
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 → ---
Reporter | ||
Comment 6•23 years ago
|
||
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.
Comment 7•23 years ago
|
||
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.
Assignee | ||
Comment 8•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Comment 9•23 years ago
|
||
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
Assignee | ||
Comment 10•23 years ago
|
||
-> 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
Comment 11•23 years ago
|
||
wording looks fine to me.
Comment 12•23 years ago
|
||
Comment on attachment 91034 [details] [diff] [review]
Patch v1 (checked in 2002-07-15)
r=javi
Comment 14•23 years ago
|
||
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 15•23 years ago
|
||
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+
Comment 16•23 years ago
|
||
I think the new error message is missing an indefinite article of speech.
I think it should say "... because a certificate ..."
Assignee | ||
Comment 17•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 18•23 years ago
|
||
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 ..."?
Comment 19•23 years ago
|
||
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.
Comment 20•23 years ago
|
||
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.
Comment 21•23 years ago
|
||
My mistake. Nelson's right, it should be "a certificate" here.
Comment 22•23 years ago
|
||
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
Comment 23•23 years ago
|
||
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?
Comment 24•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
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.
Comment 26•22 years ago
|
||
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
Assignee | ||
Comment 27•22 years ago
|
||
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
Assignee | ||
Comment 28•22 years ago
|
||
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
Assignee | ||
Comment 29•22 years ago
|
||
Instead of "my intention was" I wanted to say "my impression was the discussion
is still in progress".
Comment 30•22 years ago
|
||
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...
Assignee | ||
Comment 31•22 years ago
|
||
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".
Comment 32•22 years ago
|
||
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
Assignee | ||
Comment 33•22 years ago
|
||
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?
Comment 34•22 years ago
|
||
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
Comment 35•22 years ago
|
||
I have no problem signing into my.screenname.aol.com. Mr. Gibson, can you try
again with a new profile?
Comment 36•22 years ago
|
||
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
Comment 37•22 years ago
|
||
You can check on the OCSP settings and whether or not FIPS is enabled. Probably
though, one of your *.db files was corrupted.
Comment 38•22 years ago
|
||
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!
Comment 39•22 years ago
|
||
Marking works for me.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
Version: 2.3 → 2.4
Comment 41•19 years ago
|
||
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 → ---
Updated•19 years ago
|
Status: REOPENED → NEW
QA Contact: junruh
Assignee | ||
Comment 42•19 years ago
|
||
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."
Comment 43•19 years ago
|
||
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.
Comment 44•19 years ago
|
||
Patch, I hope.
Attachment #219310 -
Flags: superreview?(kengert)
Attachment #219310 -
Flags: review?(kengert)
Assignee | ||
Updated•19 years ago
|
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+
Comment 45•19 years ago
|
||
Checked in --> FIXED
Assignee | ||
Updated•19 years ago
|
Keywords: fixed1.8 → fixed1.8.1
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•