1

I work as a .NET developer on a small development team. Our organization has several websites, that all have certificates for serving them via HTTPS.

The websites are deployed to On-premise Windows 2019 Servers, and the certificates are imported through the Certificates snap-in in the Microsoft Management Console.

When the certificates are renewed, our boss usually sends the pfx-file in an E-mail, and the password used to import/decrypt the certificate, via a different channel.

The problem is, that we don't know how to store the certificates and the passwords, away from the servers. Right now, they are stored in a network drive, in a folder with special permissions, so that only our boss and us developers can access the files - but none of us feel that is the right way to do it.

The source code for our applications is in Azure Devops, but we do not have an Azure tenant, so we cannot use Azure Key Vault. We have thought about setting up a repository in Azure Devops for certificates and passwords, which our boss could manage access to, but we are not sure if that is the right approach either.

What are the best practices for storing certificates and the passwords used for importing/decrypting them?

Lars Kristensen
  • 113
  • 6
  • 1
    '*What are the best practices for storing certificates and their passwords?*" - I think you mean 'What are the best practices for storing our private keys?'. Certificates are public. Your site serves the certificate to a user agent whenever one connects by https. It is the private key (which corresponds to the public key in the certificate) that must be kept private. Many companies use a HSM for this. – mti2935 Jun 23 '21 at 11:44
  • @mti2935 I apologize if I have used incorrect terms - I am in no way a security / certificate expert, so I may have mixed things up :-) I was under the impression that the password used for importing the cert was separate from the actual private key. Through my browser, I can save the cert for the website I visit, but even if I knew the password for it, I wouldn't be able to import _that_ cert for use on my own website, because it doesn't contain the private key part (and doesn't require a password either). Is this incorrect? – Lars Kristensen Jun 23 '21 at 12:13
  • OP, No problem. Private keys are often encrypted using a password to prevent them from being used if they fall into the wrong hands. The password that you are referring to might be used to encrypt/decrypt your private key. WRT, 'I wouldn't be able to import that cert for use on my own website' - yes that's correct. Having another site's certificate does not enable you to impersonate that site, because the private key is also needed. See https://security.stackexchange.com/questions/105376/could-a-stolen-certificate-show-as-trusted/105377#105377 for more info. – mti2935 Jun 23 '21 at 13:13
  • @mti2935 Consider writing an answer instead of a comment. –  Jun 23 '21 at 14:07
  • @MechMK1 Thanks for the suggestion. I was considering that, but there still seems to be some confusion around the question. But, if you want to post an answer, go for it. OP, in some cases, the private key and the certificate (and possibly other certificates in the chain as well) are stored in one file (and possibly encrypted with a password). If this is the case in your setup, this might explain some of the confusion. But, the important thing is that, even if this is the case, the server only serves the certificate(s), and not the private key. – mti2935 Jun 23 '21 at 14:13
  • I have edited the question to clarify that I am asking about the password used to import/decrypt the certificates. Is there anything else about the question that needs clarifying? – Lars Kristensen Jun 25 '21 at 06:23
  • @LarsKristensen So you generate the keys for SSL certificate on some other machine and then once certificate is issued you transfer the pfx file (containing private key) to windows server for importing? And windows server host the websites? – saurabh Jun 25 '21 at 20:38
  • @saurabh Correct. My boss orders the certs from an IT department elsewhere in the organization (who in turn order them from a CA). – Lars Kristensen Jun 28 '21 at 05:57
  • Part of the confusion around this question may be around the fact the private key and the certificate are sometimes stored in the same file. See https://security.stackexchange.com/questions/226747/what-is-the-difference-between-a-certificate-and-a-private-key for more information on this. – mti2935 Jun 30 '21 at 09:20
  • Can you elaborate on exactly what is confusing? Even in the original question, I had described how we work with the pfx-files and their passwords, and from the answer in your linked question: "`.p12` and `.pfx` files are _usually_ used to store a certificate together with the private key that corresponds to this certificate." – Lars Kristensen Jun 30 '21 at 09:44

2 Answers2

3

As per discussion from the comments you are generating the keys on another machine and then after generation of the certificate transferring the PFX file containing the private key to Windows server which hosts the website.

My recommendation is to not generate keys on any other server. Instead, generate the keys on the Windows server where your website is hosted. Create a CSR (Certificate signing request) on the server itself. Send the CSR to boss and your IT department can issue a certificate without having a private key.

This ensures that your private key never left the server.

Now for the security of private keys you can opt any one of the following methods as per your security requirements:

  1. Store keys in some Hardware based security module. (Recommended)

    • HSM as suggested by one of the answers. Private keys will be generated and kept inside HSM, and you must make sure that HSM is accessible from your Windows Servers for accessibility of keys for sites.
    • TPM (Trusted Platform Module) if your Windows server has TPM capability, then you can use TPM to store keys via VSC (Virtual Smart card). Store the keys in VSC and your web server can access the keys from VSC. Keys will be non-exportable in this case once imported. You can also use TPM directly instead of using via VSC.

  2. Store keys in windows trust key store:

    • After generation of keys and certificate, import PFX file into trust store and make it non-exportable. (You are already doing it, as far as I know.) You must make sure only limited people access to Windows Server admin accounts.

Now comes the backup of keys. You can go with either one of the options:

  1. Create a backup of your Windows server itself in case of option (2).

  2. For option (1)(a) HSM manages the backup procedure.

  3. For option (1)(b): Backup of TPM and Server itself.

  4. Store password protected PFX file to some encrypted SAN storage with limited access.

    • This option, however, beats the purpose of making keys non-exportable.
    • Create PFX on the server where you have generated the keys and then transfer password protected PFX file to storage.
    • keep Password for PFX file at separate location for e.g.password manager or if possible remember the password.

Or

No backup at all:

Re-issue the keys and certificates from the CA in case of keys lost. Some CA allow re-issuing the keys without any cost, since they charge differently.

If you follow the procedure, it will ensure that developers do not have access to your private keys, at least if you do not give them Admin access to your Windows Servers or any of the security module you have used.

saurabh
  • 723
  • 1
  • 4
  • 12
  • Thanks for the detailed answer. My question was how to store the certs and the passwords for importing them, and your answer is _"Don't do that."_ While I agree, I can't change that. I'm just a dev trying to make my teams internal processes more secure. I started reading about HSM when @mti2935 first commented on my question, and while it seems like the ideal setup, it would require infrastructure restructuring, which I doubt my boss will invest in right now. I think, he thinks, that the current process is "secure enough", and I need concrete evidence that it isn't, if I want to change that. – Lars Kristensen Jun 29 '21 at 11:08
  • 1
    @LarsKristensen I've updated the answer. You can go with 4th option mentioned in keys backup part. Regarding why, I said "Don't do that" is because this is how you protect keys. Even the other answer related to HSM imply the same. You need to create keys on different location, i.e. HSM. If you go with the option of creating keys on Win server, option 2 for key protection and option 1 for backup, you do not need any infra changes. Just the process change. – saurabh Jun 29 '21 at 18:47
  • Thanks again. I suppose the solution for the current situation, is to use a password manager for storing the password for the certificate-files, but otherwise continue with storing the files on a network drive with appropriate access rights. I still agree, that the current setup is not ideal, but I don't have enough stripes on my shoulders to make a change about this in not just my own team, but several other parts of the organization. I will forward all these suggestions to my boss and ask him to address the suggestions and concerns you have outlined. – Lars Kristensen Jun 30 '21 at 11:28
2

Following the discussion in the comments after this question, my recommendation would be to use a hardware security module (HSM) to store your SSL private keys. When you use an HSM, the private keys never leave the HSM, so it's impossible for a private key to fall into the wrong hands.

Being that you are running physical servers on-prem, a HSM solution should not be too difficult to implement. See the links below for more information on how this solution works:

How should I store SSL keys on the server?

Why is an HSM required to protect CA certificates (rather than a regular USB token)?

There are also cloud-based HSM's, like this one offered by Amazon AWS:

https://docs.aws.amazon.com/cloudhsm/latest/userguide/ssl-offload-overview.html

mti2935
  • 19,868
  • 2
  • 45
  • 64