{"id":10884,"date":"2019-05-31T10:27:09","date_gmt":"2019-05-31T14:27:09","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=10884"},"modified":"2024-07-30T16:23:47","modified_gmt":"2024-07-30T20:23:47","slug":"acme-protocol-what-it-is-and-how-it-works","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/acme-protocol-what-it-is-and-how-it-works\/","title":{"rendered":"ACME Protocol: What It Is and How iI Works"},"content":{"rendered":"\n

Automated Certificate Management Environments explained.<\/h2>\n\n\n\n

The ACME (Automated Certificate Management Environment)\nprotocol was originally developed by the Internet Security Research Group for\nits public CA, Let\u2019s Encrypt.<\/p>\n\n\n\n

ACME is what facilitates Let\u2019s Encrypt\u2019s entire business\nmodel, allowing it to issue 90-day domain validated SSL certificates that can\nbe renewed and replaced without website owners ever having to lift a finger.  <\/p>\n\n\n\n

In March of this year the ACME protocol was finally published as an internet standard (RFC 8555<\/a>) and now we\u2019re starting to see commercial CAs support it. Including one of our biggest partners, Sectigo (formerly Comodo CA)<\/a>, which is currently beta testing its support for the protocol before a planned full launch this Summer.<\/p>\n\n\n\n

Obviously \u2013 given the fact Sectigo offers business authentication SSL\/TLS certificates in addition to other X.509 certificates like S\/MIME, Code Signing, etc. \u2013 the use case for the ACME protocol is about to change quite a bit. But that\u2019s to the benefit of corporate and enterprise clients with massive infrastructures and considerable digital certificate needs. <\/p>\n\n\n\n

So, today we\u2019re going to spend some time introducing the uninitiated\nto the ACME protocol, explaining what it does, how it works and why it\u2019s going\nto change the way organizations manage their digital certificates forever.<\/p>\n\n\n\n

Let\u2019s hash it out.<\/span><\/p>\n\n\n<\/span><\/span>\n\n\n

What is the ACME protocol?<\/h2>\n\n\n
\n
\"An<\/figure>\n<\/div>\n\n\n

For the vast majority of people that don\u2019t spend their time focusing on PKI and digital certificates, mention of the word \u201cACME\u201d probably calls to mind the fictional organization that used to ship Wile E. Coyote products for all those harebrained schemes that inevitably failed to get him a taste of that sweet, stringy road runner meat. <\/p>\n\n\n\n

Obviously, we\u2019re not talking about that ACME, enjoyable as discussing business ethics in the Looney Tune-iverse might be. <\/p>\n\n\n\n

Let\u2019s start with sort of an executive summary and then we\u2019ll\ndrill down into the specifics further down the page. <\/p>\n\n\n\n

The ACME protocol functions by installing a certificate management agent on a given web server. The organization or domain undergoes validation at the outset, with the agent assisting with the domain control verification aspects, and once completed the agent can request, renew and revoke certificates.<\/p>\n\n\n\n

<\/span><\/span><\/p>\n\n\n\n

The way that process works is that the agent generates a key pair and shares it with the CA at the outset of the validation process. Once validation is finished and the agent is verified as the proven owner of the key pair, it can use its key to digitally sign the CSRs it generates and sends to the CA via HTTPS requests. The CA uses the CSR, along with its associated public key, to issue the certificate and send it back to the agent. The agent downloads and installs it, then notifies the designated contact. <\/p>\n\n\n\n

The agent can be automated to check in with the CA at given intervals to rotate certificates and keys. None of this requires human intervention. Agents can be installed on any server that uses X.509 certificates and can handle multiple domains on the same server; or agents can be installed on a domain-by-domain basis. <\/p>\n\n\n\n

This knocks out about 95% of the labor typically involved\nwith requisitioning digital certificates, which can be a massive savings at\nscale.<\/p>\n\n\n\n

Now let\u2019s drill down a little deeper.<\/p>\n\n\n\n

How does the ACME protocol work?<\/h2>\n\n\n\n

There\u2019s really two explanations for this question. There\u2019s a high-level one that just covers the basics and then there\u2019s a more in-depth one that covers the technical side. We’re going to try to keep this high level.<\/p>\n\n\n\n

Once you get the ACME agent installed and configured properly, it\u2019s actually pretty simple. We\u2019ll talk about setup in a minute, but for now just keep in mind that during the verification process that takes place when the agent is installed a key pair will be generated for use by the agent and the CA. Those keys are sometimes referred to as “authorization keys.”<\/p>\n\n\n\n

Issuance\/Renewal<\/h3>\n\n\n\n

To get a digital certificate issued, the agent simply needs\nto generate a CSR for the desired domain and send it along to the CA. This is\ndone via HTTPS. <\/p>\n\n\n\n

    \n
  1. The agent generates a CSR for the domain<\/li>\n\n\n\n
  2. The agent signs the public key generated alongside the CSR with the corresponding private key<\/li>\n\n\n\n
  3. The agent signs the whole CSR with its own private key (the authorization key generated during initial configuration)<\/li>\n\n\n\n
  4. The CA verifies both signatures and issues the certificate<\/li>\n\n\n\n
  5. The agent receives the certificate and installs it on the relevant domain<\/li>\n<\/ol>\n\n\n
    \n
    \"Issuance<\/figure>\n<\/div>\n\n\n

    I realize that the agent we\u2019re discussing is definitely not a little person that resides on your server like the icons I\u2019ve chosen might indicate. So, there\u2019s no need to point that out. It’s just more amusing to imagine that way.<\/p>\n\n\n\n

    Anyway, this process plays out more or less the same with renewals, as well. The agent can be configured to ping the CA at regular intervals to either rotate keys or swap out entire certificates. And this is all done behind the scenes, without the need for any human intervention.<\/p>\n\n\n\n

    Revocation<\/h3>\n\n\n\n

    Much like getting a certificate issued, getting one revoked requires the agent to sign a request with its private key – just in this case it’s a revocation request. The CA verifies the signature, revokes the certificate and then publishes that information to the requisite Certificate Revocations Lists (CRLs) and Online Certificate Status Protocol<\/a> responders (OCSPs). These are the mechanisms that browsers use to check the validity of SSL\/TLS certificates.<\/p>\n\n\n\n

      \n
    1. The agent generates a revocation request for the
      SSL\/TLS certificate<\/li>\n\n\n\n
    2. The agent signs the request with its private key<\/li>\n\n\n\n
    3. The CA verifies the signature to ensure the
      request is authorized<\/li>\n\n\n\n
    4. The CA revokes the certificate<\/li>\n\n\n\n
    5. The certificate\u2019s revocation status is published
      to CRLs and OCSP responders<\/li>\n<\/ol>\n\n\n
      \n
      \"Revocation<\/figure>\n<\/div>\n\n\n

      There are scenarios where the admin or employee responsible for\noverseeing certificate management may have to initiate the revocation request,\nbut after that everything is hands-off. <\/p>\n\n\n\n

      Setting up ACME<\/h2>\n\n\n\n

      Ok, now let\u2019s get into what setup looks like when you decide to start using the ACME protocol. The very first thing you\u2019re going to need to decide on is what client you want to use. There are dozens of different clients that run in every conceivable language and environment. <\/p>\n\n\n\n

      \n
      \n