[HN Gopher] Build a tiny CA for your homelab with a Raspberry Pi
___________________________________________________________________
Build a tiny CA for your homelab with a Raspberry Pi
Author : timkq
Score : 86 points
Date : 2025-01-19 15:50 UTC (7 hours ago)
(HTM) web link (smallstep.com)
(TXT) w3m dump (smallstep.com)
| zikduruqe wrote:
| That isn't so tiny.
|
| This is tiny. https://github.com/FiloSottile/mkcert
| pkaye wrote:
| Does that provide an ACME server?
| likeabatterycar wrote:
| This is littered with so many missteps I don't know where to
| start.
|
| -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.
|
| -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.
|
| -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.
|
| -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.
|
| -Why do you need ACME in a homelab and can't just hand issue long
| lived certificates?
|
| -OpenSC and the crypto libraries are notoriously difficult to set
| up and working properly. A tiny CA this is not.
|
| 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.
| cwalv wrote:
| > Complete overkill requiring the use of a YubiKey for key
| storage and external RNG source - what problems does solve? For
| a Yubikey to act as a poor man's HSM you have to store the PIN
| in plaintext on the disk
|
| You still can't exfiltrate the key material.
|
| > If it's to protect against physical theft of the keys,
| they'll just put the entire Raspberry Pi in their pocket.
|
| Just because someone has compromised your device doesn't mean
| they have physical access. That's the point.
|
| > 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.
|
| The traces don't have to be left behind. Is this excessive
| 'overkill', or is the 'digital duct taping the windows and
| doors' insufficient?
|
| > An instance of openssl or xca covers 99.9% of "homelab" use
| cases
|
| The interesting thing about this article is that it adds a few
| 9's that are covered, and it's both easy and cheap.
| likeabatterycar wrote:
| > You still can't exfiltrate the key material
|
| And? What actual problem does this solve or realistic threat
| does this prevent? They are not decryption keys they are used
| to digitally sign certificates.
|
| What the DigiNotar hack taught us years ago is if your CA is
| compromised you are already 0wned doesn't matter if the key
| is stored in an HSM or not.
|
| All they can do with a stolen key is issue more certificates.
| Which they can do anyway if they have root access to the CA.
|
| You can put 12 locks on your door but if they're all keyed to
| the same key you've stored under the plant on the porch, it
| doesn't really matter.
|
| > The interesting thing about this article is that it adds a
| few 9's that are covered, and it's both easy and cheap.
|
| Hard to say if those extra 9's need an external RNG for extra
| entropy.
| cwalv wrote:
| > Which they can do anyway if they have root access to the
| CA.
|
| Until you turn it off. If they exfiltrate the keys, it's
| more complicated.
|
| This goes back to your comment:
|
| > 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
|
| But the root key is just created; it doesn't stay on the
| device and can't be used to sign anything.
|
| > What actual problem does this solve or realistic threat
| does this prevent?
|
| The problem is exfiltrating the key without physical
| access. Whether or not that's "realistic" enough to matter
| isn't a question that can be answered generally.
|
| > Hard to say if those extra 9's need an external RNG for
| extra entropy.
|
| IMO it's not. In the author's words: Optional, but fire
| mschuster91 wrote:
| > Why do you need ACME in a homelab and can't just hand issue
| long lived certificates?
|
| If there is one thing I _hate_ it is hand issuing certificates.
| Even for a homelab.
|
| SSL just plain sucks and OpenSSLs incantation and especially
| config files make an already bad problem even worse.
| bigiain wrote:
| Also, a lot of homelab people are experimenting and gaining
| experience with stuff they run in production or at work.
|
| Those people are extremely likely to be using ACME in the
| wild.
|
| Running it in your homelab makes a lot of sense to me.
| tashian wrote:
| Hi, I'm the author of the post. Thanks for your questions here.
|
| > -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.
|
| Yep, it's overkill. Homelabs are learning environments. People
| want tutorials when trying new things. It's a poor man's HSM
| because not many people will buy an HSM for their homelab, but
| almost everyone already has a YubiKey they can play with.
|
| The project solves the problem of people wanting to learn and
| play with new technology.
|
| And it's a way to kickstart a decently solid local PKI, if
| that's something you're interested in.
|
| The RNG is completely unnecessary flair that just adds to the
| fun.
|
| > -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. > -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.
|
| The tutorial shows how to generate and store the private key
| offline on a USB stick, not on the device or the YubiKey. The
| key material never touches the disk of the Raspberry Pi.
|
| Why store a copy of the CA keys offline? Because YubiKeys don't
| have the key-wrapped backup and restore feature of HSMs. So, if
| the YubiKey ever fails, you need a way to restore your CA.
| Storing the root on a USB stick is the backup. Put the USB
| stick in a safe.
|
| If you want active revocation, you can set it up so that the
| intermediate is revocable--in case physical theft of the key is
| important to you. (We have instructions to do that in our
| docs.)
|
| > -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.
|
| It's open source software downloaded from GitHub. The only non-
| smallstep code is the RNG driver (GitHub is the distribution
| point for that project). Was there a kind of verification that
| you expected to see?
|
| > -Why do you need ACME in a homelab and can't just hand issue
| long lived certificates? -OpenSC and the crypto libraries are
| notoriously difficult to set up and working properly. A tiny CA
| this is not.
|
| Most people don't need ACME in their homelab, they just want to
| learn stuff. That said, we have homelabbers in our community
| issuing certs to dozens of endpoints in their homelab.
|
| Whether you issue long-lived or short-lived certs is a
| philosophical issue. If a short-lived cert is compromised, it's
| simply less valuable to the attacker. Short-lived certs
| encourage automation. Long-lived certs can be easier to manage
| and you can just manually renew them. But unplanned expiry of
| long-lived certs has caused a lot of multi-million dollar
| outages.
|
| I hope this helps clarify things.
| rmoriz wrote:
| 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.
|
| 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.
|
| 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: "claims": {
| "minTLSCertDuration": "24h", "maxTLSCertDuration":
| "26400h", "defaultTLSCertDuration": "9000h" },
|
| 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.
|
| CAVE: macOS enforces duration limits even for trusted enterprise
| CAs, e.g. Safari won't accept your 1000 days certificate anymore.
| tashian wrote:
| It's true, the defaults are quite strict.
|
| As for the "hours" max interval, this is the result of a design
| decision in Go's time duration library, dealing with the quirks
| of our calendaring system.
| ostensible wrote:
| 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: http://holdenc.altervista.org/avalanche/.
| Bonus -- maybe it will get you hooked on electrical engineering!
|
| Btw, some versions of raspberry pi already have hardware random
| number number generator accessible at /dev/hwrng.
| tashian wrote:
| I love this idea!
| myself248 wrote:
| How does the disconnected audio input of any random PC or
| thinclient compare?
|
| I continue to find it a bit silly to see "with a raspberry pi"
| when people just mean "with any random linux box that doesn't
| need to be very powerful".
|
| It's like listening to NPR, where every smartphone is an iPhone
| even if it's an Android, you know?
| juliangoldsmith wrote:
| >How does the disconnected audio input of any random PC or
| thinclient compare?
|
| That will give you RF noise, which isn't really random.
| jcims wrote:
| I'd do this then three years later realize that something broke
| and it's just been feeding zeroes for the last 18 months.
| kevindamm wrote:
| good point, the project immediately after building the CA is
| to build a decent monitoring/alerting setup.
| bpye wrote:
| Is there any way to replace the dedicated RNG with the YubiKey
| RNG? The OpenPGP applet allows you to query its internal RNG [0].
|
| [0] -
| https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements...
| nimbius wrote:
| For those interested in an hsm pi, theres picohsm
| https://github.com/polhenarejos/pico-hsm
| pandemic_region wrote:
| Not appreciating the hijacking of the back button until the
| cookie form is dismissed.
| globular-toast wrote:
| 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.
| drpixie wrote:
| 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.
|
| 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?
| throw0101c wrote:
| See also perhaps "Running one's own root Certificate Authority in
| 2023" from a little while ago:
|
| * https://news.ycombinator.com/item?id=37537689
| jcims wrote:
| I think a nanosat running a CA that you can directly via some
| kind of low cost RF channel would be a fun experiment.
| packetlost wrote:
| I use MiniCA for this. It's really nice
___________________________________________________________________
(page generated 2025-01-19 23:00 UTC)