This is the same in both Mozilla 1.4.1 and Thunderbird 0.4, so I assume it is still a problem on the trunk, but have not yet verified that. I've been trying to debug an UW imap server running with a cert purchased from Verisign. I finally got it working, sortof, but while mutt will connect to it (tho it has some problem it doesn't tell me about, but lets me "accept once" and goes on to work), and the apple Mail client (OS X 10.2.latest) just connected but doesn't indicate any problem anywhere, before mozilla will even ask me about the cert, or ask for a password, it simply says: Could not establish an encrypted connection because certificate presented by <FQDN of server> is invalid or corrupted. Error Code: -8101 However, it doesn't give me an option to look at the cert, or indicate what the problem might be. This is my main problem. Also, in looking through the source, it appears that -8101 is ER3(SEC_ERROR_INADEQUATE_CERT_TYPE, (SEC_ERROR_BASE + 91), "Certificate type not approved for application.") I'm not sure what that means... I've put the imap server back, but there's currently a test server running on port 994 of the same server with that cert, and if anyone has time to look into it, I'd be happy to supply a hostname for testing. Thanks...

I don't really know about this myself - from the code, it looks like the cert required from the server is NS_CERT_TYPE_SSL_CA, if the useage is certUsageSSLServer or certUsageSSLServerWithStepUp, so it just sounds like you don't have the right kind of cert from verisign. The "key useage" has to be KU_KEY_CERT_SIGN, and if you're using SSL stepup, KU_NS_GOVT_APPROVED. Are you using TLS or straight SSL (connecting on the SSL port).

I'm not sure myself. How can I tell what type of cert it is? Actually, there should be two certs. The one for my server, and the "intermediate" cert which is the one signed by the Verisign CA root cert. Could this be part of the problem? According to UW imap lists and discussions, if I put the intermediate cert in the same file as the server cert and private key, it should work. And, as noted, it seems to for other clients, to varying degrees... Let me know anything you'd like me to try...

At this point, we're really in UW server configuration land and I don't know anything about that. I would think there are tools to look at certs - mozilla has such tools, but they're distributed in source code form: http://www.mozilla.org/projects/security/pki/nss/tools/ you might try asking in this newsgroup: news://news.mozilla.org/netscape.public.mozilla.crypto or tune in to the IRC channel #mozcrypto on the server irc.mozilla.org.

Thanks for the pointer. I downloaded the bundle of nss-3.8 tools for solaris 2.8 on sparc, which is what I'm using as a client right now. This is the output of an attachement to the imap server in question, with the cert in question. It does actually appear to send back both certs. It saved them, but I'm not sure what to do to figure out their "type". the vfyserv program returns: Connecting to host FQDN (addr XX.XX.XX.XX) on port 994 PROBLEM WITH THE CERT CHAIN: CERT 0. : ERROR -8101: Certificate type not approved for application. OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign, OU=VeriSign International Server CA - Class 3, OU="VeriSign, Inc.", O=VeriSign Trust Network Error in function PR_Write: -8101 - Certificate type not approved for application. So, it looks like it's complaining about the intermediate cert. But, it has to be sent by imapd, or else no client will be able to trust the server cert. Any other ideas? Wanna CC someone more NSS-aware to help?

I wonder if the cert is simply corrupted: length = 2 (0x2) fatal: certificate unknown } Cc'ing someone *much more* NSS-aware

No, I think that's just the length and content of the client's message back to the server. The length and info about the certs are up above, in read, where the server is sending them to the client...

this looks like it's a dup of bug 231775

...or 231775 is a dup of this. But I think the description of 231775 is more clear, and little would be lost by marking this as a dup. MisterSSL agree?

SSLtap output! I'm impressed! Your brand new cert contains an extension called a "Extended Key Usage" extension. That extension is a collection of Object Identifier numbers (a.k.a. OIDs) that define the purposes for which the cert may be used. Let me tell you about some OIDs that commonly appear in that extension. There is an OID that means "SSL Server authentication", and there is another OID that means "SSL Step Up Server". A "Step Up" server is one that will enable old "export" browsers (remember them?) to "step up" to 128-bit crypto. Some CAs charge a LOT of extra money to put that Step-Up OID in your cert, even though export browsers are a thing of the past. If you get a cert that has the Step-Up OID, but does NOT also have the SSL Server Authentication OID, you will get this error, -8101, Inadequate key usage, or in other words "Your cert doesn't allow the usage that you want to do (namely SSL server authentication). The immediate solution is for you to get another cert (I think you shouldn't have to pay for it again) that has the SSL Server auth OID in the Extended Key Usage list. I have opened bug 231775 against NSS about this. The two bugs are not DUPs because they're about different products.

David, if you want to resolve this bug a dup of bug 231775, that would be OK. This bug is also a dup of bug 107491 :)

resolving as dup of 231775, thx, Nelson! *** This bug has been marked as a duplicate of 231775 ***