• Registration Authority Officer (RAO): Members of Information Security are delegated authority for managing certificates for the university, and can delegate that authority to DRAOs for operational use
• Departmental Registration Authority Officer (DRAO): IT staff delegated authority to manage certificate issuance within SCM for a unit - responds to cert request from their unit's users
• User: In this context user refers to the server system admin requesting ACME certificate from a DRAO
• CM: Sectigo Certificate Manager
• Certificate Profile: Predefined configuration of certificate attributes, including validation requirements, fields, cryptographic parameters, lifecycle, and use restrictions.

Domain Validation

• Domain Control Validation (DCV): An industry-standard process to establish an organization's administrative control of a domain, and suitability for receiving issued certificates for that domain
• OV Certificate: Organization Validated SSL certificates, which include an organization's information within the certificate, thus providing a higher trust level than Domain Validated (DV), and lower than Extended Validation (EV). Information Security maintains organizational validation with InCommon, and individual domains must complete annual domain validation. Let's Encrypt offers only DV certs.

ACME

• ACME: Automated Certificate Management Environment
• ACME Endpoint: An enrollment endpoint is an HTTPS URL where the ACME server listens for the request from the ACME client
• ACME Account: CM associates a Department with an enrollment endpoint and some constraints on what the ACME account can be used for (cert profiles, domains, etc)
• ACME Client: software run on the user's server that manages ACME certificates using a provided ACME account and endpoint
• External Account Binding (EAB): Associates an ACME account with an existing non-ACME ("external") account system, in this case the CM Department. EAB credentials are used to authenticate/authorize an ACME account to use an ACME server - registration establishes keypair used for future interaction.
• Challenge: Demonstrate control over a domain so that certificates can be issued to you (usually by DNS or URL changes) - unnecessary for InCommon service

Workflow Overview

1. DRAO or user collaborates with Information Security admins to validate domain for use (DCV) annually and delegate administration of that domain to the DRAO - these steps are exactly the same as for non-ACME certificate issuance.
2. DRAO creates an ACME account for a user then provides ACME endpoint and EAB info to the user. EAB info should be treated as a password - shared and stored securely. To create the ACME account the DRAO needs to select an appropriate ACME endpoint and certificate profile.
3. User configures an ACME client to use EAB info to register their ACME account with the ACME endpoint. Registration creates crypto material that the ACME client can use thereafter to manage certificates from the ACME endpoint (request, renew, revoke, etc).

Workflow In Detail

ACME Enrollment

All the instructions that follow assume a DRAO signed into the CM, who has selected ACME enrollment from the CM side navigation.

ACME Endpoint

DRAO selects an ACME endpoint. Description of the options available when you create an account are in the table.

Endpoint	Domains Available	Profiles Available	Notes
Universal	All domains delegated to the DRAO's Department.	A single profile selected at account creation. The algorithm and key size can be configured via certbot command (e.g. "--elliptic-curve secp384r1")	For an account that needs access to many domains and/or that needs a specific Profile (not the generic profile offered by other endpoints).
InCommon ECC OV	Any domains delegated to the Department and configured by the DRAO for use with the ACME account.	Sectigo ACME	For an account that needs a defined subset of Department's domains. ECC provides better performance and likely future-proofing.
InCommon RSA OV	Any domains delegated to the Department and configured by the DRAO for use with the ACME account.	Sectigo ACME	For an account that needs a defined subset of Department's domains. RSA provides better support for legacy environments.

 

ACME Account

With your ACME endpoint selected click Accounts.

Created accounts provide the following information:

• Status
• Contacts (autogenerated)
  • ACME URL
  • Account ID
• External Account Binding (autogenerated)
  • Key ID
  • HMAC Key

View or Edit Existing Accounts

• To view an existing account: select the account and select Details.
• To edit an existing account: select the account and select Edit.

Create a New Account

To create a new account select the green plus (+) then edit. Account creation requires:

• Name (choose your own naming convention)
• Organization (always 'The University of Chicago')
• Department (most DRAOs will have only one option - cannot be changed after creation)
• Validation Type (always 'OV')
• Certificate Profile (for Universal Endpoint only)
• Domain(s) delegated (for ECC/RSA Endpoints only)

ACME Client

The DRAO provides ACME endpoint and EAB information via secure channel to the user who uses it with their ACME client of choice.

The CM provides information on ACME client usage. The DRAO can use that data for auditing, troubleshooting, etc. 

From Accounts select Clients.

Guidance on Allocation of ACME Accounts

Since an ACME account can generate certificates for any of the domain/profile combinations for which it is configured it may potentially be used for a single domain or hundreds of domains. DRAOs are able to determine how many ACME accounts should be created and how they should be used.  

When deciding how to factor your users and their servers into ACME accounts, evaluate the ACME account credentials as a password that allows the holder to generate certificates on your behalf. Consider the impact of a server compromise that requires resetting the ACME account for all servers that share the compromised server's ACME account. For maximum security there would in principle be one account per domain. In reality that may be operationally infeasible, or offer too little benefit for the operational cost. On the other hand, for maximum ease of operations there would be one account for all domains. That creates obvious security risks as well as massive potential operational disruption if the single account were compromised.

There are boundaries you should maintain unless you have a well-considered reason:

• ACME accounts should not cross administrative boundaries within your unit. For example, if you have two independent teams managing servers, those teams should not share an ACME account.
• ACME accounts should not mix domains of significantly different criticality and risk levels. For example, a web site for an annual conference should not share an ACME account with a business critical application.
• ACME accounts should use the Universal endpoint only when necessary. The Universal endpoint allows for more control over the Certificate Profile than the Public Profiles (ECC and RSA); however, it does not allow for scoping which of the Department's delegated domains are usable.

In addition, consider separating ACME accounts by:

• different applications or internal customers
• tiered environments (production versus development/testing)
• different use cases (e.g. web servers versus email servers)

Example Workflows

Example Workflow for Universal Endpoint

• The account can use any validated domain delegated to the chosen Department.
• The account can only use one profile, e.g. the most likely profile is InCommon Multi Domain SSL (SHA-2)

CM > Enrollment > ACME > Select Endpoint > Accounts > Green Plus (+) > Create ACME Account: Add Name, Department, and Select Certificate Profile > Record the endpoint and EAB information > Securely provide information to user