Skip to content

Produktioun SSL / TLS Zertifikat ofgelaaf: HSTS Hard-Fail Outages fixéieren a Loosst eis CAA / Rate-Limit Blocks verschlësselen

Noutfall Zuelen ënnerscheeden vun Land. Dës Säit benotzt 911, d'Nummer fir d'USA a Kanada. Vill aner Länner benotzen 112, 999 oder eng aner Nummer. Fannt d'Nummer fir Äert Land.

Wann eng Produktioun SSL / TLS (HTTPS) Zertifikat leeft - souguer duerch eng eenzeg Sekonn laanscht seng notAfter UTC Zäitstempel - all modernen Browser (Chrome, Safari, Firefox, Edge), mobil App (iOS App Transport Security, Android Network Security Config), Webhook Empfänger (Stripe, Shopify, Twilio, GitHub), an upstream API Client zerstéiert direkt Konnektivitéit mat NET::ERR_CERT_DATE_INVALID oder SSL_ERROR_RX_RECORD_TOO_LONG. Schlëmmer nach, wann Är Domain schéckt de Strict-Transport-Security (HSTS) Header oder ass an de Browser kompiléiert HSTS Preload List, Chrome a Safari läschen den "Fortgeschratt -> Fortschrëtt op de Site (onsécher)" Bypass Knäppchen komplett, wat zu engem 100 Prozent schwéier-fail Blackout fir all Benotzer weltwäit resultéiert. Dacks gëtt den automateschen Erneierung Cronjob (Certbot, acme.sh, Caddy, cert-manager, oder AWS ACM) ass roueg fir 30 Deeg gescheitert wéinst enger restriktiver DNS CAA Rekord, engem gebrach DNSSEC DS Rekord, eng Firewall Spär port 80 (HTTP-01 Challenge), oder e Webserver (nginx / haproxy) déi d'Datei op der Disk erneiert huet (fullchain.pem) awer ni seng In-Memory Aarbechter Prozesser nei gelueden. Wann Ären Ausbroch duerch eng ofgelaaf Domainregistrierung oder kapéierten Nummserver verursaacht gouf anstatt dem X.509 Zertifika selwer, schalt direkt op Domain Numm Kapung, ofgelaaf DNS, a Websäit Iwwernahm; wann Äre Server komplett onerreechbar ass oder aus dem Disk Space also certbot kann net schreiwen /etc/letsencrypt, gesinn Server Scheif 100% voll an null Plaz Erhuelung oder Webhosting Kris, Migratioun, a Backup Restauratioun. Wann dësen TLS-Blackout d'Spidol-Telemetrie, d'Noutverschéckungs-APIs oder d'ëffentlech Sécherheetsinfrastruktur deaktivéiert, rufft Är lokal Noutruffnummer (911 an den USA a Kanada, 112 an der Europäescher Unioun, 999 a Groussbritannien) oder konsultéiert eisen internationale Verzeechnes vun Noutfallnummeren.

Maachen dëst elo

  1. ** Iwwerpréift an 10 Sekonnen ob den Zertifikat op der Disk tatsächlech scho erneiert ass, an Äre Webserver oder Loadbalancer et einfach net an de RAM nei lueden **:
  2. Vergläichen der liewen TLS Socket géint de .pem Datei op Disk elo: 
    # 1. What the live server is serving over the network:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -issuer -serial
# 2. What is actually sitting on disk in /etc/letsencrypt/live/:
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -dates -issuer -serial
  3. ** Wann d'Datei op der Disk eng valabel Zukunft weist notAfter daten iwwerdeems de liewen port 443 weist en ofgelaafsdatum**: Ären ACME Client (certbot / acme.sh) viru Wochen gelongen, mä nginx, apache2, haproxy, oder postfix gouf ni nei gelueden, oder (haproxy / vault) verlaangt fullchain.pem + privkey.pem an engem eenzege Bündel zesummegefaasst. Lafen sudo nginx -t && sudo systemctl reload nginx (oder sudo systemctl reload apache2 haproxy) an Ären Ausfall wäert an 2 Sekonnen ophalen.
  4. ** NET lafen certbot renew --force-renewal ëmmer erëm an enger Loop wann d'Erneierung feelt **: Let's Encrypt erzwéngen eng strikt Tariflimit vun 5 Duplikatzertifikater pro 7 Deeg an 5 gescheitert Validatiounen pro Kont, pro Hostnumm, pro Stonn. Lafen --force-renewal fënnef Mol an enger Panik ouni d'Basisdaten ze fixéieren nginx reload oder DNS / Firewall Käfer wäert Är Domain aus der Let's Encrypt Emissioun fir bis zu 7 Deeg gespaarten.
  5. ** Wann Dir eng Let's Encrypt Rate Limit trefft (429 Too Many Requests), schalt Ären ACME Client op eng zweet gratis ëffentlech Zertifika Autoritéit (ZeroSSL, Buypass Go SSL, oder Google Trust Services) oder füügt en ewechgehäit Subdomain SAN direkt **:
  6. All ACME Client (certbot, acme.sh, caddy, cert-manager) kann e gratis vertrauenswürdege Certificat vun engem anere CA an 30 Sekonnen ufroen (--server https://acme.zerossl.com/v2/DV90 oder https://api.buypass.com/acme/directory), komplett ëmgoen Let's Encrypt Tariflimit.
  7. Alternativ, Let's Encrypt's "5 Duplikat Zertifikater pro 7 Deeg" Limit gëllt nëmme fir déi genau selwescht Set vun Subject Alternativen Nimm (SANs). Een extra gültege Subdomain derbäisetzen (-d example.com -d www.example.com -d tlsfix1.example.com) mécht et en net duplizéierten Zertifika an ëmgeet direkt d'Duplicate Certificate Tariflimit.
  8. ** Kuckt ob en DNS CAA Rekord oder gebrach DNSSEC blockéiert Är Zertifizéierungsautoritéit fir auszeginn (CAA record for example.com prevents issuance)***:
  9. Frot d'Zertifizéierungsautoritéit vun Ärem Domain un (CAA) records: dig +short CAA example.com. Wann Är DNS huet 0 issue "sectigo.com" oder 0 issue "amazon.com" (oder op engem Elterendeel), Loosst eis verschlësselen (letsencrypt.org) an ZeroSSL (sectigo.com) si vum RFC 8659 verbueden ze ginn, bis Dir derbäi kënnt 0 issue "letsencrypt.org" op Är DNS Zone.
  10. ** Wann port 80 (HTTP-01 Challenge) ass vun enger Firewall, CDN oder ISP gespaart, oder wann Äre Webserver refuséiert ze starten wéinst engem fehlenden Zertifika, benotzt --standalone oder --dns (DNS-01) Validatioun**:
  11. Stop nginx/apache kuerz a lafen sudo certbot certonly --standalone -d example.com, oder benotzen --manual --preferred-challenges dns ze validéieren andeems Dir eng Paste _acme-challenge.example.com TXT Rekord an Ärer DNS Konsole ouni den Hafen ze beréieren 80.
  12. ** Wann Äre Site hannert Cloudflare, AWS CloudFront oder Fastly sëtzt, kontrolléiert ob de ofgelafte Zertifika um CDN Edge oder op Ärem Origin Server ass (Error 526 Invalid SSL Certificate)***:
  13. Op Cloudflare, wann Ären Hierkonft Server Zertifikat ofgelaaf ass an Cloudflare ass agestallt Full (Strict), Benotzer gesinn ** Feeler 526 **. Wärend Dir den Origin Zertifika fixéiert, kënnt Dir de Live Site Traffic a 5 Sekonnen restauréieren andeems Dir e 15-Joer Cloudflare Origin CA Zertifikat am Cloudflare Dashboard generéiert (oder temporär SSL / TLS Modus vun Full (Strict) zu Full fir déi 10 Minutten dauert et den Urspronk ze ersetzen .pem Datei).

Danger

** Versicht ni eng HSTS Preload Sperrung ze "fixéieren" duerch Astellung Strict-Transport-Security: max-age=0 während Ären SSL/TLS Zertifika nach ofgelaf ass **: RFC 6797 verbitt explizit Browser ze veraarbecht oder ze honoréieren Strict-Transport-Security header (inkl max-age=0) iwwer eng net vertraut, selbst ënnerschriwwen oder ofgelaaf TLS Verbindung, oder iwwer Einfach HTTP. Ausserdeem, wann Är Domain huet includeSubDomains; preload zesummegesat an der Chromium / Firefox / Safari statesch HSTS Preload Lëscht, souguer max-age=0 iwwer eng valabel Verbindung wäert net de Preload Fändel fir éischte Kéier Visiteur ewechzehuelen. Deen eenzege Wee fir den Zougang zu engem HSTS-gespaarten Domain ze restauréieren ass e gëltege, ëffentlech zouverléissege X.509 Zertifika um Hafen 443 z'installéieren.

Entscheedungsbam: Diagnoséieren a fixéieren en ofgelaafte Produktioun SSL / TLS Zertifika

Follegt dësen Entscheedungsbam fir déi exakt Feelerschicht ze identifizéieren (CDN Edge vs. Origin Daemon Memory vs. ACME Challenge vs. CA Rate Limit) a restauréiert den HTTPS Traffic a Minutten:

flowchart TD
    Start["Benotzer / APIen Bericht NET::ERR_CERT_DATE_INVALID oder Cloudflare Feeler 526"] --> CheckLive["Run: openssl s_client -servername Domain -connect Domain:443 | openssl x509 -noout -dates -emittent"]

    CheckLive --> WhereExpired{"Wéi ee Certificat ass tatsächlech ofgelaf?"}

    WhereExpired -->|"Disk fullchain.pem Ass VALID, Awer Live Port 443 Ass EXPIRED"| StaleDaemon["Stale Daemon Memory oder Split Cert Store: Reload nginx / apache2 / haproxy / postfix, oder Rebuild Combined HAProxy PEM Bundle"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) ass ofgelaf"| CDNFix["Kontrolléiert DNS CAA Records fir CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) an Toggle Universal SSL oder Re-Validate ACM"]
    WhereExpired -->|"Origin Server fullchain.pem op Disk Ass EXPIRED"| DryRun["Run: sudo certbot erneieren --dry-run (oder acme.sh --renew -d Domain --debug)"]

    DryRun --> WhyFailed{"Firwat huet ACME Erneierung gescheitert?"}

    WhyFailed -->|"429 Ze vill Ufroen (Taux Limit iwwerschratt)"| RateLimit["Bypass direkt: Emissioun vun ZeroSSL / Buypass / Google Trust Services ODER Füügt 1 Extra Subdomain SAN (-d fix1.example.com)"]
    WhyFailed -->|"CAA Rekord verhënnert Emissioun oder SERVFAIL (DNSSEC)"| CAADNS["Run: dig CAA example.com -> Füügt 0 Ausgab 'letsencrypt.org' (an 'sectigo.com') oder Fix Broken DNSSEC DS Record am Registrar"]
    WhyFailed -->|"Connection Refused / Timeout / 404 op /.well-known/acme-challenge/"| HttpBlock["Port 80 Blocked or Redirect Loop: Open TCP Port 80 in Firewall, Exclude /.well-known/ from Auth/Rewrite, or Use DNS-01 Challenge"]
    WhyFailed -->|"Kubernetes Certificat-Manager Bestellung Stuck an Erwaardung"| K8sFix["Run: kubectl describe challenge -> Check Ingress Class Annotation, HTTP01 Solver Pod Network Policy, or Webhook TLS"]

    StaleDaemon --> VerifyAll["Verifizéiert Chain & OCSP Stapling: openssl s_client -connect Domain:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Phase 1: Verstoen firwat HSTS (Strict-Transport-Security) verursaacht eng total schwéier-fail Blackout

Wann eng Websäit net HSTS benotzt, weist en ofgelaften Zertifika eng interstitiell Warnung (Your connection is not private) mat engem "Fortgeschratt -> Fuert op example.com (onsécher)" Link deen verzweifelte Benotzer erlaabt duerchzeklicken.

Wéi och ëmmer, bal all modern Produktiounswebapplikatiounen, Banken, SaaS Plattformen, an .dev / .app / .page / .bank Top-Level Domainen erzwéngen HTTP Strikt Transport Sécherheet (HSTS, RFC 6797): 1. Dynamic HSTS (max-age=31536000): All Browser, deen Äre Site an de leschten 365 Deeg besicht huet, huet d'Politik cache Strict-Transport-Security: max-age=31536000; includeSubDomains. Bis deen Timer ofleeft, ** verbitt** de Browser de Benotzer duerch all Zertifikatfehler ze klicken (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, oder ERR_CERT_AUTHORITY_INVALID). 2. Statesch HSTS Preload (preload Lëscht bzw .dev / .app gTLD): Wann Är Domain ofgeliwwert gouf hstspreload.org - oder wann Är Domain e Registry-Preloaded TLD benotzt wéi .dev, .app, .page, .new, .chrome, oder .bank - all Kopie vu Chrome, Edge, Firefox, Safari, an Android WebView op der Äerd huet Ären Domän hardcodéiert a seng Binär wéi HSTS-gezwongen ier de Benotzer jeemools Är Site fir d'éischt Kéier besicht. 3. Firwat includeSubDomains brécht intern Tools a Staging Server: Wann Äre Root Domain (example.com) schéckt Strict-Transport-Security: max-age=31536000; includeSubDomains, all Subdomain (vpn.example.com, internal-jira.example.com, printer.example.com) ass och an den HSTS Hard-Fail Modus gespaart. 4. ** Firwat API a Webhook Integratiounen (Stripe, Twilio, Slack, iOS ATS) versoen direkt**: Server-zu-Server TLS Clienten (libcurl, Python requests/urllib3, Node.js undici, goen crypto/tls, Java SSLContext) strikt RFC 5280 ausféieren notAfter Validatioun als Standard an hu kee Konzept vun engem Benotzer "klickt duerch." Wärend engem TLS Ausbroch, Stripe a Shopify Webhooks falen d'Liwwerung an aginn exponentiell Backoff Retry Schlaangen.

Phase 2: Déi 60 Sekonnen Diagnostik - Ass den Zertifika tatsächlech schonn op der Disk erneiert?

A ronn 35 Prozent vun der Produktioun Let's Encrypt Outages, gouf den Zertifika viru Wochen op Disk erneiert certbot.timer oder acme.sh, awer de lafende Daemon servéiert nach ëmmer den alen ofgelaaften Zertifika vum RAM.

Schrëtt 1: Vergläicht de Live Netzwierk Socket géint d'On-Disk Datei

Run béid Kommandoen op Ärem Server: 

# Check what the live port 443 socket is presenting in RAM:
echo | openssl s_client -servername example.com -connect 127.0.0.1:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates -serial

# Check what is actually sitting on the filesystem:
sudo openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -subject -issuer -dates -serial

Schrëtt 2: Fixéiert déi 4 gemeinsam "Erneiert op Disk, ofgelaf am RAM" Fallen

Service / Proxy Firwat et hält den alen ofgelaaften Certificat no der Erneierung Genau Kommando fir direkt a permanent ze fixéieren
Nginx / Apache certbot benotzt --webroot oder --standalone (oder dns-* Plugin) amplaz --nginx, Also kee Post-Erneierung Reload Hook huet jeemools de Masterprozess signaliséiert. Lafen sudo nginx -t && sudo systemctl reload nginx. Füügt e permanenten Deploy Hook an /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh:
systemctl reload nginx (sudo chmod +x d'Schrëft).
HAProxy HAProxy verlaangt fullchain.pem AN privkey.pem zesummegefaasst an engem ** Single kombinéiert .pem Datei** (combined.pem). Certbot aktualiséiert fullchain.pem an privkey.pem, awer combined.pem ass nach ëmmer déi 90 Deeg al Kopie. De Bündel nei opbauen an HAProxy nei lueden:
sudo sh -c 'cat /etc/letsencrypt/live/example.com/fullchain.pem /etc/letsencrypt/live/example.com/privkey.pem > /etc/haproxy/certs/example.com.pem'
sudo chmod 600 /etc/haproxy/certs/example.com.pem && sudo systemctl reload haproxy
** Broken Symlink an /etc/letsencrypt/live/** Een huet manuell kopéiert /etc/letsencrypt/archive/example.com/fullchain3.pem an /etc/nginx/ssl/ amplaz ze weisen nginx.conf zu de /etc/letsencrypt/live/example.com/fullchain.pem symlink, oder Certbot erstallt eng duplizéiert Lineage genannt /etc/letsencrypt/live/example.com-0001/. Lafen sudo certbot certificates fir ze kucken ob example.com-0001 geschaf gouf. Punkt ssl_certificate an /etc/nginx/ zum aktiven /etc/letsencrypt/live/<lineage>/fullchain.pem symlink an nei lued Nginx.
Docker Container (nginx / traefik / postfix) Den Host OS erneiert /etc/letsencrypt/archive/example.com/fullchain4.pem an huet de Symlink aktualiséiert, awer den Docker Container bind-montéiert déi eenzeg Datei Inode (déi net verknäppt / ersat gouf) oder de Containerprozess am Nummraum ni kritt SIGHUP. Bind-mount dat Ganzt /etc/letsencrypt Verzeechnes (ni eng eenzeg .pem Datei well Symlink Ziler bei Erneierung änneren) a lafen docker kill -s HUP <nginx_container>.

Phase 3: DNS fixéieren CAA Rekord spären an DNSSEC Validatioun Feeler

Wann Dir lafen sudo certbot renew --dry-run a kuckt: - urn:ietf:params:acme:error:caa :: CAA record for example.com prevents issuance - urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up A/CAA for example.com

1. Wéi DNS CAA (RFC 8659) blockéiert Zertifikat Erneierung

All ëffentlech Zertifizéierungsautoritéit ass gesetzlech erfuerderlech vum CA/Browser Forum Baseline Requirements fir DNS ze froen CAA records ier e Certificat ausginn. Den CA geet op den DNS-Bam vun sub.app.example.com -> app.example.com -> example.com: - Wann example.com huet ** null CAA records , all CA ass erlaabt erausginn. - Wann example.com huet ** souguer eng eenzeg CAA Rekord (z.B. 0 issue "amazon.com" automatesch bäigefüügt wann een eng AWS CloudFront Verdeelung erstallt huet, oder 0 issue "digicert.com"), ** all aner Zertifizéierungsautoritéit op der Äerd ass strikt verbueden en Zertifika auszestellen fir example.com oder iergendeng vun hiren Ënnerdomainen**. - Ausserdeem, wann Dir en Wildcard Zertifikat (*.example.com) an Ären Domain definéiert eng spezifesch 0 issuewild "ca.example" Tag, den CA kontrolléiert den issuewild Propriétéit anstatt issue.

Diagnostesch an direkt Fix fir CAA blocks:

  1. Check CAA records souwuel am Hostnumm wéi och am Apex Domain: 
    dig +short CAA sub.example.com
dig +short CAA example.com
  2. Kontrolléiert och ob sub.example.com ass a CNAME weist op eng aner Domain (Per RFC 8659, CAs kontrolléieren och den CAA records op CNAME Ziler).
  3. An Ärem DNS Provider Dashboard (Cloudflare, Route 53, Cloud DNS, Namecheap), ** läscht net existent CAA records ** vun Ärem CDN oder AWS ACM benotzt; amplaz, ** addéieren ** zousätzlech CAA records autoriséiert Let's Encrypt an Äre Backup CAs: 
    example.com.  300  IN  CAA  0 issue "letsencrypt.org"
example.com.  300  IN  CAA  0 issue "sectigo.com"
example.com.  300  IN  CAA  0 issue "pki.goog"
example.com.  300  IN  CAA  0 issuewild "letsencrypt.org"
example.com.  300  IN  CAA  0 issuewild "sectigo.com"
  4. (Notiz: ZeroSSL benotzt sectigo.com als seng Basisdaten CAA Identifizéierer, a Google Trust Services benotzt pki.goog.)*
  5. Waart 60 Sekonnen fir Är autoritär Nummserver ze aktualiséieren (dig @ns1.yourdns.com CAA example.com) an direkt erëm lafen sudo certbot renew. Zënter CAs live rekursive Lookups maachen, déi ëffentlech Cache beim Versuch ëmgoen, geléngt d'Emissioun direkt.

2. Fixéieren DNS problem: SERVFAIL looking up CAA (DNSSEC mismatch)

Loosst eis verschlësselen, Google Trust Services, an ZeroSSL strikt ëmsetzen DNSSEC Validatioun op all DNS Lookups (A, AAAA, TXT,an an CAA). Och wann en Domain **nee CAA Rekord , muss de CA eng cryptographically valabel kréien NOERROR (eidel Äntwert) oder NXDOMAIN (NSEC / NSEC3 authentifizéierter Verweigerung vun der Existenz) Äntwert. - Wann Ären Domain Registrar e Stäck hält DS (Delegatioun Signer) Rekord nodeems Dir DNS Ubidder migréiert hutt (zum Beispill, vu GoDaddy op Cloudflare oder Route 53 geplënnert ouni DNSSEC als éischt auszeschalten), rekursive Resolveren déi DNSSEC Retour erzwéngen SERVFAIL. - Verifizéiert a 5 Sekonnen **: Run delv @8.8.8.8 example.com CAA oder Test bei dnsviz.net. Wann dig @8.8.8.8 example.com zréck status: SERVFAIL während dig +cd @8.8.8.8 example.com (+cd = Kontrolléiert Behënnert, ignoréiert DNSSEC) gitt Är IP Adress zréck, *Är DNSSEC Kette ass gebrach. Mellt Iech direkt un Ären Domain Registrar a läscht entweder de Stäck DS Rekord oder kopéieren déi aktuell DS Parameteren vun Ärem aktiven DNS Host.

Phase 4: Bypass Let's Encrypt Rate Limits (429 Too Many Requests) während engem aktive Ausfall

Wärend engem chaoteschen Tëschefall starten d'Ingenieuren dacks Container nei op oder lafen certbot ëmmer erëm bis Let's Encrypt all Ufroe refuséiert mat: - urn:ietf:params:acme:error:rateLimited :: Error creating new order :: too many certificates (5) already issued for this exact set of domains in the last 168h0m0s - urn:ietf:params:acme:error:rateLimited :: Error creating new order :: too many failed authorizations (5) recently

Waardezäite variéiere vun 1 Stonn (fir gescheitert Autorisatiounen) bis 7 Deeg (168 Stonnen) (fir d'5 Duplikat-Zertifikater Limit). ** Waart net 1 Stonn oder 7 Deeg während Är Produktiounsplaz erof ass.** Dir hutt zwee komplett legitim, direkt Léisungen:

Ëmgang A (Bescht): Wiesselt ACME Zertifizéierungsautoritéit op ZeroSSL, Buypass oder Google Trust Services an 30 Sekonnen

Den ACME Protokoll (RFC 8555) ass en oppene Standard. All gréisser Browser a Betribssystem vertraut ZeroSSL (Sectigo root), Buypass Go SSL (Norwegesch CA), an Google Trust Services (pki.goog) identesch mat Let's Encrypt (ISRG Root X1). Keen vun hinnen deelt Taux Limite mat Let's Encrypt.

  • ** Optioun 1: Emissioun direkt via Certbot benotzt Buypass Go SSL (Kee Kont / EAB Schlëssel erfuerderlech, 180 Deeg Validitéit)**:
  • (Notiz: Buypass ënnerstëtzt Multi-Domain Zertifikater bis zu 5 SANs, awer net Wildcard *.example.com Certificaten)* 
    sudo certbot certonly --webroot -w /var/www/html \
  --server "https://api.buypass.com/acme/directory" \
  -d example.com -d www.example.com \
  --email admin@example.com --agree-tos
  • ** Optioun 2: Emissioun direkt via acme.sh (déi Standard op ZeroSSL ass oder CAs wiesselt mat --server)***: 
    # Using ZeroSSL:
acme.sh --register-account -m admin@example.com --server zerossl
acme.sh --issue -d example.com -d www.example.com -w /var/www/html --server zerossl
  • ** Optioun 3: Ausgab iwwer Google Trust Services (pki.goog) Ëffentlech ACME**: An der Google Cloud Console (oder iwwer gcloud publicca external-account-keys create), generéiert eng gratis extern Kontbindung (EAB) Schlëssel an 10 Sekonnen a lafen: 
    sudo certbot certonly --webroot -w /var/www/html \
  --server "https://dv.acme-v02.api.pki.goog/directory" \
  --eab-kid "YOUR_EAB_KEY_ID" \
  --eab-hmac-key "YOUR_EAB_HMAC_KEY" \
  -d example.com -d www.example.com

Ëmgang B: Bypass d'Let's Encrypt "5 Duplicate Certificates" Limit andeems een extra SAN Hostnumm derbäigesat

Loosst eis d'168-Stonne Duplikatlimit verschlësselen (too many certificates (5) already issued for this exact set of domains) verfollegt den exakte alphabeteschen Set vu SAN Hostnamen um Certificat, wärend déi allgemeng Registréiert Domain Limit 50 Certificaten pro Woch ass. 1. Erstellt eng harmlos DNS A Rekord weist op dee selwechte Server: tls-recovery-01.example.com -> <your_server_ip>. 2. Ufro den Zertifika mat Ären originelle Domainen plus den neie Hostnumm: 

sudo certbot certonly --nginx --cert-name example.com \
  -d example.com -d www.example.com -d tls-recovery-01.example.com
(Gitt --cert-name example.com Aktualiséierungen Är bestehend /etc/letsencrypt/live/example.com/ Verzeechnes op der Plaz sou datt Dir net emol musst änneren nginx.conf.) Well {example.com, tls-recovery-01.example.com, www.example.com} ass e fuschneie Set vun Domainen, Let's Encrypt gëtt den Zertifika direkt eraus.

Phase 5: Fixéiere gebrach HTTP-01 Erausfuerderungen (Port 80) oder benotzt DNS-01 Noutfall Validatioun

Wéini certbot renew klappt mat Timeout during connect (likely firewall problem) oder Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (oder 403), kënnen d'CA-Validatiounsserver Ären HTTP Challenge Token um TCP Hafen 80 net erreechen.

Firwat HTTP-01 brécht op eemol op Serveren déi viru 60 Deeg geschafft hunn

  1. **Cloud Security Group / UFW / iptables zougemaach Port 80 **: Eppes gehärt der Firewall nëmmen port ze erlaben 443 (HTTPS), vergiesst datt RFC 8555 HTTP-01 Validatioun ** fänkt ëmmer um einfachen HTTP-Port 80 ** (obwuel et e 301 Viruleedung an https:// op port 443).
  2. ** Broken IPv6 (AAAA) Rekord**: Ären Domain huet souwuel en IPv4 (A) Rekord an en IPv6 (AAAA) Rekord. Loosst eis verschlësselen ** léiwer ëmmer IPv6 (AAAA) éischt**. Wann Är IPv6 Adress falsch routéiert ass, blockéiert duerch ip6tables, oder net an Nginx gebonnen (listen [::]:80;), d'Validatiounszäit aus, och wann IPv4 gutt funktionnéiert.
  3. Nginx / Application Router (React / Next.js / Django / Rails) interceptéiert /.well-known/acme-challenge/: Är server blockéiert op Port 80 Proxy all Traffic (location / { proxy_pass http://localhost:3000; }) op eng Backend App amplaz ze servéieren .well-known vun disk.

Zwee Instant Fixer fir gebrach HTTP-01 Validatioun

Fix 1: Füügt eng speziell héich Prioritéit /.well-known/acme-challenge/ Block am Nginx (Port 80)

Vergewëssert Iech datt Äre Port 80 blockéiert /etc/nginx/sites-enabled/ déngt ACME Stongen direkt aus /var/www/letsencrypt virdrun all return 301 https://... oder proxy_pass Direktiv: 

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location ^~ /.well-known/acme-challenge/ {
        default_type "text/plain";
        root /var/www/letsencrypt;
        allow all;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}
Erstellt dann den Dossier an Ausgab: 
sudo mkdir -p /var/www/letsencrypt/.well-known/acme-challenge
sudo nginx -t && sudo systemctl reload nginx
sudo certbot certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com

Fix 2: Bypass Port 80 a Webserver komplett mat engem Handbuch DNS-01 (TXT) Erausfuerderung

Wann den Hafen 80 vun engem Upstream ISP / Firewall blockéiert ass oder Äre Lastbalancer kann net route .well-known op multiple Backend Noden, validéiert iwwer DNS an 2 Minutten: 

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d "*.example.com"
Certbot wäert pausen a weisen: Please deploy a DNS TXT record under the name: _acme-challenge.example.com with the following value: XyZ123... 1. Öffnen Är DNS Konsole a kreéiert d' TXT Rekord _acme-challenge mat a 60 zweet TTL. 2. ** Waart a verifizéiert an enger zweeter Terminalfenster ier Dir Enter dréckt **: 
dig +short TXT _acme-challenge.example.com @8.8.8.8
3. Eemol dig dréckt Är exakt Tokenstring, dréckt Enter am Certbot. Ären Zertifikat a private Schlëssel wäert geschriwwe ginn /etc/letsencrypt/live/example.com/ direkt. (Nodeems den Ausbroch geléist ass, installéiert den automatiséierten DNS Plugin wéi z python3-certbot-dns-cloudflare oder python3-certbot-dns-route53 also zukünfteg Erneierung erfuerdert keng manuell TXT Entrée.)

Phase 6: Post-Erhuelung Verifizéierung (Zwëschenkette, OCSP Stapling, an CDN Purge)

E gemeinsame Feeler nom Noutfallzertifikat Ersatz ass d'Installatioun cert.pem (d'Blat Zertifikat eleng) amplaz fullchain.pem (de Blat Zertifikat + Zwëschen CA Zertifikat). Desktop Browser (Chrome, Firefox) maskéiert dacks e fehlend Zwëschenzertifika iwwer AIA (Authority Information Access) verfollegen oder cache Zwëscheprodukter, wärend curl, Python, OpenSSL, Android Apps, a Stripe / Twilio Webhooks falen direkt mat unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

  • ** Vergewëssert Iech datt Äre Server déi komplett Intermediate Chain schéckt (fullchain.pem)***: Run: 
    echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | grep -E "Verify return code|depth="
    Dir musst op d'mannst ** zwee Niveauen ** gesinn (depth=0 Är Domain an depth=1 der Tëschenzäit CA wéi z Let's Encrypt E5/R11 oder ZeroSSL RSA Domain Secure Site CA) an Verify return code: 0 (ok). Wann Dir gesitt Verify return code: 21 (unable to verify the first certificate), Äert Webserverkonfiguratioun änneren vun cert.pem zu fullchain.pem.
  • ** Kloer alen OCSP Stapling Cache an Nginx / Apache **: Wann ssl_stapling on; aktivéiert ass, lued de Webserver nei a kontrolléiert openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
  • ** Multi-Layer SSL Verfalls Iwwerwaachung konfiguréieren (Extern TCP Check + Prometheus blackbox_exporter)***: Vertrauen ni eleng op E-Mail Erënnerungen (Loosst eis verschlësselte gestoppt Verfalls Erënnerung E-Mailen am Joer 2025). Monitor de Live Hafen 443 Socket extern (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) a setzt en deegleche Cron Check op sudo certbot renew --dry-run.

Regional Noutfallnummeren an Agenturprotokoller

Wärend e ofgelaaf TLS Zertifika normalerweis vun Ingenieursteams geléist gëtt, kann e Zertifikatausfall, deen Gesondheetsportaler, Noutverschécken Webhooks, Bankauthentifikatioun oder ëffentlech Infrastruktur vun der Regierung brécht, reglementaresch Tëschefall Workflows ausléisen:

  • Vereenegt Staaten a Kanada:
  • ** Liewen-Sécherheet / Klinesch / Dispatch Outage**: Wielt 911 wann en TLS Zertifikatfehler d'Patiententelemetrie, d'E-Virschrëften oder d'Noutverschéckungskommunikatioun ofschneiden.
  • Cybersecurity and Infrastructure Security Agency (CISA) (US): Bundeszivilagenturen ënner CISA Binding Operational Directive (BOD) 18-01 a kritesch Infrastrukturbetreiber, déi onerlaabt Zertifikatsausgab erliewen (CA Kompromëss oder BGP/DNS Kapung) solle sech un ** mellen1-844-Say-CISA (1-844-729-2472)** oder cisa.gov/report.
  • Canadian Center for Cyber Security: Kontakt 1-833-CYBER-88 (1-833-292-3788).
  • Vereenegt Kinnekräich:
  • Noutdéngscht: Wielt 999 wann en TLS Ausfall kritesch NHS klinesch Systemer oder Liewenssécherheet beaflosst.
  • National Cyber ​​Security Center (NCSC): Wann Dir en onerlaabten Zertifika entdeckt deen fir Är Domain an Zertifikat Transparenz (crt.sh) Logbicher déi DNS-Kaping uginn, mellen via ncsc.gov.uk.
  • Europäesch Unioun:
  • Noutdéngscht: Wielt 112 an all EU-Memberstaaten.
  • NIS2 Direktiv & eIDAS Qualifizéiert Websäit Authentifikatioun Certificaten (QWACs): Wesentlech a wichteg Entitéiten ënner der NIS2-Direktiv, déi e längeren Disponibilitéitsausfall oder kompromittéierte PKI-Schlësselen erliewen, mussen hir national CSIRT bannent 24 Stonnen matdeelen.
  • Australien an Neiséiland:
  • Noutdéngscht: Wielt 000 an Australien oder 111 an Neuseeland; kontaktéiert den ACSC (1300 CYBER1) fir Infrastruktur Tëschefäll.
  • Indien an Asien-Pazifik:
  • Indien (CERT-In / Controller vun Zertifizéierungsautoritéiten CCA): Wielt 112 fir Noutfall Äntwert; Rapport PKI Kompromëss oder bedeitendst Infrastruktur outages ze incident@cert-in.org.in bannent 6 Stonnen.

Oft gestallte Froen

Firwat kënnen ech oder meng Benotzer net op "Fortgeschratt -> Weidergoen op de Site (onsécher)" am Chrome oder Safari wärend dësem Ausfall klickt?

Wann Är Domain schéckt de Streng-Transport-Sécherheet (HSTS) HTTP Header - oder benotzt en Top-Level Domain wéi .dev, .app, .Säit, oder .bank dat ass hardcoded an de Browser HSTS Preload Lëscht - RFC 6797 erfuerdert de Browser all ofgelaaft, selbst ënnerschriwwen oder net passend Zertifika als en net-recuperable fatale Feeler ze behandelen. De Browser läscht bewosst den "Proceed anyway" Contournement Knäppchen fir aktiv Man-in-the-Middle (MitM) Ugräifer ze verhënneren, d'Benotzer ze tricken duerch e spoofed Zertifika ze klicken. Wärend en Entwéckler op Desktop Chrome kann déi verstoppt Tastatursequenz tippen dëst ass onsécher direkt op de Feeler Écran ze Contournement et lokal fir Testen, real Benotzer kann net; Dir musst e gültege Certificat op Port 443 installéieren.

Loosst eis Verschlësselung opgehalen Verfallswarnungs-E-Mailen ze schécken a mäi Certificat ass ouni Préavis ofgelaf - firwat ass dat geschitt?

Let's Encrypt huet seng Verfallsnotifikatiouns-E-Mail-Service an der Mëtt vum 2025 offiziell zréckgezunn fir d'Datebehalen ze reduzéieren a well automatiséiert ACME-Setups direkt d'Erneierungsgesondheet iwwerwaachen. Fir zukünfteg Iwwerraschungen ze vermeiden, musst Dir den aktuellen TLS Handshake Verfallszäitstempel iwwer d'Netz iwwerwaachen mat engem externen Uptime Monitor (wéi Prometheus) blackbox_exporter, Uptime Kuma, Better Stack, oder Datadog Synthetic TLS Checks) Alarm bei 21 Deeg, 14 Deeg a 7 Deeg virdrun net Nach.

Firwat funktionnéiert mäi Site gutt a Chrome a Firefox op mengem Laptop, awer versoen op Android Telefonen, curl, an Stripe Webhooks nodeems ech den Zertifika aktualiséiert hunn?

Dir hutt Äre Webserver konfiguréiert (ssl_certificat an Nginx oder SSLCertificateFile an Apache) ze weisen cert.pem (d'Blat Zertifikat eleng) amplaz fullchain.pem (de Blat Zertifikat mat dem Zwëschen CA Zertifika gebündelt). Desktop Browser wéi Chrome a Firefox lueden automatesch vermësst Zwëscherzertifikater am Hannergrond mat der Autoritéit Informatiounszougang (AIA) URL an Ärem Blat Certificat, verstoppt Är Serverfehlkonfiguratioun. Allerdéngs, krullen, OpenSSL, Android System Vertrauensverifizéierer, Python, a Webhook Server maachen net AIA Chasing a refuséieren direkt d'Verbindung mat kann net lokal Emittent Zertifikat kréien. Point Är Configuratioun op fullchain.pem a lued Äre Server nei.

Wéi iwwerpréiwen ech ob en Hacker oder Rogue Admin en onerlaabten SSL Zertifika fir meng Domain ausgestallt huet?

All ëffentlech vertraut Zertifizéierungsautoritéit ass verlaangt all erausginn Zertifikat op d'Ëffentlechkeet ze protokolléieren Certificate Transparency (CT) Logbicher (RFC 6962) ier d'Browser et vertrauen. Oppen https://crt.sh/?q=%25.yourdomain.com oder Cloudflare's Certificate Transparency Monitor fir all Zertifika ze gesinn, dee jeemools fir Är Domain a seng Ënnerdomainen erausginn ass. Wann Dir e Certificat vun engem onbekannten CA erausginn, deen Dir net autoriséiert hutt, kontrolléiert direkt Ären DNS Registrar an autoritären DNS Zone fir onerlaabt Ännerungen, widderhëlt de rogue Certificat mat dem erausginn CA, a gespaart Ären DNS mat CAA records (`0 issue "letsencrypt.org"`).

Wat wann meng Kubernetes Cluster d' cert-manager konnt net eisen Ingress Zertifika erneieren an den Uerder ass festgehalen Pending?

Lafen kubectl kréien Uerdnung, Challenge -A an dann kubectl beschreiwen Challenge -n . An 90 Prozent vun Kubernetes cert-manager Ausfall, der cm-acme-http-solver-* temporäre Pod leeft, awer entweder (1) d'Ingress Ressource huet eng verännert Ingress Klass Annotatioun sou datt d'Léisungsroute ni un Äre Lastbalancer verbonnen ass, (2) e Kubernetes Netzpolitik blockéiert den Entréesverkéier op de Solver Pod um Hafen 8089, oder (3) en Hoerpin NAT / Split-Horizon DNS Problem verhënnert cert-managerintern Selbstcheck vun Ärem ëffentleche Lastbalancer IP z'erreechen (fixbar duerch Passage --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 zu de cert-manager Deployment args).

Kann ech kopéieren meng /etc/letsencrypt/ Dossier op en neie Server während enger Noutmigratioun amplaz nei ausginn?

Jo. Wann Äre primäre Server stierft an Dir migréiert op en neie Server wärend Dir duerch Let's Encrypt limitéiert ass, bewahrt Symlinks wann Dir kopéiert /etc/letsencrypt/ benotzt tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (benotzt ni einfach scp r, wat d'Symlinks ëmdréit /etc/letsencrypt/live/ an duplizéiert statesch Dateien a brécht zukünfteg Erneierungen). Extrait dat Archiv op den neie Server (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), Punkt Nginx / Apache op `/etc/letsencrypt/live/domain/fullchain.pem`, an Ären existente Zertifika funktionnéiert direkt op der neier IP Adress.

Zesummenhang Guiden

Quellen an offiziell Orientatioun

  • Internet Engineering Task Force (IETF): *RFC 8555 (Automatesch Certificate Management Ëmfeld / ACME), RFC 8659 (DNS Certification Authorization / CAA), an RFC 6797 (HTTP Strikt Transport Sécherheet / HSTS) *.
  • National Institut fir Standards an Technologie (NIST) (Vereenegt Staaten): *Special Publikatioun 800-52 Rev.
  • Internet Security Research Group (ISRG / Loosst eis offiziell Dokumentatioun verschlësselen): * Taux Limit Referenz, Duplikat Zertifikat Regelen, an ACME Challenge Troubleshooting *.
  • Cybersecurity and Infrastructure Security Agency (CISA) (Vereenegt Staaten): * Bindend Operatiounsdirektiv 18-01: E-Mail- a Websécherheet verbesseren (HTTPS- an HSTS-Ëmsetzungsrichtlinn) *.
  • National Cyber ​​​​Security Center (NCSC) (Vereenegt Kinnekräich): * Benotzt TLS fir Daten perfekt am Transit ze schützen an Certificate Transparency Monitoring Guidance*.