Introducing Advanced Authorities
J. Hunter Hawke
In the months since Smallstep’s GA announcement for Certificate Manager, users have approached us with projects that have higher security requirements (and/or need more flexibility from their PKI, have different scaling requirements, etc.). The tooling in the core of our product that we know and love is simple, intuitive, and far-reaching. The base model of Certificate Manager CA empowers developers to implement mTLS everywhere and boosts operators’ ability to automate and monitor their production certificates, but there are always certain use cases that would benefit from some advanced features.
Smallstep Certificate Manager breaks these use cases into two different certificate authority types: DevOps and Advanced. DevOps Authorities have the same features that legacy Certificate Manager offered, and they function as a great solution for most DevOps workloads. DevOps Authorities are configured out of the box with sane encryption defaults, a simplistic CA hierarchy, and the monitoring/reporting features an operator would want for all the certificates under their purview. But we’ve gotten significant interest in additional features like active revocation, BYO Root, ACME External Account Binding, and renewal after certificate expiry. This is why Smallstep has built these features and more into what we call an Advanced Authority.
When should I consider using an Advanced Authority?
Many networking projects fall outside of the general scope and boundaries of a simple cloud project, or they fall under some stricter compliance rule sets. Even smaller projects and organizations sometimes need advanced security solutions in their environments. Advanced Authorities really shine in these systems, offering powerful tooling to simplify work and save time. Make sure to leverage an Advanced Authority when…
…securing devices that with intermittent connectivity…
Our IoT power users were consistently running into a problem when provisioning devices with certificates that wouldn’t expire before the IoT device could connect to a network. For a lot of these systems, an expired certificate would turn a device into an expensive brick, so the workaround was to provision a certificate that would live for years.
With Advanced Authorities, it is now possible to enable a feature called “renewal after expiry” on a per-provisioner basis. Provisioners with this setting enabled are allowed to accept expired certificates for renewal, solving the entire problem above. While there are some drawbacks to having this setting enabled, such as having to revoke expired certificates in your environment if you don’t want them to be renewed, renewal after expiry makes systems like this substantially more secure.
With renewal after expiry, IoT manufacturers need only provision a device with a single short-lived certificate/key pair to use over the course of its lifetime. There is no more worry about how long a device sits without power, and there is no more debate about super long-lived certificates out in the wild. If a device gets compromised, that is perfectly fine; revoke the short-lived certificate, and the device will be unusable after the short time it takes for the certificate to expire.
…the project requires the ability to immediately revoke certificates…
We’ve always advocated for using passive revocation and short-lived certificates as a best practice in server management. The idea here is that if a certificate/key pair is compromised, you would revoke the certificate, leaving it unusable when it expires a short time later. However, there are some use cases where it’s more sensible or feasible to use a longer-lived certificate. There are also some use cases where data can be so sensitive that access must be cut off the second that a security operator suspects that something is wrong. To support these types of projects, we’ve made active revocation possible on our Advanced Authorities.
Advanced Authorities now provide the option to enable active revocation via a Certificate Revocation List (CRL) and an OCSP Responder at authority creation. Smallstep hosts both endpoints on behalf of our users, and operators can provide them to any applications or vendors who require endpoints for active revocation. This prevents the need for hacky solutions where you might want to host a CRL from an S3 bucket or jury-rig together a server to respond to OCSP requests. Users may now rest assured that both endpoints can be made available right out of the box.
…you need more granular security controls…
Smallstep loves and has always been a champion of the ACME protocol. We’ve built it into our open source project as one of its quintessential provisioner types, and we use the step CLI to function as an ACME client. The RFC 8555 specification for ACME lays out the concept of External Account Binding (EAB), which operators can use to associate an ACME account with an existing account in a non-ACME system.
The vanilla ACME implementation is sufficient for most ACME use cases, but it provides vague restrictions regarding whom can provision what certificates. Realistically, an entity could request a certificate for any path or subdomain that they could influence on a domain. Advanced Authorities now provide EAB features, enabling operators to connect ACME accounts to existing accounts (e.g., in Okta, AD, or GSuite) instead of creating new quasi-anonymous accounts for ACME. These accounts would then identify the endpoint and specify which certificates they would be allowed to provision—something DevOps Authorities are incapable of doing.
EAB can be difficult to implement if you only want to use policy, and ACME is the only type of provisioner supporting this functionality. For general purpose non-ACME cases, we’ve also built out the step ca policy... command subgroup. It is now possible to implement fine-grain restrictions on exactly what certificates your authority is and is not allowed to mint.
This feature is generally available on DevOps Authorities at the authority level, but this isn’t practical when you have subgroups of entities with different certificate restrictions. With an Advanced Authority, it is now possible to set specific security policies for allowed/denied domain names, IP addresses, emails, URIs, and subject common names in a fashion that is as granular as your advanced project requires.
…you’re issuing certificates to multiple private networks…
We recommend that all ACME production deployments run an ACME Registration Authority (RA) local to their environment. This step isn’t always necessary, but it is required in order to get certificates to devices on private networks. Most DevOps use cases only require one RA per cloud environment connected to that environment’s certificate authority. However, sophisticated environments may segment their networks differently.
We’ve worked with multiple customers in the financial and IoT spaces where just one RA per authority wasn’t sufficient. There have been cases where the organization has segmented its data into multiple data centers or across multiple different layers of private subnets. The solution is to deploy multiple RAs across their networks, some chained and others reporting directly back to the CA. Advanced Authorities now support this workflow; each can connect to as many RAs as the project requires.
…you want a custom PKI configuration…
Templates are a great tool to help you customize your PKI. The default provisioners can create many certificate types. They can customize the primary certificate details, add custom SANS, and configure the cipher settings for the resulting certificate. However, some use cases would benefit from templating desired configurations into all the certificates the provisioner generates, and some use cases require a change in settings that the CLI cannot specify (e.g., Key Usage types or input variables from a token). Traditional DevOps Authorities only allow three provisioners to use custom templates, but this isn’t enough to fit all custom projects. Advanced Authorities now provide operators an unlimited number of templates to accommodate large, complicated projects that would otherwise require a lot of manual intervention.
On a much higher level, some projects also call for custom CA certificates and hierarchies. By default, we configure our Certificate Manager authorities with a simple hierarchy using a single intermediate off of the authority’s root certificate. Both use elliptic curve key algorithms and live suitably long, but we’ve had several enterprise users request more customizability at this CA level.
Advanced Authorities now allow users to completely customize their PKI. If you’re maintaining a legacy system that requires any particular settings for the CA chain, Smallstep’s Customer Engineers can set up your root and intermediate certificates with the exact algorithm, key size, and fields that your overall architecture requires. Likewise, we can help you design your perfect PKI if your projects would benefit from moving away from the standard two-tier hierarchy. We can set up as many chained Advanced Authorities on Certificate Manager in any desired configuration to meet any trust model a network would require.
Some users seek Certificate Manager hoping to unify disparate PKI sprawling across their organizations. The solution isn’t replacing these existing systems with a brand new PKI; it’s leveraging our new BYO Root feature. Besides setting up custom root and intermediate certificates, Advanced Authorities also allow users to send over their existing CA certificates for our Customer Engineers to unify in Certificate Manager. BYO Root also comes in handy when compliance requires an organization to own its Root CA certificate. All you would need to do is use their Root CA to sign a CSR for Smallstep, and we can simply use the signed Intermediate to run an authority on behalf of the user.
…coming soon…
There are still a couple of projects in the works. The most exciting of them will add an inventory of hosts, services, people, and any other endpoints to Certificate Manager. An inventory record lets you associate metadata with an endpoint, and a certificate request can trigger it for a lookup. As part of this process, it will expose metadata as template variables, where it can customize certificates or authorize certificate requests. Many customers have reached out to us about this upcoming feature, and we are really excited to add it to the product.
For teams interested in compliance, we are also working on a FIPS 140-2 compliant authority. Once this is released as an option for Advanced Authorities, it’ll be simple to bypass a lot of the red tape involved with projects governed by the Federal Information Processing Standards.
These are all really exciting new features, and we at Smallstep hope that you can leverage Advanced Authorities to secure your networks in the most custom means possible. If you have any questions, our Customer Engineering team (support@smallstep.com) is available to set up a call and discuss whether an Advanced Authority would be a good choice for your project.
Have any questions about how you can use Advanced Authorities in your environment? We can help!
