Adding self signed certificate to trusted store

Question

I have been reading about certificates and often is said that self signed certificate should not be added to the trusted authority store and even if you did, remove it after usage immediately.

MSDN How to: Create Temporary Certificates for Use During Development

Be sure to delete any temporary root authority certificates from the Trusted Root Certification Authorities and Personal folders by right-clicking the certificate, then clicking Delete.

Why is adding a self signed certificate to the trusted store considered a security risk? How can this be exploited by a hacker ?

Can someone please explain me with example ?

Answer 1

Self-signed certificates

If you have a CA (private) key, which is the same as the one for the CSR you sign, then you create a self-signed certificate. If instead you create separate keys for the entity whose identity you wish to confirm and the CA used to confirm the identity, it's formally not a self-signed certificate anymore.

Self-signed certificates are mostly used for testing purposes and thus temporary. This can be enforced by limiting their validity period, but often isn't done in favor of convenience.

How the real-world CAs do it

The CAs will have a hierarchy of keys/certs (comprising the certificate chain you probably have heard of). If you - or your OS vendor - choose to trust a root CA cert it implies trust to Sub-CAs whose certs were signed with the root CA key.

What this means is that the root CA key requires the highest security, because it can be used to create any number of Sub-CAs which will be ultimately trusted if someone chose to trust the root CA cert.

Be sure to delete any temporary root authority certificates from the Trusted Root Certification Authorities and Personal folders by right-clicking the certificate, then clicking Delete.

Makes perfect sense now, if you consider that a root CA cert (with key) proper will have the biggest potential of being abused and create the biggest bang for the buck for an attacker. if compromised. You'll want to keep those stashed away securely unless you are using them right now to sign a Sub-CA CSR. Hence, remove them and keep a copy for later CSR signing purposes (if you need).

However, since the quote is clearly about "temporary root authority certificates", I think the clue is hidden in temporary and that's something you as the system administrator define for your own CAs and Sub-CAs (i.e. whether you intend to use them in the future or not).

Basically you can consider deleting a temporary CA cert/key as making it unavailable to an attacker, similar to the security measures of actual root CA keys. It assumes that this temporary CA won't be used to sign any more (development-use) certificates.

So that little word temporary implies a little more in the quote than it seems at first glance.

How this looks in practice

Let's say you have a root CA key that never expires (although in most cases it will simply be a relatively long period, like 20 years) and a corresponding root CA cert. You'll want to keep the key secure from any compromise, especially if the certificate is trusted by many many people. That is the case with the root CA certs of, say, Verisign or Comodo.

That root CA key will then be used solely to sign the cert of a Sub-CA (which has its own distinct key), thereby creating the first two links in a certificate chain which your browser or Microsoft's signtool as well as many other utilities let you inspect. The root CA key would never be used directly to process your CSR and thus confirm your identity as an end-user/website/company.

Every respective Sub-CA will usually only be used for a particular purpose (there are extra fields for certain purposes, such as code-signing) and its validity period will be a subset of the root CA cert's.

But, and that's one difference between the root CA's key and the Sub-CA's key: the root CAs key can be stashed away securely (talking physical security here) most of the time, unless absolutely needed to sign the CSR for a new Sub-CA, while the Sub-CA key will likely be used on some kind of highly secured server to sign customer CSRs (when considering a real-life certification authority like Verisign). This means that the Sub-CA is more at risk than the root CA and why you want to apply different levels of security in the first place.

The advantage being that, should the Sub-CA ever get compromised, its certificate can be put onto a ARL/CRL (authority/certificate revocation list), whereas putting the root CA certificate on a ARL/CRL is only really warranted for technical reasons (e.g. using the now compromised MD5 hash, a key length not deemed secure anymore ...). The costs attached to either of these are the defining factor at several levels:

• costs for storing the keys securely, in particular the root CA key has to be secured the most
• costs when changing root CA certs versus changing Sub-CA certs
• costs when revoking (Sub-)CA certs

Answer 2

Imagine you want to visit https://www.google.com.

How can you be sure that you are in fact visiting https://www.google.com? You can check the information provided by the SSL certificate is authentic.

If an attacker performs a MITM attack against you, the browser will display a warning in the form of a red padlock instead of a green one.

If an attacker has the ability to add a self-signed certificate to your trusted store, the browser will verify that the fake website the attacker is using to attack you is in fact authentic. This has obvious security implications as you will have no ability to verify a website's authenticity through the SSL certificate.

(EDIT: Thanks @Adnan and @D3C4FF for pointing out my answer originally does not address the situation of your adding own development certificates.)

With regards to adding certificates you generated yourself for development purposes, I do not think there is any large security risk. Assuming that the root CA cert you generated is kept local and not published somewhere (or better still deleted after you are done with it), no one else will be able to sign certificates that will show up as trusted on your browser. Microsoft's suggestion is still a sound one though, no point cluttering up your root store with random certificates you generated yourself. This might make spotting an actual malicious root certificate added by an attacker that much harder.

Answer 3

If some bad guy steals the private key of a CA that your computer trusts, then he will be able to issue fake certificates for arbitrary server names, and your computer will accept them as the genuine ones without so much as a warning. There goes your last line of defence against fake www.google.com, www.paypal.com, and so on -- welcome Man-in-the-Middle attacks, goodbye your bank account.

This worst case scenario can be averted by luck (which often works well), and by protecting the private key of your custom CA against theft, which is not as easy as it seems, especially against co-workers, who often have intermittent physical access to your machine, for instance when you are out for a coffee break (with physical access they can do a lot of bad things against you, but stealing a private key file is really especially discreet and hard to detect).

Answer 4

Terry's answer gives you a very good explanation of how certificates work. I would directly try to answer your question.

The whole purpose of having digital certificates in a web browser is to enable trust between the browser and web server you may wish to communicate with. Your browser validates the certificate sent by the server by using digital signature validation using the pre installed root certificates. This cryptographic mechanism is there to give you a sense of assurance that the party your are communicating with is really who it claims to be.

You can add your own three level certificate hierarchy in the browser for your personal use. This will avoid the warning pages shown by browsers when they encounter an untrustworthy certificate but imagine the case when you misplace a certificate that is trusted by your browser. A smart attacker may be able to perform a successful MITM using the stolen certificate and since your browser trusts the certificate there will be no warning while visiting the fake website which looks legitimate.

N.b. The whole purpose of having trust based on SSL certificates is to avoid MITM