Timeline for How to protect web server private keys on Ubuntu with Nginx without exposing any plain text credentials?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 21, 2020 at 3:15 | comment | added | rip... | You don't need a cloud-based HSM -- you can use an on-premise one that the web servers reach back to. However: this doesn't solve the underlying problem of where the bootstrapping keys are stored. The nginx server STILL needs to be able to log into the HSM to make use of the keys there. | |
| May 19, 2020 at 22:30 | answer | added | mti2935 | timeline score: 0 | |
| May 19, 2020 at 21:24 | comment | added | mti2935 | You might want to consider using a cloud-based HSM to store your SSL/TLS private key. See docs.aws.amazon.com/cloudhsm/latest/userguide/… for info about Amazon AWS' solution for this (although your web server might need to be running on an AWS instance for this to work). | |
| May 19, 2020 at 16:55 | comment | added | Pedro | (sorry forgot to paste the link) Yes, it kind of doesn't really help massively. The centralised distribution point is a way to move the key material away from the system, but at some point it needs to be pulled in. If there's no authentication in the way, then all an attacker needs to do is trigger that process....... I've taken a stab at writing an answer for you from what we've been discussing. | |
| May 19, 2020 at 16:53 | answer | added | Pedro | timeline score: 1 | |
| May 19, 2020 at 16:43 | comment | added | JustAMartin | Unfortunately this seems to be a common practice and even Nginx and Apache manuals do not warn about storing unencrypted keys or their passwords as unacceptable in production environments. Nginx touches the topic briefly in their nginx.com/blog/secure-distribution-ssl-private-keys-nginx offering a password distribution point solution... but that also needs an authentication token that has to be stored somewhere. | |
| May 19, 2020 at 16:27 | comment | added | Pedro | have a read of this, but please apply common sense - having an encrypted certificate with a plaintext file containing the password isn't really a great idea. distributing the password files from a web server makes me cry..... | |
| May 19, 2020 at 16:24 | comment | added | Pedro | It would have to be implemented by hand, I'm 99% sure nginx knows nothing about the keyring. method would be: system boots, requests password, adds to keyring, nginx would be wrapped in a script that pulls the password, decrypts certs (or cert pwd file) into RAM, starts nginx then scrubs the file. | |
| May 19, 2020 at 16:09 | comment | added | JustAMartin | @Pedro Yes, entering password on server reboot (but not on every Nginx daemon restart) might be acceptable. If only I knew how to configure Nginx itself to work with keyring and TLS certificate key passwords... Internet searches somehow don't yield anything immediately usable. | |
| May 19, 2020 at 15:39 | comment | added | Pedro | Yeah, this does happen sometimes. There's options including encrypting the files and adding the key to the kernel's keyring, though you'd certainly have to enter a passphrase once at every boot. Will it satisfy their requirements if the local file system is encrypted? | |
| May 19, 2020 at 11:49 | comment | added | multithr3at3d | I feel like the requirement is intended for application user accounts, not system things. | |
| May 19, 2020 at 10:03 | review | First posts | |||
| May 19, 2020 at 11:30 | |||||
| May 19, 2020 at 10:01 | comment | added | Marc | There are many options to store secrets, and a lot of it depends on your environment and automation vs security tradeoffs. You can find some discussion here. I would note that your arguments are indeed a bit weak. | |
| May 19, 2020 at 9:55 | history | asked | JustAMartin | CC BY-SA 4.0 |