2

For devices like decrypting HTTPS proxies, there is often a built-in mechanism for generating a key-pair and CSR. An admin can then have their in-house authority sign the CSR with a subordinate CA template, and bind the certificate to the CSR in the appliance. In this case, the private key doesn't leave the appliance (and generally cannot be exported).

The same appliances often provide an option to upload an encrypted private key and certificate. In this scenario, the admin would use (for example) OpenSSL to generate the key and CSR on a separate machine, procure the certificate, and then upload them. The advantages in that case are the ability to store the private key for backup, potentially to specify longer key lengths, and add additional information to the CSR that may not be available in the generation wizard on the appliance. This of course assumes a solid key escrow/backup process.

My question is: Assuming there is a hardened, dedicated, offline machine (or "vault") for generating the key and CSR, which is the preferred method? From a security best-practice perspective, should the key be generated on the target appliance using the wizard, or the dedicated "OpenSSL" machine?

  • should the key be generated on the target appliance using the wizard -- I always recommend this option. The key must be generated on device where it will be used. The only exception is when device has no capabilities to generate the key. – Crypt32 Sep 5 '18 at 17:39
1

Generally you should generate key pairs on the device itself. That way your key stays at the location it is used for, minimizing the possibility to attack. Besides that, you can be certain that the certificate is compatible with the protocol. Certificates follow a well established standardized protocol (X509v3) but there certainly will still be implementation differences, if just because of the complexity of the data structure.

There is generally no need to backup . If the key is lost you can simply regenerate a new set of key pair -> CSR -> certificate. This is because you generally trust a higher level certificate than the root certificate. For a professional setup I would certainly not go for a self signed certificate (a certificate chain of length 1). One reason for distributing a certificate would be a load balancing cluster in which you want to reuse the key / certificate - it that is not taken care for automatically.

If you really require special certificate details (a specific name, key size etc.) then you could import the key / certificate using a PKCS#12 key store or similar. However please remember that preciously few people will actually look at the certificates. You're the person securing the infrastructure, after all.

I'd spend most of the time thinking about accessibility of the certificates and of course the validity period of your certificates. It seems you try and follow good crypto practices for this part of the setup. Time to think about the other parts. Generally time spend splitting hairs means that other parts of the system are forgotten.

  • Key ceremonies are a pain to get through, but creating a secure backup with an IT that isn't used to handling highly sensitive key material is generally even worse. Choose between your evil options carefully and consider which one is least evil within your company :P – Maarten Bodewes Sep 21 '18 at 11:15
1

I’d second the comments that the method that least exposes the key should be preferred, i.e. generating it on the device.

If you want to be diligent, I’d ask the manufacturer how they generate the random numbers, and ask them for a means of getting a number of random numbers (say couple 100,000s) from the device. You can then subject those random numbers to a randomness test.

Another point to watch out for is if the device implements state of the art encryption & hash methods, and if the manufacturer provides software updates. If either of the two points is negative, you might prefer to generate certs on a different system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.