@kajer @cR0w fun related fact: I know of a very large institution which runs their own Certificate Authority.
This CA is basically openssl on a fully air-gapped laptop.
That laptop in 2021 was running RHEL4. Because it was *COMPLETELY* airgapped. No network. Only one USB port not filled with epoxy. Kept in a safe.
And this was deemed safe and secure because it was completely and totally airgapped.
This must have been the internal root CA. I know, because I used to run the internal root at a previous job. The workflow looked like this:
* get root CA from safe
* generate CSR on new issuing CA, copy to new flash drive
* plug flash drive into root CA, issue cert, copy to flash drive
* plug flash drive back into online machine, copy cert to issuing CA
* put root CA back in safe
There was a similar process for issuing the root CA's CRL every month
@kajer @ducksauz @cR0w you really, really have to be an absolute idiot to pay for "cloud" HSMs, honestly. They are INSANELY expensive to say the very least, and it is completely impossible for them to actually be secure.
It just is. PHYSICAL inspection and PHYSICAL tamper indicators are a non-optional part of it.
Meanwhile a Thales Luna 7 hardware HSM at the very tippy top end (max perf, 5 partitions, ent support) costs less than half that.
For 3 years.
@kajer @ducksauz @cR0w and "less than half" is being... generous. I have priced out "cloud" HSMs for certificate services.
$135,000 per year for a miserable enterprise Java Beans "cloud HSM."
The "less secure" version that is just as insecure is still over $75k per year.
Venafi has a nice product. They charge you $100,000 per year to manage it "in the cloud." Not including HSM.
I can literally just whip out a credit card and buy a Luna 7 for $52k. And I actually own it.
@rootwyrm @ducksauz @cR0w not my money, it was a DevOps thing... Until I moved to the SecOps team, then we were tasked with finding HSM solutions to support our hashicorp integrations...
Luckily my SecOps experience was revolving around defending the network from Devops and constantly pulling logs from the F5 and Palo to prove that the latest devops push was to blame for application problems, and not thew FW/LB policy
Dealing with HSMs and FEKs and the like was not what I would consider to be fulfilling work.