Issuance flow
Overview of the complete path of an issuance in the CLM — from configuring the Certificate Authority to the signed certificate appearing in the inventory.
The process has two phases: configure the CA once, then issue as many certificates as you need through it.
Phase 1 — Configure the CA
1. Connect the integration
Go to Integrations, find the desired CA's card, and click Connect.
In the Register account modal, fill in:
| Field | Description |
|---|---|
| Name | Identifier for the account in the CLM, e.g. Sectigo Production |
| Contact address registered with the CA | |
| Directory URL (ACME) | Pre-filled with the CA's official URL. Click the pencil icon to edit if your account uses a custom endpoint |
| EAB Key ID | Identifier for the External Account Binding credential, when the CA requires it |
| EAB HMAC Key | Corresponding HMAC key. Stored encrypted and never shown again |
Click Register.
2. The account stays pending registration
After saving, the account shows as pending registration. This is expected.
The CLM doesn't register the account with the CA at the moment you click Register — it stores the credentials and performs the actual registration with the CA on the first submitted signing order.
That's why incorrect EAB credentials only surface an error on the first issuance, not at registration. If the first issuance fails with an EAB error, review the credentials in the edit modal before trying again.
Phase 2 — Issue a certificate
3. Create the request
Go to CSR in the sidebar menu and click New Request.
4. Step 1 — Identification
| Field | Description |
|---|---|
| Certificate Name | Name to identify the certificate in the CLM |
| Certificate Type | SSL/TLS (filled automatically) |
| Domain / Common Name | Main domain. Accepts wildcard, e.g. *.example.com |
| Alternative Names / SANs | Additional domains separated by commas (optional) |
| Key Size | 2048, 3072, or 4096 bits (optional — default 2048) |
Click Continue.
5. Step 2 — CA and Configuration
Select the Certificate Authority from the list. The available options depend on the integrations configured in Phase 1.
For ACME CAs, the form shows:
- ACME Account — select the account registered for that CA
- Validation Method — choose between:
| Method | How it works |
|---|---|
| HTTP Challenge | The CLM serves a file under /.well-known/acme-challenge on the domain |
| DNS Challenge | The CLM creates a _acme-challenge TXT record on the domain's DNS |
Choosing DNS Challenge shows the DNS Auto-Validation (AWS Route 53) option:
| Mode | Behavior |
|---|---|
| Manual | The CLM shows the TXT record and you publish it on your DNS |
| Automatic | The CLM creates the TXT record via Route 53, waits for propagation, and completes issuance without intervention |
In automatic mode, select the AWS Integration (Route 53) and the Hosted Zone matching the domain.
Use the Notes field to record additional information about the request (optional). Click Continue.
Combining DNS Challenge with Auto-Validation via Route 53 lets you issue without any manual step — it's the recommended setup for wildcards and for domains without port 80 exposed.
6. Step 3 — Review
Check the Identification and CA and Configuration summary. Use Edit to go back to any step. Click Submit request.
7. Track the validation
Click the request to open the Domain validation modal. It shows in real time:
- DNS Status — publication and verification of the record
- Record Type, Name, and Value of the challenge
- Progress log — every step of the ACME order, from request creation to issuance
In automatic mode, no action is required — the agent creates the record, waits for propagation, and requests validation from the CA.
8. Certificate in the inventory
Once validation completes, the signed certificate appears under Certificates, with the expiration date and automatic renewal already configured.
Next steps
Each CA has its own requirements and details — credentials, CAA record, domain restrictions. See your CA's guide for the specific details before issuing.