Die Verwaltung einzelner SSL-Zertifikate für jede Subdomain wird schnell mühsam. Ein Wildcard-SSL-Zertifikat von Let’s Encrypt deckt alle Subdomains unter einer einzelnen Domain ab — *.example.com — mit einem einzigen Zertifikat. Diese Anleitung führt Sie durch die Beschaffung eines kostenlosen Wildcard-Zertifikats mit Certbot und der DNS-01-Challenge sowie die Konfiguration von Nginx für HTTPS auf allen Ihren Subdomains.

Voraussetzungen

  • Ein Linux-Server (Ubuntu 22.04/24.04 oder Debian 12) mit Root- oder Sudo-Zugang
  • Nginx installiert und in Betrieb
  • Ein registrierter Domainname mit DNS-Zugang (Möglichkeit, TXT-Einträge zu erstellen oder API-Zugang)
  • Port 443 in Ihrer Firewall geöffnet
  • Grundkenntnisse in Terminalbefehlen und Nginx-Konfiguration

Wildcard-Zertifikate verstehen

Ein Wildcard-Zertifikat sichert alle Subdomains erster Ebene einer Domain ab. Ein Zertifikat für *.example.com deckt www.example.com, api.example.com, staging.example.com und jede andere Subdomain ab — aber nicht die Bare-Domain example.com selbst, und nicht mehrstufige Subdomains wie dev.api.example.com.

Let’s Encrypt erfordert die DNS-01-Challenge für Wildcard-Zertifikate. Im Gegensatz zur HTTP-01-Challenge (bei der eine Datei auf Ihrem Webserver abgelegt wird) erfordert DNS-01 die Erstellung eines TXT-Eintrags bei _acme-challenge.example.com zum Nachweis des Domainbesitzes. Das ist sinnvoll: Ein Wildcard-Zertifikat deckt die gesamte Domain ab, daher müssen Sie die Kontrolle über das DNS der Domain nachweisen, nicht nur über einen einzelnen Server.

Certbot und DNS-Plugins installieren

Installieren Sie Certbot und das DNS-Plugin, das zu Ihrem DNS-Anbieter passt. Für Cloudflare:

sudo apt update
sudo apt install certbot python3-certbot-nginx python3-certbot-dns-cloudflare

Für andere Anbieter ersetzen Sie das Plugin-Paket:

# AWS Route 53
sudo apt install python3-certbot-dns-route53

# DigitalOcean
sudo apt install python3-certbot-dns-digitalocean

# Google Cloud DNS
sudo apt install python3-certbot-dns-google

Falls die Paketversion veraltet ist, installieren Sie über pip:

sudo pip3 install certbot certbot-nginx certbot-dns-cloudflare

Erstellen Sie als Nächstes die Anmeldedatei für Ihren DNS-Anbieter. Für Cloudflare erstellen Sie /etc/letsencrypt/cloudflare.ini:

# Cloudflare API token (recommended over Global API key)
dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN

Schränken Sie die Berechtigungen ein — diese Datei enthält Ihre API-Anmeldedaten:

sudo chmod 600 /etc/letsencrypt/cloudflare.ini

Der Cloudflare-API-Token benötigt die Berechtigung Zone:DNS:Edit, eingeschränkt auf Ihre Domain. Erstellen Sie einen unter Cloudflare Dashboard → Mein Profil → API-Token.

Das Wildcard-Zertifikat anfordern

Fordern Sie ein Zertifikat an, das sowohl das Wildcard als auch die Bare-Domain abdeckt:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.example.com" \
  -d "example.com" \
  --preferred-challenges dns-01 \
  --agree-tos \
  -m admin@example.com

Certbot erstellt einen DNS-TXT-Eintrag, wartet auf die Propagierung, validiert ihn und bereinigt ihn anschließend. Die Zertifikatsdateien landen in /etc/letsencrypt/live/example.com/:

  • fullchain.pem — das Zertifikat plus Zwischenzertifikatskette
  • privkey.pem — der private Schlüssel
  • chain.pem — nur das Zwischenzertifikat

Für manuelles DNS (ohne Plugin) verwenden Sie --manual --preferred-challenges dns-01. Certbot zeigt den TXT-Eintragswert an, den Sie manuell hinzufügen müssen. Dies funktioniert für einmalige Anfragen, kann aber nicht automatisch verlängert werden.

Nginx konfigurieren

Erstellen oder aktualisieren Sie Ihren Nginx-Serverblock, um das Wildcard-Zertifikat zu verwenden. Diese Konfiguration ermöglicht HTTPS für jede Subdomain und leitet HTTP auf HTTPS um:

# Redirect all HTTP to HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com *.example.com;
    return 301 https://$host$request_uri;
}

# HTTPS server block for all subdomains
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com *.example.com;

    # Let's Encrypt wildcard certificate
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # SSL hardening
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    # HSTS (optional, enable once confirmed working)
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

    root /var/www/example.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Testen und laden Sie Nginx neu:

sudo nginx -t
sudo systemctl reload nginx

Für subdomain-spezifisches Routing verwenden Sie separate server-Blöcke, die dieselben Zertifikatspfade teilen, aber unterschiedliche server_name- und root-/proxy_pass-Direktiven haben.

Wildcard vs. SAN vs. Einzelzertifikate

EigenschaftWildcard (*.example.com)SAN (Multi-Domain)Einzelzertifikate
Deckt alle Subdomains abJa (nur erste Ebene)Nur aufgelistete DomainsEine Domain pro Zertifikat
Root-Domain-AbdeckungMuss explizit hinzugefügt werdenJa, wenn aufgelistetJa
Mehrstufige SubdomainsNein (*.*.example.com nicht unterstützt)Ja, wenn aufgelistetJa
Anzahl der Zertifikate111 pro Domain
DNS-Challenge erforderlichJaNein (HTTP-01 funktioniert)Nein (HTTP-01 funktioniert)
VerlängerungskomplexitätBenötigt DNS-Plugin oder manuellen SchrittKann HTTP-01 verwendenEinfach mit HTTP-01
Am besten geeignet fürViele Subdomains, dynamische SubdomainsFeste Gruppe verschiedener DomainsEinzeldomain-Server

Automatische Verlängerung

Certbot richtet auf den meisten Distributionen automatisch einen Systemd-Timer ein. Überprüfen Sie, ob er aktiv ist:

sudo systemctl status certbot.timer

Wenn active (waiting) angezeigt wird, ist die Verlängerung geplant. Sie können auch prüfen:

sudo certbot renew --dry-run

Fügen Sie einen Post-Renewal-Hook hinzu, um Nginx nach jeder Verlängerung neu zu laden. Erstellen Sie /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh:

#!/bin/bash
systemctl reload nginx

Machen Sie die Datei ausführbar:

sudo chmod +x /etc/letsencrypt/renewal-hooks/post/reload-nginx.sh

Falls Sie Cron gegenüber Systemd bevorzugen, fügen Sie zum Crontab von Root hinzu:

# Renew certificates twice daily (Certbot skips if not due)
0 3,15 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"

Praxisszenario

Sie stellen eine Microservices-Plattform bereit mit api.example.com für das Backend, app.example.com für das Frontend, staging.example.com zum Testen und docs.example.com für die Dokumentation. Ohne ein Wildcard-Zertifikat müssten Sie Certbot für jede Subdomain ausführen, vier separate Zertifikate verwalten und bei jedem neuen Service neue Certbot-Befehle hinzufügen. Mit einem Wildcard-Zertifikat geben Sie einen einzigen certbot certonly-Befehl aus, verweisen jeden Nginx-Serverblock auf dieselben Zertifikatsdateien, und neue Subdomains funktionieren sofort — keine Zertifikatsänderungen erforderlich. Wenn das Team nächsten Monat monitoring.example.com einrichtet, funktioniert es einfach.

Fallstricke und Sonderfälle

  • Root-Domain nicht abgedeckt: *.example.com stimmt NICHT mit example.com überein. Fügen Sie immer beide -d "*.example.com" -d "example.com" in Ihren Certbot-Befehl ein.
  • DNS-Propagierungsverzögerungen: Einige DNS-Anbieter benötigen Minuten zur Propagierung von TXT-Einträgen. Certbot wartet standardmäßig 10 Sekunden. Erhöhen Sie den Wert mit --dns-cloudflare-propagation-seconds 60, falls die Validierung fehlschlägt.
  • Ratenlimits: Let’s Encrypt erlaubt 50 Zertifikate pro registrierter Domain pro Woche und 5 doppelte Zertifikate pro Woche. Wildcard zählt als ein Zertifikat, daher erreichen Sie diese Limits bei normalem Gebrauch wahrscheinlich nicht. Verwenden Sie --staging zum Testen.
  • Mehrstufige Subdomains: *.example.com deckt NICHT dev.api.example.com ab. Sie benötigen ein separates Zertifikat oder ein SAN-Zertifikat für verschachtelte Subdomains.
  • Certificate-Transparency-Logs: Alle Let’s Encrypt-Zertifikate werden öffentlich protokolliert. Ihre Subdomain-Namen sind in CT-Logs sichtbar. Dies ist bei jedem öffentlich vertrauenswürdigen Zertifikat unvermeidbar.
  • Sicherheit der Plugin-Anmeldedaten: Ihre DNS-API-Anmeldedaten ermöglichen die Änderung von DNS-Einträgen. Speichern Sie sie in /etc/letsencrypt/ mit 600-Berechtigungen und erwägen Sie, API-Token auf die erforderliche Domain und Berechtigungen einzuschränken.

Zusammenfassung

  • Let’s Encrypt stellt kostenlose Wildcard-Zertifikate aus, die *.ihredomain.com abdecken und 90 Tage gültig sind
  • Wildcard-Zertifikate erfordern die DNS-01-Challenge — verwenden Sie ein Certbot DNS-Plugin für Ihren Anbieter
  • Fordern Sie immer *.example.com und example.com im selben Zertifikat an
  • Speichern Sie DNS-Plugin-Anmeldedaten sicher mit chmod 600
  • Konfigurieren Sie Nginx mit ssl_certificate, das auf die Let’s Encrypt-Fullchain verweist
  • Härten Sie SSL mit TLSv1.2+, OCSP-Stapling und HSTS-Headern
  • Richten Sie automatische Verlängerung über Systemd-Timer oder Cron mit einem Post-Hook zum Neuladen von Nginx ein
  • Verwenden Sie das --staging-Flag beim Testen, um Ratenlimits zu vermeiden

Verwandte Artikel