6 ms·

I really like step[1] and step-ca[2] for this, it's a lot less fiddly than having to drive OpenSSL directly. 1. https://github.com/smallstep/cli https://github

I really like step[1] and step-ca[2] for this, it's a lot less fiddly than having to drive OpenSSL directly. 1. https://github.com/smallstep/cli https://github.com/smallstep/cli 2. https://github.com/smallstep/certificates https://github.com/smallstep/certificates

gclawes 3y ago
And they support ACME. I've been running a smallstep CA off of a Nitrokey HSM 2[1] w/ PKCS #11 for my homelab for a few years now 1. https://shop.nitrokey.com/shop/product/nkhs2-nitrokey-hsm-2-7 https://shop.nitrokey.com/shop/product/nkhs2-nitrokey-hsm-2-...
- toastal 3y ago
  Nice to see open source hardware token usage in the wild.
- op00to 3y ago
  Can you please give bullet points of your CA setup and more broadly your home lab? It sounds … awesome.
infogulch 3y ago
Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, (2) 90-day limited intermediate CA with just the (3) DNS-01 challenge? I argue that such an intermediate CA would have no more authority than a wildcard cert which you can get today, so they should be able to issue it. [1] Everything supports name constraints now, which used to be an issue but isn't anymore. [2] Then stick it in step-ca and issue all your certificates with internal ACME. This would solve a lot of problems, such as leaking private hostnames in the certificate transparency log, or hitting issuance rate limits on LE servers. [1]: https://news.ycombinator.com/item?id=29811552 https://news.ycombinator.com/item?id=29811552 [2]: https://bettertls.com/ https://bettertls.com/
- woodruffw 3y ago
  I don’t necessarily disagree, but to point out: issuing an intermediate CA does change the authority model a bit, insofar as it turns a single trusted issuance into a windowed lease to perform arbitrary issuances. On a practical level, the latter is more logistically complex (and needs to be reconciled with other hard-fought battles, like CT). Given that it’s roughly the same as a wildcard certificate in terms of end-user use, it’s IMO understandable that this isn’t a priority for the CA ecosystem to support. (The use case of circumventing CT is probably a non-starter as well. The Web PKI doesn’t want CT loopholes!)
  - infogulch 3y ago
    Nobody has ever adequately explained how a wildcard cert presents a meaningfully different security profile than a name constrained CA. Wildcard certs used to identify a subdomain are not logged in CT and nobody is freaking out about it. And if your answer is "because nested subdomains" you should also explain the differential risk of nested subdomains compared to wildcard certs, not fully qualified certs. I don't see how it's meaningfully different.
    - woodruffw 3y ago
      One accepts an arbitrary subdomain as a matter of verification policy, and the other has broader PKI implications: how should verifiers handle name constraints with multiple prospective paths? How should they handle CAs that issue longer-lives certificates than the CA/B guidelines permit? CAs that allow end-entity certs with known insecure algorithm choices, etc? In short, allowing user-controlled name-constrained intermediate CAs opens up multiple cans of worms that the ecosystem is not currently prepared to handle. Presenting a compelling argument for these user-controlled CAs means explaining (and getting buy-in) for solutions to the above.
      - infogulch 3y ago
        Thanks, I appreciate a response with some substance. > name constraints with multiple prospective paths Can you expand on this for me? Is this really a problem? > longer-live[d] certificates than the CA/B guidelines permit The iCA cert would only be valid for 90 days (or less, they could make it 30 or 15 days). Would a cert be valid if the iCA cert that issued it is expired? > known insecure algorithm choices Disallow bad algorithms by policy. Evidence of issuance using a bad algorithm gets the iCA revoked and the ACME account locked out. Many clients don't allow insecure algorithms by their own policy. If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?
mattpallissard 3y ago
I completely agree that dealing with openssl is fiddly at best when you RYO CA. But, if your org knows how PKI works it's not a big deal; a bash script or two in the simple case or a flask app at most complex. If your org doesn't know how PKI works shouldn't you be paying a vendor that does?
wejn 3y ago
That's really neat, thanks for the pointer. ;)

gclawes 3y ago

And they support ACME. I've been running a smallstep CA off of a Nitrokey HSM 2[1] w/ PKCS #11 for my homelab for a few years now 1. https://shop.nitrokey.com/shop/product/nkhs2-nitrokey-hsm-2-7 https://shop.nitrokey.com/shop/product/nkhs2-nitrokey-hsm-2-...

toastal 3y ago
Nice to see open source hardware token usage in the wild.
op00to 3y ago
Can you please give bullet points of your CA setup and more broadly your home lab? It sounds … awesome.

infogulch 3y ago

Wouldn't it be nice if LetsEncrypt could issue you a (1) name constrained, (2) 90-day limited intermediate CA with just the (3) DNS-01 challenge? I argue that such an intermediate CA would have no more authority than a wildcard cert which you can get today, so they should be able to issue it. [1] Everything supports name constraints now, which used to be an issue but isn't anymore. [2] Then stick it in step-ca and issue all your certificates with internal ACME. This would solve a lot of problems, such as leaking private hostnames in the certificate transparency log, or hitting issuance rate limits on LE servers. [1]: https://news.ycombinator.com/item?id=29811552 https://news.ycombinator.com/item?id=29811552 [2]: https://bettertls.com/ https://bettertls.com/

woodruffw 3y ago
I don’t necessarily disagree, but to point out: issuing an intermediate CA does change the authority model a bit, insofar as it turns a single trusted issuance into a windowed lease to perform arbitrary issuances. On a practical level, the latter is more logistically complex (and needs to be reconciled with other hard-fought battles, like CT). Given that it’s roughly the same as a wildcard certificate in terms of end-user use, it’s IMO understandable that this isn’t a priority for the CA ecosystem to support. (The use case of circumventing CT is probably a non-starter as well. The Web PKI doesn’t want CT loopholes!)
- infogulch 3y ago
  Nobody has ever adequately explained how a wildcard cert presents a meaningfully different security profile than a name constrained CA. Wildcard certs used to identify a subdomain are not logged in CT and nobody is freaking out about it. And if your answer is "because nested subdomains" you should also explain the differential risk of nested subdomains compared to wildcard certs, not fully qualified certs. I don't see how it's meaningfully different.
  - woodruffw 3y ago
    One accepts an arbitrary subdomain as a matter of verification policy, and the other has broader PKI implications: how should verifiers handle name constraints with multiple prospective paths? How should they handle CAs that issue longer-lives certificates than the CA/B guidelines permit? CAs that allow end-entity certs with known insecure algorithm choices, etc? In short, allowing user-controlled name-constrained intermediate CAs opens up multiple cans of worms that the ecosystem is not currently prepared to handle. Presenting a compelling argument for these user-controlled CAs means explaining (and getting buy-in) for solutions to the above.
    - infogulch 3y ago
      Thanks, I appreciate a response with some substance. > name constraints with multiple prospective paths Can you expand on this for me? Is this really a problem? > longer-live[d] certificates than the CA/B guidelines permit The iCA cert would only be valid for 90 days (or less, they could make it 30 or 15 days). Would a cert be valid if the iCA cert that issued it is expired? > known insecure algorithm choices Disallow bad algorithms by policy. Evidence of issuance using a bad algorithm gets the iCA revoked and the ACME account locked out. Many clients don't allow insecure algorithms by their own policy. If you're securing your internal network with bad algos but it never touches the wider internet, does it make a sound? Would this be better or worse than installing self-signed root CAs everywhere?

mattpallissard 3y ago

I completely agree that dealing with openssl is fiddly at best when you RYO CA. But, if your org knows how PKI works it's not a big deal; a bash script or two in the simple case or a flask app at most complex. If your org doesn't know how PKI works shouldn't you be paying a vendor that does?

wejn 3y ago

That's really neat, thanks for the pointer. ;)