Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

In old versions of IE/Windows you could install a self-signed certificate for a web site and it just worked: the warnings disappeared.

In more recent versions (and with Chrome) this just didn't work. The only way to make it work is to install the self-signed certificate as a Root Certificate Authority. I need to install it because Chrome disables caching of non-trusted SSL sites, which makes this site too slow (i could switch to another browser though).

Isn't this an unnecessary security risk? If the certificate key gets compromised it will not only affect the site but everything else. Why isn't there an option for trusted sites alone?

share|improve this question
    
Trust is central to your question. As Peter Gutmann says "Revoking self-signed certificates is hairy". Check out cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf to get a better understanding of the trust issues. –  zedman9991 Aug 7 '13 at 12:48
    
If you trust the self-signed certificate what security problems are you worried about? The purpose of any certificate is to allow the client to verify the server is the server they are talking to. –  Ramhound Aug 7 '13 at 12:56
    
I want to trust certificate "C" for site "S" only. When I install "C" as a root CA i'm potentially allowing "C" to impersonate anything. –  LatinSuD Aug 8 '13 at 11:05
add comment

1 Answer

In X.509, a certificate can be validated if it can be put at the end of a valid chain, where each certificate in the chain has issued the next one, and the chain starts with a trust anchor. The trust anchor is the certificate that you trust "ex nihilo", i.e. not by virtue of the certificate being signed by another, trusted certificate; the trust anchor is trusted by configuration. This configuration is, indeed, putting the certificate in the "root CA" certificate store.

When you put a certificate in the "root CA" store, this does not automatically means that your machine will begin to use this certificate as a CA, i.e. to validate other certificates. This merely means that the certificate is "trusted". Whether this certificate will also be accepted in the role of a CA depends on what is written in it (the Basic Constraints extension).(*)

To initiate trust, you must do "something". A Web browser must not trust transparently any self-signed certificate that it encounters; it would be a gross vulnerability. The user must make an explicit action to allow the self-signed certificate to be trusted for SSL; and, preferably, this action must not be a too easy one-click thing, because otherwise users will do it without even noticing it. Clicking through warning popups, however scary they can be, is a well-entrenched behaviour in human users; and, unfortunately, accepting a self-signed certificate without due manual verification leads to Man-in-the-Middle attacks.

In Windows/IE, the "something" needed to prime the trust system is installation of the self-signed server certificate in the "root CA" store. This requires some not-easy GUI invocations, and that's by design. It MUST NOT be easy.

For other browsers, things may vary, though the core concept is the same. For Firefox, installation of a self-signed SSL certificate is described as a "security exception"; Firefox has its own X.509 subsystem, completely disjoint from the one of the underlying OS. For Chrome, this depends a lot on the OS, the OS version and the browser version.


(*) There are subtleties. Old X.509 certificates, aka "v1", more than 15 years ago, did not support extensions at all, so there was no way to mark a certificate as "good for CA" or "not good for CA". This means that a v1 self-signed certificate, installed in the "root CA" store, will act as a CA, thus be accepted in the role of a CA, for validating other certificates. You should take care, when installing a self-signed certificate, that you do not open that door. Unfortunately, this depends on rather technical details of the certificate, so it is not easy to test for end-users.

share|improve this answer
    
I did not mean the process to be easy. I meant to be able to install as non-root. For example i generated a self-signed cert and i think it does not include by default those Basic Constraint options which i did not know until you told me (thanks). –  LatinSuD Aug 8 '13 at 11:03
    
On Windows systems, each user has its own set of "certificate stores". There is also an extra set attached to "the local machine". Only Administrator can write in the latter, but every user can add certificates in his own "root CA" store and this will work for his process. As for the lack of Basic Constraints, this is equivalent to an extension stating that the certificate is not a CA, so as long as the certificate is v3, this is fine (if the certificate has an extension, it is v3: v1 and v2 format don't have extensions). –  Thomas Pornin Aug 8 '13 at 11:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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