231686 - imaps connection failure: error code -8101

Status: RESOLVED DUPLICATE of bug 231775

(MailNews Core :: Networking: IMAP, defect)

Description

[Chris P. Ross]

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...

Comment 1

[David :Bienvenu]

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).

Comment 2

[Chris P. Ross]

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...

Comment 3

[David :Bienvenu]

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.

Comment 4

[Chris P. Ross]

Attachment: ssltap output for the connection generating error -8101 for mozilla

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?

Comment 5

[David :Bienvenu]

I wonder if the cert is simply corrupted:

   length  = 2 (0x2)
   fatal: certificate unknown
}

Cc'ing someone *much more* NSS-aware

Comment 6

[Chris P. Ross]

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...

Comment 7

[David :Bienvenu]

this looks like it's a dup of bug 231775

Comment 8

[Chris P. Ross]

...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?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

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 :)

Comment 11

[David :Bienvenu]

resolving as dup of 231775, thx, Nelson!

*** This bug has been marked as a duplicate of 231775 ***