Offtopic: what kind of private CA on a LAN warrents the investment of $ 100 for such a DIY HSM? Just curious.
3 Likes
In my case, it's a toy, I already had the Pi, and I kind of wanted to play with YubiKey anyway. Both it and the TRNG are optional; without them, the cost is $35 for the Pi (if you don't already have one), a few bucks for a SD card, whatever you want to spend for a case, and a wall wart. And if I don't want to continue running the local CA, I can repurpose both the Pi and the YubiKey.
In a business environment, it seems to me that this guide gives you a pretty high-security local CA. It's going to be pretty close to impossible to compromise the CA's private key, even with physical access to the thing, subject to how well-hardened the YubiKey is in this application. If you want TLS on your LAN resources, this gives you only one cert to deploy to your client machines (which, as you observe, can readily be done in a centralized manner). I'd think in a business environment it'd be well worth it, and would cost at least an order of magnitude less than an off-the-shelf box with similar capabilities.
6 Likes
There’s also the Nitrokey HSM, which is very inexpensive and is built for this: designed for less user interaction, fewer extraneous features, and higher performance. I haven’t played with one yet but it’s on my list.
7 Likes
I guess the advantage of a Raspberry Pi is that it has an onboard hardware random number generator in its SoC. Not sure how many other simple SoC-devices have that!
4 Likes
I think the main advantage of the Pi is that it's cheap, so you can have dedicated hardware for your CA (thus enhancing its security) without spending a bundle. I wasn't aware that it had a built-in hardware RNG, and I don't think the authors of the guide I linked were either--hence adding that as an optional extra.
6 Likes
@dpape Well, I came here to discuss this exact thing, so I'm happy to see someone else bringing this up already! I like your idea about an intermediate certificate limited to only TLDs that are reserved for local network use (such as .local). Since nobody can own the DNS entries in the public space, it should be safe to do.
I made homelab.express for the same reason - it's obviously not an ideal solution, but it works for a home lab setup. I'd love to see a better-supported option like the one you describe, and I think that Let's Encrypt is one of the best-situated CAs to make it happen.
EDIT: Reached out to GlobalSign about this, since they have an article about it:
I'll report back when I hear from their sales on if its possible and how much it would cost.
4 Likes
Notice that in the HTTP case this isn't a Secure Context and so a bunch of things just don't work. The intent from the major browser vendors (effectively now just Apple, Google and Mozilla) is that no new features will be introduced outside the Secure Context, and some older features may be gradually eliminated outside context.
Now, of course for some products none of the features introduced in the last twenty years are interesting anyway, they just wanted to have a few basic forms, but this is an important reason why "just use HTTP" isn't a way forward.
You can expect the warnings for not being in a Secure Context to increase over time as well, once upon a time it didn't even explicitly mention the lack of security.
3 Likes
@tialaramex You describe very well the reason I was making this ticket for. It is not that I think that HTTPS is flawed, in the contrary. But a solution should be created to keep all browser features working without the internet. To make a small start I have opened the following mozilla bug:
4 Likes
I've always been waiting for step-ca to provide a tool for OCSP and crl generation. 
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.