7

I recently started using AWS's Certificate Manager to get free TLS certificates for my load balancer. When I was inspecting the certificate chain I noticed that the Root CA, Starfield Class 2 Certification Authority, has the following extended key usage values:

  • SSL client
  • SSL server
  • Netscape SSL server
  • S/MIME signing
  • S/MIME encryption
  • CRL signing
  • Any Purpose
  • OCSP helper
  • Time Stamp signing

I then opened up the Trusted Root Certification Authorities store on a Windows laptop I have and started looking at several of the root CAs. It turns out that a lot of them have the same or very similar EKU values. I understand why CRL and OCSP are present (even though I would imagine the root would be kept offline which would make OCSP a bit more difficult), but why the others? Does this mean that the CA, in addition to issuing certificates, can also sign code, perform S/MIME functionality, etc.? Or does the presence of these values mean that certificates that descend from this root CA can only be used for, at most, those EKU values?

I briefly skimmed the Extended Key Usage section of RFC 5280 and the only thing I saw on the topic was this:

In general, this extension will appear only in end entity certificates.

To summarize my questions:

  1. Does placing these EKU values in the root CA cert indicate that the end-entity certificates descending from that root can have, at most, those EKU values?
  2. If no to 1, why are these values present in multiple root CAs? Is it so these CAs can also be used for those purposes? If so, why would one want to do that instead of issuing an end-entity certificate with those EKUs?
Community
  • 1
Hmmmmm
  • 235
  • 2
  • 7

3 Answers3

3

Does placing these EKU values in the root CA cert indicate that the end-entity certificates descending from that root can have, at most, those EKU values?

this is correct. The valid EKU for particular certificate is (roughly) the intersection of the EKU extension restrictions in the full cert chain. So if a CA cert has an EKU extension containing OID1 and OID2, it cannot issue certs that are valid for any other EKU OID.

However, this is not strict rule, it depends on a client application that performs certificate validation. For example, in order to validate OCSP Signing certificate, it is enough to have OCSP Signing (1.3.6.1.5.5.7.3.9) only in leaf (signing) certificate. Entire chain is not required to be valid for OCSP Signing usage.

If the issued cert contains another EKU OID and client application asks if the certificate is valid for specified usage, certificate chaining engine will not consider the cert valid for that OID.

Update 26.09.2018:

statement above is not part of RFC. In fact, RFC does not restrict CA on issuing EKU.

It is just about major vendor implementation. Systems and browsers usually implement internal cert storage (Certificate Store, KeyChain, TrustStore, etc.) and cert storage implements store-attached properties, where you or vendor can assign additional attributes to certificate without modifying signing certificate. This is how EKU constraints is handled in your example certificate. If you open the certificate, you won't find any EKU extension in it:

enter image description here

However, it somehow includes constraints:

enter image description here

And here is how constraints are set via Windows Certificate Store:

enter image description here

Like I said, EKU validation through the chain is application-specific. If application requests EKU validation through the chain and EKU is not allowed in every CA certificate in the path, validation will fail. If application requires specific EKU only in leaf certificate and specified EKU is presented, validation will succeed.

p.s. On Windows you don't need to use OpenSSL to dump certificate, instead you can use built-in certutil.exe tool:

certutil -dump path\certfile.cer
Crypt32
  • 5,750
  • 12
  • 24
  • 1
    Interesting. Can you point me to the section in the RFC where it mentions this? I am curious how this is written as a non-strict rule. Is this something that is supposed to be governed by the Certificate Policy and Certificate Practice Statement of the CA? – Hmmmmm Sep 24 '18 at 21:54
  • 1
    See updated response – Crypt32 Sep 26 '18 at 10:50
3

The reason you see that ExtendedKeyUsage list is simply down to the application used by the website linked in your question to dump the textual representation of the certificate.

If you look at the page again you will see a Base-64 encoded representation of the certificate. Copy and paste it into a file and save it. Dump the textual representation of the certificate with OpenSSL and you'll simply see the following.

Note: If you are running Windows, save it with a .cer or .crt extension and double-click on it. Windows will display the certificate in a GUI, showing similar information.

$ openssl x509 -noout -text -in StarField.cer
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Validity
            Not Before: Jun 29 17:39:16 2004 GMT
            Not After : Jun 29 17:39:16 2034 GMT
        Subject: C=US, O=Starfield Technologies, Inc., OU=Starfield Class 2 Certification Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:32:c8:fe:e9:71:a6:04:85:ad:0c:11:64:df:
                    ce:4d:ef:c8:03:18:87:3f:a1:ab:fb:3c:a6:9f:f0:
                    c3:a1:da:d4:d8:6e:2b:53:90:fb:24:a4:3e:84:f0:
                    9e:e8:5f:ec:e5:27:44:f5:28:a6:3f:7b:de:e0:2a:
                    f0:c8:af:53:2f:9e:ca:05:01:93:1e:8f:66:1c:39:
                    a7:4d:fa:5a:b6:73:04:25:66:eb:77:7f:e7:59:c6:
                    4a:99:25:14:54:eb:26:c7:f3:7f:19:d5:30:70:8f:
                    af:b0:46:2a:ff:ad:eb:29:ed:d7:9f:aa:04:87:a3:
                    d4:f9:89:a5:34:5f:db:43:91:82:36:d9:66:3c:b1:
                    b8:b9:82:fd:9c:3a:3e:10:c8:3b:ef:06:65:66:7a:
                    9b:19:18:3d:ff:71:51:3c:30:2e:5f:be:3d:77:73:
                    b2:5d:06:6c:c3:23:56:9a:2b:85:26:92:1c:a7:02:
                    b3:e4:3f:0d:af:08:79:82:b8:36:3d:ea:9c:d3:35:
                    b3:bc:69:ca:f5:cc:9d:e8:fd:64:8d:17:80:33:6e:
                    5e:4a:5d:99:c9:1e:87:b4:9d:1a:c0:d5:6e:13:35:
                    23:5e:df:9b:5f:3d:ef:d6:f7:76:c2:ea:3e:bb:78:
                    0d:1c:42:67:6b:04:d8:f8:d6:da:6f:8b:f2:44:a0:
                    01:ab
                Exponent: 3 (0x3)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
            X509v3 Authority Key Identifier: 
                keyid:BF:5F:B7:D1:CE:DD:1F:86:F4:5B:55:AC:DC:D7:10:C2:0E:A9:88:E7
                DirName:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
                serial:00

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
         05:9d:3f:88:9d:d1:c9:1a:55:a1:ac:69:f3:f3:59:da:9b:01:
         87:1a:4f:57:a9:a1:79:09:2a:db:f7:2f:b2:1e:cc:c7:5e:6a:
         d8:83:87:a1:97:ef:49:35:3e:77:06:41:58:62:bf:8e:58:b8:
         0a:67:3f:ec:b3:dd:21:66:1f:c9:54:fa:72:cc:3d:4c:40:d8:
         81:af:77:9e:83:7a:bb:a2:c7:f5:34:17:8e:d9:11:40:f4:fc:
         2c:2a:4d:15:7f:a7:62:5d:2e:25:d3:00:0b:20:1a:1d:68:f9:
         17:b8:f4:bd:8b:ed:28:59:dd:4d:16:8b:17:83:c8:b2:65:c7:
         2d:7a:a5:aa:bc:53:86:6d:dd:57:a4:ca:f8:20:41:0b:68:f0:
         f4:fb:74:be:56:5d:7a:79:f5:f9:1d:85:e3:2d:95:be:f5:71:
         90:43:cc:8d:1f:9a:00:0a:87:29:e9:55:22:58:00:23:ea:e3:
         12:43:29:5b:47:08:dd:8c:41:6a:65:06:a8:e5:21:aa:41:b4:
         95:21:95:b9:7d:d1:34:ab:13:d6:ad:bc:dc:e2:3d:39:cd:bd:
         3e:75:70:a1:18:59:03:c9:22:b4:8f:9c:d5:5e:2a:d7:a5:b6:
         d4:0a:6d:f8:b7:40:11:46:9a:1f:79:0e:62:bf:0f:97:ec:e0:
         2f:1f:17:94

This is what should be expected - no KeyUsage or ExtendedKeyUsage

A root CA certificate shouldn't really contain any extensions (other than optionally SubjectKeyUsage and AuthorityKeyUsage used to help chain building) as it limits what the certificate can be used for during the whole of its long lifetime. Such limitations should be added at the subordinate CA level.

As you stated in your question, the ExtendedKeyUsage is for the particular certificate, not for the chain (unlike policy and name constraints).

garethTheRed
  • 1,392
  • 7
  • 12
  • Thanks for your response. I did as you said and downloaded the base 64 encoded certificate and viewed it in the Microsoft Cert Viewer GUI and it does indeed show no EKU or KU values. However, I then went into my Windows Certificate store and viewed the same certificate (Thumbprint values match) that is already installed in the Trusted Root Certification Authorities and that certificate did have EKU values. It seems as though how you trigger the popup changes the values it shows. – Hmmmmm Sep 24 '18 at 22:37
  • In the absence of an EKU, the certificate is valid for all usages (subject to any constraints asserted by `keyUsage`). In this case, maybe the Windows GUI simply lists all possible EKUs rather than show no EKU? – garethTheRed Sep 25 '18 at 16:52
1

As I understand it, the answer to your first question is yes --- at least, for CAs and software following the Baseline Requirements published by the CA/Browser Forum. Specifically, the first paragraph of Section 7.1.5 ("Name Constraints") says:

For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.

There are also some related comments in Section 7.1.2 ("Certificate Content and Extension"), including a footnote that acknowledges that this use of the EKU extension does not follow RFC 5820.

(My answer is based on version 1.7.3 of the Baseline Requirements.)

Ryan Culpepper
  • 111
  • 2