We have seen an explosion in certificate use in recent years. This is partly due to the trend towards miniaturization. The monolithic applications of old are now deployed as dozens of micro-services on platforms like Kubernetes. These applications scale up and down to meet demand, creating hundreds or thousands of instances at peak times. All these instances need to prove their identity to each other, as well as third parties.
At the other end of the stack, we have countless devices coming to life every day. Less than a decade ago, our kitchens were full of appliances that merely produced coffee or kept food cold. Now they’re packed with Wi-Fi enabled minicomputers, regularly streaming data to cloud services and receiving over-the-air updates. New buildings are packed with gadgetry to control everything from security to mood lighting. You wouldn’t build a modern road bridge without sensors to monitor load, vehicle throughput, sheer stress, and so on.
A common requirement in all these settings is the provisioning of identity information after the device has been installed. Docker containers must first spring to life, before reaching out for identity certificates for their particular environment. Home devices need to be personalised to their owner and granted permission to act on their behalf. In the industrial setting, sensors or smart gateways will be delivered containing manufacturer keys and need to be “captured” when they are first turned on.
When Thales began solving these problems a few years ago, we examined the available standards and settled on a very useful protocol for certificate distribution. In the years since, this protocol hasn’t received the acclaim it deserves. It’s simple and effective, with relatively little room for interpretation when implementing. It ought to be more popular than it is. Enter the hero of our piece: Enrollment over Secure Transport (RFC 7030).
Enrollment over Secure Transport
EST is a protocol for requesting X.509 certificates over HTTPS. The device requesting the certificate is known as the EST client. The client communicates with an EST server, which listens for requests on a predictable URL path. Clients just need to know the IP address of the server to get started.
The EST server acts as a registration authority. Its job is to decide whether EST clients deserve the certificate they have requested. If so, it passes the request to the certificate authority (CA) and returns the resulting certificate to the client. The communication between the EST server and the CA is not covered by the protocol and would differ based on the CA being used.
Bootstrapping
The EST client needs initial credentials to get started. This can take the form of a shared secret or an existing private key and certificate. At first glance, this can be confusing. If you need to provision identity before you run an identity protocol, what’s the point?
The answer is that in most cases, we are talking about personalisation of a device from its factory state. We don’t want to issue certificates to every Tom, Dick and Harry, just because they can hit the EST server endpoint. In the case of physical products, the manufacturer typically injects default keys or secrets and shares this information with their customer. For containers, the platform they run on (such as Kubernetes) can usually install some basic credentials that allows the container to prove it’s running in a given cluster.
The client also needs to authenticate and authorize the EST server. If the EST server’s certificate is issued from a well-known (or otherwise trusted) root CA, the client should be able to authenticate without further intervention. Otherwise, two options are available: a certificate-less protocol can be used, based on shared secrets, such as those provided in TLS-SRP. Alternatively, a human being can be involved to validate the fingerprint of the EST server certificate. Clearly the latter option is only feasible in certain circumstances.
Protocol flow
The following sequence diagram describes the initial enrollment of a client over EST. This flow is used when the client is requesting a certificate for a key it has generated.
Notes:
- The EST client initiates a TLS connection to the EST server. The client validates the certificate offered by the server and abandons the protocol if it doesn’t like what it sees.
- The client requests and verifies the chain of trust from the server. The client may only hold a root certificate in its trust store, so it needs copies of any intermediate certificates that lie between the root and the EST CA.
- The client generates a PKCS#10 certificate request and sends it to the server. It needs to present its own credentials via one of the following approaches:
- Basic HTTP authentication with an ID and shared secret (over TLS).
- Mutual TLS using a previously issued client certificate and key.
- Certificate-less TLS, using something like TLS-SRP.
- The server validates the client’s credentials before requesting the certificate from the CA. It returns the certificate to the client in PKCS#7 format.
EST also supports server-generated keys and a number of advanced options, see RFC 7030 for more information.
There is a separate endpoint for renewing client certificates. The process flow is almost identical to the initial enrollment, although the client is almost always authenticated using mutual TLS with the existing client certificate.
Client and server implementations
Implementations of EST are slowly growing in number. Cisco maintains a test server at testrfc7030.com, which runs the Libest reference implementation. This is useful for testing new EST clients, however it only supports part of the standard.
The CA software from Nexus and EJBCA both added support for EST recently. Bouncy Castle has just added support for EST to its popular crypto library for Java.
Finally – and, if we’re honest, the reason we wrote this blog post – Thales has just released an EST client for Go. Please have a play and let us know your feedback via the issues page. We use this client internally as part of our registration flow for secure cloud services.
The forgotten standard
So, why has EST been overlooked for so long? One reason is its simplicity. It’s tempting and easy to invent similar protocols without considering whether standards already exist. Yet, standards allow us to build solutions faster and in a more interoperable fashion. They also reduce the likelihood of design errors, which are so prevalent in home-grown crypto protocols.
Another reason is timeliness – we are just entering an age of certificate flux and it takes time for the industry to realise new approaches are needed. When EST was first proposed in 2012, the world looked very different.
As we embrace this new age of IoT and cloud computing, the industry should seriously consider adopting existing standards for secure certificate issuance. EST is not the only option (perhaps a topic for a future blog), but it’s a strong candidate and one that we’ve used extensively at Thales.