Productie SSL/TLS-certificaat verlopen: HSTS-storingen oplossen en CAA/Rate-Limit-blokken coderen¶

Wanneer een productie-SSL/TLS (HTTPS) certificaat verloopt - zelfs met een seconde voorbij zijn notAfter UTC-tijdstempel - elke moderne browser (Chrome, Safari, Firefox, Edge), mobiele app (iOS App Transport Security, Android Network Security Config), webhookontvanger (Stripe, Shopify, Twilio, GitHub), en upstream API-client verbreekt onmiddellijk de connectiviteit met NET::ERR_CERT_DATE_INVALID of SSL_ERROR_RX_RECORD_TOO_LONG. Erger nog, als uw domein de Strict-Transport-Security (HSTS) header of is gecompileerd in de browser HSTS Preload List, Chrome en Safari verwijderen de omzeilknop "Geavanceerd -> Doorgaan naar site (onveilig)" volledig, wat resulteert in een 100 procent harde storing voor elke gebruiker wereldwijd. Vaak is de geautomatiseerde verlengingscronjob (Certbot, acme.sh, Caddy, cert-manager, of AWS ACM) faalt al 30 dagen stil vanwege een beperkende DNS CAA record, een kapotte DNSSEC DS record, een firewall die de poort blokkeert 80 (HTTP-01 uitdaging), of een webserver (nginx / haproxy) waarmee het bestand op schijf is vernieuwd (fullchain.pem) maar heeft de werkprocessen in het geheugen nooit opnieuw geladen. Als uw storing werd veroorzaakt door een verlopen domeinregistratie of door gekaapte naamservers en niet door het X.509-certificaat zelf, schakel dan onmiddellijk over naar domeinnaamkaping, verlopen DNS en website-overname; als uw server volledig onbereikbaar is of geen schijfruimte meer heeft certbot kan niet naar schrijven /etc/letsencrypt, zien serverschijf 100% volledig en nulruimteherstel of webhostingcrisis, migratie en back-upherstel. Als deze TLS-black-out ziekenhuistelemetrie, noodhulp-API's of openbare veiligheidsinfrastructuur uitschakelt, bel dan uw lokale alarmnummer (911 in de Verenigde Staten en Canada, 112 in de hele Europese Unie, 999 in het Verenigd Koninkrijk) of raadpleeg onze internationale gids van noodnummers.

Doe dit nu¶

1. Controleer binnen 10 seconden of het certificaat op schijf daadwerkelijk al vernieuwd is, en uw webserver of load balancer het simpelweg niet opnieuw in het RAM-geheugen heeft geladen:
2. Vergelijk de live TLS-socket met de .pem bestand op schijf nu:

   # 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. Als het bestand op schijf een geldige future toont notAfter datum terwijl de live-poort 443 toont een vervaldatum: Uw ACME-klant (certbot / acme.sh) weken geleden gelukt, maar nginx, apache2, haproxy, of postfix is nooit herladen, of (haproxy / vault) vereist fullchain.pem + privkey.pem samengevoegd tot één bundel. Loop sudo nginx -t && sudo systemctl reload nginx (of sudo systemctl reload apache2 haproxy) en uw storing eindigt over 2 seconden.
4. NIET rennen certbot renew --force-renewal herhaaldelijk in een lus als vernieuwing mislukt: Let's Encrypt handhaaft een strikte snelheidslimiet van 5 dubbele certificaten per 7 dagen en 5 mislukte validaties per account, per hostnaam, per uur. Rennen --force-renewal vijf keer in paniek zonder het onderliggende te repareren nginx herladen of een DNS/firewall-bug zal uw domein voor maximaal 7 dagen blokkeren voor de uitgifte van Let's Encrypt.
5. Als u een Let's Encrypt-snelheidslimiet bereikt (429 Too Many Requests), schakel uw ACME-client over naar een tweede gratis openbare certificeringsinstantie (ZeroSSL, Buypass Go SSL, of Google Trust Services) of voeg onmiddellijk een wegwerpsubdomein-SAN toe:
6. Elke ACME-client (certbot, acme.sh, caddy, cert-manager) kan binnen 30 seconden een gratis vertrouwd certificaat aanvragen bij een andere CA (--server https://acme.zerossl.com/v2/DV90 of https://api.buypass.com/acme/directory), waarbij de snelheidslimiet van Let's Encrypt volledig wordt omzeild.
7. Als alternatief is de limiet van "5 dubbele certificaten per 7 dagen" van Let's Encrypt alleen van toepassing op exact dezelfde set alternatieve subjectnamen (SANs). Eén extra geldig subdomein toevoegen (-d example.com -d www.example.com -d tlsfix1.example.com) maakt er een niet-duplicaat certificaat van en omzeilt onmiddellijk de snelheidslimiet voor dubbele certificaten.
8. Controleer of een DNS CAA record of gebroken DNSSEC blokkeert de uitgifte van uw certificeringsinstantie (CAA record for example.com prevents issuance):
9. Vraag de autorisatie van de certificeringsinstantie van uw domein op (CAA) registreert: dig +short CAA example.com. Als uw DNS dat heeft 0 issue "sectigo.com" of 0 issue "amazon.com" (of op een bovenliggend domein), Let's Encrypt (letsencrypt.org) en ZeroSSL (sectigo.com) zijn volgens RFC 8659 verboden totdat u deze toevoegt 0 issue "letsencrypt.org" naar uw DNS-zone.
10. Indien poort 80 (HTTP-01 challenge) wordt geblokkeerd door een firewall, CDN of ISP, of als uw webserver weigert op te starten vanwege een ontbrekend certificaat, gebruikt u --standalone of --dns (DNS-01) validatie:
11. Stop nginx/apache kort en rennen sudo certbot certonly --standalone -d example.com, of gebruik --manual --preferred-challenges dns valideren door a te plakken _acme-challenge.example.com TXT opnemen in uw DNS-console zonder de poort aan te raken 80.
12. Als uw site achter Cloudflare, AWS CloudFront of Fastly staat, controleer dan of het verlopen certificaat zich op de CDN Edge of op uw Origin Server bevindt (Error 526 Invalid SSL Certificate):
13. Op Cloudflare, als uw oorspronkelijke servercertificaat is verlopen en Cloudflare is ingesteld op Full (Strict), zien gebruikers Fout 526. Terwijl u het oorsprongscertificaat repareert, kunt u het live siteverkeer in 5 seconden herstellen door een 15-jarig Cloudflare Origin CA-certificaat te genereren in het Cloudflare-dashboard (of door tijdelijk de SSL/TLS-modus te schakelen van Full (Strict) aan Full gedurende de 10 minuten die nodig zijn om de oorsprong te vervangen .pem bestand).

Beslissingsboom: diagnose en reparatie van een verlopen productie-SSL/TLS-certificaat¶

Volg deze beslissingsboom om de exacte foutlaag te bepalen (CDN Edge vs. Origin Daemon Memory vs. ACME Challenge vs. CA Rate Limit) en herstel HTTPS-verkeer binnen enkele minuten:

flowchart TD
    Start["Gebruikers/API's die NET::ERR_CERT_DATE_INVALID of Cloudflare Error 526 rapporteren"] --> CheckLive["Uitvoeren: openssl s_client -servernaam domein -connect domein:443 | openssl x509 -noout -dates -uitgever"]

    CheckLive --> WhereExpired{"Welk certificaat is feitelijk verlopen?"}

    WhereExpired -->|"Schijf fullchain.pem is GELDIG, maar Live Port 443 is VERLOPEN"| StaleDaemon["Verouderd Daemon-geheugen of gesplitst certificaatarchief: Laad nginx / apache2 / haproxy / postfix opnieuw, of herbouw de gecombineerde HAProxy PEM-bundel"]
    WhereExpired -->|"CDN Edge-certificaat (Cloudflare / CloudFront / Fastly) is verlopen"| CDNFix["Controleer DNS CAA-records voor CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) en schakel Universal SSL in of valideer ACM opnieuw"]
    WhereExpired -->|"Origin Server fullchain.pem op schijf is VERLOPEN"| DryRun["Uitvoeren: sudo certbot renew --dry-run (of acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"Waarom mislukte de ACME-verlenging?"}

    WhyFailed -->|"429 Te veel verzoeken (tarieflimiet overschreden)"| RateLimit["Onmiddellijk omzeilen: uitgifte van ZeroSSL / Buypass / Google Trust Services OF voeg 1 extra subdomein-SAN toe (-d fix1.example.com)"]
    WhyFailed -->|"CAA-record voorkomt uitgifte of SERVFAIL (DNSSEC)"| CAADNS["Uitvoeren: dig CAA example.com -> Voeg 0 probleem 'letsencrypt.org' (en 'sectigo.com') toe of repareer een verbroken DNSSEC DS-record bij de registrar"]
    WhyFailed -->|"Verbinding geweigerd / Time-out / 404 aan /.well-known/acme-challenge/"| HttpBlock["Poort 80 geblokkeerd of omleidingslus: Open TCP-poort 80 in Firewall, sluit /.well-known/ uit van Auth/Rewrite of gebruik DNS-01 Challenge"]
    WhyFailed -->|"Kubernetes cert-manager Bestelling vastgelopen in behandeling"| K8sFix["Uitvoeren: kubectl beschrijving uitdaging -> Annotatie van Ingress-klasse, HTTP01-oplosserpod-netwerkbeleid of Webhook TLS controleren"]

    StaleDaemon --> VerifyAll["Controleer keten- en OCSP-nieten: openssl s_client -connect domain:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Fase 1: Begrijpen waarom HSTS (Strict-Transport-Security) veroorzaakt een totale hard-fail black-out¶

Wanneer een website geen HSTS gebruikt, wordt bij een verlopen certificaat een interstitiële waarschuwing weergegeven (Your connection is not private) met een link "Geavanceerd -> Doorgaan naar voorbeeld.com (onveilig)" waarmee wanhopige gebruikers kunnen doorklikken.

Bijna alle moderne productiewebapplicaties, banken, SaaS-platforms en .dev / .app / .page / .bank topniveaudomeinen handhaven HTTP strikte transportbeveiliging (HSTS, RFC 6797): 1. Dynamische HSTS (max-age=31536000): Elke browser die uw site in de afgelopen 365 dagen heeft bezocht, heeft het beleid in de cache opgeslagen Strict-Transport-Security: max-age=31536000; includeSubDomains. Totdat die timer afloopt, verbiedt de browser de gebruiker om door een certificaatfout te klikken (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, of ERR_CERT_AUTHORITY_INVALID). 2. Statische HSTS-voorbelasting (preload lijst of .dev / .app gTLD): Als uw domein is ingediend bij hstspreload.org - of als uw domein een door het register vooraf geladen TLD gebruikt, zoals .dev, .app, .page, .new, .chrome, of .bank - bij elk exemplaar van Chrome, Edge, Firefox, Safari en Android WebView op aarde is uw domein hardgecodeerd in zijn binaire bestand, zoals HSTS-afgedwongen, voordat de gebruiker uw site ooit voor de eerste keer bezoekt. 3. Waarom includeSubDomains breekt interne tools en staging-servers: als uw hoofddomein (example.com) verzendt Strict-Transport-Security: max-age=31536000; includeSubDomains, elk subdomein (vpn.example.com, internal-jira.example.com, printer.example.com) is ook vergrendeld in de HSTS-hardfailmodus. 4. Waarom API- en Webhook-integraties (Stripe, Twilio, Slack, iOS ATS) mislukt onmiddellijk: Server-naar-server TLS-clients (libcurl, Python requests/urllib3, Node.js undici, Gaan crypto/tls, Java SSLContext) voer strikte RFC 5280 uit notAfter standaard validatie en hebben geen concept van een 'doorklik' van de gebruiker. Tijdens een TLS-storing zullen Stripe- en Shopify-webhooks de levering mislukken en in exponentiële wachtrijen voor nieuwe pogingen terechtkomen.

Fase 2: De 60 seconden durende diagnose - Is het certificaat eigenlijk al vernieuwd op schijf?¶

Bij grofweg 35 procent van de productieonderbrekingen van Let's Encrypt werd het certificaat weken geleden daadwerkelijk op schijf vernieuwd door certbot.timer of acme.sh, maar de actieve daemon levert nog steeds het oude verlopen certificaat van RAM.

Stap 1: Vergelijk de live netwerksocket met het bestand op schijf¶

Voer beide opdrachten uit op uw 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

Stap 2: Repareer de 4 veelvoorkomende valstrikken "Vernieuwd op schijf, verlopen in RAM".¶

Fase 3: DNS repareren CAA recordblokken en DNSSEC validatiefouten¶

Als je rent sudo certbot renew --dry-run en zie: - 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. Hoe DNS CAA (RFC 8659) blokkeert certificaatvernieuwing¶

Elke openbare certificeringsinstantie is wettelijk verplicht door de CA/Browser Forum Baseline-vereisten om DNS-query's uit te voeren CAA registreren voordat er een certificaat wordt afgegeven. De CA loopt de DNS-boom op vanaf sub.app.example.com -> app.example.com -> example.com: - Als example.com heeft nul CAA records, mag elke CA uitgeven. - Als example.com heeft zelfs een enkele CAA opnemen (bijvoorbeeld 0 issue "amazon.com" automatisch toegevoegd wanneer iemand een AWS CloudFront-distributie heeft gemaakt, of 0 issue "digicert.com"), Het is ten strengste verboden voor elke andere certificeringsinstantie op aarde om een certificaat uit te geven example.com of een van de subdomeinen. - Als u bovendien een Wildcard-certificaat (*.example.com) en uw domein definieert een specifiek 0 issuewild "ca.example" tag, controleert de CA de issuewild eigendom in plaats van issue.

Diagnostische en onmiddellijke oplossing voor CAA blokken:¶

1. Controleer CAA records op zowel de hostnaam als het Apex-domein:

   dig +short CAA sub.example.com
   dig +short CAA example.com
   

2. Controleer ook of sub.example.com is een CNAME verwijzend naar een ander domein (volgens RFC 8659 controleren CA's ook de CAA records op CNAME-doelen).
3. In het dashboard van uw DNS-provider (Cloudflare, Route 53, Cloud DNS, Namecheap), verwijder de bestaande niet CAA records gebruikt door uw CDN of AWS ACM; in plaats daarvan voeg extra toe CAA records die Let's Encrypt en uw back-up-CA's autoriseren:

   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"
   

   (Opmerking: ZeroSSL gebruikt sectigo.com als de onderliggende CAA-identificatiecode, en die Google Trust Services gebruikt pki.goog.)
4. Wacht 60 seconden totdat uw gezaghebbende naamservers zijn bijgewerkt (dig @ns1.yourdns.com CAA example.com) en onmiddellijk opnieuw uitvoeren sudo certbot renew. Omdat CA's live recursieve zoekopdrachten uitvoeren en bij nieuwe pogingen de openbare caches omzeilen, slaagt de uitgifte onmiddellijk.

2. Bevestiging DNS problem: SERVFAIL looking up CAA (DNSSEC niet-overeenkomende)¶

Let's Encrypt, Google Trust Services en ZeroSSL handhaven DNSSEC-validatie strikt bij alle DNS-lookups (A, AAAA, TXT, en CAA). Zelfs als een domein nr CAA record, moet de CA een cryptografisch geldig certificaat ontvangen NOERROR (leeg antwoord) of NXDOMAIN (NSEC / NSEC3 geauthenticeerde ontkenning van het bestaan) antwoord. - Als uw domeinregistreerder een oud DS (Delegation Signer) record nadat u DNS-providers hebt gemigreerd (bijvoorbeeld als u van GoDaddy naar Cloudflare of Route 53 bent overgestapt zonder DNSSEC eerst uit te schakelen), recursieve solvers die DNSSEC-retour afdwingen SERVFAIL. - Verifieer binnen 5 seconden: Uitvoeren delv @8.8.8.8 example.com CAA of testen bij dnsviz.net. Als dig @8.8.8.8 example.com retourneert status: SERVFAIL terwijl dig +cd @8.8.8.8 example.com (+cd = Aanvinken Uitgeschakeld, DNSSEC negeren) retourneert uw IP-adres, uw DNSSEC-keten is verbroken. Meld u onmiddellijk aan bij uw domeinregistreerder en verwijder het verouderde bestand DS registreer of kopieer de huidige DS parameters van uw actieve DNS-host.

Fase 4: Let's Encrypt-snelheidslimieten omzeilen (429 Too Many Requests) tijdens een actieve storing¶

Tijdens een chaotisch incident herstarten engineers vaak containers of rennen ze weg certbot herhaaldelijk totdat Let's Encrypt alle verzoeken afwijst met: - 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

Wachttijden variëren van 1 uur (voor mislukte autorisaties) tot 7 dagen (168 uur) (voor de limiet van 5 dubbele certificaten). Wacht niet 1 uur of 7 dagen terwijl uw productielocatie niet beschikbaar is. U heeft twee volkomen legitieme, onmiddellijke oplossingen:

Oplossing A (beste): schakel de ACME-certificeringsinstantie binnen 30 seconden over naar ZeroSSL, Buypass of Google Trust Services¶

Het ACME-protocol (RFC 8555) is een open standaard. Alle grote browsers en besturingssystemen vertrouwen op ZeroSSL (Sectigo root), Buypass Go SSL (Noorse CA) en Google Trust Services (pki.goog) identiek aan Let's Encrypt (ISRG Root X1). Geen van hen deelt de tarieflimieten met Let's Encrypt.

• Optie 1: Direct uitgeven via Certbot met Buypass Go SSL (geen account/EAB-sleutel vereist, geldigheidsduur van 180 dagen): (Opmerking: Buypass ondersteunt multi-domeincertificaten tot 5 SAN's, maar geen 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
  

• Optie 2: Direct uitgeven via acme.sh (standaard ingesteld op ZeroSSL of schakelt over naar CA's met --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
  

• Optie 3: Uitgifte via Google Trust Services (pki.goog) Openbare ACME: In Google Cloud Console (of via gcloud publicca external-account-keys create), genereer een gratis externe accountbinding (EAB) toets 10 seconden in en voer uit:

  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
  

Oplossing B: omzeil de limiet van Let's Encrypt "5 dubbele certificaten" door één extra SAN-hostnaam toe te voegen¶

Let's Encrypt's duplicaatlimiet van 168 uur (too many certificates (5) already issued for this exact set of domains) houdt de exacte alfabetische set SAN-hostnamen op het certificaat bij, terwijl de totale limiet voor geregistreerde domeinen 50 certificaten per week bedraagt. 1. Creëer een onschadelijke DNS A record dat naar dezelfde server verwijst: tls-recovery-01.example.com -> <your_server_ip>. 2. Vraag het certificaat aan met uw originele domeinen plus de nieuwe hostnaam:

sudo certbot certonly --nginx --cert-name example.com \
  -d example.com -d www.example.com -d tls-recovery-01.example.com

Fase 5: Reparatie kapot HTTP-01 uitdagingen (Port 80) of gebruiken DNS-01 noodvalidatie¶

Wanneer certbot renew mislukt met Timeout during connect (likely firewall problem) of Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (of 403), kunnen de CA-validatieservers uw HTTP-challengetoken op TCP-poort 80 niet bereiken.

Waarom HTTP-01 plotseling kapot op servers die 60 dagen geleden nog werkten¶

1. Cloudbeveiligingsgroep / UFW / iptables gesloten poort 80: iemand heeft de firewall zodanig verhard dat alleen poort wordt toegestaan 443 (HTTPS), vergetend dat RFC 8555 HTTP-01 validatie begint altijd op gewone HTTP-poort 80 (hoewel deze volgt op een 301 doorverwijzen naar https:// op haven 443).
2. Gebroken IPv6 (AAAA) Record: Uw domein heeft zowel een IPv4 (A) record en een IPv6 (AAAA) opnemen. Let's Encrypt ** geeft altijd de voorkeur aan IPv6 (AAAA) eerst**. Als uw IPv6-adres verkeerd wordt gerouteerd, geblokkeerd door ip6tables, of niet gebonden in Nginx (listen [::]:80;), er treedt een time-out op bij de validatie, ook al werkt IPv4 prima.
3. Nginx / Applicatierouter (React / Next.js / Django / Rails) onderschept /.well-known/acme-challenge/: Jouw server blokkeer op poort 80 proxy's al het verkeer (location / { proxy_pass http://localhost:3000; }) naar een backend-app in plaats van te serveren .well-known vanaf schijf.

Twee directe oplossingen voor defecten HTTP-01 validatie¶

Oplossing 1: voeg een speciale hoge prioriteit toe /.well-known/acme-challenge/ blok in Nginx (poort 80)¶

Zorg ervoor dat poort 80 wordt geblokkeerd /etc/nginx/sites-enabled/ bedient ACME-tokens rechtstreeks van /var/www/letsencrypt vóór enige return 301 https://... of proxy_pass richtlijn:

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;
    }
}

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: Omzeil poort 80 en webservers volledig met een handleiding DNS-01 (TXT) uitdaging¶

Als poort 80 wordt geblokkeerd door een upstream ISP/firewall of als uw load balancer niet kan routeren .well-known naar meerdere backend-nodes, valideer via DNS in 2 minuten:

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

dig +short TXT _acme-challenge.example.com @8.8.8.8

Fase 6: Verificatie na herstel (tussenketen, OCSP-nieten en CDN-opschoning)¶

Een veel voorkomende fout na vervanging van een noodcertificaat is het installeren cert.pem (alleen het bladcertificaat) in plaats van fullchain.pem (het bladcertificaat + tussenliggend CA-certificaat). Desktopbrowsers (Chrome, Firefox) maskeren vaak een ontbrekend tussencertificaat via AIA (Authority Information Access) tussenproducten achtervolgen of in de cache opslaan, terwijl curl, Python, OpenSSL, Android-apps en Stripe/Twilio-webhooks mislukken onmiddellijk unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• Controleer of uw server de volledige tussenliggende keten verzendt (fullchain.pem): Uitvoeren:

  echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | grep -E "Verify return code|depth="
  

  Je moet minimaal twee niveaus zien (depth=0 uw domein en depth=1 de tussenliggende CA zoals Let's Encrypt E5/R11 of ZeroSSL RSA Domain Secure Site CA) en Verify return code: 0 (ok). Als je het ziet Verify return code: 21 (unable to verify the first certificate), wijzig uw webserverconfiguratie van cert.pem aan fullchain.pem.
• Verouderde OCSP-nietcache wissen in Nginx / Apache: Als ssl_stapling on; is ingeschakeld, laad de webserver opnieuw en controleer openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
• Configureer meerlaagse SSL-vervalcontrole (externe TCP-controle + Prometheus blackbox_exporter): Vertrouw nooit uitsluitend op e-mailherinneringen (Let's Encrypt heeft in 2025 de e-mails met vervalherinneringen stopgezet). Bewaak de live poort 443-aansluiting extern (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) en stel een dagelijkse cron-check in sudo certbot renew --dry-run.

Regionale noodnummers en protocollen van instanties¶

Hoewel een verlopen TLS-certificaat meestal wordt opgelost door technische teams, kan een certificaatstoring die gezondheidszorgportals, webhooks voor noodgevallen, bankauthenticatie of openbare infrastructuur van de overheid verbreekt, workflows voor regelgevende incidenten veroorzaken:

• Verenigde Staten en Canada:
• Levensveiligheid / Klinische / Dispatch-storing: Bel 911 als een TLS-certificaatfout de telemetrie van de patiënt, het elektronisch voorschrijven of de noodhulpcommunicatie verbreekt.
• ** Agentschap voor cyberbeveiliging en infrastructuurbeveiliging (CISA) (VS)**: Federale civiele instanties onder CISA Binding Operational Regulation (BOD) 18-01 en exploitanten van kritieke infrastructuur die te maken krijgen met ongeoorloofde certificaatuitgifte (CA-compromis of BGP/DNS-kaping) moeten zich melden bij 1-844-Say-CISA (1-844-729-2472) of cisa.gov/report.
• Canadees Centrum voor Cyberbeveiliging: Contact1-833-CYBER-88 (1-833-292-3788).
• Verenigd Koninkrijk:
• Hulpdiensten: bel 999 als een TLS-storing gevolgen heeft voor kritieke klinische systemen van de NHS of voor de levensveiligheid.
• Nationaal Cyber Security Centrum (NCSC): Als u in Certificaattransparantie (Certificaattransparantie) een niet-geautoriseerd certificaat ontdekt dat voor uw domein is uitgegevencrt.sh) logs die DNS-kaping aangeven, rapporteer via ncsc.gov.uk.
• Europese Unie:
• Hulpdiensten: bel 112 in alle EU-lidstaten.
• NIS2-richtlijn en eIDAS-gekwalificeerde website-authenticatiecertificaten (QWACs): Essentiële en belangrijke entiteiten onder de NIS2-richtlijn die te maken krijgen met een langdurige uitval van de beschikbaarheid of gecompromitteerde PKI-sleutels moeten hun nationale CSIRT binnen 24 uur hiervan op de hoogte stellen.
• Australië en Nieuw-Zeeland:
• Hulpdiensten: bel 000 in Australië of 111 in Nieuw-Zeeland; neem contact op met de ACSC (1300 CYBER1) voor infrastructuurincidenten.
• India en Azië-Pacific:
• India (CERT-In / Controleur van certificeringsautoriteiten CCA): Kies 112 voor noodhulp; rapporteer PKI-compromis of aanzienlijke infrastructuurstoringen aan incident@cert-in.org.in binnen 6 uur.

Veelgestelde vragen¶

Waarom kunnen ik of mijn gebruikers tijdens deze storing niet op 'Geavanceerd -> Doorgaan naar site (onveilig)' klikken in Chrome of Safari?¶

Wanneer uw domein de Strenge transportbeveiliging (HSTS) HTTP-header - of gebruikt een topniveaudomein zoals .dev, .app, .pagina, of .bank dat hardgecodeerd is in de HSTS Preload List van de browser - RFC 6797 vereist dat de browser elk verlopen, zelfondertekend of niet-overeenkomend certificaat behandelt als een niet-herstelbare fatale fout. De browser verwijdert opzettelijk de bypass-knop 'Toch doorgaan' om te voorkomen dat actieve Man-in-the-Middle (MitM)-aanvallers gebruikers ertoe verleiden door een vervalst certificaat te klikken. Terwijl een ontwikkelaar op desktop Chrome de verborgen toetsenbordreeks kan typen dit isonveilig direct op het foutscherm om het lokaal te omzeilen voor testen, echte gebruikers kunnen dat niet; u moet een geldig certificaat installeren op poort 443.

Let's Encrypt is gestopt met het verzenden van e-mails met vervalwaarschuwingen en mijn certificaat is zonder voorafgaande kennisgeving verlopen. Waarom is dat gebeurd?¶

Let's Encrypt heeft medio 2025 officieel de e-mailservice voor vervalmeldingen stopgezet om de overhead voor het bewaren van gegevens te verminderen en omdat geautomatiseerde ACME-installaties de status van verlenging rechtstreeks zouden moeten monitoren. Om toekomstige verrassingen te voorkomen, moet u de feitelijke vervaldatum van de TLS-handshake via het netwerk controleren met behulp van een externe uptimemonitor (zoals Prometheus blackbox_exporter, Uptime Kuma, Better Stack of Datadog Synthetic TLS-controles) waarschuwingen 21 dagen, 14 dagen en 7 dagen vóór nietNa.

Waarom werkt mijn site prima in Chrome en Firefox op mijn laptop, maar niet op Android-telefoons? curlen Stripe-webhooks nadat ik het certificaat heb bijgewerkt?¶

U heeft uw webserver geconfigureerd (ssl_certificaat in Nginx of SSLCertificaatBestand in Apache) om naar te verwijzen cert.pem (alleen het bladcertificaat) in plaats van fullchain.pem (het leaf-certificaat gebundeld met het Intermediate CA-certificaat). Desktopbrowsers zoals Chrome en Firefox downloaden automatisch ontbrekende tussenliggende certificaten op de achtergrond met behulp van de Toegang tot autoriteitsinformatie (AIA) URL in uw leaf-certificaat, waardoor de verkeerde configuratie van uw server wordt verborgen. Echter, krul, OpenSSL, Android's systeemverificatieverificator, Python en webhook-servers voeren geen AIA-achtervolging uit en weigeren onmiddellijk de verbinding met Kan het lokale uitgeverscertificaat niet verkrijgen. Wijs uw configuratie naar fullchain.pem en herlaad uw server.

Hoe controleer ik of een hacker of kwaadwillende beheerder een ongeautoriseerd SSL-certificaat voor mijn domein heeft uitgegeven?¶

Elke openbaar vertrouwde certificeringsinstantie is verplicht elk uitgegeven certificaat openbaar te maken Certificaattransparantie (CT)-logboeken (RFC 6962) voordat browsers het zullen vertrouwen. Openen https://crt.sh/?q=%25.uwdomein.com of Cloudflare's Certificate Transparency Monitor om elk certificaat te bekijken dat ooit voor uw domein en zijn subdomeinen is uitgegeven. Als u een certificaat ziet dat is uitgegeven door een onbekende CA en die u niet heeft geautoriseerd, inspecteer dan onmiddellijk uw DNS-registrar en gezaghebbende DNS-zone op ongeoorloofde wijzigingen, trek het frauduleuze certificaat in bij de uitgevende CA en vergrendel uw DNS met CAA records (`0 issue "letsencrypt.org"`).

Wat als mijn Kubernetes-cluster cert-manager is er niet in geslaagd ons Ingress-certificaat te vernieuwen en de bestelling blijft hangen Pending?¶

Rennen kubectl krijg bestelling, uitdaging -A en dan kubectl beschrijft uitdaging -n . In 90 procent van Kubernetes certificaat-manager storingen, de cm-acme-http-oplosser-* tijdelijke pod is actief, maar (1) de Ingress-resource heeft een verouderde ingress-klasseannotatie, zodat de oplosserroute nooit aan uw load balancer is gekoppeld, (2) een Kubernetes Netwerkbeleid blokkeert inkomend verkeer naar de solver-pod op poort 8089, of (3) een hair-pin NAT/split-horizon DNS-probleem verhindert certificaat-manager's interne zelfcontrole van het bereiken van uw openbare load balancer-IP (kan worden opgelost door te slagen --dns01-recursieve-naamservers=8.8.8.8:53,1.1.1.1:53 naar de certificaat-manager implementatieargs).

Kan ik mijn /etc/letsencrypt/ map naar een nieuwe server tijdens een noodmigratie in plaats van opnieuw uit te geven?¶

Ja. Als uw primaire server is overleden en u naar een nieuwe server migreert terwijl de snelheid beperkt is door Let's Encrypt, bewaar dan de symlinks bij het kopiëren /etc/letsencrypt/ gebruiken tar -czpf letencrypt_backup.tar.gz /etc/letsencrypt (gebruik nooit gewoon scp-r, waardoor symlinks worden omgezet /etc/letsencrypt/live/ in dubbele statische bestanden en verbreekt toekomstige verlengingen). Pak dat archief uit naar de nieuwe server (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), wijs Nginx/Apache naar `/etc/letsencrypt/live/domain/fullchain.pem`, en uw bestaande certificaat werkt onmiddellijk op het nieuwe IP-adres.

Gerelateerde handleidingen¶

• Domeinnaamkaping, verlopen DNS en overname van websites
• Serverschijf 100% vol (0 bytes vrij): database- en nulruimteherstel
• Aangepaste Google Workspace- of Microsoft 365-domeinbeheerdersvergrendeling en DNS TXT-redding
• Webhostingcrisis, migratie en back-upherstel
• DNS-kaping, WAN-herconfiguratie van ISP-router en captive portal-spoofing
• Noodnummers per land

Bronnen en officiële richtlijnen¶

• Internet Engineering Taskforce (IETF): RFC 8555 (Automatic Certificate Management Environment / ACME), RFC 8659 (DNS Certification Authority Authorization / CAA) en RFC 6797 (HTTP Strict Transport Security / HSTS).
• Nationaal Instituut voor Standaarden en Technologie (NIST) (Verenigde Staten): Speciale publicatie 800-52 Rev. 2: Richtlijnen voor de selectie, configuratie en gebruik van Transport Layer Security (TLS)-implementaties en SP 1800-16: Webtransacties beveiligen: TLS Server Certificate Management.
• Onderzoeksgroep Internetbeveiliging (ISRG / Laten we officiële documentatie versleutelen): Referentie over tarieflimieten, dubbele certificaatregels en probleemoplossing voor ACME-uitdagingen.
• Agentschap voor cyberbeveiliging en infrastructuurbeveiliging (CISA) (Verenigde Staten): Bindende operationele richtlijn 18-01: Verbeter e-mail- en webbeveiliging (HTTPS- en HSTS-implementatierichtlijnen).
• Nationaal Cyber Security Centrum (NCSC) (Verenigd Koninkrijk): Gebruik van TLS om gegevens perfect te beschermen tijdens de overdracht en begeleiding bij het bewaken van de transparantie van certificaten.