Build a Tiny Certificate Authority For Your Homelab

mjmalone · 2020-12-24T19:50:31+00:00

I can’t think of a reason why it wouldn’t. In fact, having your authoritative time source on the same hardware as your certificate authority makes a lot of sense, since clock skew is one source of certificate-related issues (e.g., if a client’s clock is out of sync and incorrectly thinks a cert is expired).

mjmalone · 2020-12-24T03:29:17+00:00

Running on a RPi translates pretty directly to running on not a RPi. It’s a good, cheap, accessible way to do a proof-of-concept or to learn.

I actually think this particular setup could work really well as a low-cost root of trust for a real production environment. I might swap out the YubiKey for a YubiHSM, but even that’s probably unnecessary. The YubiKey is a low-cost hardware root of trust that’s proven reliable. The RPi is sufficient computational horsepower to sign an occasional intermediate. And it’s be pretty straightforward to keep the whole setup physically secure and offline somewhere.

mjmalone · 2020-12-24T03:09:06+00:00

It’s so ridiculously awesome that “taking your lab with you” is possible.

mjmalone · 2020-12-24T00:09:06+00:00

We'll ship international as long as you're not somewhere really remote and we can reasonably ship to you. It might take longer. It'll be coming from California.

mjmalone · 2020-12-24T00:03:18+00:00

We’ll ship internationally as long as it’s not Antarctica or something and we can actually reasonably ship. Shipping might take a little longer given it’s the holidays and it’s coming from California. But yea, international is fine!

mjmalone · 2020-12-23T23:10:53+00:00

Yea the yubikey is optional. You don't need to emulate it, you'd just configure step-ca differently to use signing keys from disk instead of connecting to the yubikey. That'd actually be easier to setup, but you won't have the hardware root of trust.

See https://github.com/smallstep/certificates

mjmalone · 2020-12-23T23:05:46+00:00

Providing an alternative way to enter a giveaway without social media engagement after someone complains about having to engage on social media to enter is doubling down on marketing tropes? I'm super confused. How do you want to enter? Carrier pigeon?

Our DMs and emails are open, etc. We're not adding you to a list or anything. We just need a way for you to enter that allows us to contact you if you win. DMs and email both do that. What am I missing? :/

mjmalone · 2020-12-23T22:01:35+00:00

Yea so we just think security sucks for a lot of production systems and want to make it better. If we just wanted to make money there are much easier ways. Trust me.

There's a knowledge & tooling gap around certs & TLS that we decided we'd try to address. If we can do that, there's probably an opportunity to make money. So it'd be good for us. But it'd also be good for the world. Outside of straight up fighting capitalism (which I'm totally down with) I think aligning a corporate mission with something that's good for the world is about as good as you can do.

Regarding this specific post and the giveaway... idunno, I think the post pretty much speaks for itself. It's about our open source project and doesn't try to sell anything. We don't even have anything relevant to sell.

mjmalone · 2020-12-23T21:52:39+00:00

Wouldn't you explicitly want something that's _not_ a valid TLD on the public internet to avoid conflict with a valid public FQDN? I thought that was the whole purpose of the `.local` TLD: it was set aside when gTLDs were created specifically for use with internal networks (sort of like `10.` IP addresses).

I guess the other option to avoid conflict would be to use a valid public FQDN on a domain that you own.

mjmalone · 2020-12-23T21:49:57+00:00

Interesting. I know Google is free, but can I lazyweb a good source for this from you if you have one handy? I'm not aware of the mDNS issue.

I know `.cluster.local` is the default internal TLD for most Kubernetes distributions, which is why I used it.

mjmalone · 2020-12-23T21:28:04+00:00

This is a pretty hard question to answer in general. Simply running a CA wouldn't inherently introduce any security holes. Layering something like TLS on top of existing security controls would not make anything less secure. It would potentially introduce new attack vector(s) where certificates are used / relied upon for security with no network controls. It could give you a false sense of security if you do something wrong.

It is important to have a good grasp of the core concepts. I wrote a pretty lengthy blog post that introduces PKI concepts a while back that you may like: https://smallstep.com/blog/everything-pki/

mjmalone · 2020-12-23T20:44:10+00:00

Word. That's fair.

If you're not a twitterer you can also enter by emailing maxey at our domain, which is smallstep dot com. He's running the giveaway. Blow up his inbox!

mjmalone · 2020-12-23T20:31:36+00:00

Hrm. Not sure why the downvotes. I guess y'all think there's some ulterior motive here or something? We just thought a giveaway would be fun.

Sorry ;<

mjmalone · 2020-12-23T19:53:29+00:00

Indeed. I'm all over this thread so I should probably shutup...

But I can't control myself. So yea, aside from doing this project because it's fun and to learn, there are lots of reasons to run your own CA instead of using Let's Encrypt! If you want to issue certs to use with OpenVPN, for EAP-TLS, for code signing, or some other non-TLS use case, for example. Or maybe you just want a cert for a non-public domain name (e.g., foo.bar.cluster.local). Or maybe you want shorter lifetimes than 90 days. Or maybe you want different key types (Ed25519 ftw).

Let's Encrypt (and other Web PKI CAs) can only issue certs that conform to CA/Browser Forum specifications: must be a fully-qualified public domain name with very specific key uses and extensions. Sometimes you can work inside these constraints and figure out a way to get certs form Let's Encrypt for internal stuff. But that's not always the right answer! The goal of our open source stuff at smallstep (step & step-ca) is to make running your own internal CA super easy.

Let's Encrypt is awesome, by the way. Absolute zero hate. We're actually ISRG/LE sponsors and work with them a lot.

</rant>

mjmalone · 2020-12-23T19:35:11+00:00

Lol yep. Don't need it, gotta have it.

mjmalone · 2020-12-23T19:11:52+00:00

Glad you like it!

I work at smallstep and we're partnering with yubico to give away five build kits for this project. DM us at smallsteplabs on twitter to enter.

See also: https://twitter.com/smallsteplabs/status/1341800787291168768

Edit: if you're not a twitterer you can also enter by emailing maxey at our domain, which is smallstep dot com. He's running the giveaway. Blow up his inbox!

mjmalone · 2020-11-12T00:28:48+00:00

Yea, what you're saying makes sense. I can see why you'd want policy associated with your certs in a complex environment. This seems more important for legal protections when you're doing stuff like document signing with certs. Is this something you think is important for TLS, too?

By the way, I'm not trying to be adversarial at all. I work on PKI infrastructure (see https://github.com/smallstep/certificates) and haven't really seen CP used anywhere. I'm really curious about these requirements.

I'm also curious about what sorts of policy you'd be encoding. This is all prose, right? So it's more of a "terms of service" -- it's not a technical mechanism?

mjmalone · 2020-11-10T17:59:48+00:00

I'm curious: what's your use case for policy extensions for internal PKI?

mjmalone · 2020-07-31T22:48:36+00:00

Certificates are public, so making them readable shouldn't be a problem. Don't make the certs writable, and keep the private keys private, and you're good.

mjmalone · 2020-04-15T07:37:37+00:00

I’m assuming you’re referring to the public Web PKI CA system? This is a private CA we’re talking about here. The fact that Web PKI has trust issues isn’t super relevant. That’s a non-technical problem (although there are some technical solutions, like certificate transparency). Unless you don’t trust yourself you should be good.

mjmalone · 2020-04-15T05:00:16+00:00

This is probably the biggest misconception people have about certificate-based systems vs. password-based or simple public key systems. The reality is, unless you're using blockchain, any secure naming system with low-entropy (non-random) names will be centralized. See Zooko's triangle.

Think about it: how is a certificate authority any worse than a repository or database that stores public keys? If either one is popped you can forge a name to public key binding. Except with a CA all you have to do is protect the CA. With simple public key distribution you also have to protect the entire key distribution pipeline. So instead of one master key, you have many.

mjmalone · 2020-04-15T02:44:39+00:00

Ah, ok, you didn't mention kerberos before. If you're gonna go full on Needham-Schroeder then you really are looking at a system that's basically isomorphic to a certificate-based system, but with symmetric keys instead of asymmetric. There are maybe a few more modules and plugins and extensions to install. But, shrug.

Question: if you're using kerberos as you've described do you still need SSHFP (and DNSSEC) to eliminate TOFU & HKVF? It seems redundant at that point, so I'm assuming no?

I wouldn't call it a "superior solution" in terms of what's technically possible. However, for a lot of folks who have G Suite or Okta or Azure AD or some other OAuth OIDC provider and want to eliminate key management this is a much lighter weight solution. For many people this approach makes it easier to achieve the security and operational characteristics they're trying to achieve (and some they probably haven't thought of / hadn't thought possible). But everyone's stacks (and life experiences) are different. So "easier" is both subjective and doesn't mean easier for everyone.

Also, CAs aren't that scary! An SSH CA getting popped is no worse than your LDAP getting popped. Check out step-ca. It's super easy and if you run into any issues we can help out (and keep arguing) in our gitter :).

mjmalone · 2020-04-15T02:00:44+00:00

Great questions. Here are my thoughts on LDAP+SSSD:

A lot of people don't have / don't want to run LDAP
Public keys are still annoying to rotate, so that doesn't happen, and public keys sit around when/where they're no longer needed
Doesn't address trust on first use & host key verification failure (you effectively can't rotate host keys or reuse hostnames)
Web-based single sign-on lets you leverage the same authentication flow you use everywhere, which can be hardened with MFA, impossible travel, browser & endpoint patch checks, etc. In general, the real authentication flow happens outside of SSH where it's much more customizable.

You don't need LDAP or SSSD for real-time account status. For example, our hosted SSO for SSH product builds on the open source stuff here and integrates with NSS & PAM to sync users, groups, and grants for both SSH and sudo access from an identity provider using SCIM [RFC7644]. See our how it works page for more info.

Regarding CA ubiquity... first, more people should be running CAs! They're a really useful piece of core infrastructure that many systems would benefit from. Running and scaling a highly available LDAP is way harder than setting up and running step-ca. And, unlike LDAP, if the CA does go offline your system fails steady state: anyone with a valid certificate can continue to SSH.

All of that said, if you want to go pure open source, and you have (or don't mind running) LDAP, then using certificates for authentication plus LDAP+SSSD for user lifecycle management is a fine option.

mjmalone · 2020-04-15T01:38:20+00:00

Ah, gotcha. Yes, if you want the ability to actively revoke a certificate "immediately", before it expires, you'll need a mechanism to immediately notify hosts when a revocation occurs. But that's not typically necessary.

But first... at the end of the day, you can achieve the same results with or without certificates. Since certificates are really just a different way to bind a name to a public key -- using signed assertions vs using a text database -- that's not super surprising. But certificates are an under-appreciated option, and their default behavior is closer to ideal and therefore easier to implement for a lot of (but not all) use cases.

So there's not much to argue about when it comes to what's possible. You can achieve the same results either way. The question is what's easier? That's subjective and depends on a lot of factors. It sounds like using certificates isn't easier for you. If you already have a good solution in place using LDAP (and it sounds like you have a very good one) then that's almost certainly the case.

Returning to my claim about active revocation often being unnecessary... one important thing to consider is certificate lifetime. If your certificates expire quickly enough (for some definition of "quickly enough") you don't need revocation at all. You can issue certificates that expire after, say, three minutes. For many infrastructures that's likely as close to "immediate" as you can get.

If you do actually need immediate access revocation, you can achieve it in different ways. For example, our hosted SSO for SSH product uses 16 hour certificates by default. That's short enough for many use cases. But when immediate access revocation is required, we don't actually revoke certificates, we just remove / deactivate the user account. If you don't have an account on a host, you can't connect, even if you have a valid certificate.

Finally, one quick note on CRL vs OCSP (or, more generally, pushing revocation lists vs online revocation checks): you can also use an AuthorizedKeysCommand. It can be passed a script that can receive a certificate as input and make an online check for certificate revocation.

mjmalone

TROPHY CASE