Set up a wildcard certificate with ACME DNS-01 validation, not HTTP-01. Your ACME client proves control of the domain by publishing a token-derived TXT record at _acme-challenge.example.com; the certificate authority then issues a certificate for names such as *.example.com. DNS-01 does not require the server to accept inbound connections on port 80, so it works for private, firewalled, or non-web services.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Plan the certificate around the names you actually serve. A certificate containing only *.example.com covers one-label hosts such as game.example.com, but it does not cover the apex example.com or deeper names such as panel.game.example.com. Request the apex and wildcard together when both are needed, then install the resulting certificate and private key on every dependent service and reload those services after each renewal.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsWhat a wildcard certificate covers
A wildcard certificate uses a name beginning with an asterisk to cover multiple hostnames below one DNS name. For example, *.example.com can authenticate games.example.com, status.example.com, and api.example.com. The wildcard replaces exactly one label. It does not match example.com itself, and it does not match a two-level name such as node.eu.example.com.
That boundary matters on a self-hosted server. If players connect to example.com as well as play.example.com, include both names in the certificate request. Certbot’s instructions explicitly distinguish the apex from the wildcard: the wildcard name alone does not cover the base domain.
#1 Best Overall
One wildcard certificate can simplify certificate distribution across several subdomains, but every service using it also depends on the same private key. Treat that key as a high-value secret and decide whether the operational convenience outweighs the impact of a compromise. For services with different trust boundaries, separate certificates can reduce blast radius.
Why DNS-01 is the required challenge
ACME validation is the proof that you control a domain. Let’s Encrypt’s challenge documentation states that HTTP-01 cannot issue wildcard certificates, while DNS-01 can issue them: Let’s Encrypt challenge types. DNS-01 works by having the client publish a TXT value derived from the authorization token at _acme-challenge.<YOUR_DOMAIN>. The certificate authority queries DNS and continues when it finds the expected value.
| Characteristic | HTTP-01 | DNS-01 |
|---|---|---|
| Wildcard issuance | Not supported | Supported |
| Validation location | HTTP resource served by the domain | TXT record under _acme-challenge |
| Inbound port 80 required | Normally yes, because the authority connects to the web server | No; the authority validates DNS instead |
| Useful for private or firewalled services | Often impractical | Yes, provided public DNS can be updated |
| Unattended renewal | Requires a reachable HTTP challenge path | Requires repeatable DNS record automation |
DNS-01 therefore solves two common self-hosting constraints at once: it is the only Let’s Encrypt validation method for a wildcard, and it does not require exposing the application server on port 80. Port 80 may still be useful for ordinary HTTP-to-HTTPS redirects, but it is not needed for the DNS-01 proof itself. The Certbot wildcard instructions describe the same distinction.
What you need before requesting the certificate
- A registered domain and authoritative DNS access. You must be able to create TXT records in the zone that contains the name being validated.
- A DNS provider with an API or a narrowly scoped authentication hook. Automated renewal requires the client to create and remove challenge records repeatedly without a person clicking through a dashboard.
- An ACME client. Certbot and acme.sh both support DNS-based workflows. Certbot’s documentation identifies DNS plugins as the wildcard method: Certbot usage documentation.
- Administrative access to the server. The client must write certificate files, and the web server must be able to read the installed certificate and key.
- A list of every hostname you intend to serve. Decide whether you need the apex, one wildcard, several wildcards, or additional explicit names before issuance.
- A reload mechanism for each dependent service. A renewed file on disk does not change the certificate held by a running process until that process reloads or restarts.
Use a DNS API token limited to the required zone and record-management actions whenever your provider supports that scope. Do not give an ACME client broad account credentials when a zone-specific token is available. Store the token outside source repositories and restrict its file permissions just as you would for the private key.
Choose an automation approach
| Approach | DNS API needed | Credential scope | Renewal suitability | Operational concern |
|---|---|---|---|---|
| Certbot DNS plugin | Yes | Provider-specific token or credentials file | Good when the plugin and credentials remain available | Use certonly for files only, or an installer plugin where supported |
| acme.sh DNS integration | Yes, through the selected provider integration | Provider environment variables or configuration | Good when paired with --install-cert and a reload hook |
Provider syntax differs; verify the integration before scheduling renewal |
| Manual TXT entry | No API, but a person must edit DNS | Human dashboard access | Poor for unattended renewal | Every renewal pauses for a new token and is easy to miss |
| Delegated or custom authentication hook | Depends on the hook | Can be narrowly limited if designed carefully | Possible, but requires maintaining the hook | Test creation, cleanup, propagation, and failure handling |
For a server that must renew without supervision, select the first or second approach only after confirming that it can update the authoritative DNS zone and that the client can run with the same credentials from its scheduler.
Request the wildcard with Certbot
1. Install Certbot and the DNS plugin
Install Certbot using your operating system’s package method, then install the DNS plugin matching your provider. Plugin package names and installation commands vary by distribution and provider, so use the provider-specific instructions linked from the Certbot documentation. Do not proceed with a generic HTTP plugin: HTTP-01 cannot issue a wildcard.
2. Create a restricted credentials file
Save the provider token in a root-owned file outside your web directory. A typical Linux setup is:
sudo install -m 600 /path/to/provider-credentials.ini /etc/letsencrypt/dns-provider.iniThe exact file format is defined by the DNS plugin. Check that the ACME client can read it, while ordinary users and the web server’s public document root cannot.
3. Request the apex and wildcard names
Use certonly when you want Certbot to obtain and maintain certificate files without changing your web-server configuration. Replace the provider placeholder with the actual plugin name and use your real domain:
sudo certbot certonly --dns-<provider> --dns-<provider>-credentials /etc/letsencrypt/dns-provider.ini -d example.com -d '*.example.com' -m [email protected] --agree-tosThe two -d options are intentional. The first covers the apex; the second covers one-label subdomains. Add another -d for a specific host that is outside the wildcard’s one-label scope. Certbot will ask the DNS plugin to create a TXT record at _acme-challenge.example.com, wait for the authority to observe it, and complete issuance after the value matches.
4. Confirm the issued files
Certbot normally places managed files under /etc/letsencrypt/live/<certificate-name>/, including the private key and full chain. The exact certificate-name directory depends on the names and any prior certificates on the machine, so inspect the path reported by the command rather than assuming a directory name. Keep the private key readable only by root or the service account that must load it.
Use acme.sh instead
acme.sh is another ACME client with DNS integrations. Its provider-specific authentication variables and command options differ, so configure the integration documented by the project before issuing. The general flow is an issue command containing both the apex and wildcard, followed by an installation command that copies the key and full chain to stable service paths.
acme.sh --issue --dns <provider> -d example.com -d '*.example.com'After issuance, use --install-cert and provide a reload command. A representative Nginx installation looks like this; substitute paths that are writable by the client and readable by Nginx:
acme.sh --install-cert -d example.com --key-file /etc/ssl/private/example.key --fullchain-file /etc/ssl/certs/example.fullchain.pem --reloadcmd 'systemctl reload nginx'The acme.sh project calls the reload hook important because renewal is incomplete if new files are copied but the running server continues using the old certificate: acme.sh installation and reload documentation.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Install the certificate on Nginx
Point Nginx at the full chain and its matching private key in the TLS-enabled server block. The full chain should be presented to clients; the private key must never be placed in the public document root.
server {
listen 443 ssl;
server_name example.com *.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:8080;
}
}Nginx’s HTTPS configuration reference documents the certificate and key directives: Nginx configuring HTTPS. The server_name line controls which virtual host handles a request; it does not expand the certificate’s coverage. Ensure every hostname sent by clients is either covered by the certificate or handled by another certificate and server block.
Validate before reloading
- Check the configuration syntax:
sudo nginx -t. - If the test succeeds, reload without dropping existing connections:
sudo systemctl reload nginx. - Inspect the service status and error log if the reload fails.
- Connect to each important hostname and verify that the served certificate contains the expected names and that the chain is complete.
For Apache or another TLS terminator, use that server’s equivalent certificate, key, full-chain, syntax-test, and graceful-reload settings. The principle is unchanged: install the matching files, validate configuration, then reload every process that terminates TLS.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Automate renewal correctly
ACME certificates must be renewed before they expire, and wildcard renewal repeats the DNS-01 process. Certbot’s renew action checks managed certificates that are approaching expiry and reuses the plugin and options originally selected. It will not magically convert a manually completed TXT challenge into unattended automation. Certbot’s FAQ notes that manual certificates do not renew automatically unless an authentication hook is supplied: Certbot FAQ.
- Keep the DNS credentials available to the scheduler. The scheduled process must be able to create the TXT record without interactive input.
- Run the client’s renewal action. For Certbot, schedule or enable the packaged service or timer and use
certbot renew. For acme.sh, use its managed scheduler and the certificate’s installation configuration. - Reload after successful renewal. Certbot can run a deploy or post-renewal hook; acme.sh uses
--reloadcmd. The hook should reload only after new files have been written. - Test the complete path. Use the client’s staging or dry-run facility where available, then confirm that DNS creation, validation, file installation, reload, and the externally served certificate all work.
- Monitor failures. Send scheduler output or service logs somewhere you will notice. An unreported DNS API failure can leave the old certificate serving until expiry.
| Renewal stage | What must succeed | What to verify |
|---|---|---|
| Authentication | Client can read the DNS token | Credential file permissions and scheduler environment |
| DNS update | TXT record is created under _acme-challenge |
Authoritative DNS shows the new value |
| Issuance | ACME authority matches the token | Client reports a renewed certificate rather than a skipped one |
| Installation | New key and full chain replace or update service paths | File timestamps, ownership, and permissions |
| Activation | TLS service reloads successfully | External connection serves the new certificate |
Common failures and fixes
The client says the TXT record is missing
Check that the record was created in the authoritative zone, not in a similarly named delegated or secondary zone. Confirm the exact label: the challenge is beneath _acme-challenge, not the ordinary web host. DNS publication can take time; allow the client to wait for propagation rather than deleting the record immediately. If your provider’s API token cannot edit the zone, issue a new narrowly scoped token with the required DNS-record permission.
The request uses HTTP-01 and rejects the wildcard
Switch to the provider’s DNS plugin or a DNS authentication hook. Let’s Encrypt explicitly says HTTP-01 cannot issue wildcard certificates, so opening port 80 will not turn an HTTP challenge into a wildcard-capable method.
The certificate works for a subdomain but not the base domain
Inspect the certificate’s subject alternative names. If it contains only *.example.com, request a replacement containing both example.com and *.example.com. A wildcard never implicitly includes the apex.
The files are renewed but clients still see the old certificate
The running TLS process has not reloaded, or the reload hook points at the wrong service. Run the configuration test manually, reload the actual TLS terminator, and connect again from outside the server. If several services share the certificate, reload each one or install separate deploy hooks for each service.
Nginx refuses to start after installation
Run nginx -t and read the reported file path and line. Common causes are a key that does not match the certificate, a path that the Nginx worker cannot read, an incomplete full-chain file, or a syntax error introduced while editing the server block. Restore the last known-good configuration, correct ownership and permissions, test again, and reload only after the test passes.
Renewal works interactively but fails on schedule
Compare the scheduler’s environment with your interactive shell. Provider API variables may not be loaded, the credentials file may be inaccessible, or the scheduled account may lack permission to install files and reload the service. Use an absolute path to credentials and commands, then run a dry run under the same account and scheduler context.
Operational checklist
- Use DNS-01 for every wildcard request.
- Verify the DNS API can edit the authoritative zone containing
_acme-challenge. - Restrict the API token and protect its file.
- Request the apex separately when clients use the apex.
- Remember that the wildcard covers one label only.
- Use
certonlywhen you want to manage Nginx configuration yourself; use an installer integration only when you understand its edits. - Store the full chain and matching private key at stable, protected paths.
- Run a syntax check before every reload.
- Configure a deploy or reload hook for every TLS-terminating service.
- Perform a renewal dry run and verify the certificate from an external client before relying on unattended operation.
The durable setup is not merely “a wildcard certificate exists.” It is a tested chain from restricted DNS credentials, through DNS-01 validation and renewal, to protected files and a successful reload on every service that presents the certificate.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
