Closed Bug 138746 Opened 24 years ago Closed 24 years ago

Invalid certificate error code -8182

Categories

(Core Graveyard :: Security: UI, defect)

Product:
Core Graveyard
Component:
Security: UI
Version:
Other Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: piotrlg, Assigned: ssaux)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 BuildID: 2002041711 We have certificates generated by openssl 0.9.6. This includes CA and host certificate. Host certificate is signed by our own CA cert. We use 128 bit encoding. The problem started from 0.9.9 milestone till now (mozilla rc1) (so it worked fine till 0.9.8). When I try to get mail using ssl connection to my IMAP server (apache and modssl) this error appears: 'Could not establish en encrypted connection because certificate presented by our.host.name is invalid or corrupted. Error code:-8182' Note, that it works fine with Netscape 4.x and Outlook (with 128 bit). Reproducible: Always Steps to Reproduce: 1.Generate two certificates using openssl (CA and host both 128 bit). 2.Configure smpt, imap etc to use ssl. 3.configure mozilla email account to use ssl 4.get messages 5. error Actual Results: I can't connect to my imap server using ssl. Normal (not ssl) connection works fine.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0
-> PSM (thorgal@amiga.com.pl You should know this if you have the power to confirm. Why do you confirmed this without a comment ?)
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: MailNews → PSM
Version: other → unspecified
Sorry, I actually didn't know that I have to comment. But since you asked: yes, I can the same thing with both POP and IMAP on their server. Mozilla 2002041709/Linux-i686.
Mozilla 1.0RC1 (Build ID 2002041711), Linux (SuSE 7.3, RedHat 7.2) I got the following situation here: * A mail server, RedHat 7.2, imap-2001a, openssl-0.9.6b, using IMAPS with a self issued SSL certificate (not signed by an official CA). * A web server, SuSE 7.3, apache, openssl-0.9.6c, which allows access to the mailbox by HTTPS. Another self issued certificate, not signed by an official CA. Note that both certificates were created by different people on different machines with different Linux and OpenSSL versions. With the very same Mozilla, I *can* access the IMAPS mail server without any problems. But as soon as I try to access the mailbox by HTTPS, I will get this error code as stated by the reporter. It was working fine before Mozilla 1.0RC1. It was even working with Mozilla 0.9.9 here. @piotrlg: Can you give the exact OpenSSL version (0.9.6 a, b or c)?
> @piotrlg: Can you give the exact OpenSSL version (0.9.6 a, b or c)? The exact versions are: OpenSSl 0.9.6 (precompiled solaris package), imap 2001. You may try this link to install our own CA certificate: http://sci.pam.szczecin.pl/cgi-bin/InstCAcert.pl then try https://sci.pam.szczecin.pl. It should generate the error 8182. What is strange: https://med.pam.szczecin.pl works fine (both email and www) despite it is *exactly* the same machine as sci(except for the host certificate of course).
cc nelsonb
The problem is apparently related to the cert. I suggest the submittor attach the DER certs (the server cert and its entire cert chain, base 64 encoded) to this bug.
We have looked closer to our certificates. The problem is with our own generated CA cert, because host specific certificates worked fine. Finally I can access mail or www using ssl and the latest mozilla. What we have changed in CA cert was the Common Name. Previously CA cert was generated by 'sci' and for 'sci' and it caused that only 'med' was working. Now CA was generated on completely another host and on that another host this new CA was used to sign host certificates for sci and med. So it looks like that CA cert shouldn't have nothing in common with the hosts it is used by. I wonder why is it so? Having small network and only one host you can't generate your own CA and use it to sign this one host. Thats only mozilla behavior ;-( Is it normall (standard legal?) or bug?
Reporter, do you have FIPS enabled? If so, try disabling it. Edit>Prefs>Privacy>Manage Security Devices>Disable FIPS.
No, I don't have FIPS enabled.
I believe I now know why the signature verification failed before, and why it succeeds after changing the CN attribute of the server cert's subject name. Since I do not have the original pair of certs, with which the problem was experienced, I can only conjecture, but this conjecture is consistent with what I now observe. If this conjecture is correct (Piotr, please confirm) then this bug is invalid, and is due to the creation of an invalid cert chain. Looking at the certs that Piotr's systems have now, I see that all the certs, including the server certs and the CA cert, all have subject names that are identical, except for one field, and that field is the CN. Here's one example: cms.pam.szczecin.pl <- different on each cert operator@pam.szczecin.pl <- same on all certs ZIB <- same on all certs PAM <- same on all certs Szczecin, Zachodniopomorskie, PL <- same on all certs. According to Piotr's comment #7 above, originally, his CA cert's subject name had CN=sci.pam.szczecin.pl and he had two server certs, one of which also had CN=sci.pam.szczecin.pl, and the other had CN=med.pam.szczecin.pl. With that combination, he found that he was able to access the "med" server, but not the "sci" server. Now, with the added knowledge (missing from comment #7) that the certs' subject names were all identical except for the CN attribute, it is apparent why he got an invalid signature error on the sci server, but not on the med server, and why after changing the CNs so that no two certs had the same CN any more, the signatures were valid. Prior to the change, the subject name in the root CA cert and the subject name in the https server cert for the "sci" server were identical. Consequently, the subject name and the issuer names in the sci server cert were identical, causing the sci server cert to appear to be self-signed, even though it was not actually self signed. Both the sci server cert and the root CA cert appeared to be self-signed certs. It was an invalid cert chain. The signature on the "sci" server cert could be correctly verified using the public key in the root CA cert, but because the sci server cert appeared to be self-signed, its signature was verified using the public key in the same sci server cert, not with the public key in the root CA cert. The med server cert did not have this problem, it did not appear to be self signed. Changing the sci server cert so that its issuer and subject names were no longer identical caused the cert to no longer appear to be self-signed, which in turn enabled SSL to find the correct issuer CA cert and verify the signature properly. Nevertheless, the cert chain was invalid (containing two apparently self-signed certs), so this bug report is invalid. I will mark the bug resolved invalid. Piotr, if you still have those old certs, and the sci server's cert did not have identical subject and issuer names, you may reopen this bug report. The problem Richard Körber described in comment #3 is different (but similar) in that both his server certs were self signed, and he had no separate root CA cert (as I understand it). So, that appears to be a different issue. Richard, If you're still having that problem, please file a separate bug about it, and CC me.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Verified.
Status: RESOLVED → VERIFIED
This bug is invalid. That is rigth. I generated new CA certificate on other host (cms.pam.szczecin.pl) whit "common name" value - cms.pam.szczecin.pl Then I genereted and signed new certificate for sci.pam.szczecin.pl and med.pam.szczecin.pl hosts. The value "common name" must be different for CA certificate and certificates hosts. Now this is working ok. Thanks for your help.
*** Bug 167733 has been marked as a duplicate of this bug. ***
Product: PSM → Core
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.