TLS-Zertifikate und automatische Erneuerung

Warum es notwendig ist

TLS verschlüsselt den Datenverkehr „kliyent↔servis“, bestätigt die Authentizität des Servers (und mit mTLS - Client) und schützt auch vor Spoofing. Hauptrisiken: verspätete Zertifikate, schwache Schlüssel, falsche Vertrauenskette, manuelle Verfahren. Ziel des Artikels ist es, eine Architektur zu beschreiben, in der Zertifikate immer aktuell sind und Rotationen unbemerkt von den Nutzern ablaufen.

Grundlegende Konzepte

CA/Subscriber: Zertifizierungsstelle (öffentlich oder intern).
Kette (fullchain): Blattzertifikat + Zwischen- + Stammzertifikat (normalerweise Stammzertifikat in Clientspeichern).
SAN (Subject Alternative Name): Domain/IP-Liste für ein einzelnes Zertifikat (Multi-SAN).
Wildcard: `.example. com'- praktisch für viele Subdomains, erfordert DNS-Validierung.
OCSP-Stapelung: Der Server wendet einen neuen Sperrstatus an. reduziert Verzögerungen und Abhängigkeit von externen OCSPs.
HPKP: veraltet/nicht verwenden; stattdessen CT-Protokolle und Schlüsselhygiene.
CT (Certificate Transparency): öffentliche Ausgabeprotokolle - wichtig für die Kontrolle gefälschter Emissionen.

Kryptoprofil und Schlüssel

• ECDSA (P-256) - schnell und kompakt Bevorzugt für moderne Kunden.
• RSA-2048/3072 - immer noch kompatibel; kann dual-cert (RSA + ECDSA) gehalten werden.
• Schlüsselgenerierung: nur auf der Zielseite (keine Übertragung von Privatleuten über das Netzwerk), Schutz der Zugriffsrechte ('0600').
• HSM/KMS: für kritische Bereiche (Payment/PII) Schlüssel im HSM/KMS speichern, Betriebsaudit ermöglichen.
• Lebensdauer: Kurze Zertifikate (90 Tage/30 Tage für intern) fördern eine häufige Rotation und verringern das Risiko einer Kompromittierung.

Architektonische TLS-Verwaltungsmodelle

1. Öffentliche CA über ACME (Let's Encrypt/Buypass/etc.)

Validierung: HTTP-01 (über Webserver/Ingress) oder DNS-01 (für Wildcard/Off-Thread-Domains).
Vorteile: kostenlos/automatisiert, breites Vertrauen. Nachteile: externe Abhängigkeiten.

2. Interne Unternehmens-CA

Werkzeuge: HashiCorp Vault PKI, Smallstep (step-ca), Microsoft AD CS, CFSSL.
Vorteile: benutzerdefinierte Richtlinien, mTLS, kurze TTLs, Freigabe für interne Domains. Nachteile: Wurzelverteilung, Vertrauensmanagement.

3. Hybride

Öffentliche CA für externe Nutzer; interne CA - für Service-to-Service (mTLS), Inter-Cluster-Kanäle und Admins.

Automatische Verlängerungsmuster (renew)

Allgemeine Grundsätze

Verlängerungsschwelle: Beginn bei '≤ 30' Tage vor Ablauf; für kritische Dienste bei „≤ 45“ Tagen.
Zero-Downtime: Ausstellung eines neuen Zertifikats, atomarer Ersatz, reibungsloser Reload ohne Unterbrechung der Verbindungen.
Doppelter Halt (blau/grün): Speichern Sie das aktuelle und das nächste cert; Umschalten - über Symlink oder versioniertes Geheimnis.
Alerting: Warnungen für 45/30/14/7/3/1 Tag; eine eigene Alert beim Ausfall der ACME-Challenge.

ACME-Clients und ihre Anwendung

certbot / acme. sh/lego: leichte Agenten auf VM/bare-metal.
cert-manager (Kubernetes): Operator, der mit Issuer/ClusterIssuer arbeitet; automatisiert release/renew und schreibt in Secret.
step-ca/Vault Agent: automatische Freigabe/Rotation mit kurzen TTLs, Sidecar-Muster zur Aktualisierung von Schlüsseln und Ketten.

Prozesse für Kubernetes

yaml apiVersion: cert-manager. io/v1 kind: ClusterIssuer metadata:
name: le-http01 spec:
acme:
email: devops@example. com server: https://acme-v02. api. letsencrypt. org/directory privateKeySecretRef:
name: le-account-key solvers:
- http01:
ingress:
class: nginx

yaml apiVersion: cert-manager. io/v1 kind: Certificate metadata:
name: app-cert namespace: prod spec:
secretName: app-tls dnsNames:
- app. example. com issuerRef:
name: le-http01 kind: ClusterIssuer privateKey:
algorithm: ECDSA size: 256 renewBefore: 720h # 30 дней

Ein Hot Swap in NGINX-Ingress erfolgt automatisch, wenn Sie ein 'Secret' -Update durchführen. Fügen Sie' ssl-ecdh-curve: secp256r1 'hinzu und aktivieren Sie OCSP stapling über annotation/ConfigMap.

Prozesse für VM/Bare-metal

bash sudo certbot certonly --webroot -w /var/www/html -d example. com -d www.example. com \
--deploy-hook "systemctl reload nginx"

Periodische' certbot renew 'durch systemd timer.
Verwenden Sie für die Wildcard DNS-01 (Plugin-Anbieter) und einen ähnlichen '--deploy-hook'.

bash export CF_Token="" # example for Cloudflare acme. sh --issue --dns dns_cf -d example. com -d '.example. com' \
--keylength ec-256 --ecc \
--reloadcmd "systemctl reload nginx"

NGINX: Atomarer Ersatz

Speichern Sie' fullchain. pem` и `privkey. pem 'unter stabilen Pfaden (Symlink zu versionierten Dateien), dann' nginx -s reload'.

Interne PKI und mTLS

bash vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki vault write pki/root/generate/internal common_name="Corp Root CA" ttl=87600h vault write pki/roles/service \
allowed_domains="svc. cluster. local,internal. example" allow_subdomains=true \
max_ttl="720h" require_cn=false key_type="ec" key_bits=256

Automatische Freigabe: über Vault Agent Injector (K8s) oder Sidecar; die Anwendung liest cert erneut aus der Datei/FS-watcher.
Kurze TTL: 24-720 Stunden, was häufige Rotation fördert und den Wert des gestohlenen Schlüssels reduziert.
mTLS: Stellen Sie Client-Zertifikate für bestimmte Dienste/Rollen aus; am Eingang - mutual TLS in ingress/sidecar-proxy.

Sicherer Betrieb

Trennung von Geheimnissen: private Schlüssel - nur auf dem Host/Pod, Zugriff nach dem Prinzip der geringsten Privilegien.
Dateirechte: '600' für den Schlüssel; Der Besitzer ist der Benutzer des Prozesses.
Grace-Periode: Stellen Sie' renewBefore' so ein, dass DNS/ACME/Provider-Fehler berücksichtigt werden.
OCSP Stapling: an den Fronten einschalten; Überwachen Sie die Frische der Antwort (normalerweise 12-72 Stunden).
HSTS: Aktivieren Sie schrittweise (ohne' preload 'zu Beginn), um sicherzustellen, dass alle Inhalte korrekt HTTPS geliefert werden.
Dual-cert (RSA + ECDSA): verbessert Kompatibilität und Leistung; moderne Kunden geben ECDSA.

Überwachung und SLO

• Tage vor Ablauf (gauge) für jede Domain/jedes Geheimnis; SLO: „kein cert von <7 Tagen bis expiry“.
• Kettenvalidität (Linting), SAN-Konformität mit den erforderlichen Domänen/IP.
• OCSP Stapling Status (Frische der Antwort).
• Anteil erfolgreicher/erfolgloser ACME-Challenges.
• Leitensi TLS-Handshake, Protokollversionen/Chiffren (Audit).

• Warn: 30 Tage vor Ablauf.
• Crit: 7 Tage/flop 'renew'.
• Seite: 72 Stunden/nicht-valide Kette im Produkt/kein OCSP-Stapeln.

Vorfälle und Rollbacks

Zertifikat überfällig: vorübergehend neu ausstellen und manuell debuggen, RCA fixieren (warum hat renew nicht funktioniert, DNS-Sperren/API-Einschränkungen).
Kompromittierung des Schlüssels: sofortige Neuausstellung/Rückruf, Rotation der Geheimnisse, Audit des Zugangs, Rotation der Token des DNS-Providers/ACME-Kontos.
Falsche Kette: dringende Deploy richtige' fullchain', erzwungene Reload Fronten.
Lock-in zum DNS-Provider: Halten Sie einen redundanten Validierungspfad (HTTP-01) oder sekundären DNS.

Checkliste für die AutoErneuerung

1. Modell auswählen (öffentliche CA über ACME/interne PKI/Hybrid).
2. Definieren Sie das Kryptoprofil: ECDSA-P256, gegebenenfalls Dual-Cert mit RSA-2048.
3. Konfigurieren Sie den automatischen Agenten (cert-manager, certbot, acme. sh, Vault Agent).
4. Zero-Downtime-Ersatz organisieren (Symlink-Muster, Hot-Reload-Ingress/NGINX/Envoy).
5. Aktivieren Sie OCSP-Stapeln und HSTS (schrittweise).
6. Alerting von Terminen und Herausforderungsstatus hinzufügen; SLO vorschreiben.
7. Dokumentation der Break-Glas- und manuellen Freigabeprozesse.
8. Führen Sie „Fail“ -Übungen durch: gebrochenes DNS-01, ACME-Sturz, abgelaufene Wurzel/dazwischen.
9. Überprüfen Sie Ihre privaten Schlüsselzugriffe, rotieren Sie DNS-Provider-Token und ACME-Konten.

Features für iGaming/Fintech

PCI DSS/PII: strenge Cipher Suites, erzwungene TLS 1. 2+/1. 3, deaktivieren Sie schwache Chiffren/Kompression, Sitzungsresumption ohne Sicherheitskompromisse.
Domain-Segmentierung: separate Zertifikate für Payment-Subdomains und Admins; für Inhalteanbieter isolierte Ketten.
Audit und Logging: Freigabe/Rückruf/Rotation erfassen; CI/CD-Artefakte signieren.
Multiregionalität: Lokale Issuer auf Regionen, um nicht von überregionalen Ablehnungen abhängig zu sein.

Beispiele für Konfigurationen

NGINX (RSA+ECDSA, OCSP stapling)

nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_ecdh_curve secp256r1;

ssl_certificate   /etc/nginx/certs/app_ecdsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_ecdsa/privkey. pem;
ssl_certificate   /etc/nginx/certs/app_rsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_rsa/privkey. pem;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000" always;

OpenSSL: CSR (ECDSA-P256)

bash openssl ecparam -name prime256v1 -genkey -noout -out privkey. pem openssl req -new -key privkey. pem -out csr. pem -subj "/CN=app. example. com" \
-addext "subjectAltName=DNS:app. example. com,DNS:www.example. com"

CFSSL: Profil und Ausgabe

json
{
"signing": {
"profiles": {
"server": {
"usages": ["digital signature","key encipherment","server auth"],
"expiry": "2160h"
}
}
}
}

bash cfssl gencert -profile=server ca. json csr. json      cfssljson -bare server

FAQ

Brauche ich eine Wildcard?
Wenn häufig neue Subdomains auftauchen - ja (über DNS-01). Andernfalls verwenden Sie Multi-SAN für explizite Domains.

Was soll ich wählen: cert-manager oder certbot?
Kubernetes → cert-manager. VM/Microservices außerhalb der K8s → certbot/lego/acme. sh. Interne PKI → Vault/step-ca.

Kann die TTL auf einen Tag reduziert werden?
Für interne mTLS - ja, wenn Automation/Sidecar Rotation garantieren und Anwendungen Hot-Reload können.

Wie kann man DNS-01 schützen?
Separater Token/minimaler Zugriff auf die Zone, Schlüsselrotation, beschränken Sie den IP-API-Zugriff, führen Sie ein Audit durch.

Summe

Das robuste TLS-Management ist eine Kombination aus korrektem Kryptoprofil, automatisierter Freigabe und Verlängerung, Zero-Downtime-Rotationen, Beobachtbarkeit und klaren Incident-Respons-Verfahren. Bauen Sie eine ACME/PXI-Pipeline auf, fügen Sie eine strenge Warnung hinzu und trainieren Sie regelmäßig „Notfall“ -Szenarien - und abgelaufene Zertifikate werden keine Quelle für nächtliche Pager mehr sein.