Skapa ett wildcard-certifikat med Let's Encrypt

Ett Let’s Encrypt wildcard-certifikat är användbart när flera underdomäner ska skyddas med ett gemensamt certifikat, till exempel app.example.com, vpn.example.com och portal.example.com. Det kan vara praktiskt för Sophos ZTNA, reverse proxy-servrar, testmiljöer eller flera interna webbtjänster.

Det är viktigt att ha rätt förväntningar: Let’s Encrypt-certifikat har kort giltighetstid. Fördelen är inte lång giltighet, utan kostnadsfri utfärdning och automatisering. Om certifikatet skapas manuellt med en DNS TXT-post måste den kommande förnyelsen planeras medvetet.

Om certifikatet ska skapas direkt på Sophos Firewall för WAF, WebAdmin eller portaler är brandväggens inbyggda metod oftast lämpligare: Konfigurera Let’s Encrypt-certifikat på Sophos Firewall. Den här artikeln beskriver den externa wildcard-metoden med Certbot.

När ett wildcard-certifikat är lämpligt

Ett wildcard-certifikat täcker en nivå under en domän. *.example.com täcker därför portal.example.com, men inte automatiskt example.com och inte heller a.b.example.com.

• Många underdomäner i samma zon: Ett wildcard-certifikat kan förenkla administrationen.
• Endast en publik tjänst: Ett certifikat för ett specifikt FQDN är ofta tydligare.
• Certifikatet ska användas på flera system: Ett wildcard-certifikat kan vara praktiskt, men distributionen av den privata nyckeln måste kontrolleras strikt.
• Helt automatisk förnyelse krävs: Planera för en DNS-leverantör med Certbot-plugin eller en annan ACME-klient.
• Sophos Firewall ska bara skydda WAF, WebAdmin eller portaler: Kontrollera brandväggens inbyggda Let’s Encrypt-metod.

Ett wildcard-certifikat är inte i sig säkrare. Om samma privata nyckel lagras på flera system ökar konsekvensen av en kompromettering. Det bör därför dokumenteras på vilka system certifikatet har importerats och vem som ansvarar för den privata nyckeln.

Förutsättningar

För ett wildcard-certifikat behövs:

• en egen domän eller delegerad underdomänzon
• åtkomst till domänens DNS TXT-poster
• en Linux-server eller administratörsdator med Certbot
• behörighet att köra Certbot med root-rättigheter
• en plan för förnyelse, import och nyckellagring
• åtkomst till målsystemet, till exempel Sophos Central ZTNA, en reverse proxy eller en brandvägg

Wildcard-certifikat valideras med DNS-01-challenge. En TXT-post skapas på _acme-challenge.example.com. Let’s Encrypt kontrollerar DNS-posten och utfärdar sedan certifikatet. Let’s Encrypt-dokumentationen om challenge-typer beskriver de grundläggande valideringsmetoderna.

Installera Certbot

Certbots projektsida rekommenderar installation via Snap för många Linux-miljöer. På ett lämpligt Linux-system är grundproceduren:

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

Om Certbot redan har installerats via apt, dnf eller en annan pakethanterare bör det först kontrolleras vilken körbar fil som faktiskt används. Parallella installationsmetoder kan annars leda till att en oväntad version eller andra förnyelsejobb än de avsedda används.

Skapa wildcard-certifikatet manuellt

För manuell DNS-validering körs Certbot med --manual och --preferred-challenges dns. I det här exemplet ska certifikatet täcka både example.com och *.example.com:

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

Certbot visar sedan ett eller flera TXT-värden. När example.com och *.example.com begärs tillsammans skapas två separata DNS-01-challenges. Båda värdena måste läggas till som separata TXT-poster på _acme-challenge.example.com. Lägg till den andra posten utan att skriva över den första.

Innan processen fortsätter i Certbot bör åtminstone domänens auktoritativa namnservrar och en extern resolver returnera de förväntade TXT-värdena. En enda resolver är bara en indikation, eftersom DNS-leverantörer kan sprida ändringar olika snabbt beroende på plats.

Praktisk kontroll:

dig TXT _acme-challenge.example.com @1.1.1.1

De auktoritativa namnservrarna kan hittas med dig NS example.com. Därefter kan samma TXT-post frågas direkt från en av dessa servrar. Ta bort challenge-TXT-värden som inte längre behövs efter en lyckad validering. Gamla värden gör senare kontroller otydliga och kan, om många poster samlas, göra DNS-svaret onödigt stort.

• certonly: Hämta eller förnya ett certifikat utan att installera det.
• --manual: Ställa in DNS-värdet manuellt.
• --preferred-challenges dns: Använda DNS-01-challenge.
• -d example.com: Inkludera rotdomänen.
• -d '*.example.com': Inkludera wildcard-domänen.

Rotdomänen och wildcard-domänen är separata namn. Om endast *.example.com begärs inkluderas inte example.com automatiskt. När båda namnen begärs samtidigt kan flera TXT-poster med samma namn behövas. DNS stöder detta, och valideringen misslyckas ofta just för att ett befintligt TXT-värde skrivs över av misstag.

Hitta certifikatfilerna

Certbot visar det faktiska certifikatnamnet, inkluderade domäner, utgångsdatum och filsökvägar med det här kommandot som endast läser information:

sudo certbot certificates

Efter en lyckad utfärdning finns filerna vanligtvis under:

/etc/letsencrypt/live/example.com/

Viktiga filer:

• fullchain.pem: Certifikatet inklusive mellanliggande certifikat.
• cert.pem: Endast servercertifikatet.
• privkey.pem: Privat nyckel.
• chain.pem: Mellanliggande certifikat.

Många målsystem kräver fullchain.pem och privkey.pem. Vissa importdialoger förväntar sig certifikatet och nyckeln separat, medan andra även kräver kedjan. Kontrollera vilket format målsystemet förväntar sig före importen.

⚠️ privkey.pem är den privata nyckeln. Filen får inte placeras i ärenden, chattar, e-post eller osäker lagring. Den som får tag på den privata nyckeln kan missbruka certifikatet.

Planera förnyelsen

Den manuella metoden med --manual är enkel för tester och engångsåtgärder, men bara delvis lämplig för produktionscertifikat. Utan automatisering måste ett nytt DNS TXT-värde ställas in vid varje förnyelse.

För produktion finns tre rimliga alternativ:

• DNS-plugin för DNS-leverantören: Lämpligt när Certbot får uppdatera DNS-poster via ett API.
• Annan ACME-klient med DNS-automatisering: Lämpligt när leverantören eller plattformen stöds bättre av en annan klient.
• Manuell förnyelse med en ansvarig och kalenderpåminnelse: Endast lämpligt för tester eller sällan använda certifikat.

DNS-API-uppgifter är särskilt känsliga. En DNS-token bör begränsas till den nödvändiga zonen och, om möjligt, till de posttyper som krävs. Uppgifter med breda administratörsrättigheter för domänen bör inte lagras oskyddade på en webbserver.

Förnyelsen testas normalt med:

sudo certbot renew --dry-run

För certifikat som skapats med manuell DNS-validering är testet bara meningsfullt om DNS-processen är automatiserad eller om de manuella hookarna fungerar korrekt.

En lyckad förnyelse på Certbot-systemet uppdaterar inte automatiskt ett certifikat som tidigare importerats till Sophos Firewall, ZTNA eller en reverse proxy. Det krävs en dokumenterad återimport eller en testad distributionsprocess som bara körs efter en lyckad förnyelse. Efter varje distribution kontrolleras namn, kedja och nytt utgångsdatum direkt på det faktiska målsystemet.

Importera till Sophos-miljöer

Kontrollera följande innan certifikatet importeras till Sophos ZTNA, en brandvägg, en reverse proxy eller ett annat Sophos-relaterat system:

• Matchar certifikatnamnet det publika värdnamnet?
• Behövs rotdomänen utöver wildcard-domänen?
• Förväntar sig målsystemet fullchain.pem eller separata certifikatkomponenter?
• Accepterar det den privata nyckeln eller måste den konverteras till ett annat format?
• Finns det en dokumenterad process för nästa förnyelse?
• Är det tydligt på vilka system samma certifikat har importerats?

Om certifikatet bara behövs för WAF, WebAdmin eller portaler på Sophos Firewall är den inbyggda processen ofta enklare, eftersom utfärdning och förnyelse sker direkt på brandväggen. För riktiga wildcard-certifikat är den externa Certbot- eller ACME-metoden fortfarande relevant. Importera och tilldela certifikat på Sophos Firewall förklarar sedan hur den privata nyckeln, CA-kedjan och tjänstetilldelningen kontrolleras.

Typiska fel

• Valideringen misslyckas: TXT-posten är ännu inte synlig, DNS-zonnamnet är fel eller ett av flera TXT-värden har skrivits över. Kontrollera med dig TXT _acme-challenge.example.com @1.1.1.1.
• Certifikatet täcker inte example.com: Endast *.example.com begärdes. Lägg till rotdomänen med -d example.com.
• Certifikatet täcker inte a.b.example.com: Wildcard-domänen täcker bara en underdomännivå. Planera ett separat certifikat eller en lämplig wildcard-domän för den djupare zonen.
• Förnyelsen körs inte automatiskt: Den manuella DNS-metoden är inte automatiserad. Kontrollera om det finns ett lämpligt DNS-plugin eller en annan ACME-klient.
• Certbot förnyar certifikatet, men målsystemet visar fortfarande det gamla: Återimporten eller distributionsprocessen har inte körts. Kontrollera serienummer eller utgångsdatum direkt på målet.
• Importen misslyckas: Filen eller formatet är fel. Jämför kraven för fullchain.pem, cert.pem, privkey.pem och certifikatkedjan.
• Kopior av nyckeln skapar en säkerhetsrisk: Den privata nyckeln lagras på flera system. Dokumentera lagringsplatser, åtkomsträttigheter och importpunkter.

Checklista

• Domän och nödvändig underdomännivå fastställda.
• Rotdomän och wildcard-domän medvetet valda.
• DNS-åtkomst och behörighet att skapa TXT-poster finns.
• Certbot installerat på ett konsekvent sätt.
• DNS-01-challenge validerad med lyckat resultat.
• Certifikatfiler och privat nyckel lagrade säkert.
• Målsystem och nödvändigt importformat kända.
• Förnyelse planerad med en ansvarig, påminnelse eller DNS-automatisering.
• Återimport eller distributionsprocess till målsystemet testad.
• Gamla certifikat och nycklar borttagna kontrollerat efter en lyckad migrering.

Vanliga frågor