3

I've been researching how to secure privaye keys for SSL certificats using nginx as a webserver, but have not been able to find many satisfactory answers.

Specifically, for a client who wants to me to deploy a website under their own sub-domain, they are afraid that someone could access their sub-domain's certificate private key, and hence setup a legitimate-looking unsafe website. They have asked me to use some kind of software vault solution to secure they private key.

This article from nginx's blog as well as this one describe some solutions, but in the end they both rely on the same principle: the private key is protected by a passphrase, that we will retrieve from either a local or remote location, and this "retrieval" procedure requires a password/token.. that is stored locally.

Hence I fail to understand how the private key really gets more secure - it looks a bit like locking your frontdoor key in a keybox instead of leaving it under the mat... and then leaving the keybox key under the mat.

Am I missing something? Is there a better way to secure a private key with nginx?

Buno
  • 155
  • 2
  • 8
  • If they are willing to point a sub domain record to your server, they have to implicitly trust you. Instead of stealing their key, you can also just use Let's Encrypt to generate a new one. There's no way around it: the server in question needs to contain the key. You haven't really made clear why this server can't be trusted. – Halfgaar Apr 19 '20 at 17:29
  • Sorry if unclear - they do trust my server, what they are afraid of is that if a hacker compromises my server and steal the certificate and private key under their name, they could create a replica website, for phishing purpose for instance, and still get it to look like a "legit" website from their corporation. IMO it's only a real danger if the certificate they issue me is a wildcard certificate - which they shouldn't do - but as often in business, a client "is right" just because he's the client.... – Buno Apr 19 '20 at 18:52
  • You may be interested in this article: https://www.nginx.com/blog/protecting-ssl-private-keys-nginx-hashicorp-vault/ which also mentions HSM as an option, but the other options are also about hardening against simple attacks – JohannesB Apr 20 '20 at 06:37

3 Answers3

3

Based on your last comment, I see several options:

  • You show you have good SSH security, which can be IP whitelisted access, no password logins, etc.
  • You show the private key file is readable only to the root user and stored outside of the document root, for example, as common somewhere in /etc/ssl. Hacking a hosted website is much more common than the entire server, and that way, there is protection against it being read that way.
  • About the above point: careful of running docker containers; they typically run as root, and are, in my opinion, a security issue. Docker containers can run rootless (experimental), but images have to be designed specifically to do so. Most images you get elsewhere, depend on being root. Anything in it running as root can break the jail. (Edit: it indeed requires some nuance after re-evaluation. I should say, could break the jail. It does depend on some extra mechanisms being secure, that you otherwise wouldn't need to worry about.)
  • If they are really concerned, they should set up a reverse proxy to your server, and they can do the SSL termination on their end.

And about giving you an SSL certificate: they don't have to. You can just set up Letsencrypt. Added bonus is that those certificates are short lived.

Halfgaar
  • 7,921
  • 5
  • 42
  • 81
  • 1
    I would definitely disagree, that properly configured containers are security issue. This is just personal opinion. We have NISM standards for Docker. They provide way broader isolation (process, resources and namespaces). Misconfigured containers might be a security issue, but as each service. Properly configured give better process isolation. Of course, not as much as virtualization, but still... better than nothing. – limakzi Apr 19 '20 at 22:18
  • Docker containers *can* run as non-root, but images have to be designed specifically to do so. Most images you get elsewhere, depend on being root. Anything in it running as root can break the jail. – Halfgaar Apr 20 '20 at 06:36
  • Thanks. FYI we can't use Letsencrypt certificates because they want to provide an EV certificate but I do agree a good access control and server security should be "good enough" for that specific risk. The reverse proxy is a very interesting solution (provided a VPN connection between the reverse proxy and our infrastructure is "sturdy" enough, as the machine used as RP would be in the client's infrastructure) – Buno Apr 20 '20 at 15:50
  • Do people still use EV certs? Browsers no longer show the whole company name from the certificate in the address bar, so I don't see the point of them anymore. – Halfgaar Apr 21 '20 at 06:56
  • @Halfgaar, there is one. The two, actually. Business and prestige. Both badly understood. :) – limakzi Apr 21 '20 at 17:25
2

There is one solution, but, indeed, it does not remove the need to trust your server. If you Client is willing to put his record to your server, he has to trust you, somehow. There is one solution that might protect your Client.

  • They point subdomain to Web Application Firewall, like Cloudflare. They create you an Origin certificate (the one that is on your server) and send you certificate and key, via trusted communication protocol, like GPG.

  • They point this subdomain to your servers IP address.

  • They do not give you access to their Cloudflare account.

Keeping all of that. They control Edge certificate. They control Origin certificate. They can always revoke it. They control their domain. The only thing, your Client does not control is of course your server. ;)

Of course, the whole security setup presented by @Halfgaar is still up to date.

————————————————————-

If you want to build trust, you can show audits from your server. Present audit logs. Prove that your servers security is compliant with standards, like NISM or STIGS.

limakzi
  • 171
  • 4
2

  • Everything is covered up by the comments and answers, I would just
    like to add up, stealing the certificates alone is not enough. The attacker also has to come up with valid domain for which the certificate has been verified.

  • In case of phishing attacks the website might look the same but the
    domain might not be the same, and the certificates won't work with different domain.

  • Until the DNS is pointing correct IP, and DNS is not spoofed or messed, stealing the SSL certificates is useless.

  • In this situation where client is somewhat in doubt, you can use let's encrypt certificates which comes with less period
    of validity (90 days). And have to be renewed regularly.

  • Obtaining and renewing Let's encrypt certificates needs domain verification each time. So stealing the certificates won't be much useful for long time.

mandar
  • 21
  • 2