Auto-detection Rules

When the DigiCert ACME Client submits a certificate request, DigiCert must decide how to treat that request:

A reissue — replacement certificate on the same certificate order while prepaid coverage remains (no new coverage-term charge)
A renewal — starts a new prepaid coverage term and involves payment for the next period
A new enrollment — a new, billable certificate order

This decision is made automatically using auto-detection rules when you submit a certificate request (for example, by running dc-acme request enroll again).

Understanding these rules helps prevent unexpected new orders, duplicate certificates, and confusion during migrations.

Acronyms used on this page

Term	Meaning
ACME	Automated Certificate Management Environment — the protocol used to automate certificate issuance and renewal
ADU	ACME Directory URL — the endpoint and credential profile you create in CertCommand under Automation > ACME Directory URLs
ARI	ACME Renewal Information — optional CA-directed schedule for when to renew a certificate
CN	Common Name — primary hostname on the certificate (`--cn` flag)
SAN	Subject Alternative Name — additional hostnames on the same certificate (`--sans` flag)

Auto-detection vs. ARI

These are different mechanisms:

Mechanism	When it applies	Who submits the request
ARI (recommended for production)	Automatic reissues in the background	The `DigicertAcmeClient` service—no manual enroll
Auto-detection	You run `request enroll` (or a forced action)	You, via CLI or automation

When ARI is enabled, the service polls DigiCert and submits replacement orders on its own schedule. DigiCert still decides reissue vs. renewal on that path—see Understanding Automated Renewals.

Auto-detection applies to manual certificate requests. That includes migration enrolls, adding servers with the same CN, and any time you override defaults with ACME Automation Actions.

A key concept

From the ACME client’s perspective:

Every request is just a certificate request.

The client does not explicitly choose “renew,” “reissue,” or “enroll.” DigiCert applies matching logic on the server side after the request arrives.

What auto-detection looks at

To match an existing ACME-issued order, DigiCert evaluates:

Certificate product
Common Name (CN)
Subject Alternative Names (SANs)
Whether the original order was created via ACME
Certificate type (wildcard vs non-wildcard)

Only certificates that were originally issued through ACME are eligible for ACME reissue or renewal matching.

Non-wildcard certificates

For non-wildcard certificates, auto-detection is strict.

To match an existing order:

The CN must match exactly
The SAN list must match exactly (including “no SANs”)
The certificate product must be the same

If any of these differ, DigiCert treats the request as a new enrollment and creates a new billable order.

Adding SANs does not work via reissue. A forced reissue with --sans on a non-wildcard order may succeed, but the new SAN is ignored—you get the original name set only. To add hostnames, run a new enroll with the complete CN and SAN list—this creates a new, billable order. See Adding SANs after the first certificate.

Wildcard certificates

Wildcard orders are handled more flexibly when the wildcard CN stays the same.

For wildcard orders (for example, --cn "*.example.com"):

SANs may be added or removed on later enrolls while the wildcard CN is unchanged
DigiCert typically reissues the existing order rather than creating a new enrollment
Additional SANs require DCV and may incur additional charges in CertCommand—confirm under Certificates > Orders

Does not match the wildcard order:

A different wildcard base (for example, *.other.com when *.example.com exists) → new enrollment

See Wildcard certificates and Adding SANs later.

Multiple matching orders

If multiple existing ACME-issued orders could match a request, DigiCert selects the order with:

The longest remaining validity
A matching product type

This helps ensure continuity when overlapping certificates exist.

What happens if no match is found

If DigiCert cannot find a matching ACME-issued order:

The request is treated as a new enrollment
A new certificate order is created
The request is billable

This is expected behavior—not an error.

Why this sometimes surprises customers

Common reasons for unexpected new orders:

SAN changes on a non-wildcard certificate
Switching from manual issuance to ACME
Using a different certificate product
Manual reissue in CertCommand for an ACME-managed certificate—breaks ACME renewal tracking for that order

Manual reissue outside ACME. If an ACME-issued certificate is reissued manually in CertCommand, it is no longer treated as an active ACME-managed order for matching purposes. Prefer reissues through the ACME client.

Forcing a specific outcome

You can override auto-detection with URL parameters on the ACME Directory URL or with CLI flags—see ACME Automation Actions.

Examples:

?action=enroll — force a new enrollment
?action=renew&orderId=123456789 — force renewal of a specific order
?action=reissue&orderId=123456789 — force reissue of a specific order

Auto-detection is the recommended approach for routine operation. Use explicit actions only for controlled migrations or edge cases.

How to see what happened

After a request completes:

sudo dc-acme request list

Review the resulting order in CertCommand under Certificates > Orders. That view is authoritative for:

Whether the request was a reissue, renewal, or new enrollment
Whether new charges applied
Which certificate order was affected

For unexpected new orders, see Troubleshooting — Unexpected new orders.

Key takeaways

Auto-detection applies to manual certificate requests—not ARI background reissues
Only ACME-issued orders are eligible for matching
Non-wildcard matching is exact (CN + SAN list)
Wildcard matching allows SAN changes when CN stays *.zone
Forced reissue does not add SANs on non-wildcard orders
Confirm outcomes in CertCommand and request list

Next step

ACME Automation Actions »

← Back to Advanced Automation