This page contains details on the different options available on the
resource's DNS01 challenge solver configuration.
For more information on configuring ACME
Issuers and their API format, read the
ACME Issuers documentation.
DNS01 provider configuration must be specified on the
Issuer resource, similar
to the examples in the setting up documentation.
You can read about how the DNS01 challenge type works on the Let's Encrypt challenge types page.
apiVersion: cert-manager.io/v1alpha2kind: Issuermetadata:name: example-issuerspec:acme:email: firstname.lastname@example.org: https://acme-staging-v02.api.letsencrypt.org/directoryprivateKeySecretRef:name: example-issuer-account-keysolvers:- dns01:clouddns:project: my-projectserviceAccountSecretRef:name: prod-clouddns-svc-acct-secretkey: service-account.json
Each issuer can specify multiple different DNS01 challenge providers, and
it is also possible to have multiple instances of the same DNS provider on a
Issuer (e.g. two CloudDNS accounts could be set, each with their own
For more information on utilizing multiple solver types on a single
read the multiple-solver-types section.
cert-manager will check the correct DNS records exist before attempting a DNS01
challenge. By default, the DNS servers for this check will be taken from
/etc/resolv.conf. If this is not desired (for example with multiple
authoritative nameservers or split-horizon DNS), the cert-manager controller
exposes a flag that allows you alter this behavior:
If you're using the
cert-manager helm chart, you can set recursive nameservers
.Values.extraArgs or at the command at helm install/upgrade time
By default, cert-manager will not follow CNAME records pointing to subdomains.
If granting cert-manager access to the root DNS zone is not desired, then the
_acme-challenge.example.com subdomain can instead be delegated to some other,
less privileged domain. This could be achieved in the following way. Say, one has two zones:
- Create a CNAME record pointing to this less privileged domain:
_acme-challenge.example.com IN CNAME _acme-challenge.less-privileged.com.
Grant cert-manager rights to update
Provide configuration/credentials for updating this less privileged zone and add an additional field into the relevant
dns01solver. Note that
selectorfield is still working for the original
example.com, while credentials are provided for
apiVersion: cert-manager.io/v1alpha2kind: Issuermetadata:...spec:acme:...solvers:- selector:dnsZones:- 'example.com'- dns01:# Valid values are None and FollowcnameStrategy: Followroute53:region: eu-central-1accessKeyID: <Access ID for less-privileged.com here>hostedZoneID: <Zone ID for less-privileged.com here>secretAccessKeySecretRef:...
If you have a multitude of (sub)domains requiring separate certificates, it is possible to share an aliased less-privileged domain. To achieve it one should create a CNAME record for each (sub)domain like this:
_acme-challenge.example.com IN CNAME _acme-challenge.less-privileged.com._acme-challenge.www.example.com IN CNAME _acme-challenge.less-privileged.com._acme-challenge.foo.example.com IN CNAME _acme-challenge.less-privileged.com._acme-challenge.bar.example.com IN CNAME _acme-challenge.less-privileged.com.
With this configuration cert-manager will follow CNAME records recursively in order to determine which DNS zone to update during DNS01 challenges.
A number of different DNS providers are supported for the ACME
is a listing of available providers, their
.yaml configurations, along with
additional Kubernetes and provider specific notes regarding their usage.
cert-manager also supports out of tree DNS providers using an external webhook. Links to these supported providers along with their documentation are below:
cert-manager-webhook-oci(Oracle Cloud Infrastructure)
You can find more information on how to configure webhook providers here.
To create a new unsupported DNS provider, follow the development documentation here.