Implications of Root CA without CRL

certificate-authoritycrlpki

I'm currently setting up a PKI for my company and while I have come up with a good layout and planned the overall policy of certificate issuance, I'm still puzzled by what role the CRL plays.

By looking at other root CA certificates installed in browsers, we concluded that we could go without a revocation list for our root CA.

We also based it on the fact that our certificate chain will be installed in strictly firewalled and closed environments on our customer sites, which means retrieving the CRL from our HTTP site won't work.

Is it a bad idea not to include a CRL in the root? And would applications (IIS, IE, Firefox) behave badly or need additional configuration to work right?

I'm aware that by not having CRL's, I lose the ability to revoke a certificate, but this is currently not an issue. The question concerns the root, the subordinate CA would, or could, have a CRL, depending on the Class (Class 1 = production, Class 3 = testing etc.) according to our CP.

Best Answer

If you're willing to scrap the root CA completely the event that it's used to issue a bad certificate, or an issued certificate is compromised, then it should be no problem.

If the certificate doesn't specify CRL distribution points, then (as far as I'm aware) browsers and other certificate validators should have no qualms about validating the certificate.

Even if an unreachable CDP is specified, browsers are very.. lax about allowing the certificate anyway - this is why the recent certificate authority compromises have prompted OS and browser vendors to issue patches blacklisting the certificates, instead of just trusting browsers to check the CRL properly.

Related Solutions

Unable to submit certificate request to 2k8R2 CA

I was able to resolve this after finding further information You cannot submit a certificate request generated by Exchange Management Console (EMC) or Exchange Management Shell (EMS) to Microsoft Certificate Services

In summary, this is becuase the certificate request was stored as Unicode encoding and Microsoft Certificate services do not support unicode-encoded files.

The fix is to open the request file in notepad and save-as as a new file this time with ANSI encoding. Resubmitting this ANSI encoded file to the CA is then works and certificate is issued.

Re-issuing self-signed root CA without invalidating certificates signed by it

Two certificates are considered the same as long as the Subject Name and the Public Key of the certificates match.

Therefore, all you need to do is to re-use the keys and ensure that the Subject Name in the new certificate is the same as the old. After that, you can change any of the other fields and/or extensions and the resulting certificate will be considered the same.

For example, create your OpenSSL configuration file:

[ req ]

prompt             = no
string_mask        = default
distinguished_name = x509_distinguished_name
x509_extensions     = x509_ext

[ x509_distinguished_name ]

# Note that the following are in 'reverse order' to what you'd expect to see.
# Adjust for your setup:

countryName = za
organizationName = My Company
organizationalUnitName = Security
commonName = My Root CA

[ x509_ext ]

basicConstraints = critical,CA:true
keyUsage = critical, keyCertSign, cRLSign
subjectKeyIdentifier = hash
crlDistributionPoints = URI:http://security.mycompany.co.za/root.crl

and save it as e.g. rootca.cnf. Ensure that the elements of the [req_distinguished_name] are identical to the ones in your original Root CA certificate (this is the identical Subject Name part).

Next, run:

openssl req -new -x509 -key rootca.key -out MyNewCA.pem -config rootca.cnf

where rootca.key is the private key used in the original certificate (this is the identical Public/Private Key part).

This creates MyNewCA.pem, which you can check with:

$ openssl x509 -noout -text -in MyNewCA.pem

Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 17564687072266118846 (0xf3c24dd49d5166be)
Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=za, O=My Company, OU=Security, CN=My Root CA
    Validity
        Not Before: Jul 15 05:05:54 2017 GMT
        Not After : Aug 14 05:05:54 2017 GMT
    Subject: C=za, O=My Company, OU=Security, CN=My Root CA
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:c8:3d:32:8a:56:31:f6:27:1a:ce:9e:b2:1d:fb:
                ce:9f:ce:5b:42:25:aa:fe:8b:f4:34:32:ac:b3:02:
                50:71:f8:c3:43:0c:c7:2c:9f:fe:48:1b:c6:c0:e7:
                d6:44:a9:e7:d7:a0:7e:58:f4:b6:38:61:7e:d0:af:
                0f:56:21:e7:49:7a:66:13:f5:7a:fe:3d:ab:65:f8:
                01:eb:52:a7:3b:ae:a0:cf:50:57:b9:e0:09:0b:1f:
                90:14:fb:18:56:1d:57:99:a9:76:a2:63:d1:c2:d3:
                a3:f4:3a:ff:91:0d:ee:8d:44:13:58:00:09:93:da:
                e8:6a:fd:64:5f:c3:42:8e:2a:49:6e:0d:73:b7:b9:
                d4:6c:c6:ce:30:c5:82:24:a5:00:37:17:a0:1d:f1:
                c9:e9:e3:18:48:22:4f:33:96:a7:3c:a9:31:f1:3f:
                14:40:6a:74:e8:78:82:45:04:d4:4b:56:0b:cd:be:
                48:8d:03:fb:39:70:0b:91:99:70:06:bd:5e:8b:f2:
                d1:f4:6f:fc:ce:e7:f8:3c:0a:20:ea:35:b8:5f:2f:
                ee:8d:ff:d3:93:85:6b:fb:71:db:1b:e6:e9:1d:a7:
                f8:e4:ae:f4:71:fe:35:a7:89:24:af:69:a4:34:3b:
                14:66:05:02:5e:2a:1d:ac:e0:d2:48:6c:13:4e:75:
                58:93
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 Subject Key Identifier: 
            3B:45:93:3A:2A:BC:39:29:36:13:6C:BD:B6:B4:31:C7:E7:BB:32:73
        X509v3 CRL Distribution Points: 

            Full Name:
              URI:http://security.mycompany.co.za/root.crl

Signature Algorithm: sha256WithRSAEncryption
     4d:96:d4:03:4f:e3:7c:26:be:59:f8:23:87:60:f7:4c:d3:a1:
     1c:77:a1:14:e3:e7:da:c8:2a:a3:1b:06:2a:4d:55:1c:83:26:
     73:46:0d:8a:e4:b7:d1:1e:38:cc:78:90:00:01:b3:8e:f9:3c:
     62:be:04:09:90:4e:22:87:b1:aa:bd:f9:73:bd:a7:76:ad:d5:
     ae:2d:7a:1c:1e:1a:67:c8:57:4c:f9:6d:8b:62:d6:e5:ea:e0:
     40:5c:12:28:7e:ea:f0:0c:d6:cd:f4:1d:d5:56:09:ad:43:b4:
     eb:8c:68:ce:56:a2:a8:ae:a4:d5:35:bb:58:b8:ed:82:82:b5:
     ef:cb:e2:6d:76:61:ed:ee:a5:1f:68:95:07:ed:5b:f0:65:92:
     d2:dc:1d:c6:fa:7f:e0:c9:38:c2:c6:6f:03:38:e7:3a:b0:24:
     06:e0:bc:07:dd:e7:a0:dc:74:09:e5:37:7b:66:e1:6f:47:4c:
     71:ff:02:48:7f:d4:4f:ce:cb:91:e9:ee:cd:b6:f1:0a:03:19:
     3e:19:05:7d:8f:48:e7:f1:cc:07:37:3d:91:3c:6f:54:71:3c:
     a2:6c:55:c3:03:c1:7f:eb:9e:70:f1:8f:a1:fb:62:33:8b:86:
     2c:79:bc:76:e2:01:9a:68:df:af:40:a1:b2:9c:f6:a1:e1:6e:
     2a:dd:1a:d6

Use this new certificate in place of the original.

You can change other fields and extensions, such as the validity period of the certificate, but bear in mind that you shouldn't really have any constraints (other than basicConstraints = critical,CA:true) on the Root CA certificate.

After further consideration, your issue may simply be down to the fact that your replacement Root CA certificate doesn't have the basicConstraint and possibly the keyUsage extensions. It might be worth trying adding those two extensions to your ext.conf first and testing the resulting new Root CA certificate using the -x509toreq method you posted.

Best Answer

Related Solutions

Unable to submit certificate request to 2k8R2 CA

Re-issuing self-signed root CA without invalidating certificates signed by it

Related Topic