4

I'm trying to understand the validation logic that would occur in the following hypothetical scenario

  • An unpatched XP user who trusts a list of root CAs. Those CAs in particular have been renewed (using a different public key) but have only been updated in newer versions of Windows

  • A Windows 8.1 client who has the newer Root Certificate described above, and not the "old" certificate.

  • Two different websites: one with a HTTPS certificate issued from the old CA, one from the renewed CA.

Question

  1. How does trust flow when the XP user accesses a web certificate issued by the new CA?
  2. How does trust flow when the Win 8.1 user accesses a web certificate issued by the old CA?
  3. What if I, as an end user, no longer trust the integrity of certificates after the key was renewed. How can I, as an XP user, cause a validation exception?

I'm assuming that once a CA is renewed, the former CA isn't revoked per-se, but am unsure if it will appear in the CRL as "superseded" or something along those lines.

This question isn't supposed to be specific to Windows but rather a general understanding on how a PKI is supposed to work.

If things work as I'm understanding, a renewed CA with a different key should be similar in some respects to a sub CA.

Additional Related Scenario:

Since this question is all about how the chain of trust is followed & validated, I'm curious if there is a way for a root certificate to become a subCA of a new "meta-root", (renewing a Root CA with a new Parent) and how that would work.

Assuming that client software will constrain a certificate's usage to the EKU in the chain, this could be a security issue if

  1. the root CA was constrained to issue only SMIME certificates, through a defined EKU in the self-signed cert.
  2. The root CA is renewed, but is then signed by a "meta root" CA
  3. Assume that the "meta root" contains the EKU for SMIME AND server/client authentication

If the above was possible, I wonder if a user who trusts the rootCA (not Meta Root) could be affected by the meta-root's issuance of HTTPS certificates; thereby allowing the inadvertent spoofing of their HTTPS connection

In a sense, I'm trying to figure out if there is a need for the opposite of an "End Entity" attribute, e.g. "Root Entity" that can't be superseded, or if that is unnecessary

10
+100

The question is... a bit complex. The critical issues are existence and availability of intermediate CA certificates. Consider the following points:

  • Root CA are not "revoked". Revocation is a mechanism by which the issuer for a given certificate specifies, directly or indirectly, that one of its issued certificates is not to be trusted and must not be used for any purpose. Root CA have no issuer (they are "self-issued"); therefore, there is no entity qualified to revoke a root CA. As a result, no CRL or OCSP response will ever talk about a root CA certificate.

    When a root CA is conceptually "renewed", the old CA just floats around. Trust in root CA is always direct: a client either trusts a root CA, or does not trust a root CA. As such, it is up to each client to decide whether to include the new root and/or to discard the old root. An important consequence is that there is no way to make a machine aware of a renewal. From the client's point of view, there is no such thing as a "renewal"; there are two distinct root certificates.

  • "Renewal" is not a well-defined concept. There are variations. Basically the new root CA may or may not use the same key, and may or may not use the same name. In fact, when the CA changes its name (its subjectDN), the notion that the new CA is a "renewal" of the previous one is a business concept; technically, this is just "another root CA".

    There is no rule which mandates a change of key upon renewal. Decision to change the key should theoretically be driven by considerations on the safety of the private key storage, within the key lifecycle management. In short, you need to change the key when the previous one is too small with regards to current cryptanalytic results. If the root key is, say, RSA-2048, stored in a good HSM, then there should be no need to change the key. (This begs the question then: Why you would like to "renew" the CA in the first place? Usually, this is because the old root CA was tagged with an expiry date by someone who was not completely aware of what he was doing, and that date was not far enough in the future.)

  • When a client wants to validate the certificate of some SSL server, the client tries to build a valid certificate chain which goes from a root CA trusted by the client (the "trust anchor") down to the EE certificate (the "end-entity", i.e. the server's certificate). In between are the intermediate CA certificates. Rules for what constitutes a valid chain are mindbogglingly complex but, for the purposes of the discussion here, they can be summarized as follows:

    • The signature on each certificate can be verified with the public key stored in the previous certificate.
    • The issuerDN of each certificate is equal to the subjectDN of the previous certificate.
    • The current date is between the notBefore and the notAfter dates of each certificate.
    • Each certificate (except possibly the EE) contains a Basic Constraints extension with the cA flag set to TRUE.

    As long as the client can come up with such a chain, the client will be happy.

A consequence is that if you renew a root CA by reusing the same name and the same key (i.e. you just changed the validity dates), then the old and new root CA are interchangeable, as long as neither has expired. That is, every chain which begins with the old CA will be equally valid if you replace the old CA with the new CA. In that case, the transition is smooth: both your old "XP" user, and the new "Windows 8" client will be able to validate the same certificates, from both servers.

Now what if you changed the key and/or the name ?

Then trouble begins. For better illustration, let me switch to Microsoft terminology:

  • We are still at a time when both the old and new root are still valid (when the old root expires, it virtually disappears, so the "XP" user ceases to be able to validate anything).
  • The "old root" is called root0.
  • The "new root" is called root1.
  • As per Microsoft procedures, the renewal included a cross-certification. This kind of thing was initially meant for two distinct PKI to "merge" somehow, but it is also used for renewals. Namely, two extra intermediate CA certificates have been issued:

    • root0-1 contains the name and key of root0, but is signed by root1
    • root1-0 contains the name and key of root1, but is signed by root0

    Note that whether a CA is "intermediate" or "root" is a property of the certificate, not of the actual CA. Here, both root CA have two certificates, one being "root" and the other "intermediate".

  • The first server's certificate (signed by the old root) is serverOld.

  • The second server's certificate (signed by the new root) is serverNew.

From the point of view of the "XP" user, both serverOld and serverNew can be validated, with the two following paths:

  • root0 -> serverOld
  • root0 -> root1-0 -> serverNew

while the "Windows 8" user can also validate the certificates with:

  • root1 -> root0-1 -> serverOld
  • root1 -> serverNew

So everything is fine ? Not so fast ! What I explain above is that the existence of the intermediate CA certificates root0-1 and root1-0 potentially allows for a smooth transition. But this works only if the said certificates are indeed made available in some way to the client.

An SSL client will build chains based on certificates found in three sources:

  1. What the client already has. For instance, if you inspect the "certificate stores" in a Windows machine, you will see a store called "Intermediate Certification Authorities" which is a repository for intermediate CA certificates. These are not intrinsically trusted but are available for certificate path building.

  2. What the server sent. As per the TLS specification, an SSL/TLS server does not send its certificate alone, but as part of a pre-built chain. A client is entitled to simply try that exact chain and nothing else; but, in practice, modern clients (Web browsers) will do some path building of their own if the chain from the server fails to validate. Importantly, the certificates from the pre-built chain sent by the server can be reused by the client to build other chains.

  3. What the client can download by itself. Any certificate C may contain an Authority Information Access extension with URL pointing to places where "the" certificate of the CA which issued C can be obtained.

So if you want the "XP" client to use the "root0 -> root1-0 -> serverNew" chain, without being able to "push" the root1-0 certificate into the client machine through some out-of-band administrative operation, you have two options:

  • You may configure the server to send the "root1-0 -> serverNew" chain, instead of just "serverNew". That chain can be validated by the XP client, while the Windows 8 client should be able to notice that the "serverNew" certificate can be linked directly under the "root1" certificate.

    Such server configuration cannot necessarily be enforced. First, SSL servers might be under control of people other than the PKI itself. Second, some SSL software cannot be (easily, or at all) configured to send a specific chain. For instance, IIS is configured with just the EE certificate, and will send what is from its point of view a valid chain; if the IIS machine trusts root1, it will not send a chain containing root1-0.

  • You could arrange for "serverNew" to contain an AIA extension which points at the root1-0 certificate. The XP client will use that URL to dynamically obtain the root1-0 certificate (and hopefully cache it locally for future usage). The Windows 8 client will be able to verify the "serverNew" certificate with root1 directly and will just ignore the extension.

The second solution must be applied on the new CA itself, so that when it issues certificates (e.g. serverNew), it includes an AIA extension pointing to root1-0. This is feasible; however, the dual case is not. The "dual case" is the validation of "serverOld" by the Windows 8 machine: with the cross-certificates, the Windows 8 machine must build "root1 -> root0-1 -> serverOld". However, "serverOld" was issued by the old root before the new root existed, and thus cannot contain an AIA pointing to root0-1, since that certificate did not exist at that time. A corrective action would be, when the new machine is configured with the new root, to also install the root0-1 certificate in its "intermediate CA" store.

Bottom-line: cross-certification does not work well. It is theoretically good, but it fails in practice because of the lack of availability of the cross-intermediate CA (these magic certificates exist, but there is no way to make all clients aware of their existence). In closed environments, cross-certification works: for instance, from an Active Directory server, you can forcibly push arbitrary intermediate CA certificates into all domain machines. You cannot do that in the Internet at large...

In practice, renewal strategies (for when key and/or name is changed(*)) overlap. The "new root" is simply handled as "another root". This is done in several phases:

  1. The new root is created. The new root CA certificate is installed in all machines. EE certificates are still issued with the old root.
  2. After a few months or years, the new root is put to use: EE certificates are now issued by the new root. This assumes that the new root has been distributed to all relevant clients during the first phase.
  3. When all EE certificates which were issued by the old root are expired, we just leave the old root alone, to die silently (ideally, the old root key is forcibly destroyed in a formal key ceremony).

But, really, root CA "renewals" are best avoided. In that respect, the Year 2038 will be a problem, because most root CAs have set their expiry dates in 2037 or earlier to avoid the potential issue (which is probably as exaggerated as the famous Y2K). Consequently, there will be a lot of renewals 20 years from now.

Intermediate CA renewals are easier, because clients download intermediate CA automatically by following AIA extensions (contrary to root CA). This can be explained in the following conceptual sense: validation is context-free. Clients don't trust or mistrust certificates based on history, but only on what certificate chains they can build right now. All certificates are supposed to be downloaded automatically or found in shared repositories or sent by parties to each other; that is, all certificates except the "trust anchors", which are managed manually. So clients have no notion of renewal. Intermediate CA certificates, and EE certificates, can be renewed transparently since they are meant to be downloaded anew every time (though they can be cached locally). But for root CA, local administrative action is required.

(*) It does not make much sense to keep the same key if you change the name. The opposite does make sense (same name, because that's the same formal CA entity, but distinct key) but, in practice, is best avoided: when Windows uses the wrong CA, instead of claiming "this path does not work because I don't have the right CA", it instead says "this path does not work because the certificate has been corrupted and you are under attack" (I am paraphrasing here, but the message is definitely and unduly scary).

1

I will caution that I haven't tested this behavior, so while I believe my answers are based on sound logic it may not be the same logic that Microsoft chose to implement.

When a client is determining whether to trust a certificate it will work its way up the CA tree (from initial certificate to root CA) verifying signatures of the certs. If a CA's key pair has been changed and the client does not have the associated CA certificate to use for signature verification, then that verification should fail. You will see the 'cert untrusted' message in the web browser.

It doesn't matter that it has an older or newer cert for that same CA, because it essentially sees them as different CAs. Clients that only trust the old CA cert will only trust certificates signed with the old cert, and clients that only trust the new CA cert will only trust certificates signed with the new cert. If they have both CA certs installed then they should trust all old and new issued certs (assuming we don't have certificate revocation checking enabled). I don't believe that renewing a certificate generally places the old certificate in a CRL unless you specifically revoke it.

If you no longer want to trust anything signed by a CA you must remove that CA's cert from your Trusted Root Certification Authorities store on that computer. You can use the Certificates MMC snap-in to do this, assuming your user account has the proper permissions. This also assumes your browser uses the Windows certificate store and not it's own certificate repository.

--Edited to address your new Related Scenario--

There is something called cross certification between CAs that kind of makes one look like a subordinate to the other from their respective users' perspectives. It is not something that is generally implemented and I don't think it happens much at all outside of internal CA infrastructures. The Federal Bridge CA system seems like one of few public examples.

Since cross certification seems to normally imply a two-way trust (and not just one root CA trusting the other), then your meta root would be trusted by users that formally only trusted their own root CA. So that meta root could issue HTTPS server certs that your users would trust.

If the cross signing process allows you to place constraints on what EKUs you will trust from the meta CA then you should be able to avoid that threat.

-1

Normally if a CA is renewed, the new CA uses the same public/private key pair as the old. If not, all certificates issued by the CA will no longer be valid. Creating a CA with the same subject and serial number as the old CA but with a different public/private key is more or less a completely new CA from a PKIs perspective. So if the XP client only has the old root CA installed, all certificates issued by the root CA will still be valid. For the Windows 8 client with the new root CA installed, all issued certificates will also be valid since the same public/private keypair is used. When renewing a CA, make sure that atleast the subject/serial number and the public/private key pair are the same as the old CA.

  • "Normally if a CA is renewed, the new CA uses the same public/private key pair as the old" That is simply wrong. Key pairs aren't normally reused. – Stephane Jul 11 '14 at 15:58
  • Since he wanted newly certificates to be valid even with the old root, this implies that the root was not expired yet and it implies that either the keys are reused or that you use some kind of cross certification. Creating a root with the same name as the old but with different keys is similar to generating a new root. Calling a new root with new keys a renewal is more a procedural decision. From a PKI perspective it's a complete new tree and not a renewal. – martijnbrinkers Jul 14 '14 at 7:39

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.