143280 - Invalid Certificate -8102

Status: VERIFIED INVALID

(Core Graveyard :: Security: UI, defect, P2)

Description

[Steve Egbert]

Got this error dialog box showing "Could not establish an encrypted connection
because certificate presented by egbert.net is invalid or corrupted. Error Code:
-8102" when trying to access https://www.egbert.net/

The certificate key is a jumbo-capability (all options) and serves "*.egbert.net"

Comment 1

[Steve Egbert]

Works with Microcrap Internet Explorer 6.0.2600.0000 and 5.1, but ONLY AFTER
saying YES to accepting the security certificate authority.

The Egbert Family Network certificate authority is a self-signed CA certificate.

Comment 2

[John Unruh]

Confirming. Nav 4.79 cannot connect either.

Comment 3

[Stephane Saux]

confirm that it works in IE.
cc nelsonb.
The error is SEC_ERROR_INADEQUATE_KEY_USAGE

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

There are numerous problemw with the SSL server cert being supplied by this
SSL server.   Here's one of them, the one that causes the error code named
above.

This cert contains a Netscape Certificate Type extension.  That extension was 
defined by Netscape before X.509 added the extended Key usage extension, 
OID { 2 5 29 37 }, which accomplishes the same thing.  This specification is 
public, and any software is free and welcome to recognize and use this 
extension, but Netscape NSS-based software always recognizes and honors it.  
It is probably ignored by IE.  

This extension, if present, limits the types of applications for which the 
certificate can be used by Netscape software.  It always reduces the 
acceptable applications, it never increases the acceptable applications.  
Adding it to a cert reduces the uses of the cert, it does not increase them.
The 8 defined classes of applications that can be specified by this 
extension are:

SSL_CLIENT         (0x80)   ASN.1 bit 0 (ASN.1 numbers bits left to right)
SSL_SERVER         (0x40)
EMAIL              (0x20)
OBJECT_SIGNING     (0x10)
RESERVED           (0x08)
SSL_CA             (0x04)
EMAIL_CA           (0x02)
OBJECT_SIGNING_CA  (0x01)   ASN.1 bit 7 

This cert's Certificate Type extension bears the value 0x06, with the last bit
being "unused" and therefore zero.  This value tells Netscape software (and any 
other software that recognizes this publicly defined extension) that this cert 
is only valid to be used as an SSL CA or as an EMAIL (S/MIME) CA, but not valid 
to be used as an SSL client or an SSL server or for an email signature or for a 
jar file signature.

So, this certificate explicitly tells Netscape software that it is not 
valid to be used as an SSL server, yet an SSL server is using it as its
server certificate.

I'd guess that IE ignores this extension, and does not disallow this cert
to be used as an SSL server cert for that reason.

If the creator of this cert was trying to build a "super cert", that can be 
used for all types of applications, then it would be better to just omit this 
extension, or for the cert type usage extension to contain the value 0xFF, 
allowing all 8 classes of application.

However, there are also other problems with this cert.  This cert also bears
an X.509 keyUsage extension, OID (2 5 29 15), with the value 0x06.  
The bits in that extension are defined as follows:

KU_DIGITAL_SIGNATURE            (0x80)  /* bit 0 */
KU_NON_REPUDIATION              (0x40)  /* bit 1 */
KU_KEY_ENCIPHERMENT             (0x20)  /* bit 2 */
KU_DATA_ENCIPHERMENT            (0x10)  /* bit 3 */
KU_KEY_AGREEMENT                (0x08)  /* bit 4 */
KU_KEY_CERT_SIGN                (0x04)  /* bit 5 */
KU_CRL_SIGN                     (0x02)  /* bit 6 */

So, the value 0x06 tells us that the cert is valid for Cert Signing (that is
for issuing certs), and for signing CRLs, but not for other purposes such as
key encipherment or key agreement.  To be valid as an SSL server cert with an 
RSA public key, the cert must be allowed for key encipherment, which this cert 
is not.  

The key usage extension is optional, except in CA certs, and if present it 
serves only to limit (reduce) the usages for which the cert is acceptable. 

This server cert is self signed.  It is apparently intended to be both an 
SSL server cert and a CA cert.  There are likely to be other problems 
associated with having one cert that is both CA and SSL server.  

I recommend having separate CA and SSL server certs.  This is the intent 
of the PKI specs, and is more likely to work in many cases.  

I'm resolving this bug invalid, because the cert appears to be invalid for
use as an SSL server cert.

Comment 5

[John Unruh]

Verified. Thanks for your explanation, Nelson.

Comment 6

[Henrik Gemal]

*** Bug 193991 has been marked as a duplicate of this bug. ***

Comment 7

[John Unruh]

*** Bug 206280 has been marked as a duplicate of this bug. ***

Comment 8

[Jaime Mitchell (use [e-mail] for email)]

*** Bug 294470 has been marked as a duplicate of this bug. ***

Comment 9

[Adam Guthrie]

*** Bug 322296 has been marked as a duplicate of this bug. ***