[likeabatterycar]

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.

[mschuster91]

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

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.

[cwalv]

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

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

> 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

[tashian]

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.

[000ooo000]

Despite the critical feedback you've received above, I found the article interesting, and having a homelab with several spare Pi's, it's got me considering setting a CA up. Thank you.

[johntash]

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