7

I'm a budding website developer, so please bear with my ignorance.

Say I had to encrypt my website with HTTPS and I got sick of having to click "Continue" every time a warning came up about an untrusted certificate. I used this method to install my site's certificate.

Say the certificate I signed is issued by "xyz." Since the store is called "Trusted Root Certification Authorities," I assume that it trusts "xyz" as a certification authority. When my certificate is added to the store, does that mean that any certificate issued by "xyz" now is automatically trusted?

Or does installing an SSL certificate for a domain to "Trusted Root Certification Authorities" only make that one domain trusted?

The point is I want to ignore the warnings for my website in particular but do not want to ignore the warnings for any other website.

EDIT: I probably should elucidate on the exact procedure I used to create the certificate. The website is deployed on a Ubuntu 10.04 server with the default OpenSSL and Apache configurations. To create the certificate and key file, I simply used

# make-ssl-cert generate-default-snakeoil –force-overwrite

and left /etc/apache2/sites-available/default-ssl alone because the make-ssl-cert command wrote the two files to the same paths that the Apache configuration files point to. So I didn't even set up a certificate authority to generate my website's certificate from.

Does this change the scenario at all? What's the difference between installing a certificate created without a certificate authority as trusted root on a client, and installing a certificate created with one?

EDIT 2: Okay, it would be better if I were to narrow the question down as much as I could: Is it safe to ask others to install my certificate as trusted root if I secure the certificate for my website and make sure it never escapes? Will attackers ever be able to take advantage of my self signed certificate and target those who have installed it to their trusted certificate store?

Improve this question

2 Answers 2

Reset to default
11

When you install a CA certificate as "trusted root" then this means that your applications will trust whatever certificates are issued by this CA certificate. This is not, by default, restricted to a specific domain. X.509, the standard for certificates, includes a way to specify that a given CA is for issuing certificates only in a specific "area", e.g. for servers in a domain (that's the Name Constraints extension, see section 4.2.1.10), but it is poorly supported, or not supported at all, by existing implementations. So I would recommend against relying on this feature.

So the basic rule is that when you install a new trusted root, you are entrusting the owner of the private key with your browsing security. If you are the owner (that's your self-signed certificate, which you generated yourself), then it is up to you to keep the CA key safe. As long as nobody else gets a copy of the private key, then there is no problem. This leads to the following method:

  1. Create a new key pair and a self-signed certificate.
  2. Use that newly created CA to issue a certificate for your server.
  3. Import the CA certificate as trusted root.
  4. Forget the CA private key (destroy the key; ideally, the key is in a file which you put on a RAM-backed filesystem, making suppression reasonably complete).

and you are done. If the private key is no more, it is, in particular, out of reach of malevolent adversaries.

An alternate method is to use a self-signed certificate for the server itself, and instruct your Web browser to nonetheless trust that certificate for your site only. If your browser can do that, then no need to fiddle with root CA. Firefox can do that; they call it a security exception.

Improve this answer
4
  • Chome and Safari can do it almost equally as easily. IE makes it a little more difficult, though I hear it's gotten easier in IE9 and later.
    – Polynomial
    Oct 13, 2012 at 15:57
  • So basically I should follow tc.umn.edu/~brams006/selfsign.html with step 1B and then throw out ca.key? I didn't make my own CA when I made my key. I just executed "sudo make-ssl-cert generate-default-snakeoil –force-overwrite" in Linux and left the default SSL configurations in Apache. Is this inherently less secure than self signing a CA and then creating a certificate from it if I am to install the certificate as trusted root?
    – Kevin Jin
    Oct 13, 2012 at 22:19
  • @KevinJin: Yes, that's inherently less secure. You've trusted a certificate, which means you'll trust any certificate it signs now or in the future. It was originally created self-signed, but nothing requires that it only ever sign itself, if anyone got into your server and got access to that cert's private key (this should be obvious if you consider that the CA certificate Thomas proposes is also self-signed), they could sign new certificates named after any domain, and you would trust them because the root is a certificate you trust.
    – Ben Voigt
    Aug 12, 2016 at 20:45
  • @KevinJin: An important consideration is that in the two certificate method, the private key which is kept corresponds to a certificate which is marked with a purpose of "website encryption" but not a purpose of "certificate signing". In the one certificate method, the purpose of "certificate signing" must be enabled, or else the self-signature would be invalid as well.
    – Ben Voigt
    Aug 12, 2016 at 20:46
0

In case when someone is intercepting your users' traffic, that person can pull a man-in-the-middle attack and present your users with their own certificate to install instead of yours. In this case they will be able to decrypt all data passing between clients and the server.

Other than this, no consequences.

Improve this answer

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.