certificates

We just added ACME support to `step-ca`, an open source private certificate authority that I work on. ACME is the protocol that Let's Encrypt uses to automate certificate management for websites. ACME support in `step-ca` means you can leverage existing ACME clients and libraries to get certificates from your own private certificate authority (CA). This is particularly useful for: * Using ACME in production to issue certificates to workloads, proxies, queues, databases, etc. so you can use mutual TLS for authentication & encryption. * Simulating Let’s Encrypt’s CA in dev & pre-production in scenarios where connecting to Let’s Encrypt’s staging server is problematic. We're supporting the `http-01` and `dns-01` challenge types, so you should be able to get certs using any ACMEv2 client that supports one of these (most do). * More info and e

It sounds like using Let’s Encrypt makes sense for your use case since people are accessing these appliances via a web browser, but for “normal internal servers” the right answer is almost definitely to use your own internal PKI, not to use wildcard certs. See: https://github.com/cloudflare/cfssl https://github.com/hashicorp/vault https://github.com/smallstep/certificates

The disadvantages are: it’s less secure — you’re trusting (many) third parties with your security and relying on the security of DNS it’s less flexible — you can’t sign certificates with internal names (e.g., *.cluster.local) and certs must be for 90 days, etc it’s kind of hacky — you have to work around rate limits and whatnot because Let’s Encrypt wasn’t designed for this use case The advantage is it’s easier. But that’s arguable. What the article describes isn’t easy. Using something like cfssl (https://github.com/cloudflare/cfssl) or vault (https://github.com/hashicorp/vault) or step certificates (https://github.com/smallstep/certificates) (which I work on) is probably easier and definitely better for internal services.

There’s nothing special about a “client certificate” —- they’re not (necessarilly) any different than a TLS server certificate. Technically a relying party might check that a client certificate includes the “client auth” key use, but most (all?) commercial certificates issued for TLS/HTTPS servers do this (I know Let’s Encrypt does). So... what they’re asking for isn’t actually anything fancy. Just go buy a normal certificate like you would for any other server (or get one for free from let’s encrypt). In fact, if they want a cert that is signed by a CA that “works in browsers by default” it must be the case that what they’re looking for is a vanilla commercial “Web PKI” certificate. This must be true because the CA/Browser Forum requirements that commercial CAs are audited against stipulate that CAs are only allowed to sign vanilla certi