Skapa Let's Encrypt jokerteckencertifikat

Ett Let’s Encrypt Wildcard-certifikat är användbart om flera underdomäner behöver säkras med ett gemensamt certifikat, till exempel app.example.com, vpn.example.com och portal.example.com. Detta kan vara användbart för Sophos ZTNA, omvända proxyservrar, testmiljöer eller flera interna webbtjänster.

Det viktiga är förväntningarna: Let’s Encrypt-certifikat är kortlivade. Fördelen ligger inte på lång sikt, utan i fri emission och automatisering. Om certifikatet skapas manuellt med en DNS TXT-post måste efterföljande förnyelse planeras medvetet.

Om certifikatet ska skapas direkt på en Sophos Firewall för WAF, WebAdmin eller portaler är den inbyggda brandväggsmetoden vanligtvis bättre: Konfigurera Sophos Firewall Let’s Encrypt certifikat. Den här artikeln beskriver den externa jokerteckenvägen med Certbot.

När ett jokertecken-certifikat är vettigt

Ett jokerteckencertifikat täcker en nivå under en domän. Så *.example.com passar för portal.example.com, men inte automatiskt för example.com själv och inte heller för a.b.example.com.

• Många underdomäner under samma zon: Wildcard-certifikat kan förenkla administrationen.
• Bara en enda public service: enda FQDN-certifikat är ofta renare.
• Certifikatet ska användas på flera system: Jokerteckencertifikat kan vara praktiskt, men kontrollera nyckeldistributionen strikt.
• Helautomatisk förnyelse krävs: Schemalägg DNS-leverantör med Certbot-plugin eller annan ACME-klient.
• Sophos Firewall är endast avsedd att säkra WAF/WebAdmin/Portals: Inbyggd brandvägg Let’s Encrypt check.

Ett jokerteckencertifikat är inte en säkerhetsvinst i sig. Faktum är att om samma privata nyckel finns på flera system, ökar effekten av en nyckelförlust. Därför bör det dokumenteras var certifikatet importerades och vem som hanterar den privata nyckeln.

Krav

För ett jokertecken-certifikat behöver du:

• din egen domän eller subdomänzon
• Tillgång till DNS TXT-poster för domänen
• en Linux-server eller administratörsdator med Certbot
• Behörighet att köra Certbot med root-privilegier
• en plan för förnyelse, import och nyckellagring
• Tillgång till målsystemet, till exempel Sophos Central ZTNA, omvänd proxy eller brandvägg

Wildcard-certifikat valideras via DNS-01 Challenge. En TXT-post ställs in under _acme-challenge.example.com. Let’s Encrypt kontrollerar denna DNS-post och utfärdar sedan certifikatet. Let’s Encrypt beskriver de grundläggande utmaningstyperna i Utmaningstyper-dokumentationen.

Installera Certbot

Certbot projektsida rekommenderar installation via Snap för många Linux-miljöer. På ett lämpligt Linux-system ser den grundläggande processen ut så här:

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

Om Certbot redan har installerats via apt, dnf eller något annat paket bör du kontrollera i förväg vilken Certbot som faktiskt används. Annars leder flera parallella installationsvägar snabbt till felaktiga versioner eller oväntade förnyelsejobb.

Skapa jokerteckencertifikat manuellt

För manuell DNS-validering kan Certbot startas med --manual och --preferred-challenges dns. I exemplet ska certifikatet gälla 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. Om example.com och *.example.com begärs samtidigt skapar Certbot två separata DNS-01-utmaningar. Båda TXT-värdena måste läggas till som separata TXT-poster under _acme-challenge.example.com. Lägg alltså till den andra posten dessutom och skriv inte över den första.

Först när alla DNS-poster är synliga globalt bör man bekräfta i Certbot och fortsätta valideringen.

Praktisk kontroll:

dig TXT _acme-challenge.example.com @1.1.1.1

• visst: Ansök om eller förnya ett certifikat utan att installera det.
• --manual: DNS-värdet ställs in manuellt.
• --preferred-challenges dns: Använd DNS-01 Challenge.
• -d example.com: Lägg till ytterligare rotdomän.
• -d '*.example.com': Inkludera jokerteckendomän.

Rotdomänen och wildcard-domänen är separata namn. Om endast *.example.com begärs inkluderas inte example.com automatiskt. Om båda namnen begärs samtidigt kan flera TXT-poster med samma namn behövas. Det är tillåtet i DNS och det är just här valideringar ofta misslyckas, eftersom ett befintligt TXT-värde råkar ersättas.

Hitta certifikatfiler

Efter framgångsrik utfärdande finns filerna vanligtvis på:

/etc/letsencrypt/live/example.com/

Viktiga filer:

• fullchain.pem: Certifikat inklusive mellanliggande certifikat.
• cert.pem: bara servercertifikatet.
• privkey.pem: privat nyckel.
• chain.pem: Mellanliggande certifikat.

Många målsystem kräver fullchain.pem och privkey.pem. Vissa importmasker kräver certifikatet och nyckeln separat, andra kräver också kedjan. Innan du importerar bör det vara klart vilket format målsystemet förväntar sig.

⚠️ privkey.pem är den privata nyckeln. Denna fil får inte hamna i biljetter, chattar, e-postmeddelanden eller osäker lagring. Alla som har den privata nyckeln kan missbruka certifikatet.

Planera förnyelse

Den manuella metoden --manual är enkel för tester och individuella åtgärder, men lämpar sig endast delvis för produktiva certifikat. Utan automatisering måste en ny DNS TXT-post ställas in varje gång den förnyas.

Det finns tre rena varianter för produktiv användning:

• DNS-plugin för DNS-leverantören: om Certbot tillåts ställa in DNS-poster via API.
• en annan ACME-klient med DNS-automatisering: om leverantören eller plattformen stöds bättre.
• manuell förnyelse med kalender och ägare: endast för tester eller sällan använda certifikat.

När DNS API-åtkomst används är API-uppgifterna särskilt viktiga. En DNS-token bör endast tillåtas att ändra den nödvändiga zonen och, om möjligt, endast de nödvändiga posttyperna. Admin-åtkomst för bred domän hör inte oskyddad till en webbserver.

Ett förnyelsetest kontrolleras vanligtvis med Certbot så här:

sudo certbot renew --dry-run

För manuellt skapade DNS-certifikat är detta test endast meningsfullt om DNS-processen också är automatiserad eller om de manuella krokarna fungerar korrekt.

Importera till Sophos-miljöer

Om certifikatet används för Sophos ZTNA, en brandvägg, en omvänd proxy eller annat Sophos-relaterat system, bör du kontrollera dessa punkter innan du importerar:

• Matchar certifikatnamnet det offentliga värdnamnet?
• Krävs rotdomänen utöver jokertecknet?
• Förväntar målsystemet fullchain.pem eller separata certifikatkomponenter?
• Är den privata nyckeln accepterad eller måste den konverteras till ett annat format? – Finns det en dokumenterad process inför nästa förnyelse?
• Är det tydligt på vilka system samma certifikat importerades?

När det gäller just WAF, WebAdmin eller portaler på Sophos Firewall är den inbyggda brandväggsprocessen ofta enklare eftersom skapande och förnyelse sker direkt på brandväggen. Den externa Certbot- eller ACME-rutten förblir dock relevant för riktiga jokerteckencertifikat.

Typiska fel

• Validering misslyckas: TXT-posten är ännu inte synlig, DNS-zonnamnet är fel eller ett av flera TXT-värden har skrivits över. dig TXT _acme-challenge.example.com @1.1.1.1 kontrollera.
• Certifikatet gäller inte för example.com: endast *.example.com begärd. Lägg till rotdomän ytterligare med -d example.com.
• Certifikatet gäller inte för a.b.example.com: Jokertecken täcker bara en underdomännivå. planera ditt eget certifikat eller lämpligt jokertecken för en djupare zon.
• Förnyelse fungerar inte automatiskt: manuellt DNS-sätt utan automatisering. Kontrollera DNS-plugin eller annan ACME-klient.
• Import misslyckas: fel fil eller format. fullchain.pem, cert.pem, privkey.pem och jämför kedjeförfrågan.
• Säkerhetsrisk på grund av nyckelkopior: privat nyckel finns på flera system. Dokumentlagring, åtkomst och importplatser.

Checklista

• Domän- och underdomännivåuppsättning.
• Rotdomän och jokertecken har medvetet valts.
• DNS-åtkomst och TXT-postbehörighet tillgänglig.
• Certbot installerad rent.
• DNS-01-utmaningen har kontrollerats.
• Certifikatfiler och privat nyckel lagras säkert.
• Målsystem och erforderligt importformat känt.
• Förnyelse schemalagd med ägare, kalender eller DNS-automatisering.
• Gamla certifikat och nycklar tas bort på ett kontrollerat sätt efter lyckad konvertering.

Vanliga frågor