Een Let's Encrypt-wildcardcertificaat maken

Een Let’s Encrypt-wildcardcertificaat is nuttig wanneer meerdere subdomeinen met één certificaat moeten worden beveiligd, bijvoorbeeld app.example.com, vpn.example.com en portal.example.com. Dit kan praktisch zijn voor Sophos ZTNA, reverse proxies, testomgevingen of meerdere interne webdiensten.

De juiste verwachting is belangrijk: Let’s Encrypt-certificaten zijn kort geldig. Hun voordeel is niet een lange looptijd, maar gratis uitgifte en automatisering. Wanneer het certificaat handmatig via een DNS TXT-record wordt aangemaakt, moet de latere vernieuwing bewust worden gepland.

Als het certificaat rechtstreeks op Sophos Firewall voor WAF, WebAdmin of portals wordt gemaakt, is de ingebouwde firewallmethode meestal geschikter: Let’s Encrypt-certificaten op Sophos Firewall instellen. Dit artikel beschrijft de externe wildcardmethode met Certbot.

Wanneer een wildcardcertificaat zinvol is

Een wildcardcertificaat dekt één niveau onder een domein. *.example.com dekt dus portal.example.com, maar niet automatisch example.com en ook niet a.b.example.com.

• Veel subdomeinen binnen dezelfde zone: Een wildcardcertificaat kan het beheer vereenvoudigen.
• Slechts één openbare dienst: Een certificaat voor één specifiek FQDN is vaak overzichtelijker.
• Het certificaat wordt op meerdere systemen gebruikt: Een wildcardcertificaat kan praktisch zijn, maar de verspreiding van de privésleutel moet strikt worden beheerd.
• Volledig automatische vernieuwing is nodig: Plan een DNS-provider met een Certbot-plugin of een andere ACME-client.
• Sophos Firewall hoeft alleen WAF, WebAdmin of portals te beveiligen: Controleer de ingebouwde Let’s Encrypt-methode van de firewall.

Een wildcardcertificaat is op zichzelf niet veiliger. Als dezelfde privésleutel op meerdere systemen staat, neemt de impact van een compromittering toe. Daarom moet worden vastgelegd op welke systemen het certificaat is geïmporteerd en wie verantwoordelijk is voor de privésleutel.

Vereisten

Voor een wildcardcertificaat zijn nodig:

• een eigen domein of gedelegeerde subdomeinzone
• toegang tot de DNS TXT-records van het domein
• een Linux-server of beheerwerkstation met Certbot
• toestemming om Certbot met rootrechten uit te voeren
• een plan voor vernieuwing, import en opslag van de sleutel
• toegang tot het doelsysteem, zoals Sophos Central ZTNA, een reverse proxy of een firewall

Wildcardcertificaten worden gevalideerd met de DNS-01-challenge. Hiervoor wordt een TXT-record op _acme-challenge.example.com aangemaakt. Let’s Encrypt controleert dit DNS-record en geeft daarna het certificaat uit. De Let’s Encrypt-documentatie over challenge-typen beschrijft de basisvalidatiemethoden.

Certbot installeren

De Certbot-projectpagina adviseert voor veel Linux-omgevingen installatie via Snap. Op een geschikt Linux-systeem is de basisprocedure:

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

Als Certbot al via apt, dnf of een andere pakketbeheerder is geïnstalleerd, moet eerst worden gecontroleerd welk uitvoerbaar bestand daadwerkelijk wordt gebruikt. Parallelle installatiemethoden kunnen anders leiden tot een onverwachte versie of andere vernieuwingstaken dan bedoeld.

Het wildcardcertificaat handmatig maken

Voor handmatige DNS-validatie wordt Certbot uitgevoerd met --manual en --preferred-challenges dns. In dit voorbeeld moet het certificaat zowel example.com als *.example.com dekken:

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

Certbot toont vervolgens één of meer TXT-waarden. Wanneer example.com en *.example.com tegelijk worden aangevraagd, ontstaan twee afzonderlijke DNS-01-challenges. Beide waarden moeten als aparte TXT-records op _acme-challenge.example.com worden toegevoegd. Voeg het tweede record toe zonder het eerste te overschrijven.

Voordat in Certbot wordt doorgegaan, moeten minimaal de autoritatieve nameservers van het domein en een externe resolver de verwachte TXT-waarden teruggeven. Eén resolver is slechts een indicatie, omdat DNS-providers wijzigingen afhankelijk van de locatie met verschillende snelheid kunnen verspreiden.

Praktische controle:

dig TXT _acme-challenge.example.com @1.1.1.1

De autoritatieve nameservers zijn te vinden met dig NS example.com. Daarna kan hetzelfde TXT-record rechtstreeks bij een van deze servers worden opgevraagd. Verwijder na een geslaagde validatie de challenge-TXT-waarden die niet meer nodig zijn. Oude waarden maken latere controles onoverzichtelijk en kunnen bij veel records het DNS-antwoord onnodig vergroten.

• certonly: Een certificaat aanvragen of vernieuwen zonder het te installeren.
• --manual: De DNS-waarde handmatig instellen.
• --preferred-challenges dns: De DNS-01-challenge gebruiken.
• -d example.com: Het hoofddomein opnemen.
• -d '*.example.com': Het wildcarddomein opnemen.

Het hoofddomein en het wildcarddomein zijn afzonderlijke namen. Als alleen *.example.com wordt aangevraagd, wordt example.com niet automatisch opgenomen. Wanneer beide namen tegelijk worden aangevraagd, kunnen meerdere TXT-records met dezelfde naam nodig zijn. DNS ondersteunt dit, en validaties mislukken vaak juist omdat een bestaande TXT-waarde per ongeluk wordt overschreven.

De certificaatbestanden vinden

Certbot toont de werkelijke certificaatnaam, opgenomen domeinen, vervaldatum en bestandspaden met deze opdracht die alleen informatie uitleest:

sudo certbot certificates

Na een geslaagde uitgifte staan de bestanden doorgaans onder:

/etc/letsencrypt/live/example.com/

Belangrijke bestanden:

• fullchain.pem: Certificaat inclusief de intermediate certificaten.
• cert.pem: Alleen het servercertificaat.
• privkey.pem: Privésleutel.
• chain.pem: Intermediate certificaten.

Veel doelsystemen hebben fullchain.pem en privkey.pem nodig. Sommige importvensters verwachten het certificaat en de sleutel afzonderlijk, terwijl andere ook de chain vereisen. Controleer vóór de import welk formaat het doelsysteem verwacht.

⚠️ privkey.pem is de privésleutel. Dit bestand hoort niet thuis in tickets, chats, e-mail of onbeveiligde opslag. Iedereen die de privésleutel bemachtigt, kan het certificaat misbruiken.

De vernieuwing plannen

De handmatige methode met --manual is eenvoudig voor tests en eenmalige acties, maar slechts beperkt geschikt voor productiecertificaten. Zonder automatisering moet bij elke vernieuwing een nieuwe DNS TXT-waarde worden ingesteld.

Voor productie zijn er drie verstandige opties:

• DNS-plugin voor de DNS-provider: Geschikt wanneer Certbot DNS-records via een API mag bijwerken.
• Andere ACME-client met DNS-automatisering: Geschikt wanneer de provider of het platform beter door een andere client wordt ondersteund.
• Handmatige vernieuwing met een verantwoordelijke en kalenderherinnering: Alleen geschikt voor tests of zelden gebruikte certificaten.

DNS-API-gegevens zijn bijzonder gevoelig. Een DNS-token moet worden beperkt tot de benodigde zone en, waar mogelijk, tot de vereiste recordtypen. Inloggegevens met brede domeinbeheerrechten horen niet onbeveiligd op een webserver te staan.

De vernieuwing wordt normaal getest met:

sudo certbot renew --dry-run

Bij certificaten die met handmatige DNS-validatie zijn gemaakt, is deze test alleen zinvol wanneer het DNS-proces is geautomatiseerd of de handmatige hooks correct werken.

Een geslaagde vernieuwing op het Certbot-systeem werkt een eerder in Sophos Firewall, ZTNA of een reverse proxy geïmporteerd certificaat niet automatisch bij. Daarvoor is een gedocumenteerde herimport of een getest uitrolproces nodig dat alleen na een geslaagde vernieuwing wordt uitgevoerd. Na iedere uitrol worden namen, chain en nieuwe vervaldatum op het werkelijke doelsysteem gecontroleerd.

Importeren in Sophos-omgevingen

Controleer vóór import in Sophos ZTNA, een firewall, een reverse proxy of een ander Sophos-gerelateerd systeem het volgende:

• Komt de certificaatnaam overeen met de openbare hostname?
• Is naast het wildcarddomein ook het hoofddomein nodig?
• Verwacht het doelsysteem fullchain.pem of afzonderlijke certificaatonderdelen?
• Accepteert het de privésleutel of moet deze naar een ander formaat worden geconverteerd?
• Is er een gedocumenteerde procedure voor de volgende vernieuwing?
• Is bekend op welke systemen hetzelfde certificaat is geïmporteerd?

Als het certificaat alleen voor WAF, WebAdmin of portals op Sophos Firewall nodig is, is het ingebouwde proces vaak eenvoudiger omdat uitgifte en vernieuwing rechtstreeks op de firewall plaatsvinden. Voor echte wildcardcertificaten blijft de externe Certbot- of ACME-methode relevant. Certificaten importeren en toewijzen op Sophos Firewall legt daarna uit hoe de privésleutel, CA-chain en servicetoewijzing worden gecontroleerd.

Typische fouten

• De validatie mislukt: Het TXT-record is nog niet zichtbaar, de DNS-zonenaam is onjuist of een van meerdere TXT-waarden is overschreven. Controleer met dig TXT _acme-challenge.example.com @1.1.1.1.
• Het certificaat dekt example.com niet: Alleen *.example.com is aangevraagd. Voeg het hoofddomein toe met -d example.com.
• Het certificaat dekt a.b.example.com niet: De wildcard dekt slechts één subdomeinniveau. Plan een apart certificaat of een passende wildcard voor de diepere zone.
• De vernieuwing wordt niet automatisch uitgevoerd: De handmatige DNS-methode is niet geautomatiseerd. Controleer of een geschikte DNS-plugin of andere ACME-client beschikbaar is.
• Certbot vernieuwt het certificaat, maar het doelsysteem presenteert nog het oude: De herimport of het uitrolproces is niet uitgevoerd. Controleer serienummer of vervaldatum rechtstreeks op het doel.
• De import mislukt: Bestand of formaat is onjuist. Vergelijk de vereisten voor fullchain.pem, cert.pem, privkey.pem en de certificaatketen.
• Kopieën van de sleutel vormen een beveiligingsrisico: De privésleutel staat op meerdere systemen. Documenteer opslaglocaties, toegangsrechten en importpunten.

Checklist

• Domein en vereist subdomeinniveau vastgelegd.
• Hoofddomein en wildcard bewust geselecteerd.
• DNS-toegang en toestemming om TXT-records te maken beschikbaar.
• Certbot op één consistente manier geïnstalleerd.
• DNS-01-challenge met succes gevalideerd.
• Certificaatbestanden en privésleutel veilig opgeslagen.
• Doelsysteem en vereist importformaat bekend.
• Vernieuwing gepland met een verantwoordelijke, herinnering of DNS-automatisering.
• Herimport of uitrolproces naar het doelsysteem getest.
• Oude certificaten en sleutels na een geslaagde migratie gecontroleerd verwijderd.

Veelgestelde vragen