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?

Improve this question
10
  • 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
    Commented Jun 23, 2021 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
    Commented Jun 23, 2021 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 security.stackexchange.com/questions/105376/… for more info.
    – mti2935
    Commented Jun 23, 2021 at 13:13
  • @mti2935 Consider writing an answer instead of a comment.
    – user163495
    Commented Jun 23, 2021 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
    Commented Jun 23, 2021 at 14:13

2 Answers 2

Reset to default
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.

Improve this answer
3
  • 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
    Commented Jun 29, 2021 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.
    – sau_t
    Commented Jun 29, 2021 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
    Commented Jun 30, 2021 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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .