Meep, Meep, ACME Comes To The Rescue of Cybersecurity

We all know the ACME Corporation from our youth, with Wile E. Coyote sourcing a whole range of things in order to capture that pesty road…

Meep, Meep, ACME Comes To The Rescue of Cybersecurity

We all know the ACME Corporation from our youth, with Wile E. Coyote sourcing a whole range of things in order to capture that pesky road runner:

But in cybersecurity, it stands for Automated Certificate Management Environments (ACME). As you know, digital certificates, and PKI, in general, is one of the least understood areas of cybersecurity, but is also one of the most fundamental building blocks of trust on the Internet. A single certificate time-out of a certificate can cause chaos on a corporate infrastructure, and a single breach of a private key can cause a wide-spread lack of trust. In 2013, Microsoft forgot to update the certificate used in the Microsoft Auzre Cloud, and took their cloud off line for a whole day:

With ACME, we have a protocol which makes it easy to provide a certificate on a domain, and is at the core of Let’s Encrypt’s business model [here]:

While it started with Let’s Encrypt, it has now expanded to be used by either CAs (Certificate Authorities). In fact, it has been such a success that it is now being scaled to sign other things such as code signing and email. It basically works by creating an agent which will request, renew and revoke digital certificates. On a request, the agent initially creates a key pair (typically an RSA 2K key pair), and then shares this with a CA, and which then validates the site. Next, it signs a CSR (Code Signing Request) and sends it to the CA. The CA then takes the public key on the key pair, and issues a digital certificate and sends it back to the requestor. This can then be automated where the agent will make another request when the certificate needs to be updated or revoked. The great thing is that there is no human intervention required, and that will make many people happy, as certificate updates can cause so many problems.

The protocol is available on many different languages and with a range of target Web server environments. Here is the .NET version:

In the initial step, we need to generate a CSR. In the following we use OpenSSL to illustrate this:

The start of the process is the creation of a key pair. This can be achieved using Openssl [here]:

$ openssl genrsa -out ca.key 2048
Loading 'screen' into random state - done
Generating RSA private key, 2048 bit long modulus
..............................................+++
.......................................................+++
e is 65537 (0x10001)

In this case we have created 2,048-bit key pairs, and which are contained in the ca.key file:

Next create a self-signed root CA certificate ca.crt for MegaCorp:

$ openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:UK
State or Province Name (full name) [Some-State]:None
Locality Name (eg, city) []:Edinburgh
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MegaCorp
Organizational Unit Name (eg, section) []:None
Common Name (e.g. server FQDN or YOUR name) []:None
Email Address []:none

Next we will create a subordinate CA (My Little Corp), and which will be used for the signing of the certificate. First, generate the key:

$ openssl genrsa -out ia.key 2048
Generating RSA private key, 2048 bit long modulus
............................................................+++
...............................................................................................................+++
e is 65537 (0x10001)

Next we will request a certificate for our newly created subordinate CA and create a code signing request (CSR):

$ openssl req -new -key ia.key -out ia.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:UK
State or Province Name (full name) [Some-State]:None
Locality Name (eg, city) []:Edinburgh
Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Little Corp
Organizational Unit Name (eg, section) []:MLC
Common Name (e.g. server FQDN or YOUR name) []:MLC.none
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:Qwerty123
An optional company name []:

The code signing request has the form of:

We can then create a certificate from the subordinate CA certificate and signed by the root CA.

$ openssl x509 -req -days 730 -in ia.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out ia.crt
Signature ok
subject=/C=UK/ST=None/L=Edinburgh/O=My Little Corp/OU=MLC/CN=MLC.none
Getting CA Private Key

If we want to use this certificate to digitally sign files and verify the signatures, we need to convert it to a PKCS12 file:

$ openssl pkcs12 -export -out ia.p12 -inkey ia.key -in ia.crt -chain -CAfile ca.crt
Enter Export Password: Qwerty123
Verifying - Enter Export Password: Qwerty123

The crt format is in encoded in binary. If we want to export to a Base64 format, we can use DER:

$ openssl x509 -inform pem -outform pem -in ca.crt -out ca.cer

and for My Little Corp:

$ openssl x509 -inform pem -outform pem -in ia.crt -out ia.cer

view of the cer file shows that it is in Base64 format:

Note what has happened here:

The client requestor setups an authorization key pair with the CA. This will be used to sign for CSR.
The client requestor creates a key pair for the domain.
The client requestor creates a CSR and sends it to the CA. It signs this with the private key of the authorization key pair that it setup security with the CA.
The CA check the CSR, and then signs a new certificate with its private key and puts the client’s public key on it. The public key of the CA is stored on a trusted root or intermediate level certificate.

Let’s Encrypt is an intermediate signer, and uses a root CA of DST Root CA X3:

For revocation, the client requestor signs a revocation request with its private key. The CA then posts the details of this on the Certificate Revocations Lists (CRLs) and Online Certificate Status Protocol responders (OCSPs).

The latest version of ACME is V2, and it has added the support for wild card certificates. As wild cards are not good practice, there is a strong challenge on the DNS record challenge, and whether the client has control over the domain.

And here it is my site with a 3K RSA public key [here]:

Want to understands certificates? Here is a simple introduction: