10

As a hosting provider, I'd like to make the process of generating a certificate for a customer's domain as convenient as possible.

I was pondering creating a webpage where anyone could:

  • generate a CSR for a given hostname from our private key
  • take that CSR away and return to us with a certificate

Is there any danger in allowing anyone to generate potentially thousands of CSRs based off our private key?

Addressing some concerns/questions:

I think the real danger here is re-using the same private key for a lot of domains.

Is it really any different (from a security point of view, not management) than having a single certificate with many SANs? For instance, the certificate presented by our Cloudflare CDN has these SANs:

DNS:ssl2917.cloudflare.com, DNS:*.app.com.pk, DNS:*.boldstatementmarketing.com, DNS:*.lacasadivetro.com, DNS:forospyware.com, DNS:*.reportcrowd.com, DNS:*.vladtv.com, DNS:*.1bse.com, DNS:*.discourse.org, DNS:*.forospyware.com, DNS:*.gossipbrigade.com, DNS:*.gsmcodigos.com, DNS:*.is.gl, DNS:*.madepal.co, DNS:*.mejorando.la, DNS:*.oceanvillageresort.com, DNS:*.pinside.com, DNS:*.ratelossprogram.com, DNS:*.soopermexican.com, DNS:*.tequierocali.org, DNS:1bse.com, DNS:app.com.pk, DNS:boldstatementmarketing.com, DNS:discourse.org, DNS:gossipbrigade.com, DNS:gsmcodigos.com, DNS:is.gl, DNS:lacasadivetro.com, DNS:madepal.co, DNS:mejorando.la, DNS:oceanvillageresort.com, DNS:pinside.com, DNS:ratelossprogram.com, DNS:reportcrowd.com, DNS:soopermexican.com, DNS:tequierocali.org, DNS:vladtv.com

Is there are realistic scenario in which you would have reason to believe the key of one site has leaked, while the keys of the other sites remain secure.

Not really. Should a customer using one of these keys request to move his site we wouldn't hand out the key.

You should be generating a new private key for each CSR you generate.

Right, we should. This is a case of trading off convenience (on our end) for security. For banking, hell no. Forum sites? Possibly worth it.

What you really need to think about in your setup is integrity of the CSR. The customers need to be absolutely certain, that the public key in the CSR they have signed is indeed the correct public key.

Come to think of it, the best option here is probably to forego the requirement of generating a CSR… we could just hand out a single CSR to everyone and have them sign it with the hostname they prefer (similar to what startssl does - when signing the CSR they throw away the requested hostname and use what you enter on their webpage.

I don't know if all (any?) CAs will do that, but it's an option.

MikeyB
  • 201
  • 1
  • 6
  • 8
    I think the real danger here is re-using the same private key for a lot of domains. – Tom van der Woerdt Mar 19 '15 at 21:29
  • 1
    Using the same private key for a lot of domains *is* a risk - I'll grant that. Is it really a risk if all those keys/certificates are sitting on the same SSL offload appliance, right next to each other? Does using different keys really help in that scenario? – MikeyB Mar 20 '15 at 02:12
  • 1
    There are two risks I can see. First, seeing the same key in many certs gives an attacker a tremendous amount of knowledge about your architecture. Second, the risk of disclosure multiplies by the number of sites (are you sure NONE of the thousands of sites have a malicious PHP script or some other vulnerability that is able to expose the private key?) while the effort of mitigation also multiplies by the number of sites (because you may have to get thousands of customers to all revoke and re-issue their certs). – Kevin Keane Mar 20 '15 at 05:18
  • 2
    @KevinKeane If the key is in an SSL offload appliance, then a malicious script would not have any access to it. – kasperd Mar 20 '15 at 12:42
  • 2
    The key question to ask may be this: Is there are realistic scenario in which you would have reason to believe the key of one site has leaked, while the keys of the other sites remain secure. With an SSL offload appliance, I would consider it a vulnerability in the appliance, if the key of any site could be leaked even with the intent of the site owner. Should I have reason to believe such a vulnerability should have existed and has been fixed, I would rotate the keys of all sites. So there would not be much benefit from using different keys. – kasperd Mar 20 '15 at 13:23
  • What you really need to think about in your setup is integrity of the CSR. The customers need to be absolutely certain, that the public key in the CSR they have signed is indeed the correct public key. – kasperd Mar 20 '15 at 13:31

3 Answers3

11

In theory, provided a system was secure enough and you only ever signed the CSR on a separate server, keeping that key damn secure, there would be no issue with this.

However,

  • What happens in the event that you do somehow have that private key compromised?
  • What's your plan in the event of a breach?
  • Will you have that private key for your TLS certificate on the same server as the signing server?

Ask yourself: is there any benefit to using the same key for 1000+ domains? Can you explain the single point of failure to your customers?

In addition, RSA (at least) has no currently known attack on being used for signing repeatedly that would give away the key. That one's reserved for DSA with a dodgy PRNG.

Still, it's a bad idea.

Update

The system you want in this case would be as follows:

  1. Every customer is jailed (via chroot()) into their own directory on the server
  2. For every CSR generated, a private key is generated in the user's jail, but outside of the webroot.
    • e.g. /jail/customername/private/server.key
    • /jail/customername/domains/<domain>/subdomains/<subdomain>/public
    • /jail/customername/domains/<domain>/public
    • /jail/a/domains/a.com/public/, etc.
  3. The webserver must respect jails, and scripting languages must run as a user that cannot access the private folder in every user's jail.

There would be no issue with this system; I'm assuming you are running a shared host system, and that you want an easy way to generate a CSR for each customer to enable TLS.

This way, you have correct and enforced separation of privileges for each customer and in the event a customer is compromised (barring any local privilege escalation exploits), the rest of your infrastructure is sound and you can just revoke the TLS certificate from the user who was exploited.

Amelia
  • 211
  • 3
  • 8
  • The CSRs would all be signed by a public authority of the customer's choice, not by an internal CA. – MikeyB Mar 20 '15 at 02:13
  • @MikeyB in that case I have an updated answer for you when I get to work – Amelia Mar 20 '15 at 08:33
  • 1
    If all the keys would be on a single server, that server will be as much a single point of failure if the keys are different as it is if the keys are identical. And running multiple servers is not going to help either, as a vulnerability would put all of them at risk anyway. Some customers will perceive the leak of 1000 private keys as worse than the leak of 1 private key. – kasperd Mar 20 '15 at 13:29
  • @kasperd A complete machine compromise would be catastrophic regardless. In this situation, userland compromise results in just that user being compromised, not everyone. The issue is that enforcing privilege separation that rigidly will come with plenty of headaches, especially in shared web hosting. – Amelia Mar 20 '15 at 13:32
  • @kasperd also, I just read the comments from the OP and this is ssl offloading, so the point about userland security is moot. Whoops. – Amelia Mar 20 '15 at 13:36
3

There is no danger in creating a lot of CSRs for the same private key, other than the re-using of the private key itself.

A CSR contains :

  • certificate request information (Subject etc)
  • the public key
  • a signature of the above, using the private key

As far as I'm aware there has never been a case where repeated signing using a private key degraded the security of the private key. If there was we'd all be in trouble.

However. Re-using the same private key for a lot of domains is a terrible idea. You should be generating a new private key for each CSR you generate. As soon as you start doing this there might be some trouble though! An attacker could generate a lot of private keys and this would in turn reduce the available entropy on your system, (hypothetically) causing private keys to be more predictable.

Tom van der Woerdt
  • 131
  • 2
  • 2
    *"An attacker could generate a lot of private keys and this would in turn reduce the available entropy on your system,"* - I don't think this is accurate. The correct practice is to use a cryptographically secure pseudorandom generator (e.g., `/dev/urandom`) to generate private keys. If you do that, this won't be a problem. Indeed, that's guaranteed by the very definition of what it means to be "cryptographically secure". If you *aren't* using a cryptographically secure prng to generate your private keys, you have more serious problems. – D.W. Mar 19 '15 at 21:58
  • 2
    @D.W. Either the system will grind to a halt because of low entropy (`/dev/random`), or the entropy degrades and keys are more predictable (`/dev/urandom`). Both are dangerous – Tom van der Woerdt Mar 19 '15 at 22:13
  • 5
    1. No, that is simply incorrect. If you use `/dev/urandom`, keys do not become more predictable. The purported danger simply does not exist. See http://security.stackexchange.com/a/3939/971. 2. Don't use `/dev/random`. See http://security.stackexchange.com/q/3936/971 and http://security.stackexchange.com/a/7074/971 and http://security.stackexchange.com/q/14669/971. (But even if you did, the only risk would be that it would take a long time to generate each private key. It wouldn't cause private keys to become predictable.) – D.W. Mar 19 '15 at 22:20
  • Is having `N` certificates based from the same private key any different from having a single certificate with `N` SANs? Other than the amount of work required to obtain/revoke? (security focus here, not management) – MikeyB Mar 26 '15 at 06:56
3

I originally wrote a comment with two possible issues earlier, and then realized there may be an even bigger one that warrants an answer.

Let's say that there is a (so far, hypothetical) zero-day vulnerability in the Web server, OS, or somewhere else that allows a PHP application access to the private key. Normally, this would only be exploitable by inserting a malicious PHP file. It would be a serious vulnerability, but can only be exploited remotely through other vulnerabilities that allows unauthorized uploading of a PHP script.

If you share the private key, such a vulnerability would become catastrophic. All an attacker would have to do is sign up for an account with you, upload the PHP exploit, and he'd instantly have the private key for thousands of other Web sites.

Similarly, in your scenario, something like Heartbleed wouldn't just compromise one site, but reveal the private key for all your customers at once, making this already serious issue utterly catastrophic.

Kevin Keane
  • 1,009
  • 7
  • 8