7

I have created a New Trusted certification authority which issues certificate to the end entity and the end entity will use this certificate as trusted one for all their PKI operations. Some how the Root CA Key got compromised.

Now my question here is how can I revoke the ROOT CA as its a self -signed ?

  • next time make sure you don't actually use the root-certificate for signing and store the key somewhere really safe so it cannot be compromised and use an intermediate certificate which can be revoked. – r_3 May 28 '15 at 11:27
12

Revocation really is cancelling the certificate issuance -- the CA which has signed the certificate announces that it now denies it. A root CA being self-issued, it cannot be revoked. A root CA, by definition, is trusted a priori, not because its certificate was signed by some higher-placed CA in the hierarchy. Thus, there is nobody to emit revocation information that would be authoritative on that CA.

Some extra comments must be made, though:

  • You do not revoke a CA; you revoke a certificate. Any entity that has a name and owns a key pair, in particular a CA, may own several certificates. Each certificate is an assertion of that key ownership. What you think as a "root CA" may also be an intermediate CA in the following sense: besides its self-issued (traditionally self-signed) certificate, it may also have obtained another certificate that contains its name and its public key, and issued (signed) by another CA. The latter certificate, being issued by a distinct CA, can be revoked. This kind of situation is common in case of "root CA renewal" (a new root CA is created, and "cross-certificates" are issued so that the transition is smooth).

  • What certificates cannot do, maybe other systems can. For instance, a Web browser may contain a list of a priori trusted root CA (for validation of SSL server certificates); then, any update of the browser executable may add or remove root CA. There is no CRL involved, but it sure looks like a revocation mechanism, especially since modern browsers update themselves automatically. Windows has a similar system with a "disallowed" certificate store that acts like an OS-enforced, super-CRL which can make any certificate untrusted, even root CA certificates explicitly added to the store of trusted roots.

Trying to make a CRL containing the serial number of the compromised root, as was suggested in another answer, will not have the intended effect, for two reasons:

  1. Systems that validate certificates (e.g. SSL clients when trying to verify the server's certificate) download CRL only for certificates where it makes sense, i.e. not for root CA, since they cannot verify the signature on the CRL save relatively to the public-key of the CA higher in the chain, since there is no such CA. You can write what you want in any CRL; if clients don't look at it, it won't get you far.

  2. Even if you could somehow convince a client to download that "suicide CRL", where the root CA kills itself, remember that the private key have been compromised, thus the key thief may produce and sign a counter-CRL that says that everything is fine and nobody is revoked. Since the CRL download cannot be otherwise protected, the attacker can prevent that self-destruction mechanism to happen, even assuming that it would have worked with existing clients (and it does not).

  • the thief needs control of DNS, client exploit, or some means of MiTM to get clients to use their counter-CRL once the key has been declared as compromised. There doesn't seem to be an elegant solution other than updating all clients via scripts, updates, enterprise config mgmt., adhoc, etc. – user2320464 Jan 16 '18 at 17:53
  • But say, if it were compromised, there was a mistake, cessation of operation, or other reason for revoking it, couldn't the CA itself add its own cert to the CRL (even if just temporary)? Seems like that'd be easier than creating a giant CRL for every cert it ever produced. The list is still signed by the CA; it's the CA itself that carries the authority, not it's public key certificate right? Even if private key were compromised and a client got "mixed msgs" (CA & attacker), might be better than nothing/enough to cause the client to take precautions(?). Maybe that's what an ARL is for? – user1172173 Mar 11 at 4:20
4

make a Certificate Revocation for your root certificate and export it to a Certification Revocation List, putting it at the location you specified the CRL will be placed.

  • Yeah. I can revoke, but here the problem is that CA have one private key which is used to sign, if suppose the key got compromised, how can I use the same compromised key to sign the CRL of its own and publish ? – user45475 May 27 '15 at 23:04
  • Because the listing invalidates the Certificate and possibly the key as well, you can do this. but its better to just use a commercial CA due to this problem (among others) – LvB May 27 '15 at 23:06
  • 1
    It means the only way is to have the new setup and re-issue all the certificates ? – user45475 May 27 '15 at 23:19
  • 1
    and revoke the old certificates. – LvB May 27 '15 at 23:21
  • 2
    @user45475 There's no security problem with allowing a self-signed cert to revoke itself. If it gets hacked, then you're allowing the hacker to to jump up and down and yell "HEY LOOK! I hacked this cert!!!!". Which, if it was hacked, is what you want to do anyway, and by far the least destructive thing they can do with your private key. – Mike Ounsworth May 27 '15 at 23:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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