What happens if root ca is compromised

If a CA certificate is revoked then it cannot be used that's the point of revoking a certificate: so that it is not used anymore. In particular, certificate validation should not be able to use that CA certificate anymore.

The certificates which that CA issued are not revoked: possibly, they may be verifiable with another CA certificate which contains the same key: a CA certificate is like any other certificate, it binds a name with a public key; nothing prevents the existence of several distinct certificates which assert that binding, and this is a normal situation in the case of "bridge CA" mostly used so that some certificates may be verified relatively to several trust anchors.

Of course, if the CA certificate is revoked because the CA private key was stolen, then the sensible course of action is to revoke all certificates issued to that CA, and the certificates issued by that CA will be no longer verifiable by anybody.

So, to sum up, revoking a CA certificate does not revoke all certificates issued by that CA, but it prevents verifying those certificates through that CA. If the CA certificate is revoked, it's issued certificates should no longer be considered 'signed'.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. How is revocation of a root certificate handled? Ask Question. Asked 10 years, 5 months ago. Active 10 years, 2 months ago. Viewed 9k times. Improve this question. Cratylus Cratylus Add a comment. Active Oldest Votes. Improve this answer. Dean Povey Dean Povey 8, 1 1 gold badge 38 38 silver badges 49 49 bronze badges.

So in the path building the path is build from the target certificate up to the trust anchor. The revocation checking then is done the other way round then? From the top excluding trust anchor to the target certificate?

Also what would be the process practically to re-issue all the certificates that CA has issued? The only practical way to reissue all the certificates is to revoke the CA, create a new CA certificate and then issue new certificates for every entity.

It's a catastrophic failure, and for this reason CA's should try not to get their certs revoked The CRL to revoke the root certificate could be signed by the root certificate itself. It is the same way as PGP public keys are revoked. Thomas Pornin Thomas Pornin In this case, the public key is the same but I assume the subject dn is different?

The certificate binds a key to a name which should be the key owner. What you could have is the same key and the same subject DN, but distinct issuer DN this means that two CA are asserting "this is Bob's public key" for the same Bob and the same key. In this case, there are multiple validation paths, right?. So in a simplified question, if for example there is a check if a certificate X has been revoked, and using certificate X and it's signing certificate Y only in the validation path, is there a case that a certificate higher in the chain could be revoked, but we get e.

To consider a certificate as valid, it must be signed by a valid CA certificate, and revocation status check must respond "not revoked". If a certificate "higher in the chain" is revoked then it cannot be used, in particular not to validate the rest of the chain. The revocation status of 'X' is thus irrelevant: 'X' should first be verified to be signed by a valid CA public key, and this cannot happen with a revoked certificate higher in the chain.

ThomasPornin I am suggesting an improvement to this answer, please click here for details. Mel Mel 5, 1 1 gold badge 13 13 silver badges 12 12 bronze badges. In this situation, revocation is possible. An example is if enrollment agent credentials are obtained.

The CA will still log all issued certificates. When a CA is compromised, assume that every certificate issued by the CA is potentially compromised. The response from an End Entity perspective is slightly different, and the handling of the CA or PKI in general depends on the type of compromise. There are two major compromise possibilities for full key compromise or access for a CA - an operating system compromise or a cryptographic compromise.

Both of these compromises are covered below. There are a number of attack vectors for the operating system of a CA server and the response depends on many factors. Operating systems can be compromised physically or remotely. Examples of physical attacks involve an attacker gaining access to a server by using the console due to:.

The use of storage media to inject an exploit or create a unique bootable operating system partition to make changes to the primary operating system drive. Both offline and online CA server types are susceptible to physical attack, whether it is by an intruder, an insider attack, or an unknowing person via a social engineering attack or infected file transfer device. If an offline CA is kept offline, it is not susceptible to remote attacks. However, online CA servers as well as web servers responsible for enrollment services or enrollment validation are susceptible.

Brute force attacks against credentials to gain access using Remote Desktop Services or other remote management tools. Malware introduced by an operating system vulnerability or an unknowing person with access to the system being coerced into installing the malware. For CA servers, regardless if the operating system compromise is physical or remote, the severity of the compromise and the corresponding response depends on whether the private key integrity is known to be good or if the key integrity is unknown or compromised.

Another attack vector that can lead to full key access is the cryptography of the PKI. For each public key, there is only one mathematically unique private key and the algorithm to perform encryption and decryption is well known. Researchers or dedicated attackers can dedicate multiple servers and build testing algorithms to try to derive the private key by brute force.

If a weakness is found in an algorithm used by the CA, the weakness could be further exploited to identify the private key or issue certificates that appear to come from the CA. After identifying there has been compromise, the first actions taken after determining the nature and degree of damage are to restore functionality and assurance of the CA and any End Entity certificate consumers.

Some actions are more severe than others and which actions you execute depends on the type of compromise. You should document response actions in an Operations Guide or in Business Continuity plans. The following are some examples of response actions. Log on to the parent CA and revoke the subordinate CA certificate. Publish a new full CRL. Certificates requiring an enrollment agent, certificate manager approval, or other intervention handled individually.

Once you understand the types of compromises and have established the potential actions for response, put a response plan in place. The diagrams below shows an example correlation between compromise and actions for a server operating system compromise and an example correlation between compromise and actions for a cryptographic compromise.

Once the response plan is complete, perform drills to practice execution of a compromise response in a test environment.