Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Build a tiny CA for your homelab with a Raspberry Pi

smallstep.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Build a tiny CA for your homelab with a Raspberry Pi

#41

Post by akerl_ »

rmoriz wrote: post #10

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 c…

For what it's worth, I've had quite a bit of success using ACME for devices that don't natively support it by using a sidecar service.

Basically, running the ACME flow on a Linux system and then having it programmatically update the cert/key for the service that needs it. Have done this for my NAS, printer, router, etc.

Re: Build a tiny CA for your homelab with a Raspberry Pi

#42

Post by 8xeh »

ostensible wrote: post #11

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 h…

I was not aware of this! That's kinda fun.

I did an entropy test on my Pi5 (according to https://rob-turner.net/post/raspberrypi-hwrng), and it (7.999832 bits per byte) has about the same entropy as /dev/urandom (7.999831 bits per byte).

However, when using it directly, it's pretty slow. /dev/hwrng is 200 KB/s, /dev/urandom is 40 MB/s.

Though, maybe that doesn't matter if it's just intended to be used to add entropy to the system entropy pool.

Re: Build a tiny CA for your homelab with a Raspberry Pi

#43

Post by theamk »

Keyframe wrote: post #40
theamk wrote: post #29

Earlier quoted context omitted.

Electrical noise (including RF noise) is really random, as in it is impossible to predict exact value. It does have non-flat spectrum, meaning some values are more probable than others, but that only means you need to whiten it. (A rough analogy might be a 6-sided die labeled with 1,1,1,2,3,4 - yes, number 1 is much more likely to come out. No, this does not make it "not really random", and some trivial math can prod…

it's an often-made mistake where random generation / randomness is confused with probability distribution. Having said that, I don't know (as is in really don't know) if RF noise is unbiased; doesn't sound like it?

If you are talking about DC bias (as in, long term average of raw readings), then "unconnected audio input" is pretty likely to have it - it's easy to introduce via component tolerances, and there is no real reason to keep it exactly zero for audio purposes. But it's also pretty trivial to fix in software.

If you are talking bias in more general sense, then audio input noise is non-uniform in the frequency space, for example there is low-pass filter which filters out high input frequency, and it will affect noise values too. Good whitening algorithm is essential.

The good news however is there are many noise sources which are actually caused by quantum effects in electronic parts, and therefore completely unpredictable. Even if NSA recorded all RF noise, they still could not predict what the ADC will capture. (But they might be able to capture digital bits as they travel over the bus...)

Re: Build a tiny CA for your homelab with a Raspberry Pi

#44

Post by dsymonds »

NewJazz wrote: post #36
tashian wrote: post #13

Earlier quoted context omitted.

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.

This is the api presumably. Not sure about what would prevent days, wasn't familiar with the lore. https://pkg.go.dev/time#ParseDuration

It's because units up to hours are of a fixed size, but days in most places are only 24h for ~363/365 days of the year, with some being 23h and some being 25h.

(This is ignoring leap seconds, since the trend is to smear those rather than surface them to userspace.)

Re: Build a tiny CA for your homelab with a Raspberry Pi

#47

Post by johntash »

akerl_ wrote: post #41
rmoriz wrote: post #10

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 c…

For what it's worth, I've had quite a bit of success using ACME for devices that don't natively support it by using a sidecar service. Basically, running the ACME flow on a Linux system and then having it programmatically update the cert/key for the service that needs it. Have done this for my NAS, printer, router, etc.

This is what I do as well. I use acme.sh on one linux server to generate a cert with a few SANs on it, then copy that cert to things like opnsense/truenas/etc either using ssh or their api if there is one.

Re: Build a tiny CA for your homelab with a Raspberry Pi

#48

Post by johntash »

likeabatterycar wrote: post #4

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 jus…

> ... For a Yubikey to act as a poor man's HSM you have to store the PIN in plaintext on the disk. ...

I haven't read the article fully yet, but it's not a bad idea to store the Root CA on the yubikey, and then generate a separate intermediate CA that is not stored on the yubikey. This way, all your day-to-day certs are issued using the intermediate and you only need to touch the root ca if you need to re-issue/revoke/etc the intermediate.

Re: Build a tiny CA for your homelab with a Raspberry Pi

#49

Post by aaronmdjones »

talkingtab wrote: post #31

"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). 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?

> 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?

As my sibling comment says, this doesn't use FIDO, it uses PIV. The YubiKey pretends to be a USB CCID-class smartcard reader [1], with a PIV-capable smartcard inserted. You could use any other PIV-capable smartcard, but then you would also probably have to buy a smartcard reader. I do have a Dell keyboard with a built-in smartcard reader [2], but I don't use it. This would also be much bulkier.

Edit: Smartcard vendors also vary wildly in terms of their support for "Things that aren't Microsoft Windows".

[1] among other things, such as a USB HID keyboard for the OTP functionality

[2] https://m.media-amazon.com/images/I/51m7Fuu3nWL.jpg

Re: Build a tiny CA for your homelab with a Raspberry Pi

#50

Post by tikkabhuna »

globular-toast wrote: post #18

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.

Having spent time at a reasonable sized corporate environment with our own CA, I have to agree.

Its often a case of its fine until it isn't and different organisations handle it differently. Python requests installed via pip will use its own truststore, but installed via rpm it will automatically use the system store. Amazon Corretto JDK also installs its own truststore, so you have to correct that. Running thirdparty applications often comes with trouble, too.

More recently, we've been bitten by a JDK bug[0] that prevents Java from correctly interpeting Name Constraints.

[0] https://bugs.openjdk.org/browse/JDK-8311546

Post reply on HN