Closed Bug 660836 Opened 9 years ago Closed 4 years ago

Self Signed Root-CA not correctly verified when keyUsage set (Certificate Sign, CRL Sign)

Categories

(Core :: Security: PSM, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: pest, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
Build Identifier: 3.1.10, Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10

If I try to install a X.509 Root or intermediate CA with the keyUsage bits set to
(Certificate Sign, CRL Sign) Thunderbird doesn't detect the correct uses for the CA. KeyUsage is defined as required in the RFC.
Thunderbird behaves wrong and this makes e-mail encryption totally useless as the corresponding encryption certificate is not found correctly.

If keyUsage in the CA-certificates is removed, Thunderbird detects the correct uses and encryption is possible.
 


Reproducible: Always

Steps to Reproduce:
1. Import new self signed Root-CA with keyUsages set
2. Check Uses of the imported Root-CA (contains only "SSL Certificate Authority")
3. Import Root-CA with keyUsage removed.
4. Check Uses of the imported Root-CA (contains other uses as well)
Can you give more details on how your key was created ?
Component: Security → Security: PSM
Product: Thunderbird → Core
QA Contact: thunderbird → psm
I have the same problem:
using openssl to create root CA with attributes:

keyUsage = cRLSign, keyCertSign
nsCertType = sslCA, emailCA

in openssl.cnf

than it is not possible to choose identify email users with this root CA
Can you attach the certitifcate? ( I would like to see all the certificate details)
I sent my root ca certificate via email to you
(In reply to Peter from comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
> rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17
> Build Identifier: 3.1.10, Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
> rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
> 
> If I try to install a X.509 Root or intermediate CA with the keyUsage bits
> set to
> (Certificate Sign, CRL Sign) Thunderbird doesn't detect the correct uses for
> the CA. KeyUsage is defined as required in the RFC.
> Thunderbird behaves wrong and this makes e-mail encryption totally useless
> as the corresponding encryption certificate is not found correctly.
> 
> If keyUsage in the CA-certificates is removed, Thunderbird detects the
> correct uses and encryption is possible.
>  
> 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. Import new self signed Root-CA with keyUsages set
> 2. Check Uses of the imported Root-CA (contains only "SSL Certificate
> Authority")
> 3. Import Root-CA with keyUsage removed.
> 4. Check Uses of the imported Root-CA (contains other uses as well)

This behavior is expected. The KeyUsages extension places limits on what that particular certificate can do (see rfc 5280, section 4.2.1.3: http://tools.ietf.org/html/rfc5280#section-4.2.1.3)  The absence of KeyUsages implies that any usage is valid for that partciular certificate.

Unless you disagree with this I will close this bug as invalid soon.
(In reply to Lars Hartmann from comment #4)
> I sent my root ca certificate via email to you

Lars, your problem is different, you cannot see that the certificate can be used as a trust anchor for email. Plase file a different bug. Notice also that the use of nsCertType is deprecated.
Hello Camilo, which flag I have to set for the root ca certificate to verify the client certificates:

KeyUsage ::= BIT STRING {
           digitalSignature        (0),
           nonRepudiation          (1), -- recent editions of X.509 have
                                -- renamed this bit to contentCommitment
           keyEncipherment         (2),
           dataEncipherment        (3),
           keyAgreement            (4),
           keyCertSign             (5),
           cRLSign                 (6),
           encipherOnly            (7),
           decipherOnly            (8) }

cRLSign, keyCertSign are set. which other one is needed?
thanks for your help.
[solved]: I played a little bit with options in openssl.cnf. and now it works!
If someone is interested or has the same problem, here is the coontent of my openssl.cnf (section [ usr_cert ] for client certificates and section [ v3_ca ] for the RootCA ):

# For use with easy-rsa version 2.0

#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn't
# defined.
HOME			= .
RANDFILE		= $ENV::HOME/.rnd
openssl_conf		= openssl_init

[ openssl_init ]
# Extra OBJECT IDENTIFIER info:
#oid_file		= $ENV::HOME/.oid
oid_section		= new_oids
engines                 = engine_section

# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions		= 
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by 'ca' and 'req'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6

####################################################################
[ ca ]
default_ca	= CA_default		# The default ca section

####################################################################
[ CA_default ]

dir		= $ENV::KEY_DIR		# Where everything is kept
certs		= $dir			# Where the issued certs are kept
crl_dir		= $dir			# Where the issued crl are kept
database	= $dir/index.txt	# database index file.
new_certs_dir	= $dir			# default place for new certs.

certificate	= $dir/ca.pem	 	# The CA certificate
serial		= $dir/serial 		# The current serial number
crl		= $dir/crl.pem 		# The current CRL
private_key	= $dir/ca.key	 	# The private key
RANDFILE	= $dir/.rand		# private random number file

x509_extensions	= usr_cert		# The extentions to add to the cert

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crl_extensions	= crl_ext

default_days	= 3650			# how long to certify for
default_crl_days= 30			# how long before next CRL
# default_md	= md5			# which md to use.
default_md	= sha1			# which md to use.
preserve	= no			# keep passed DN ordering

# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy		= policy_anything

# For the CA policy
[ policy_match ]
countryName		= match
stateOrProvinceName	= match
organizationName	= match
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional

# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName		= optional
stateOrProvinceName	= optional
localityName		= optional
organizationName	= optional
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional

####################################################################
[ req ]
default_bits		= $ENV::KEY_SIZE
default_keyfile 	= privkey.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
x509_extensions	= v3_ca	# The extentions to add to the self signed cert

# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret

# This sets a mask for permitted string types. There are several options. 
# default: PrintableString, T61String, BMPString.
# pkix	 : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
string_mask = nombstr

# req_extensions = v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]
countryName			= Country Name (2 letter code)
countryName_default		= $ENV::KEY_COUNTRY
countryName_min			= 2
countryName_max			= 2

stateOrProvinceName		= State or Province Name (full name)
stateOrProvinceName_default	= $ENV::KEY_PROVINCE

localityName			= Locality Name (eg, city)
localityName_default		= $ENV::KEY_CITY

0.organizationName		= Organization Name (eg, company)
0.organizationName_default	= $ENV::KEY_ORG

# we can do this but it is not needed normally :-)
#1.organizationName		= Second Organization Name (eg, company)
#1.organizationName_default	= World Wide Web Pty Ltd

organizationalUnitName		= Organizational Unit Name (eg, section)
#organizationalUnitName_default	=

commonName			= Common Name (eg, your name or your server\'s hostname)
commonName_max			= 64

emailAddress			= Email Address
emailAddress_default		= $ENV::KEY_EMAIL
emailAddress_max		= 40

# JY -- added for batch mode
organizationalUnitName_default = $ENV::KEY_OU
commonName_default = $ENV::KEY_CN

# SET-ex3			= SET extension number 3

[ req_attributes ]
challengePassword		= A challenge password
challengePassword_min		= 4
challengePassword_max		= 20

unstructuredName		= An optional company name

[ usr_cert ]

# These extensions are added when 'ca' signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=critical,CA:FALSE

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = clientAuth, emailProtection, 1.3.6.1.5.5.7.3.7, 1.3.6.1.4.1.311.20.2.2

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
subjectAltName=email:copy

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl		= http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

[ server ]

# JY ADDED -- Make a cert with nsCertType set to "server"
basicConstraints=critical,CA:FALSE
nsCertType			= server

subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage=serverAuth

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment

[ v3_ca ]


# Extensions for a typical CA


# PKIX recommendation.

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer:always

# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = critical,CA:true,pathlen:0

# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
keyUsage = critical, cRLSign, keyCertSign

certificatePolicies=anyPolicy

# Some might want this also
# nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF

[ crl_ext ]

# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.

# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always

[ engine_section ]
#
# If you are using PKCS#11
# Install engine_pkcs11 of opensc (www.opensc.org)
# And uncomment the following
# verify that dynamic_path points to the correct location
#
pkcs11 = pkcs11_section

[ pkcs11_section ]
engine_id = pkcs11
dynamic_path = /usr/lib/engines/engine_pkcs11.so
MODULE_PATH = $ENV::PKCS11_MODULE
PIN = $ENV::TOKEN_PIN
init = 0
Looks like the issue here was that a correct key usage was not included.

Currently, it looks like the requirement is either digitalSignature or nonRepudiation: https://hg.mozilla.org/mozilla-central/annotate/7d517a67d1a2/security/certverifier/CertVerifier.cpp#l490
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.