1

We're considering setting up an internal certificate authority to issue ssl certificates. The certificates would primarily be used to secure internal websites, but I could foresee us potentially issuing certificates to secure our VPN infrastructure at some future point as well. Our systems are primarily windows based joined to active directory although we also centos systems and some mac systems. So I'm just wondering what the best strategy is?

I'm inclined to setup an offline root CA, and an enterprise issuing CA (two-tier PKI hierarchy). My impression is that I can do this with VMs entirely but that there's also a possibility that the root CA could be done with a hardware HSM? A HSM presents an interesting situation in the sense that it can be completely offline, and stored somewhere safe, there's also presumably no OS to worry about patching, maintaining, upgrading etc. Given that we'd probably issue the root certificate for 20 years this seems fairly appealing.

Has anyone used a HSM before? Any you'd recommend that are usb based, cheap (no more than a few hundred dollars), and simple to setup. Any challenges incorporating the HSM in with a Microsoft issuing CA? What else should we consider? Can anyone recommend any good how-to's? I'm searching google with mixed results.

Thanks, Brad

Brad
  • 613
  • 6
  • 12
  • You should keep your root offline. However, cheap usb HSMs is not the way I'd recommend you implement this. An offline Linux box with an encrypted hard drive should be adequate if you are not willing to invest into proper HSM. Make sure to future-proof your root and generate 4096 SHA-256 keys using known-good crypto module with sufficient entropy. Also, have you considered what you are going to do for revocation checking? OCSP vs CRL? – Kirill Sinitski Mar 16 '17 at 14:17
  • PKI cards supported by OpenSC are fairly cheap and can be used with OpenSSL. Get two, cross-sign their certs so if one card is lost/broken you can still operate your PKI. – André Borie Mar 16 '17 at 14:34
  • @KirillSinitski - I haven't gotten so far to consider OCSP vs CRL. To be honest this will be my first time implementing PKI - thus my question so that I can try and avoid some of the gotchas. Obviously reading as much as I can but still appreciate input from people who've actually implemented this stuff. I also want to make sure that we end up with a solution that will meet our needs for the immediate future but not over engineer it. We don't need NSA grade solution. The data being protected is low value (in fact its HTTP right now) so any encryption will be a step forward. – Brad Mar 16 '17 at 15:08
  • Then bitlocker-encrypted VM may be suitable for you. Though, you will have to turn on root CA machine to issue new CRLs and when you get new subordinate CA to sing the certificate. I would strongly recommend to setup everyting in lab with software keys just to test the whole PKI solution and only when it works as expected you can put concerns on key storage. You can use cheap user-grade smart cards to store CA keys, but it may not be supported by Microsoft and card vendor. – Crypt32 Mar 20 '17 at 21:13
  • @KirillSinitski CRL vs OCSP, the answer is easy: CRL is mandatory, OCSP is optional and if there is real need (when CRL traffic significantly exceeds potential OCSP traffic). – Crypt32 Mar 20 '17 at 21:15
  • @Crypt32 Could you please explain why you consider CRL mandatory and OCSP optional? – Kirill Sinitski Mar 22 '17 at 13:06
  • Because OCSP may not be supported by clients and there are cases when at some conditions client stops OCSP query and falls back to CRL checking (even if OCSP is fully working). This is why CRL must be configured and published to locations specified in the CDP extension. – Crypt32 Mar 22 '17 at 20:51

0 Answers0