This being raspberry pi absolves you from needing to buy a separate hardware noise generator: it has plenty of GPIO. For example, one can obtain entropy by sampling random noise generated by reverse-biasing a junction in a cheap pn transistor. Here is an example: <a href="http://holdenc.altervista.org/avalanche/" rel="nofollow">http://holdenc.altervista.org/avalanche/</a>. Bonus — maybe it will get you hooked on electrical engineering!<p>Btw, some versions of raspberry pi already have hardware random number number generator accessible at
/dev/hwrng.
I'm running smallstep CA in my homelab. While it's nicely done and clearly focuses to the containerized enterprise market, its defaults are very harsh.<p>Take for example the maximum certificate duration. While from a production/security perspective short-lived certificates are great, you don't want to renew certs in your homelab every 24-48hrs. Also, many things just don't support ACME but still benefit from a valid certificate, e.g. router/firewall/appliance web interfaces. Out of the box, the limit for traditionally issued certificates using the CLI is very low, too.<p>The default prevents expired certificates to be renewed. If your homelab does not offer a couple of nines behind the comma, you'll pretty much have to intervene on a regular basis UNLESS you adjust the defaults. You can't set the max duration to years, months or days but only hours:<p><pre><code> "claims": {
"minTLSCertDuration": "24h",
"maxTLSCertDuration": "26400h",
"defaultTLSCertDuration": "9000h"
},
</code></pre>
If the goal of hour homelab is to design/test/experiment with a fault-tolerant high availability k8s infra, e.g. for your job, it's great.<p>CAVE: macOS enforces duration limits even for trusted enterprise CAs, e.g. Safari won't accept your 1000 days certificate anymore.
This is littered with so many missteps I don't know where to start.<p>-Complete overkill requiring the use of a YubiKey for key storage and external RNG source - what problems does this solve? For a Yubikey to act as a poor man's HSM you have to store the PIN in plaintext on the disk. So if the device is compromised, they can just issue their own certs. If it's to protect against physical theft of the keys, they'll just put the entire Raspberry Pi in their pocket. You could choose to enter the PIN manually but this precludes any automation including CRL generation. It's also a waste of a good YubiKey.<p>-Creates a two-tier PKI... on the same device. This completely defeats the purpose so you can't revoke anything in case of key compromise. You could make it a 100-tier PKI and it would make no difference if they're on the same device. Though they would need a whole lot of YubiKeys and USB hubs for that.<p>-They're generating the private key on disk then importing into the YubiKey. Which defeats having an external key storage device because you have left traces of the key on disk.<p>-All this digital duct taping the windows and doors yet the article instructs you to download and run random binaries off GitHub with no verification whatsoever.<p>-Why do you need ACME in a homelab and can't just hand issue long lived certificates?<p>-OpenSC and the crypto libraries are notoriously difficult to set up and working properly. A tiny CA this is not.<p>An instance of openssl or xca covers 99.9% of "homelab" use cases. This is like using a battery operated drill to open a can of soup.
"with a Yubikey" is probably a better title. The yubikey thingy costs more than the PI (and there is a helpful link if you want to buy one).<p>Very little of this has to do with a PI, it seems like almost any kind of home server would work (especially linux). And it is unclear to me what value is added by the yubikey? And would any FIDO device work, or is this yubikey brand only?
For those interested in an hsm pi, theres picohsm <a href="https://github.com/polhenarejos/pico-hsm">https://github.com/polhenarejos/pico-hsm</a>
Is there any way to replace the dedicated RNG with the YubiKey RNG? The OpenPGP applet allows you to query its internal RNG [0].<p>[0] - <a href="https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements_to_OpenPGP_3.4.html" rel="nofollow">https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements...</a>
That isn't so tiny.<p>This is tiny. <a href="https://github.com/FiloSottile/mkcert">https://github.com/FiloSottile/mkcert</a>
I wish it was easier to get your CA installed in trust stores. Even for devices you control it's annoying but even worse if you want to share your services with mates at your house or over VPN etc. In the end it's just easier to go with LE certs for all practical cases.
Bit of an aside, but the "Infinite Noise TRNG" seems to generate not very random "raw" data, which it hashes to make it appear as random bits.<p>Am I missing something, or wouldn't it be better to start with highly random raw data, and hash that to get more bits-per-second?
See also perhaps "Running one’s own root Certificate Authority in 2023" from a little while ago:<p>* <a href="https://news.ycombinator.com/item?id=37537689">https://news.ycombinator.com/item?id=37537689</a>
This has been on my list to implement for a while. It's a really great idea for things like proxmox and pfsense that you probably don't want to use LetsEncrypt for, but support ACME.
I guess I'm not the intended audience, but the last thing I want in my homelab is a CA. One more thing I'd set up, forget how it works, then spend an entire weekend trying to fix when it breaks a year from now.