Certbot · Wildcard · Help

Certbot: wildcard certificates fail with --standalone

Identify the unsupported authenticator combination and plan a renewable DNS challenge for your wildcard certificate.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

Certbot's HTTP standalone authenticator cannot validate a wildcard certificate. Wildcards require DNS-01, so freeing an HTTP port will not remove this limitation. First check whether the requested names really need a wildcard and inspect the authenticator stored in the certificate configuration. Then select a suitable DNS integration with limited credentials and verify that future renewal can run without manual intervention.

Source basis: Q1 · Q2 · Q3

Applies to
Covers Let's Encrypt wildcard names and Certbot authentication methods. The original report used Certbot 5.8.0; the DNS-01 requirement is documented independently.
How to verify the result
The certificate covers the intended names, a representative renewal test succeeds without manual TXT entry, and the consuming service loads the correct certificate.
Your first check

Does the certificate request include a wildcard name?

Compare the requested names with the authenticator. A wildcard requires DNS-01; HTTP standalone cannot provide that proof.

You request a certificate for a domain and *.example.com using --standalone. Certbot says that the selected authenticator does not support the necessary combination of challenges. That exact kind of command appears in the original report. It establishes an unsupported combination, not a demonstrated port conflict or DNSSEC failure. Q1

Why the command cannot succeed

HTTP-01 does not support wildcard issuance; DNS-01 provides the appropriate challenge type. Q2 Opening additional web-server ports cannot make an HTTP standalone authenticator satisfy the wildcard requirement. First decide which hostnames the certificate actually needs to cover.

Build a request that can be maintained

  1. Review the requested names. List every name, including the base domain and wildcard. Determine whether arbitrary subdomains are required or whether a finite set of individual hosts would meet the service requirement. That decision affects both validation and ongoing maintenance.
  2. Inspect existing renewal configuration. If a certificate already exists, identify its stored authenticator and installation method. A new command copied into a terminal does not describe how the existing certificate was originally configured. Preserve the current files while investigating.
  3. Identify the DNS operator and permissions. Establish who controls the challenge record and whether a maintained plugin supports that provider. Give an API credential only the rights needed for the intended operation. Do not paste credentials into support forms or public logs.
  4. Run a controlled DNS test. In an appropriate test environment, observe the expected TXT value and its management throughout the run. Check for parallel certificate jobs using the same name. Successfully adding a record by hand does not demonstrate that the next renewal will be automatic.
  5. Connect issuance to deployment. After a successful issuance, check the included names, expiry and certificate actually served by the application. Plan renewal and any targeted reload together. Certbot documents separate authenticators, installers and hooks for these responsibilities. Q3

If you cannot change DNS

Establish who owns that responsibility before attempting more certificate orders. If only specific hostnames are required, an appropriate HTTP challenge may be an alternative for those names. Reducing the requested coverage changes the service design and should be an explicit decision. Repeating an identical wildcard standalone request will not resolve the underlying mismatch.

For handoff, prepare the sanitised name list, command, DNS provider, current renewal method and destination service. Keep the intended coverage separate from what the failing request currently contains. This makes it possible to choose a repair without unexpectedly excluding an application hostname.

Frequently asked questions

Do I need to stop Apache or nginx?

Not to resolve this wildcard/authenticator mismatch. A web-server interruption does not answer the DNS challenge requirement.

Is one manually created TXT record enough?

It may allow a single validation. Unattended future renewals require a deliberate automated process that handles each new challenge.

Describe your case

Support with this issue

We can prepare the DNS challenge, permissions and renewal process for your domains.

Describe your case →Related service: Data & improvements

Sources