11

We have a web application that we run for clients at their booth on fairs. The communication between clients and the server was done over HTTP until recently.

We're currently working on improving several security-related aspects of this application. For example, I now implemented support for HTTPS and wrote a small script to generate a self-signed certificate for the server. The clients should add this certificate to their trusted certificate stores so that the browser doesn't complain about it. So far so good.

On chat, someone mentioned that I should never use a standalone, self-signed certificate and that I should instead use a certificate authority to sign my certificate, even if the CA itself is self-signed.

Given that I would still have to manually trust the self-signed CA on the clients, I don't see how this would have any benefit from a security standpoint. I guess it would be slightly more convenient in certain cases, but we usually erase the clients and server after each deployment and reimage the next time we need to set the system up.

1 Answer 1

11

The distinction depends on some details about the self-signed certificate and how the browser and the OS will react to it.

A normal certificate includes a Basic Constraints extension which contains a flag telling whether the certificate is for a CA or not; when the flag is TRUE then the certificate is considered acceptable as an issuer for other certificates. If the extension is altogether missing, then the certificate is to be considered as non-CA.

Root CA certificates are "special"; they are not true certificates. They are trust anchors; a TA is, nominally, a public key coupled with a name. It is traditional to encode trust anchors as certificates, and since a certificate includes a field for a signature, some bytes must be stored there; there again, Tradition says that we shall make the certificate self-signed. Nobody really checks that signature, though; junk bytes of approximately the right size would serve just as well.

The tricky point is then that the interpretation of the certificate extensions, if any, found in such a "root CA certificate", is non-standard. In particular, some historical root CA date from before the invention of the Basic Constraints extension; as true certificates, they would be interpreted as "not CA", but since they are trust anchors disguised as certificates, the normal interpretation rules do not apply.

So on some browsers or OS, a non-CA certificate (lacking a Basic Constraints extension, or even featuring one with the cA flag set to FALSE), once installed in the "root CA" store, may very well begin to be accepted as a CA. Thus, confidentiality of the private key for any certificate installed in the user's trust store is rather critical.

What's the difference in your case ? After all, in your situation, there are two choices:

  • You create a self-signed certificate for your server, and the user installs that certificate as "trusted".
  • You create a self-signed CA certificate, that the user installs as "trusted". You issue a normal certificate for your server with this CA.

In both cases, the user surrenders his security to some certificate from you, that the user installs as "trusted". So what would it change ?

The difference is that if you use a custom CA, you can store the corresponding private key with good protection. For instance, you do the CA business on a laptop which is kept offline at all times. There is no possibility of a remote exploit when there is no network at all. Root CA should always be offline, and used only as part of manual procedures and USB keys for data transfer. On the other hand, your server is, well, a server, so it is online and intrinsically exposed. An attacker who hacks into your server may get a copy of the server's private key. If the corresponding public key has been installed as "trusted root" in the users' machines, then the attacker gains a lot of leverage on these machines as well.

Briefly said, making a custom CA distinct from the server's certificate (as used all day long) allows for better protection of the private key, and thus a lower risk of catastrophic attacker's power escalation.

There are browsers which are not as vulnerable. What you really want, with a self-signed server certificate, is that the users trust that certificate only for SSL connections (not as a CA), and only for that specific server. Firefox knows how to do that; it is called a "security exception" in Firefox terminology (see the Preferences -> Advanced -> Certificates -> View Certificates, then the "Servers" tab).

6
  • No mention of certificate revocation? Sep 28, 2013 at 1:49
  • In the specific context of this question, it seems that going through all clients and servers on a non-regular basis is "acceptable". Revocation is a way to "cancel" a certificate whose private key has been compromised; it makes coping with such an event easier (no need to go through all clients to change a trusted root) but at some expense (you have to produce the CRL regularly and distribute it, which is at odds with the notion of an "offline CA"), and it is asynchronous (the attacker gets a few hours of days to play).
    – Tom Leek
    Sep 28, 2013 at 11:18
  • As I understand the context, in case of compromise, all server and client systems could be manually inspected anyway. I am here interested in containing potential damage between server compromise and manual intervention; for that, revocation does not seem to add much value.
    – Tom Leek
    Sep 28, 2013 at 11:22
  • But even if you use a CA to issue a certificate, the certificate's private key is still needed at the server so it can use the certificate, so the private key is still subject to being compromised, right? Jul 18, 2014 at 14:21
  • The CA private key is needed on the machine which issues certificates; that needs not be the same as the SSL server. In particular, the CA can be an offline machine. What the SSL server needs is the private key for the SSL server's own certificate. Having a separate CA allows for easier damage containment in case of compromise of the SSL server (if the CA is offline, it is assumed that it cannot be compromised remotely).
    – Tom Leek
    Jul 18, 2014 at 14:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .