IT Services Knowledge - ACME SSL for Users

The Automatic Certificate Management Environment (ACME) protocol automates interactions between certificate authorities and their users' servers. ACME is commonly referenced using its most popular implementation: Let's Encrypt. The University's InCommon Certificate Service provides its own ACME-based option, which uses External Account Binding (EAB) which builds on its existing Domain Control Validation methods, in contrast to Let's Encrypt which uses DNS or HTTP-based challenges.

Using the InCommon ACME Service

Users of the InCommon ACME service must have:

A domain validated for use with InCommon Service using one of the standard Domain Control Validation options. This service does not use do real-time validation like Let's Encrypt.
An ACME account created by your Department Registration Authority Officer (DRAO), i.e. the team that approves your certificate requests. An ACME account is distinct from any other University or Sectigo account. The External Account Binding (EAB) process authorizes your ACME account to use a specific ACME endpoint.
An ACME client: user-managed software running on the server using SSL, registered with the ACME Endpoint using EAB values.

Domain Control Validation

Prior to you using ACME, validate your domain for use with InCommon Service using one of the standard Domain Control Validation options.

ACME Account

Each DRAO (the team that approves your certificate requests) will establish its own procedure for requesting ACME accounts, built on the Certificate Manager procedures described in ACME for DRAOs. An ACME account associates your ACME endpoint (the server you will use for ACME transactions) and your External Account Binding information (which establishes that you have the authority to receive certificates for your domain. In practice this means the account includes:

Account ID
ACME endpoint URL
External Account Binding Key ID
External Account Binding HMAC Key

ACME Client

ACME is an internet standard (RFC8555) which means there are many valid software options. Choose an ACME client that works for you. The most well known is certbot.

Example Setup Using Debian and Certbot

Examples are for illustration only, based on a simple Debian environment. Users are responsible for understanding what is appropriate for their systems.

Example Install ACME client


$ sudo apt install python3-certbot-apache

Example: Register ACME Account with Endpoint


$ sudo certbot register \
--email <email address> \
--server <ACME endpoint URL> \
--eab-kid  <EAB Key Identifier> \
--eab-hmac-key <EAB Key>

Example: Obtain OV Certificate

Options include running as --standalone and manually establishing the server configuration to use the new certificate/chain filepaths OR run software-specific commands like --apache OR --nginx


$ sudo certbot certonly       \  
--standalone           \ 
--non-interactive      \
--agree-tos            \
--email  <email address>        \
--server <ACME endpoint URL>    \
--eab-kid  <EAB Key Identifier> \
--eab-hmac-key <EAB HMAC Key>   \ 
--domain <domain>,<domain>...   \
--cert-name <name> (for certbot use only)

Example: Verify Auto-Renew for systemd


$ sudo systemctl list-timers | grep certbot
Tue 2024-02-20 00:45:00 CST  6h left  Mon 2024-02-19 12:56:45 CST  5h 1min ago  certbot.timer  certbot.service

$ sudo tail -4 /lib/systemd/system/certbot.service
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

ACME SSL for Users