Create a Let's Encrypt wildcard certificate

A Let’s Encrypt wildcard certificate is useful when multiple subdomains need to be secured with one certificate, for example app.example.com, vpn.example.com, and portal.example.com. This can be practical for Sophos ZTNA, reverse proxies, test environments, or several internal web services.

The key expectation is that Let’s Encrypt certificates are short-lived. Their advantage is not a long validity period, but free issuance and automation. If the certificate is created manually with a DNS TXT record, its later renewal must be planned deliberately.

If the certificate is to be created directly on Sophos Firewall for WAF, WebAdmin, or portals, the built-in firewall method is usually the better choice: Set up Let’s Encrypt certificates on Sophos Firewall. This article covers the external wildcard method using Certbot.

When a wildcard certificate makes sense

A wildcard certificate covers one level below a domain. *.example.com therefore covers portal.example.com, but not example.com itself and not a.b.example.com.

• Many subdomains in the same zone: A wildcard certificate can simplify administration.
• Only one public service: A certificate for one specific FQDN is often cleaner.
• The certificate will be used on multiple systems: A wildcard certificate can be practical, but distribution of the private key must be tightly controlled.
• Fully automated renewal is required: Plan for a DNS provider with a Certbot plugin or another ACME client.
• Sophos Firewall only needs to secure WAF, WebAdmin, or portals: Check the built-in Let’s Encrypt method on the firewall.

A wildcard certificate is not inherently more secure. If the same private key is stored on several systems, the impact of a key compromise increases. It should therefore be documented where the certificate was imported and who is responsible for the private key.

Requirements

A wildcard certificate requires:

• a domain or delegated subdomain zone under your control
• access to the domain’s DNS TXT records
• a Linux server or administration workstation with Certbot
• permission to run Certbot with root privileges
• a plan for renewal, import, and key storage
• access to the target system, such as Sophos Central ZTNA, a reverse proxy, or a firewall

Wildcard certificates are validated through the DNS-01 challenge. A TXT record is created at _acme-challenge.example.com. Let’s Encrypt checks this DNS record and then issues the certificate. The Let’s Encrypt challenge types documentation explains the basic validation methods.

Install Certbot

The Certbot project page recommends Snap installation for many Linux environments. On a suitable Linux system, the basic procedure is:

sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

If Certbot was already installed through apt, dnf, or another package manager, first check which executable is actually being used. Parallel installation methods can otherwise result in an unexpected version or renewal job.

Create the wildcard certificate manually

For manual DNS validation, run Certbot with --manual and --preferred-challenges dns. In this example, the certificate must cover both example.com and *.example.com:

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d '*.example.com'

Certbot then displays one or more TXT values. When example.com and *.example.com are requested together, they produce two separate DNS-01 challenges. Both values must be added as separate TXT records at _acme-challenge.example.com. Add the second record without overwriting the first.

Before continuing in Certbot, verify that at least the domain’s authoritative name servers and an external resolver return the expected TXT values. One resolver is only an indication because DNS providers may distribute changes at different speeds depending on location.

Practical check:

dig TXT _acme-challenge.example.com @1.1.1.1

The authoritative name servers can be found with dig NS example.com. The same TXT record can then be queried directly from one of those servers. After successful validation, remove challenge TXT values that are no longer needed. Old values make later checks harder to understand and can unnecessarily enlarge the DNS response when many records accumulate.

• certonly: Obtain or renew a certificate without installing it.
• --manual: Set the DNS value manually.
• --preferred-challenges dns: Use the DNS-01 challenge.
• -d example.com: Include the root domain.
• -d '*.example.com': Include the wildcard domain.

The root domain and wildcard domain are separate names. If only *.example.com is requested, example.com is not included automatically. When both names are requested together, multiple TXT records with the same name may be required. DNS supports this, and validation often fails at this exact point because an existing TXT value is overwritten accidentally.

Find the certificate files

Certbot shows the actual certificate name, included domains, expiry date, and file paths with this read-only command:

sudo certbot certificates

After successful issuance, the files are typically stored under:

/etc/letsencrypt/live/example.com/

Important files:

• fullchain.pem: Certificate including the intermediate certificates.
• cert.pem: Server certificate only.
• privkey.pem: Private key.
• chain.pem: Intermediate certificates.

Many target systems require fullchain.pem and privkey.pem. Some import dialogs expect the certificate and private key separately, while others also require the chain. Confirm the format expected by the target system before importing.

⚠️ privkey.pem is the private key. It must not be placed in tickets, chats, email, or unprotected storage. Anyone who obtains the private key can misuse the certificate.

Plan renewal

The manual --manual method is convenient for tests and one-off operations, but is only partly suitable for production certificates. Without automation, a new DNS TXT value must be set for every renewal.

There are three sensible approaches for production use:

• DNS plugin for the DNS provider: Suitable when Certbot may update DNS records through an API.
• Another ACME client with DNS automation: Suitable when the provider or platform has better support elsewhere.
• Manual renewal with an owner and calendar reminder: Appropriate only for tests or rarely used certificates.

DNS API credentials are particularly sensitive. A DNS token should be restricted to the required zone and, where possible, to the required record types. Broad domain-administrator credentials should not be stored unprotected on a web server.

A renewal test is normally performed with:

sudo certbot renew --dry-run

For certificates created with manual DNS validation, this test is only meaningful when the DNS process is automated or the manual hooks work correctly.

A successful renewal on the Certbot system does not automatically update a certificate previously imported into Sophos Firewall, ZTNA, or a reverse proxy. This requires either a documented reimport or a tested deployment process that runs only after a successful renewal. After every rollout, verify the certificate names, chain, and new expiry date on the actual target system.

Import into Sophos environments

Before importing the certificate into Sophos ZTNA, a firewall, a reverse proxy, or another Sophos-related system, check the following:

• Does the certificate name match the public hostname?
• Is the root domain required in addition to the wildcard?
• Does the target system expect fullchain.pem or separate certificate components?
• Does it accept the private key, or must the key be converted to another format?
• Is there a documented process for the next renewal?
• Is it clear on which systems the same certificate was imported?

If only WAF, WebAdmin, or portals on Sophos Firewall need the certificate, the built-in firewall process is often easier because issuance and renewal take place directly on the firewall. For genuine wildcard certificates, the external Certbot or ACME method remains relevant. Import and assign certificates on Sophos Firewall explains how to check the private key, CA chain, and service assignment afterwards.

Typical errors

• Validation fails: The TXT record is not visible yet, the DNS zone name is wrong, or one of several TXT values was overwritten. Check with dig TXT _acme-challenge.example.com @1.1.1.1.
• The certificate does not cover example.com: Only *.example.com was requested. Add the root domain with -d example.com.
• The certificate does not cover a.b.example.com: The wildcard covers only one subdomain level. Plan a separate certificate or a suitable wildcard for the deeper zone.
• Renewal does not run automatically: The manual DNS method has no automation. Check for a suitable DNS plugin or another ACME client.
• Certbot renews the certificate, but the target still presents the old one: The reimport or deployment process did not run. Check the serial number or expiry date directly on the target system.
• Import fails: The file or format is wrong. Compare the requirements for fullchain.pem, cert.pem, privkey.pem, and the certificate chain.
• Key copies create a security risk: The private key is stored on multiple systems. Document its storage, access permissions, and import locations.

Checklist

• Domain and required subdomain level defined.
• Root domain and wildcard selected deliberately.
• DNS access and permission to create TXT records available.
• Certbot installed consistently.
• DNS-01 challenge validated successfully.
• Certificate files and private key stored securely.
• Target system and required import format known.
• Renewal planned with an owner, calendar reminder, or DNS automation.
• Reimport or deployment process to the target system tested.
• Old certificates and keys removed in a controlled manner after a successful migration.

FAQ