Create Let's Encrypt wildcard certificate

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

What is important is the expectation: Let’s Encrypt certificates are short-lived. The advantage lies not in the long term, but in free issuance and automation. If the certificate is created manually using a DNS TXT entry, subsequent renewal must be planned consciously.

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

When a wildcard certificate makes sense

A wildcard certificate covers one level below a domain. So *.example.com fits for portal.example.com, but not automatically for example.com itself and also not for a.b.example.com.

• Many subdomains under the same zone: Wildcard certificate can simplify administration.
• Just a single public service: single FQDN certificate is often cleaner.
• Certificate should be used on multiple systems: Wildcard certificate can be practical, but strictly control key distribution.
• Fully automatic renewal required: Schedule DNS provider with Certbot plugin or other ACME client.
• Sophos Firewall is only intended to secure WAF/WebAdmin/Portals: Built-in firewall Let’s Encrypt check.

A wildcard certificate is not a security gain in itself. In fact, if the same private key is on multiple systems, the impact of a key loss increases. Therefore, it should be documented where the certificate was imported and who manages the private key.

Requirements

For a wildcard certificate you need:

• your own domain or subdomain zone
• Access to DNS TXT records of the domain
• a Linux server or admin computer with Certbot
• Permission to run Certbot with root privileges
• a plan for renewal, import and key storage
• Access to the target system, for example Sophos Central ZTNA, reverse proxy or firewall

Wildcard certificates are validated via the DNS-01 Challenge. A TXT record is set under _acme-challenge.example.com. Let’s Encrypt checks this DNS entry and then issues the certificate. Let’s Encrypt describes the basic challenge types in the Challenge Types documentation.

Install Certbot

The Certbot project page recommends installing via Snap for many Linux environments. On a suitable Linux system, the basic process looks like this:

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

If Certbot has already been installed via apt, dnf or another package, you should check beforehand which Certbot is actually being used. Otherwise, multiple parallel installation paths quickly lead to incorrect versions or unexpected renewal jobs.

Create wildcard certificate manually

For manual DNS validation, Certbot can be started with --manual and --preferred-challenges dns. In the example, the certificate should apply to 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. If example.com and *.example.com are requested at the same time, Certbot creates two separate DNS-01 challenges. Both TXT values must be added as separate TXT records under _acme-challenge.example.com. Add the second record in addition to the first one; do not overwrite it.

Only when all DNS entries are visible worldwide should you confirm in Certbot and continue the validation.

Practical check:

dig TXT _acme-challenge.example.com @1.1.1.1

• certonly: Apply for or renew a certificate without installing it.
• --manual: DNS value is set manually.
• --preferred-challenges dns: Use DNS-01 Challenge.
• -d example.com: Add additional root domain.
• -d '*.example.com': Include wildcard domain.

The root domain and the wildcard domain are separate names. If only *.example.com is requested, example.com itself is not automatically included. If both names are requested at the same time, multiple TXT records with the same name may be required. This is allowed in DNS and is exactly where validations often fail because an existing TXT value is accidentally replaced.

Find certificate files

After successful issuance, the files are typically located at:

/etc/letsencrypt/live/example.com/

Important files:

• fullchain.pem: Certificate including intermediate certificates.
• cert.pem: just the server certificate.
• privkey.pem: private key.
• chain.pem: Intermediate certificates.

Many target systems require fullchain.pem and privkey.pem. Some import masks require the certificate and key separately, others also require the chain. Before importing, it should be clear which format the target system expects.

⚠️ privkey.pem is the private key. This file must not end up in tickets, chats, emails or insecure storage. Anyone who has the private key can misuse the certificate.

Plan renewal

The manual --manual method is easy for tests and individual actions, but is only partially suitable for productive certificates. Without automation, a new DNS TXT record must be set each time it is renewed.

There are three clean variants for productive use:

• DNS plugin for the DNS provider: if Certbot is allowed to set DNS records via API.
• another ACME client with DNS automation: if the provider or platform is better supported.
• manual renewal with calendar and owner: only for tests or rarely used certificates.

When DNS API access is used, API credentials are particularly critical. A DNS token should only be allowed to change the necessary zone and, if possible, only the necessary record types. Wide domain admin access does not belong unprotected on a web server.

A renewal test is usually checked with Certbot like this:

sudo certbot renew --dry-run

For manually created DNS certificates, this test is only meaningful if the DNS process is also automated or the manual hooks work properly.

Import into Sophos environments

If the certificate is used for Sophos ZTNA, a firewall, a reverse proxy or another Sophos-related system, you should check these points before importing:

• 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?
• Is the private key accepted or does it need to 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?

When it comes to just WAF, WebAdmin or portals on Sophos Firewall, the built-in firewall process is often simpler because creation and renewal takes place directly on the firewall. However, the external Certbot or ACME route remains relevant for real wildcard certificates.

Typical errors

• Validation fails: TXT record not yet visible, incorrect DNS zone name, or one of multiple TXT values was overwritten. dig TXT _acme-challenge.example.com @1.1.1.1 check.
• Certificate does not apply to example.com: only *.example.com requested. Add root domain additionally with -d example.com.
• Certificate does not apply to a.b.example.com: Wildcard only covers one subdomain level. plan your own certificate or suitable wildcard for a deeper zone.
• Renewal does not work automatically: manual DNS way without automation. Check DNS plugin or other ACME client.
• Import fails: wrong file or format. fullchain.pem, cert.pem, privkey.pem and compare chain request.
• Security risk due to key copies: private key is on multiple systems. Document storage, access and import locations.

Checklist

• Domain and subdomain level set.
• Root domain and wildcard deliberately selected.
• DNS access and TXT record permission available.
• Certbot installed cleanly.
• DNS-01 Challenge successfully checked.
• Certificate files and private key stored securely.
• Target system and required import format known.
• Renewal scheduled with Owner, Calendar or DNS automation.
• Old certificates and keys are removed in a controlled manner after successful conversion.

FAQ