Wildcard Certificates
Request a wildcard certificate (for example, *.example.com) with the DigiCert ACME Client using CLI flags only.
DNS-01 is required. Wildcard certificates cannot be validated with HTTP-01. You must use --challenge-type "dns-01" with a DNS provider handler and valid credentials.
Command pattern
Use a wildcard Common Name and DNS-01 challenge flags. This example uses Route 53 and installs into NGINX on Linux—adapt handler args for your DNS provider and swap installer flags for your web server (see NGINX with DNS-01 or IIS with HTTP-01 for platform-specific install details).
# Production wildcard DNS-01 request with NGINX install (replace placeholder values)
sudo dc-acme request enroll \
--directory-url "https://one.digicert.com/mpki/api/v1/acme/v2/directory" \
--email "admin@example.com" \
--eab-key "YOUR_EAB_KEY_ID" \
--eab-hmac "YOUR_EAB_HMAC_KEY" \
--auto-ari-renew=true \
--cn "*.example.com" \
--challenge-type "dns-01" \
--challenge-handler-name "default" \
--challenge-handler-args "DNS_PROVIDER_NAME=route53,AWS_ACCESS_KEY_ID=YOUR_AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_ACCESS_KEY,AWS_REGION=us-east-1" \
--installer-handler-name "nginx" \
--installer-handler-args "identifier=example.com"
Installer identifier vs wildcard --cn. The NGINX installer matches on a concrete server_name in your config—pass the site hostname you are securing (for example example.com or www.example.com), not the wildcard string.
Using a wildcard on multiple servers
A single wildcard order often needs to live on more than one host—for example, a Linux NGINX server, a Windows IIS box, and a staging environment. You do not copy one certificate file between machines. Instead, run the same enroll command on each server, keeping --cn identical (for example --cn "*.example.com"). Change only what differs per host: DNS handler credentials, challenge handler, installer (nginx vs iis), and the site-specific identifier or hostname argument.
When DigiCert already has a valid wildcard order for that base domain, its auto-detection rules typically treat the next request as a reissue of that order—not a new enrollment. You can request as many reissues as you need; each server gets its own key pair and certificate files.
Those copies are independent. A certificate already installed on one machine stays valid when you enroll on another—deploying on a second host does not revoke or replace the first. Each instance remains valid on its own until it expires or that host renews it.
First server vs. additional servers. The first enroll for *.example.com creates the order. On each additional server, run the same pattern with the same --cn; DigiCert matches the existing wildcard order and issues another reissue. Confirm the outcome in CertCommand under Certificates > Orders and in dc-acme request list on each host.
Adding SANs later
Unlike non-wildcard certificates, a wildcard order can gain or lose SANs after the first issuance—as long as --cn stays the same wildcard (for example *.example.com). Run another enroll with an updated --sans list; DigiCert typically reissues the existing order rather than creating a new enrollment.
- List every SAN you want on the certificate in
--sans(including names you are keeping). - DCV runs for each new hostname you add.
- Additional charges may apply in CertCommand for new SANs—confirm under Certificates > Orders.
For the full comparison with non-wildcard behavior (including what not to do on a standard CN), see Subject Alternative Names (SANs) — Adding SANs after the first certificate.
Related topics
- Subject Alternative Names (SANs) — Adding or changing SANs after the first certificate
- NGINX with DNS-01 — Full DNS-01 walkthrough
- Production CLI Examples — All CLI-only recipes
- DNS-01 handler reference — Provider-specific handler arguments
← Back to Production CLI Examples