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.

A wildcard certificate is required for a Sophos ZTNA gateway. Sophos Central can create this certificate and then manage and renew it. Alternatively, it can be created with Certbot as described in this article and uploaded as a custom certificate. 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.

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
• for Sophos Central, permission to create and modify the required CNAME record in DNS
• for the manual Certbot method, permission to create and modify the domain’s DNS TXT records
• for the manual method, a Linux server or administration workstation with Certbot
• for the manual method, permission to run Certbot with root privileges
• a renewal, import, and key-storage plan appropriate for the chosen method
• access to the target system, such as Sophos ZTNA in Sophos Fusion, a reverse proxy, or a firewall

Wildcard certificates are validated through the DNS-01 challenge. With the manual Certbot method, a TXT record is created at _acme-challenge.example.com. With the managed Sophos Central method, a CNAME record delegates this validation to Sophos. The Let’s Encrypt challenge types documentation explains the basic challenge types.

For Sophos ZTNA: Create the certificate in Sophos Central

For a ZTNA gateway, the managed method in Sophos Central is usually easier than a manual Certbot process: Sophos creates the Let’s Encrypt certificate and then takes care of its management and renewal. The gateway domain must be known, and access to its DNS provider is required.

If the DNS zone uses CAA records, Let’s Encrypt must be authorized there as a certificate authority. Otherwise, Let’s Encrypt cannot issue a certificate even when domain validation succeeds.

1. In Sophos Central, open My Products > ZTNA and click Settings.
2. Open Domains and certificates and click Add domain. Sophos allows up to 100 domains here. Enter the domain in the format example.com and add it.
3. Sophos generates a CNAME value for this domain. Create it with the DNS provider at _acme-challenge.example.com. Replace example.com with your own gateway domain.
4. Return to Domains and certificates, click Validate, and confirm that the CNAME record has been created. Sophos uses it to verify control of the domain.
5. After successful validation, click Generate LE certificate, read and accept the Let’s Encrypt Subscriber Agreement, and start generation. According to Sophos, this takes about 60 seconds; you can leave the page while it runs.

⚠️ If a TXT record already exists at _acme-challenge.example.com, it must be removed to use the CNAME record required by Sophos. First check whether another application needs that TXT record. The CNAME record must then remain in DNS.

For domains already present in Sophos Central, the procedure depends on their validation status:

• Already validated using a DNS TXT record:
  1. Under My Products > ZTNA > Settings > Domains and certificates, click Generate LE certificate.
  2. Under Add CNAME, copy the CNAME record and create it with the DNS provider at _acme-challenge.example.com.
  3. Remove any existing TXT record there only after performing the impact check described above.
  4. Confirm that the CNAME record has been created.
  5. Accept the Let’s Encrypt Subscriber Agreement and click Continue.
  6. Complete certificate generation and, under Domains and certificates, verify that the domain and its CNAME record are displayed in the new format.
• Not yet validated: Remove the existing domain, add it again using Add domain, validate it with Validate, and then create the Let’s Encrypt certificate using Generate LE certificate.

Sophos creates only one Let’s Encrypt certificate per Central account. It contains all validated domains. If another domain is validated later, the certificate must be generated again to include it.

To associate the certificate with an existing gateway, open My Products > ZTNA > Gateways, select the gateway, and set Domain and certificate to Automatic (Let’s Encrypt). Save the change, then check the certificate validity and expiration date on the gateway. If validation or generation has not yet completed successfully, do not switch the gateway to the new certificate; first check the CNAME record with the authoritative DNS provider.

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?

For Sophos ZTNA, assign the certificate created with Certbot to the gateway in Sophos Central: open My Products > ZTNA > Gateways, click the gateway name, and under Domain and certificate select Upload custom certificate. Upload the generated certificate and click Save. Then check its validity and expiration date on the gateway; a certificate that is about to expire must be renewed, uploaded again, and checked again on the gateway.

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 externally managed wildcard certificates, the 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.
• For Sophos Central: DNS access and permission for the required CNAME record available.
• For the manual Certbot method: DNS access and permission for TXT records available.
• Issuance through Sophos Central or an external ACME client deliberately selected.
• Certbot installed consistently for the manual method.
• Domain validation using the Sophos CNAME or the manual DNS-01 challenge completed successfully.
• For the external method, certificate files and private key stored securely.
• For the external method, target system and required import format known.
• Renewal planned through Sophos Central or with an owner, calendar reminder, or DNS automation.
• For the external method, reimport or deployment process to the target system tested.
• Old certificates and keys removed in a controlled manner after a successful migration.

FAQ