🔐DigiCert ACME Certificate Automation with LEGO, Persistent DNS & Azure Key Vault🔐

🔐 DigiCert ACME Certificate Automation with LEGO: Enroll, Renew, Reissue & Duplicate Using Persistent DNS + Azure Key Vault

Enterprise implementation guide using LEGO v5.3.1, DigiCert ACME, Persistent DNS validation, Linux, Managed Identity and Azure Key Vault.

⏱️ Estimated reading time: 19 minutes

go-acme / LEGO

This article uses *.example.com as a security-sanitized example. Never publish real EAB HMAC values, API keys, private keys, PFX passwords, Azure tokens or internal identifiers.

📘 Before You Start — Terms You Should Know

If you are new to certificate automation, these terms will make the rest of the article much easier to follow.

Term	Simple meaning
CA	Certificate Authority. In this design, DigiCert is the public CA that issues the certificate.
ACME	Automatic Certificate Management Environment — a standard protocol used to automate certificate lifecycle operations.
LEGO	An open-source ACME client. LEGO talks to DigiCert using the ACME protocol.
ACME Directory	The DigiCert CertCentral configuration/endpoint that defines which product, organization, domains and permissions the ACME client can use.
EAB KID	External Account Binding identifier used to associate the ACME client with the DigiCert ACME account.
EAB HMAC	Secret used together with the EAB KID. Treat it like a password and store it securely.
CSR	Certificate Signing Request containing the certificate subject and requested DNS names.
DCV	Domain Control Validation — proof that the requester is authorized to obtain a certificate for the domain.
Persistent DNS	DigiCert domain validation using a persistent TXT record that can be reused while the validation remains valid.
SAN	Subject Alternative Name — DNS names included in the certificate.
Order ID	The identifier of an existing DigiCert certificate order. It is used for explicit renew, reissue and duplicate operations.
PFX	A package that can contain the certificate, private key and certificate chain for deployment.
Azure Key Vault	Azure service used here to securely store ACME secrets and the issued certificate.

🔄 Simple End-to-End Flow

This is the high-level flow before we go into the detailed architecture.

1. Validate Organization in DigiCert (OV/EV) | v 2. Validate Domain using Persistent DNS | v 3. Create ACME Directory in DigiCert CertCentral | v 4. Store ACME URL + EAB KID + EAB HMAC in Azure Key Vault | v 5. Linux VM reads secrets using Managed Identity | v 6. LEGO connects to DigiCert | v 7. Choose certificate lifecycle action New Certificate Existing DigiCert Order | | v v ENROLL RENEW / REISSUE / DUPLICATE No Order ID Existing Order ID \ / \ / +---------------+------------------+ | v 8. DigiCert verifies authorization / validation | v 9. DigiCert issues certificate | v 10. Validate certificate + private key | v 11. Create PFX | v 12. Import to Azure Key Vault | v 13. Deploy to application / server

ACME Clientgoacme/lego:v5.3.1

ℹ️ ACME client alternative: This implementation uses LEGO v5.3.1, but Certbot or another compatible ACME client can also be used with DigiCert if it supports the required DigiCert ACME lifecycle workflow.

Lifecycle?action=renew&orderId=<ORDER_ID>

ValidationDigiCert Persistent DNS

Secret StoreAzure Key Vault

Azure IdentityManaged Identity

DNS WritesNone by LEGO in this design

Index

1. DigiCert ACME Lifecycle Actions and Order ID Rule
2. End-to-End Architecture
3. DigiCert Service User and Approval Delegation
4. Persistent DNS Domain Validation
5. Create ACME Directory in DigiCert CertCentral
6. DigiCert API Key
7. Azure Key Vault and Secrets
8. Managed Identity and RBAC
9. Prepare Linux
10. Directory Layout
11. Lifecycle Pre-checks
12. Create Private Key and CSR
13. Verify CSR and Key Match
14. Load Secrets and Build Action URL
15. Prepare LEGO Account State
16. Run LEGO with Selected Action
17. Expected Successful Behavior
18. Validate Issued Certificate
19. Create PFX and Import to Key Vault
20. Export PFX for Deployment
21. Cleanup and Security Controls
22. Production Checklist
23. Official References

💡 How to read this article: If you are new to ACME, read the glossary, simple flow and Sections 1–5 first. If you already understand PKI/ACME, you can jump directly to the architecture, Key Vault, LEGO and implementation sections using the Index.

🔁 1. DigiCert ACME Lifecycle Actions and Order ID Rule

DigiCert CertCentral supports four important lifecycle actions for third-party ACME clients: enroll, renew, reissue, and duplicate.

⚠️ Important terminology: DigiCert uses the action name reissue — not issue — when replacing a certificate under an existing order.

Action	Order ID required?	Simple meaning	Example
Enroll	No	Create a brand-new DigiCert certificate order.	You need a new *.example.com certificate and there is no existing order to target.
Renew	Yes for an explicit targeted action	Renew the certificate coverage on an existing order.	The existing certificate/order is reaching its renewal lifecycle.
Reissue	Yes for an explicit targeted action	Issue a replacement certificate under an existing order.	You need a new certificate/private key while keeping the same commercial order.
Duplicate	Yes	Issue another certificate from an existing order.	The same order needs an additional certificate instance and the certificate profile allows duplicates.

⚠️ What Happens to the Existing Certificate After Each Action?

This is important during production migration because issuing a new certificate does not always mean the certificate already installed on the server immediately becomes invalid.

Action	What happens to the existing certificate?	Operational meaning
Enroll	A new, independent DigiCert order and certificate are created. Existing certificates are not automatically replaced or revoked by the new enrollment.	You can deploy the new certificate separately. Old certificates continue according to their own validity/revocation status.
Renew	The renewal issues a new certificate with new validity. The certificate already deployed does not become invalid merely because the new certificate was issued; it normally remains usable until its own expiration unless it is separately revoked.	This gives an overlap window to deploy and validate the renewed certificate before the older certificate expires.
Reissue	A new version of the certificate is issued on the same order. The previous certificate can remain valid, but some reissue changes can trigger revocation. DigiCert specifically warns that changing or removing SANs can cause the original certificate and related duplicates/reissues to be revoked within 72 hours.	Do not assume an unlimited overlap window after a reissue. Check DigiCert Certificate History / revocation warnings and deploy the replacement quickly when SAN changes are involved.
Duplicate	A separate certificate is issued from the existing order. DigiCert documents duplicate certificates as a way to obtain another certificate without revoking the original.	Original and duplicate certificates can coexist. Each certificate has its own serial number and deployment location.

⚠️ Important: Certificate issuance and certificate revocation are different lifecycle events. Always verify the status of the old certificate in DigiCert CertCentral/Trust Lifecycle Manager before removing it from production. Reissue is the main case where requested certificate changes can cause automatic revocation of previously issued certificates.

Example migration window Existing certificate on production server | | Renew / Duplicate / eligible Reissue v New certificate issued | +---- Old certificate may still be valid | v Deploy new certificate | v Validate application / TLS | v Remove old deployment when safe Exception: Reissue with SAN changes/removal | v DigiCert may place older certificates into revocation pending | v Replace them before DigiCert's revocation deadline

🔗 Complete DigiCert ACME URL Examples

# Base ACME Directory URL https://one.digicert.com/mpki/api/v1/acme/v2/directory # ENROLL - create a new order - no Order ID required https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=enroll # RENEW - existing order https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=renew&orderId=555123456 # REISSUE - existing order https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=reissue&orderId=555123456 # DUPLICATE - existing order https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=duplicate&orderId=555123456

CertCentral auto-detection: If action and orderId are omitted, CertCentral can auto-detect a matching ACME-issued order and apply its default lifecycle action. If no matching order is found, the request is treated as a new enrollment. For predictable automation, this guide recommends using an explicit action when you know the intended lifecycle operation.

⚠️ Safety rule: Never allow automation to silently change between enroll, renew, reissue, or duplicate. Renew/reissue/duplicate operate against existing certificate lifecycle state, and renewal can have commercial/funding impact.

↑ Back to Index

🏗️ 2. End-to-End Architecture

DigiCert CertCentral Console | |-- Automation > ACME Directory URLs > Add ACME Directory URL |-- Select Product |-- Select validated Organization for OV/EV |-- Select Service User / Owner |-- Configure Allowed SANs / validity / restrictions |-- Generate ACME URL + EAB KID + EAB HMAC | v Azure Key Vault |-- ACME base URL |-- EAB KID |-- EAB HMAC |-- DigiCert API key (optional pre-checks) |-- Existing Order ID (for targeted existing-order actions) | v Azure DevOps / Engineer | v Linux VM / Self-hosted Agent |-- System-Assigned Managed Identity |-- Docker + LEGO v5.3.1 | v Lifecycle Decision | |-- New order | --> ?action=enroll | Order ID NOT required | |-- Existing order --> ?action=renew&orderId=<ORDER_ID> --> ?action=reissue&orderId=<ORDER_ID> --> ?action=duplicate&orderId=<ORDER_ID> | v Validation Gate |-- Domain/DCV valid |-- OV/EV Organization validation valid | v DigiCert ACME Authorization |-- Persistent DNS already valid |-- LEGO performs no DNS write in this design | v Certificate issued | v PFX --> Azure Key Vault --> Deployment systems

⚙️ ACME Directory creation: Create the ACME Directory credentials in the DigiCert CertCentral console. For Enterprise/Partner-style accounts, DigiCert documents the path as Automation → ACME Directory URLs → Add ACME Directory URL. The generated ACME URL, KID, and HMAC are shown once, so store them securely.

The architecture separates identities: DigiCert certificate automation uses the Service User + ACME EAB credentials, while Azure access uses the Linux VM Managed Identity.

Communication	Authentication / identity used
Linux VM → Azure Key Vault	Azure System-Assigned Managed Identity
LEGO → DigiCert ACME	EAB KID + EAB HMAC
DigiCert automation ownership	DigiCert Service User
Optional DigiCert API pre-checks	DigiCert Services API key

↑ Back to Index

👤 3. DigiCert Service User and Order Approval Delegation

Create a dedicated non-human DigiCert Service User. Select the same Service User as the ACME Directory user/owner. Where required, Order Approval Delegation should be approved.

↑ Back to Index

🌐 4. Persistent DNS Domain Validation

The DNS team creates the DigiCert Persistent DNS validation TXT record in the authoritative zone. LEGO should not create, update or delete DNS records during the certificate operation.

🌍 Normal DNS Challenge vs Persistent DNS

Normal DNS-01 automation	Persistent DNS design used here
ACME client creates a temporary TXT challenge record, waits for validation, and later removes it.	DNS team creates DigiCert's persistent validation TXT record once. When DigiCert still shows the domain as Valid, LEGO does not need to modify DNS during the certificate operation.

Normal DNS Challenge LEGO --> Create temporary TXT --> DNS --> DigiCert validates --> TXT can be removed Persistent DNS Design DNS Team --> Create persistent TXT once --> DigiCert DCV Valid | v LEGO --> DigiCert | v "Authorization is already valid" | v No DNS modification

Record Type : TXT Record Name : _validation-persist FQDN : _validation-persist.example.com Record Value: digicert.com;accounturi=https://digicert.com/account/<PERSISTENT_ACCOUNT_URI> TTL : 300

dig TXT _validation-persist.example.com @8.8.8.8 +short dig TXT _validation-persist.example.com @1.1.1.1 +short

⚠️ Important: Public DNS visibility does not prove that DigiCert currently shows the domain as Valid. Confirm DCV status in DigiCert before the certificate operation.

✅ Expected LEGO message: Authorization is already valid; skipping the challenge.

DigiCert Persistent DNS is not the same as LEGO's --dns-persist option.

↑ Back to Index

⚙️ 5. Create the ACME Directory in DigiCert CertCentral

What is an ACME Directory? Think of it as the DigiCert configuration and ACME endpoint that tells LEGO which certificate product, validated organization, domains/SANs and restrictions it is allowed to use.

The ACME Directory must be created in the DigiCert CertCentral console. For Enterprise and Partner accounts, go to:

CertCentral --> Automation --> ACME Directory URLs --> Add ACME Directory URL

Configure the ACME credentials with the certificate settings that should apply to requests made through this directory.

Setting	Recommendation
Name	Use a clear automation-specific name.
Product	Select the exact DigiCert certificate product you intend to use.
Organization	For OV/EV, select the validated organization that should appear in the certificate.
User / Owner	Select the dedicated DigiCert Service User.
Allowed SANs	Restrict the directory to only the approved domains/SANs.
Validity / Coverage	Use your organization-approved DigiCert certificate settings.

🏢 Organization / CSR [O] note: For OV/EV certificates, the organization selected in CertCentral must be an active, validated organization. If your CSR contains an O = (Organization) value, keep that value consistent with the validated legal organization selected for the ACME credentials. Do not use a different organization name in the CSR. The organization itself is selected in CertCentral; it is not supplied through the orderId URL parameter.

DigiCert CertCentral Organization | v Example Organization Limited | v CSR Subject O = Example Organization Limited Order ID is a different concept: Order ID = identifies an existing DigiCert certificate order.

📋 New enrollment prerequisite: For a new OV/EV enrollment, make sure the intended organization validation is current and the certificate domains are validated/authorized before expecting immediate issuance. DigiCert states that new organizations must complete validation before ACME issuance can succeed.

After creating the ACME Directory, CertCentral displays the ACME Directory URL, EAB KID, and EAB HMAC. Store them immediately in Azure Key Vault. DigiCert displays these credentials only once.

↑ Back to Index

🔑 6. DigiCert API Key

A DigiCert Services API key is optional for LEGO issuance. It can be used for controlled pre-checks such as order details, product, expiry, domain validation and organization validation.

🔐 LEGO issuance uses: ACME Directory URL + EAB KID + EAB HMAC.

↑ Back to Index

🔐 7. Azure Key Vault and Secrets

Secret	Purpose
DIGICERT-ACME-URL-EXAMPLE-PROD	ACME base URL
DIGICERT-EAB-KID-EXAMPLE-PROD	EAB KID
DIGICERT-EAB-HMAC-EXAMPLE-PROD	EAB HMAC
DIGICERT-API-KEY-EXAMPLE-PROD	Optional API key
DIGICERT-ORDER-ID-EXAMPLE-PROD	Existing Order ID — needed only when explicitly targeting renew, reissue or duplicate

RG="<RESOURCE_GROUP>" LOCATION="centralindia" VAULT="<KEY_VAULT_NAME>" az keyvault create --name "$VAULT" --resource-group "$RG" --location "$LOCATION" --enable-rbac-authorization true

Never publish EAB HMAC, API keys, PFX passwords, private keys or Azure tokens.

↑ Back to Index

🛡️ 8. Managed Identity and RBAC

Role	Purpose
Key Vault Certificates Officer	Certificate import/manage
Key Vault Secrets User	Read ACME/EAB/API/order secrets

az login --identity --allow-no-subscriptions az keyvault secret show --vault-name "<KEY_VAULT_NAME>" --name DIGICERT-ACME-URL-EXAMPLE-PROD --query id -o tsv

↑ Back to Index

🐧 9. Prepare Linux

cat /etc/os-release openssl version docker --version az version systemctl is-active docker docker pull goacme/lego:v5.3.1 docker run --rm goacme/lego:v5.3.1 --version

Required path: outbound HTTPS TCP/443 to DigiCert and Azure Key Vault. No inbound listener is required when authorization is already valid through Persistent DNS.

↑ Back to Index

📁 10. Directory Layout and Permissions

sudo mkdir -p /datadisk/ssl-cert-auto/lego/prod/example-wildcard/{account-state,transaction-state,csr,output,logs,export} sudo chmod 700 /datadisk/ssl-cert-auto/lego/prod/example-wildcard/{account-state,transaction-state,csr,output,export}

↑ Back to Index

✅ 11. Pre-checks Before Enroll, Renew, Reissue, or Duplicate

1. Managed Identity login works.
2. Azure Key Vault access works.
3. DigiCert Service User is active.
4. Order Approval Delegation is approved where required.
5. The ACME Directory is created in DigiCert CertCentral and assigned to the intended Service User.
6. The certificate product in the ACME Directory matches the intended request.
7. For OV/EV, the selected organization is active and validation is current.
8. If the CSR contains O =, keep it consistent with the validated organization selected in CertCentral.
9. Persistent DNS/DCV for all requested domains is valid.
10. CN/SANs are allowed by the ACME Directory restrictions.
11. Enroll: no existing Order ID is required when explicitly using ?action=enroll.
12. Renew / Reissue / Duplicate: confirm the exact existing Order ID before building the explicit action URL.
13. For duplicate, confirm the certificate profile allows duplicates.
14. For renewal, confirm commercial/funding approval where applicable.

⚠️ Production rule: If domain validation or required OV/EV organization validation is not Valid, stop the automation. Do not bypass validation and do not give LEGO DNS write access for this Persistent DNS design.

↑ Back to Index

🧾 12. Create Private Key and CSR

[ req ] default_bits = 2048 prompt = no default_md = sha256 distinguished_name = dn req_extensions = req_ext [ dn ] C = IN ST = Maharashtra L = Mumbai O = Example Organization Limited CN = *.example.com [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = *.example.com DNS.2 = example.com

openssl genrsa -out example-wildcard.key 2048 chmod 600 example-wildcard.key openssl req -new -key example-wildcard.key -out example-wildcard.csr -config example-csr.conf

↑ Back to Index

🔎 13. Verify CSR and Key Match

openssl req -in example-wildcard.csr -noout -subject openssl req -in example-wildcard.csr -noout -text | grep -A2 "Subject Alternative Name" openssl pkey -in example-wildcard.key -pubout -outform DER | sha256sum openssl req -in example-wildcard.csr -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum

The two public-key hashes must match.

↑ Back to Index

🔗 14. Load Secrets and Build the Required ACME Action URL

Load the ACME base URL and EAB credentials from Azure Key Vault. Load an Order ID only for an operation that targets an existing order.

VAULT="<KEY_VAULT_NAME>" BASE_ACME_URL="$(az keyvault secret show --vault-name "$VAULT" --name DIGICERT-ACME-URL-EXAMPLE-PROD --query value -o tsv)" export LEGO_EAB_KID="$(az keyvault secret show --vault-name "$VAULT" --name DIGICERT-EAB-KID-EXAMPLE-PROD --query value -o tsv)" export LEGO_EAB_HMAC="$(az keyvault secret show --vault-name "$VAULT" --name DIGICERT-EAB-HMAC-EXAMPLE-PROD --query value -o tsv)" # NEW ENROLLMENT - no Order ID export LEGO_SERVER="${BASE_ACME_URL}?action=enroll" # EXISTING ORDER examples - load Order ID first export ORDER_ID="$(az keyvault secret show --vault-name "$VAULT" --name DIGICERT-ORDER-ID-EXAMPLE-PROD --query value -o tsv)" # Renewal export LEGO_SERVER="${BASE_ACME_URL}?action=renew&orderId=${ORDER_ID}" # Reissue export LEGO_SERVER="${BASE_ACME_URL}?action=reissue&orderId=${ORDER_ID}" # Duplicate export LEGO_SERVER="${BASE_ACME_URL}?action=duplicate&orderId=${ORDER_ID}"

💡 Operational recommendation: Make the action an explicit pipeline parameter with an allow-list such as enroll|renew|reissue|duplicate. Require an Order ID for renew/reissue/duplicate and reject an Order ID for a forced new enroll.

↑ Back to Index

🧩 15. Prepare LEGO Account State for the Certificate Transaction

BASE_STATE=/datadisk/ssl-cert-auto/lego/prod/example-wildcard/account-state TRANSACTION_STATE=/datadisk/ssl-cert-auto/lego/prod/example-wildcard/transaction-state rm -rf "$TRANSACTION_STATE" mkdir -p "$TRANSACTION_STATE" chmod 700 "$TRANSACTION_STATE" # Reuse only the ACME account state when it already exists. if [ -d "$BASE_STATE/accounts" ]; then cp -a "$BASE_STATE/accounts" "$TRANSACTION_STATE/" fi

💡 Why use transaction-state? This article covers enroll, renew, reissue and duplicate, so the generic name avoids making every operation look like a renewal. Reuse the ACME accounts state when appropriate, but start the certificate transaction without carrying an old local certificates directory that could influence LEGO local renewal timing.

💡 About --renew-force: Use this LEGO flag only when you intentionally want LEGO to submit a renewal even when its local renewal timing says the certificate is not due yet. It does not select the DigiCert lifecycle action. DigiCert renewal must still be explicitly selected through LEGO_SERVER, for example ?action=renew&orderId=.... Do not add --renew-force to enroll, reissue or duplicate examples.

↑ Back to Index

🚀 16. Run LEGO with the Selected DigiCert Action

The DigiCert lifecycle behavior is determined by LEGO_SERVER. For renewal, the following example also uses LEGO --renew-force so LEGO does not skip the request because of its local renewal timing.

♻️ Renew Example — with --renew-force

# LEGO_SERVER must already contain: # https://one.digicert.com/mpki/api/v1/acme/v2/directory?action=renew&orderId=<EXISTING_ORDER_ID> docker run --rm -v /datadisk/ssl-cert-auto/lego/prod/example-wildcard/transaction-state:/var/lib/lego:Z -v /datadisk/ssl-cert-auto/lego/prod/example-wildcard/csr:/csr:Z -e LEGO_SERVER -e LEGO_EAB_KID -e LEGO_EAB_HMAC goacme/lego:v5.3.1 run --path /var/lib/lego --accept-tos --email "certificate-automation@example.com" --eab --http --renew-force --csr /csr/example-wildcard.csr

⚠️ Important: --renew-force is a LEGO renewal-timing flag. It forces LEGO to renew even if the locally stored certificate is not yet due. It does not replace DigiCert's ?action=renew&orderId=... URL.

🔁 Enroll / Reissue / Duplicate

Do not use --renew-force merely to trigger enroll, reissue or duplicate. Select those DigiCert lifecycle actions through the ACME URL (LEGO_SERVER) and run LEGO without the renewal-force flag.

🌐 Why --http? LEGO requires a challenge solver to be selected. In this design DigiCert should already consider authorization valid through Persistent DNS, so the challenge is skipped. If a wildcard authorization is not already valid, stop and fix DCV rather than attempting HTTP-01 validation.

↑ Back to Index

✅ 17. Expected Successful Behavior with Persistent DNS

INFO Obtaining bundled SAN certificate given a CSR. INFO Authorization is already valid; skipping the challenge. INFO Validations succeeded; requesting certificates. INFO Server responded with a certificate.

The key design result: no per-operation DNS TXT write is required when DigiCert authorization remains valid through Persistent DNS.

↑ Back to Index

🔍 18. Validate the Issued Certificate

CERT=/datadisk/ssl-cert-auto/lego/prod/example-wildcard/transaction-state/certificates/_.example.com.crt openssl x509 -in "$CERT" -noout -subject -issuer -serial -dates -ext subjectAltName openssl x509 -in "$CERT" -pubkey -noout | openssl pkey -pubin -outform DER | sha256sum openssl pkey -in /datadisk/ssl-cert-auto/lego/prod/example-wildcard/csr/example-wildcard.key -pubout -outform DER | sha256sum

↑ Back to Index

📦 19. Create PFX and Import the Certificate to Key Vault

PFX_PASSWORD="$(openssl rand -base64 32)" openssl pkcs12 -export -out example-wildcard-renewed.pfx -inkey example-wildcard.key -in _.example.com.crt -certfile _.example.com.issuer.crt -password pass:"$PFX_PASSWORD" az keyvault certificate import --vault-name "<KEY_VAULT_NAME>" --name EXAMPLE-WILDCARD-PROD --file example-wildcard-renewed.pfx --password "$PFX_PASSWORD" unset PFX_PASSWORD

↑ Back to Index

📤 20. Export PFX for Deployment

az keyvault secret download --vault-name "<KEY_VAULT_NAME>" --name EXAMPLE-WILDCARD-PROD --file EXAMPLE-WILDCARD-PROD.pfx --encoding base64 chmod 600 EXAMPLE-WILDCARD-PROD.pfx

⚠️ Temporary PEM risk: if repackaging with -nodes, the temporary PEM contains unencrypted private-key material. Delete it immediately.

↑ Back to Index

🧹 21. Cleanup, Logging and Security Controls

• Never echo EAB HMAC, API key, PFX password, private key or Azure token.
• Protect and retain reusable LEGO account state.
• Retain audit metadata: order ID, serial, thumbprint, validity dates and pipeline run ID.
• Use Key Vault RBAC at Key Vault resource scope.
• Pin and vulnerability-scan the LEGO image.
• Do not grant DNS write privileges for this Persistent DNS design.

unset LEGO_EAB_KID unset LEGO_EAB_HMAC unset LEGO_SERVER unset ORDER_ID unset BASE_ACME_URL

↑ Back to Index

☑️ 22. Production Checklist

• ✅ Linux host hardened and tools verified.
• ✅ LEGO pinned to goacme/lego:v5.3.1.
• ✅ System-assigned Managed Identity enabled.
• ✅ Key Vault Certificates Officer assigned at Key Vault scope.
• ✅ Key Vault Secrets User assigned at Key Vault scope.
• ✅ ACME URL, EAB KID and EAB HMAC stored in Key Vault.
• ✅ For explicit renew/reissue/duplicate, the approved existing Order ID is securely available (for example in Key Vault).
• ✅ Dedicated DigiCert Service User configured.
• ✅ Order Approval Delegation approved.
• ✅ ACME Directory owned by the Service User.
• ✅ Persistent DNS validation is Valid.
• ✅ Organization and domain validation are current.
• ✅ For renew/reissue/duplicate, the existing Order ID and product are confirmed.
• ✅ For enroll, organization/product/domain prerequisites are confirmed and no existing Order ID is required.
• ✅ CSR CN/SANs match approved scope.
• ✅ Explicit lifecycle action is selected: enroll, renew, reissue, or duplicate.
• ✅ Before deployment, confirm the existing certificate revocation/overlap impact for the selected lifecycle action—especially for reissues that change or remove SANs.
• ✅ Order ID is supplied for explicit renew/reissue/duplicate, and is not required for a forced new enroll.
• ✅ No DNS write occurs during a healthy certificate operation when Persistent DNS/DCV is already valid.
• ✅ Issued certificate and private key match.
• ✅ PFX imported into Azure Key Vault and validated.

🎯 What This Architecture Demonstrates

• DigiCert ACME can be driven through LEGO using a dedicated Service User and EAB credentials.
• An existing DigiCert order can be explicitly targeted for renew, reissue or duplicate.
• Persistent DNS can avoid per-operation DNS TXT creation while authorization remains valid.
• Azure Managed Identity removes the need to store Azure credentials on the Linux host.
• Azure Key Vault can centrally store ACME credentials/metadata and the issued certificate.

↑ Back to Index

📚 23. Official References

• DigiCert — Create and manage ACME credentials in CertCentral
• DigiCert — ACME automation actions and URL parameters (CertCentral)
• DigiCert — ACME automation actions
• LEGO — Obtain / renew certificate with a CSR
• LEGO Documentation
• Microsoft — Azure Key Vault RBAC guide
• Microsoft — Managed identities for Azure resources

🔐 Security note: All names and domains in this article are sanitized examples. Never publish production credentials, real EAB values, API keys or private keys.

Published on MiddlewareBox.com

Suggested labels: DigiCert, ACME, LEGO, SSL, TLS, Azure Key Vault, Managed Identity, Certificate Automation, Persistent DNS, DevOps