There will always be a “secret” in a file. You get to pick the file, that’s it.
The certificate is public. The servers hands it to anybody that connects to it, so put it wherever you want. The important part is the private key that goes with the certificate. Let’s concentrate on the private key.
Say a plug-in existed that allowed to store the private key in Vault with TLS in mind. It would work in one of two ways:
- Vault hands of the private key when nginx starts (what the kv store actually does)
- nginx asks Vault to do the cryptographic operations required for TLS to work (what a plugin would do)
Both options require nginx to have valid credentials in Vault, like an AppRole
secret_id. You’ve done nothing but to pick a different file to put your secret in. If you are worried an attacker can read the private key, you are now worried they can read the secret-id that provides the private key. No security gain, just added mere minutes to your hacker’s plan.
Option 2 - setting aside the huge latency and performce issue it brings - would allow the private key to never leave Vault. But you would still credentials to ask Vault to perform the operations. If you absolutely must keep the private key outside your server’s filesystem, you can use a Hardware Security Module (HSM) optimized for that purpose. They are really expensive and hard to manage and usually not worth it in a risk reduction scenario.
The best solution for this is to use short lived certificates issued by Vault. You still need credentials to get them, but at least you get to control and audit what the certificate is used for.