Skip to content

Produktions-SSL/TLS-certifikat udløbet: Reparation af HSTS Hard-Fail-udfald og lad os kryptere CAA/Rate-Limit-blokke

Nødnumre varierer fra land til land. Denne side bruger 911, nummeret for USA og Canada. Mange andre lande bruger 112, 999 eller et andet nummer. Find nummeret for dit land.

Når en produktions-SSL/TLS (HTTPS) certifikat udløber - selv med et enkelt sekund forbi dets notAfter UTC-tidsstempel - enhver moderne browser (Chrome, Safari, Firefox, Edge), mobil app (iOS App Transport Security, Android Network Security Config), webhook-modtager (Stripe, Shopify, Twilio, GitHub), og upstream API-klient afbryder straks forbindelse med NET::ERR_CERT_DATE_INVALID eller SSL_ERROR_RX_RECORD_TOO_LONG. Endnu værre, hvis dit domæne sender Strict-Transport-Security (HSTS) header eller er kompileret i browseren HSTS Preload List, Chrome og Safari fjerner "Avanceret -> Fortsæt til websted (usikker)" omgå-knappen fuldstændigt, hvilket resulterer i en 100 procent hard-fail blackout for hver bruger i hele verden. Ofte er den automatiske fornyelse cronjob (Certbot, acme.sh, Caddy, cert-manager, eller AWS ACM) har stillet fejl i 30 dage på grund af en restriktiv DNS CAA rekord, en ødelagt DNSSEC DS record, en firewall-blokerende port 80 (HTTP-01 udfordring) eller en webserver (nginx / haproxy), der fornyede filen på disken (fullchain.pem), men genindlæste aldrig sine arbejdsprocesser i hukommelsen. Hvis dit udfald var forårsaget af en udløbet domæneregistrering eller kaprede navneservere i stedet for selve X.509-certifikatet, skal du straks skifte til kapring af domænenavn, udløbet DNS og overtagelse af websteder; hvis din server er fuldstændig utilgængelig eller ikke har mere diskplads, så certbot kan ikke skrive til /etc/letsencrypt, se serverdisk 100% fuld og nul-plads gendannelse eller webhosting-krise, migrering og gendannelse af backup. Hvis denne TLS blackout deaktiverer hospitalets telemetri, nødafsendelses-API'er eller offentlig sikkerhedsinfrastruktur, skal du ringe til dit lokale alarmnummer (911 i USA og Canada, 112 i hele EU, 999 i Storbritannien) eller se vores internationale oversigt over alarmnumre.

Gør dette nu

  1. Tjek om 10 sekunder, om certifikatet på disken faktisk allerede er fornyet, og din webserver eller load balancer simpelthen ikke kunne genindlæse det i RAM:
  2. Sammenlign den levende TLS-stikdåse med .pem fil på disk lige 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. Hvis filen på disken viser en gyldig fremtid notAfter dato, mens den levende port 443 viser en udløbsdato: Din ACME-klient (certbot / acme.sh) lykkedes for uger siden, men nginx, apache2, haproxy, eller postfix blev aldrig genindlæst, eller (haproxy / vault) kræver fullchain.pem + privkey.pem sammenkædet i et enkelt bundt. Løb sudo nginx -t && sudo systemctl reload nginx (eller sudo systemctl reload apache2 haproxy), og dit udfald slutter om 2 sekunder.
  4. Løb IKKE certbot renew --force-renewal gentagne gange i en løkke, hvis fornyelsen mislykkes: Let's Encrypt håndhæver en streng hastighedsgrænse på 5 duplikerede certifikater pr. 7 dage og 5 mislykkede valideringer pr. konto, pr. værtsnavn, pr. time. Løb --force-renewal fem gange i panik uden at fikse det underliggende nginx genindlæs eller DNS/firewall-fejl vil låse dit domæne ude af Let's Encrypt-udstedelse i op til 7 dage.
  5. Hvis du rammer en Let's Encrypt Rate Limit (429 Too Many Requests), skift din ACME-klient til en anden gratis offentlig certifikatmyndighed (ZeroSSL, Buypass Go SSL, eller Google Trust Services) eller tilføj et bortkastet underdomæne SAN med det samme:
  6. Hver ACME-klient (certbot, acme.sh, caddy, cert-manager) kan anmode om et gratis betroet certifikat fra en anden CA på 30 sekunder (--server https://acme.zerossl.com/v2/DV90 eller https://api.buypass.com/acme/directory), helt uden om Let's Encrypts hastighedsgrænse.
  7. Alternativt gælder Let's Encrypts "5 dubletter af certifikater pr. 7 dage"-grænse kun for det præcis samme sæt af alternative emnenavne (SANs). Tilføjelse af et ekstra gyldigt underdomæne (-d example.com -d www.example.com -d tlsfix1.example.com) gør det til et ikke-duplikeret certifikat og omgår satsgrænsen for duplikatcertifikat med det samme.
  8. Tjek om en DNS CAA rekord eller brudt DNSSEC blokerer din certifikatmyndighed fra at udstede (CAA record for example.com prevents issuance):
  9. Forespørg på dit domænes Certification Authority Authorization (CAA) registrerer: dig +short CAA example.com. Hvis din DNS har 0 issue "sectigo.com" eller 0 issue "amazon.com" (eller på et overordnet domæne), Lad os kryptere (letsencrypt.org) og ZeroSSL (sectigo.com) er ifølge RFC 8659 forbudt at udstede, indtil du tilføjer 0 issue "letsencrypt.org" til din DNS-zone.
  10. Hvis port 80 (HTTP-01 udfordring) er blokeret af en firewall, CDN eller internetudbyder, eller hvis din webserver nægter at starte på grund af et manglende certifikat, brug --standalone eller --dns (DNS-01) validering:
  11. Stop nginx/apache kort og løb sudo certbot certonly --standalone -d example.com, eller brug --manual --preferred-challenges dns at validere ved at indsætte en _acme-challenge.example.com TXT optag i din DNS-konsol uden at røre porten 80.
  12. Hvis dit websted sidder bag Cloudflare, AWS CloudFront eller Fastly, skal du kontrollere, om det udløbne certifikat er på CDN Edge eller på din Origin Server (Error 526 Invalid SSL Certificate):
  13. På Cloudflare, hvis dit oprindelsesservercertifikat udløb og Cloudflare er indstillet til Full (Strict), brugere ser Fejl 526. Mens du reparerer oprindelsescertifikatet, kan du gendanne live sitetrafik på 5 sekunder ved at generere et 15-årigt Cloudflare Origin CA-certifikat i Cloudflare-dashboardet (eller midlertidigt skifte SSL/TLS-tilstand fra Full (Strict) til Full i de 10 minutter, det tager at erstatte oprindelsen .pem fil).

Danger

Forsøg aldrig at "fikse" en HSTS Preload lockout ved at indstille Strict-Transport-Security: max-age=0 mens dit SSL/TLS-certifikat stadig er udløbet: RFC 6797 forbyder eksplicit browsere at behandle eller respektere evt. Strict-Transport-Security overskrift (inklusive max-age=0) over en upålidelig, selvsigneret eller udløbet TLS-forbindelse eller over almindelig HTTP. Desuden, hvis dit domæne har includeSubDomains; preload kompileret i Chromium/Firefox/Safari statiske HSTS preload liste, endda max-age=0 over en gyldig forbindelse vil ikke fjerne preload-flaget for førstegangsbesøgende. Den eneste måde at gendanne adgang til et HSTS-låst domæne på er at installere et gyldigt, offentligt betroet X.509-certifikat på port 443.

Beslutningstræ: diagnosticering og reparation af et udløbet produktions-SSL/TLS-certifikat

Følg dette beslutningstræ for at lokalisere det nøjagtige fejllag (CDN Edge vs. Origin Daemon Memory vs. ACME Challenge vs. CA Rate Limit) og gendan HTTPS-trafik på få minutter:

flowchart TD
    Start["Brugere/API'er rapporterer NET::ERR_CERT_DATE_INVALID eller Cloudflare-fejl 526"] --> CheckLive["Kør: openssl s_client -servernavn domæne -connect domæne:443 | openssl x509 -noout -datoer -udsteder"]

    CheckLive --> WhereExpired{"Hvilket certifikat er faktisk udløbet?"}

    WhereExpired -->|"Disk fullchain.pem er GYLDIG, men Live Port 443 ER UDLØB"| StaleDaemon["Forældet Daemon Memory eller Split Cert Store: Genindlæs nginx / apache2 / haproxy / postfix, eller genopbyg kombineret HAProxy PEM Bundle"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) er udløbet"| CDNFix["Tjek DNS CAA Records for CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) og skift Universal SSL eller re-valider ACM"]
    WhereExpired -->|"Origin Server fullchain.pem på disk er UDLØB"| DryRun["Kør: sudo certbot renew --dry-run (eller acme.sh --renew -d domæne --debug)"]

    DryRun --> WhyFailed{"Hvorfor mislykkedes ACME-fornyelsen?"}

    WhyFailed -->|"429 for mange anmodninger (takstgrænsen er overskredet)"| RateLimit["Omgå med det samme: Udstedelse fra ZeroSSL / Buypass / Google Trust Services ELLER Tilføj 1 ekstra underdomæne-SAN (-d fix1.example.com)"]
    WhyFailed -->|"CAA Record forhindrer udstedelse eller SERVFAIL (DNSSEC)"| CAADNS["Kør: dig CAA example.com -> Tilføj 0 problem 'letsencrypt.org' (og 'sectigo.com') eller Fix Broken DNSSEC DS Record at Registrar"]
    WhyFailed -->|"Forbindelse nægtet / Timeout / 404 på /.well-known/acme-challenge/"| HttpBlock["Port 80 Blokeret eller Redirect Loop: Åbn TCP Port 80 i Firewall, Ekskluder /.well-known/ fra Auth/Rewrite, eller brug DNS-01 Challenge"]
    WhyFailed -->|"Kubernetes cert-manager Ordre sidder fast i afventer"| K8sFix["Kør: kubectl describe challenge -> Check Ingress class annotation, HTTP01 solver pod network policy eller Webhook TLS"]

    StaleDaemon --> VerifyAll["Bekræft kæde- og OCSP-hæftning: openssl s_client -connect domæne:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Fase 1: Forstå hvorfor HSTS (Strict-Transport-Security) forårsager en total hard-fail blackout

Når et websted ikke bruger HSTS, viser et udløbet certifikat en mellemliggende advarsel (Your connection is not private) med et "Avanceret -> Fortsæt til eksempel.com (usikkert)" link, der tillader desperate brugere at klikke sig igennem.

Men næsten alle moderne produktionswebapplikationer, banker, SaaS-platforme og .dev / .app / .page / .bank domæner på topniveau håndhæver HTTP Strict Transport Security (HSTS, RFC 6797): 1. Dynamisk HSTS (max-age=31536000): Enhver browser, der har besøgt dit websted inden for de seneste 365 dage, cachelagde politikken Strict-Transport-Security: max-age=31536000; includeSubDomains. Indtil denne timer udløber, forbyder browseren brugeren at klikke sig igennem enhver certifikatfejl (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, eller ERR_CERT_AUTHORITY_INVALID). 2. Statisk HSTS Preload (preload liste eller .dev / .app gTLD): Hvis dit domæne blev sendt til hstspreload.org - eller hvis dit domæne bruger en Registry-Preloaded TLD som f.eks .dev, .app, .page, .new, .chrome, eller .bank - hver kopi af Chrome, Edge, Firefox, Safari og Android WebView på jorden har dit domæne hardkodet til dets binære som HSTS-håndhævet, før brugeren nogensinde besøger dit websted for første gang. 3. Hvorfor includeSubDomains bryder interne værktøjer og iscenesættelsesservere: Hvis dit roddomæne (example.com) sender Strict-Transport-Security: max-age=31536000; includeSubDomains, hvert underdomæne (vpn.example.com, internal-jira.example.com, printer.example.com) er også låst til HSTS hard-fail-tilstand. 4. Hvorfor API og Webhook integrationer (Stripe, Twilio, Slack, iOS ATS) fejler med det samme: Server-til-server TLS-klienter (libcurl, Python requests/urllib3, Node.js undici, Gå crypto/tls, Java SSLContext) udføre strenge RFC 5280 notAfter validering som standard og har intet begreb om en bruger "gennemklik". Under en TLS-afbrydelse vil Stripe- og Shopify-webhooks mislykkes med leveringen og kommer ind i eksponentielle backoff-genforsøgskøer.

Fase 2: 60 sekunders diagnostik - Er certifikatet faktisk allerede fornyet på disken?

I omkring 35 procent af produktionen Let's Encrypt udfald, blev certifikatet faktisk fornyet på disk for uger siden af certbot.timer eller acme.sh, men den kørende dæmon serverer stadig det gamle udløbne certifikat fra RAM.

Trin 1: Sammenlign live-netværksstikket med filen på disken

Kør begge kommandoer på din 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

Trin 2: Ret de 4 almindelige "Fornyet på disk, udløb i RAM"-fælder

Service / fuldmagt Hvorfor det bliver ved med at tjene det gamle udløbne certifikat efter fornyelse Præcis kommando til at rette øjeblikkeligt og permanent
Nginx / Apache certbot brugt --webroot eller --standalone (eller dns-* plugin) i stedet for --nginx, så ingen genindlæsningskrog efter fornyelse har nogensinde signaleret masterprocessen. Løb sudo nginx -t && sudo systemctl reload nginx. Tilføj en permanent implementeringshook ind /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh:
systemctl reload nginx (sudo chmod +x manuskriptet).
HAProxy HAProxy kræver fullchain.pem OG privkey.pem sammenkædet til en enkelt kombineret .pem fil (combined.pem). Certbot opdateret fullchain.pem og privkey.pem, men combined.pem er stadig den 90 dage gamle kopi. Genopbyg bundtet og genindlæs HAProxy:
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
** Ødelagt Symlink ind /etc/letsencrypt/live/** Nogen kopierede manuelt /etc/letsencrypt/archive/example.com/fullchain3.pem ind i /etc/nginx/ssl/ i stedet for at pege nginx.conf til /etc/letsencrypt/live/example.com/fullchain.pem symlink, eller Certbot oprettede en dublet afstamning ved navn /etc/letsencrypt/live/example.com-0001/. Løb sudo certbot certificates at se om example.com-0001 blev oprettet. Punkt ssl_certificate ind /etc/nginx/ til den aktive /etc/letsencrypt/live/<lineage>/fullchain.pem symlink og genindlæs Nginx.
Docker Container (nginx / traefik / postfix) Værts OS fornyet /etc/letsencrypt/archive/example.com/fullchain4.pem og opdaterede symbollinket, men Docker-beholderen bind-monterede den enkelte fil-inode (som blev fjernet/erstattet) eller containerprocessen inde i navnerummet modtog aldrig SIGHUP. Bind-monter det hele /etc/letsencrypt mappe (aldrig en enkelt .pem fil, fordi symlink-mål ændres ved fornyelse) og køre docker kill -s HUP <nginx_container>.

Fase 3: Reparation af DNS CAA optageblokke og DNSSEC valideringsfejl

Hvis du løber sudo certbot renew --dry-run og se: - 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. Hvordan DNS CAA (RFC 8659) blokerer for certifikatfornyelse

Enhver offentlig certifikatmyndighed er lovligt påkrævet af CA/Browser Forum Baseline Requirements for at forespørge DNS CAA optegnelser før udstedelse af ethvert certifikat. CA går op i DNS-træet fra sub.app.example.com -> app.example.com -> example.com: - Hvis example.com har nul CAA optegnelser, har enhver CA lov til at udstede. - Hvis example.com har selv en enkelt CAA optage (f.eks. 0 issue "amazon.com" tilføjet automatisk, når nogen oprettede en AWS CloudFront-distribution, eller 0 issue "digicert.com"), enhver anden certifikatmyndighed på jorden er strengt forbudt at udstede et certifikat for example.com eller et hvilket som helst af dets underdomæner. - Desuden, hvis du anmoder om et Wildcard-certifikat (*.example.com) og dit domæne definerer en specifik 0 issuewild "ca.example" tag, kontrollerer CA'en issuewild ejendom fremfor issue.

Diagnostisk og øjeblikkelig rettelse til CAA blokke:

  1. Tjek CAA poster på både værtsnavnet og apex-domænet: 
    dig +short CAA sub.example.com
dig +short CAA example.com
  2. Tjek også evt sub.example.com er en CNAME peger på et andet domæne (Pr. RFC 8659 kontrollerer CA'er også CAA optegnelser på CNAME-mål).
  3. I din DNS-udbyders dashboard (Cloudflare, Route 53, Cloud DNS, Namecheap), slet ikke eksisterende CAA poster brugt af din CDN eller AWS ACM; i stedet tilføj yderligere CAA optegnelser, der autoriserer Let's Encrypt og dine backup-CA'er: 
    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"
    (Bemærk: ZeroSSL bruger sectigo.com som dets underliggende CAA-id, og Google Trust Services bruger pki.goog.)
  4. Vent 60 sekunder på, at dine autoritative navneservere opdateres (dig @ns1.yourdns.com CAA example.com) og køres straks igen sudo certbot renew. Da CA'er udfører rekursive opslag uden om offentlige caches ved genforsøg, lykkes udstedelsen med det samme.

2. Fastgørelse DNS problem: SERVFAIL looking up CAA (DNSSEC uoverensstemmelse)

Lad os kryptere, Google Trust Services og ZeroSSL håndhæver strengt DNSSEC-validering på alle DNS-opslag (A, AAAA, TXT, og CAA). Også selvom et domæne har nr CAA record, skal CA modtage en kryptografisk gyldig NOERROR (tomt svar) eller NXDOMAIN (NSEC / NSEC3 autentificeret benægtelse af eksistensen) svar. - Hvis din domæneregistrator har en forældet DS (Delegation Signer)-registrering efter at du migrerede DNS-udbydere (for eksempel ved at flytte fra GoDaddy til Cloudflare eller Route 53 uden at deaktivere DNSSEC først), rekursive resolvere, der gennemtvinger DNSSEC-retur SERVFAIL. - Bekræft på 5 sekunder: Kør delv @8.8.8.8 example.com CAA eller test kl dnsviz.net. Hvis dig @8.8.8.8 example.com returnerer status: SERVFAIL mens dig +cd @8.8.8.8 example.com (+cd = Afkrydsning Deaktiveret, ignorerer DNSSEC) returnerer din IP-adresse, din DNSSEC-kæde er brudt. Log ind på din domæneregistrator med det samme, og fjern enten det forældede DS optage eller kopiere den aktuelle DS parametre fra din aktive DNS-vært.

Fase 4: Omgå Lad os kryptere hastighedsgrænser (429 Too Many Requests) under et aktivt afbrydelse

Under en kaotisk hændelse genstarter ingeniører ofte containere eller kører certbot gentagne gange, indtil Let's Encrypt afviser alle anmodninger med: - 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

Ventetider varierer fra 1 time (for mislykkede godkendelser) til 7 dage (168 timer) (for grænsen på 5 duplikatcertifikater). Vent ikke 1 time eller 7 dage, mens dit produktionssted er nede. Du har to fuldstændig legitime, øjeblikkelige løsninger:

Løsning A (bedst): Skift ACME Certificate Authority til ZeroSSL, Buypass eller Google Trust Services på 30 sekunder

ACME-protokollen (RFC 8555) er en åben standard. Alle større browsere og operativsystemer har tillid til ZeroSSL (Sectigo root), Buypass Go SSL (norsk CA) og Google Trust Services (pki.goog) identisk med Let's Encrypt (ISRG Root X1). Ingen af ​​dem deler hastighedsgrænser med Let's Encrypt.

  • Mulighed 1: Udsted straks via Certbot bruger Buypass Go SSL (ingen konto/EAB-nøgle påkrævet, 180 dages gyldighed): (Bemærk: Buypass understøtter multi-domæne certifikater op til 5 SAN'er, dog ikke jokertegn *.example.com certifikater) 
    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
  • Mulighed 2: Udsted straks via acme.sh (som som standard er ZeroSSL eller skifter CA'er med --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
  • Mulighed 3: Udstedelse via Google Trust Services (pki.goog) Offentlig ACME: I Google Cloud Console (eller via gcloud publicca external-account-keys create), generer en gratis ekstern kontobinding (EAB) indtast 10 sekunder og kør: 
    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

Løsning B: Omgå grænsen for Lad os kryptere "5 Duplicate Certificates" ved at tilføje et ekstra SAN-værtsnavn

Lad os kryptere 168-timers duplikatgrænse (too many certificates (5) already issued for this exact set of domains) sporer det nøjagtige alfabetiske sæt af SAN-værtsnavne på certifikatet, mens den samlede grænse for registreret domæne er 50 certifikater om ugen. 1. Opret en harmløs DNS A post, der peger på den samme server: tls-recovery-01.example.com -> <your_server_ip>. 2. Anmod om certifikatet med dine originale domæner plus det nye værtsnavn: 

sudo certbot certonly --nginx --cert-name example.com \
  -d example.com -d www.example.com -d tls-recovery-01.example.com
(Bestået --cert-name example.com opdaterer din eksisterende /etc/letsencrypt/live/example.com/ mappe på plads, så du ikke engang behøver at redigere nginx.conf.) Fordi {example.com, tls-recovery-01.example.com, www.example.com} er et helt nyt sæt domæner, Let's Encrypt udsteder certifikatet med det samme.

Fase 5: Fixering brudt HTTP-01 udfordringer (Port 80) eller ved hjælp af DNS-01 nødvalidering

Hvornår certbot renew fejler med Timeout during connect (likely firewall problem) eller Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (eller 403), kan CA-valideringsserverne ikke nå dit HTTP-udfordringstoken på TCP-port 80.

Hvorfor HTTP-01 pludselig går i stykker på servere, der fungerede for 60 dage siden

  1. Cloud Security Group / UFW / iptables lukket port 80: Nogen hærdede firewallen til kun at tillade port 443 (HTTPS), glemmer at RFC 8555 HTTP-01 validering begynder altid på almindelig HTTP-port 80 (selvom den vil følge en 301 omdirigere til https:// på havn 443).
  2. ** Ødelagt IPv6 (AAAA) Record**: Dit domæne har både en IPv4 (A) record og en IPv6 (AAAA) optage. Lad os kryptere ** foretrækker altid IPv6 (AAAA) først**. Hvis din IPv6-adresse er omdirigeret forkert, blokeres af ip6tables, eller ikke bundet i Nginx (listen [::]:80;), validering timeout, selvom IPv4 fungerer fint.
  3. Nginx / Application Router (React / Next.js / Django / Rails) opsnapper /.well-known/acme-challenge/: Din server blokere på port 80 proxyer for al trafik (location / { proxy_pass http://localhost:3000; }) til en backend-app i stedet for at tjene .well-known fra disken.

To øjeblikkelige rettelser til brud HTTP-01 validering

Fix 1: Tilføj en dedikeret høj prioritet /.well-known/acme-challenge/ blok i Nginx (Port 80)

Sørg for, at din port 80 blokerer /etc/nginx/sites-enabled/ serverer ACME-tokens direkte fra /var/www/letsencrypt før evt return 301 https://... eller 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;
    }
}
Opret derefter mappen og problem: 
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: Omgå port 80 og webservere helt med en manual DNS-01 (TXT) udfordring

Hvis port 80 er blokeret af en upstream internetudbyder/firewall eller din load balancer ikke kan rute .well-known til flere backend-noder, valider via DNS på 2 minutter: 

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d "*.example.com"
Certbot pauser og viser: Please deploy a DNS TXT record under the name: _acme-challenge.example.com with the following value: XyZ123... 1. Åbn din DNS-konsol og opret TXT optage _acme-challenge med en 60 anden TTL. 2. Vent og bekræft i et andet terminalvindue, før du trykker på Enter: 
dig +short TXT _acme-challenge.example.com @8.8.8.8
3. En gang dig udskriver din nøjagtige token-streng, tryk på Enter i Certbot. Dit certifikat og din private nøgle vil blive skrevet til /etc/letsencrypt/live/example.com/ straks. (Når udfaldet er løst, skal du installere det automatiserede DNS-plugin som f.eks python3-certbot-dns-cloudflare eller python3-certbot-dns-route53 så fremtidige fornyelser kræver ikke manuel TXT indgang.)

Fase 6: Verifikation efter gendannelse (mellemliggende kæde, OCSP-hæftning og CDN-rensning)

En almindelig fejl efter udskiftning af nødcertifikat er installationen cert.pem (alene bladattesten) i stedet for fullchain.pem (bladcertifikatet + mellemliggende CA-certifikat). Desktop browsere (Chrome, Firefox) maskerer ofte et manglende mellemcertifikat via AIA (Authority Information Access) jager eller cachelagrede mellemprodukter, mens curl, Python, OpenSSL, Android apps og Stripe/Twilio webhooks fejler øjeblikkeligt med unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

  • Bekræft, at din server sender hele mellemkæden (fullchain.pem): Kør: 
    echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | grep -E "Verify return code|depth="
    Du skal se mindst to niveauer (depth=0 dit domæne og depth=1 den mellemliggende CA som f.eks Let's Encrypt E5/R11 eller ZeroSSL RSA Domain Secure Site CA) og Verify return code: 0 (ok). Hvis du ser Verify return code: 21 (unable to verify the first certificate), skift din webserverkonfiguration fra cert.pem til fullchain.pem.
  • Ryd gammel OCSP-hæftecache i Nginx/Apache: Hvis ssl_stapling on; er aktiveret, genindlæs webserveren og kontroller openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
  • Konfigurer flerlags SSL-udløbsovervågning (ekstern TCP-kontrol + Prometheus blackbox_exporter): Stol aldrig udelukkende på e-mail-påmindelser (Let's Encrypt udgåede påmindelser om udløb i 2025). Overvåg live-port 443-stikket eksternt (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) og sæt et dagligt cron-tjek til sudo certbot renew --dry-run.

Regionale alarmnumre og agenturprotokoller

Mens et udløbet TLS-certifikat normalt løses af ingeniørteams, kan et certifikatudfald, der bryder sundhedsportaler, nødafsendelseswebhooks, bankgodkendelse eller offentlig offentlig infrastruktur udløse regulatoriske hændelsers arbejdsgange:

  • USA og Canada:
  • Livssikkerhed / Klinisk / Afbrydelse af forsendelse: Tast 911 hvis en TLS-certifikatfejl afbryder patienttelemetri, e-ordination eller nødudsendelseskommunikation.
  • Cybersikkerhed og Infrastruktursikkerhedsagentur (CISA) (US): Føderale civile agenturer under CISA Binding Operational Direktiv (BOD) 18-01 og operatører af kritisk infrastruktur, der oplever uautoriseret certifikatudstedelse (CA-kompromis eller BGP/DNS-kapring), bør rapportere til 1-844-Say-CISA (1-844-729-2472) eller cisa.gov/report.
  • Canadian Center for Cyber Security: Kontakt 1-833-CYBER-88 (1-833-292-3788).
  • Storbritannien:
  • Nødtjenester: Tast 999 hvis en TLS-afbrydelse påvirker kritiske NHS kliniske systemer eller livssikkerhed.
  • Nationalt Cybersikkerhedscenter (NCSC): Hvis du opdager et uautoriseret certifikat udstedt til dit domæne i Certificate Transparency (crt.sh) logfiler, der indikerer DNS-kapring, rapporter via ncsc.gov.uk.
  • Den Europæiske Union:
  • Nødtjenester: Tast 112 på tværs af alle EU-medlemslande.
  • NIS2-direktivet og eIDAS-kvalificerede webstedsgodkendelsescertifikater (QWACs): Væsentlige og vigtige enheder i henhold til NIS2-direktivet, der oplever et længerevarende tilgængelighedsudfald eller kompromitterede PKI-nøgler, skal underrette deres nationale CSIRT inden for 24 timer.
  • Australien og New Zealand:
  • Nødtjenester: Tast 000i Australien eller 111 i New Zealand; kontakt ACSC (1300 CYBER1) for infrastrukturhændelser.
  • Indien og Asien-Stillehavsområdet:
  • Indien (CERT-In / Controller for certificeringsmyndigheder CCA): Ring 112 til nødberedskab; rapportere PKI-kompromis eller væsentlige infrastrukturudfald til incident@cert-in.org.in inden for 6 timer.

Ofte stillede spørgsmål

Hvorfor kan jeg eller mine brugere ikke klikke på "Avanceret -> Fortsæt til webstedet (usikkert)" i Chrome eller Safari under denne afbrydelse?

Når dit domæne sender Streng-Transport-Sikkerhed (HSTS) HTTP-header - eller bruger et topdomæne som f.eks .dev, .app, .side, eller .bank der er hårdkodet i browserens HSTS Preload List - RFC 6797 kræver, at browseren behandler ethvert udløbet, selvsigneret eller uoverensstemmende certifikat som en fatal fejl, der ikke kan gendannes. Browseren fjerner bevidst omgå-knappen "Fortsæt alligevel" for at forhindre aktive Man-in-the-Middle (MitM)-angribere i at narre brugere til at klikke sig igennem et forfalsket certifikat. Mens en udvikler på skrivebordet Chrome kan skrive den skjulte tastatursekvens dette er usikkert direkte på fejlskærmen for at omgå den lokalt til test, kan rigtige brugere ikke; du skal installere et gyldigt certifikat på port 443.

Let's Encrypt stoppede med at sende advarselsmails om udløb, og mit certifikat udløb uden varsel - hvorfor skete det?

Let's Encrypt trak officielt sin udløbsmeddelelses-e-mail-tjeneste tilbage i midten af ​​2025 for at reducere dataopbevaringsomkostninger, og fordi automatiserede ACME-opsætninger skulle overvåge fornyelsestilstanden direkte. For at forhindre fremtidige overraskelser skal du overvåge det faktiske tidsstempel for TLS-håndtryks udløb over netværket ved hjælp af en ekstern oppetidsmonitor (såsom Prometheus blackbox_eksportør, Uptime Kuma, Better Stack eller Datadog Synthetic TLS-tjek) alarmering 21 dage, 14 dage og 7 dage før ikke Efter.

Hvorfor fungerer mit websted fint i Chrome og Firefox på min bærbare computer, men fejler på Android-telefoner, curl, og Stripe webhooks efter jeg har opdateret certifikatet?

Du har konfigureret din webserver (ssl_certifikat i Nginx eller SSLCertificateFile i Apache) at pege på cert.pem (alene bladattesten) i stedet for fuldkæde.pem (bladcertifikatet bundtet med det mellemliggende CA-certifikat). Desktopbrowsere som Chrome og Firefox downloader automatisk manglende mellemliggende certifikater i baggrunden ved hjælp af Authority Information Access (AIA) URL inde i dit bladcertifikat, skjuler din serverfejlkonfiguration. Men krølle, OpenSSL, Android's system trust verifier, Python og webhook-servere udfører ikke AIA-chasing og afviser straks forbindelsen med ude af stand til at få lokalt udstedercertifikat. Peg din konfiguration til fuldkæde.pem og genindlæs din server.

Hvordan kontrollerer jeg, om en hacker eller useriøs administrator har udstedt et uautoriseret SSL-certifikat til mit domæne?

Enhver offentligt betroet certifikatmyndighed er forpligtet til at logge alle udstedte certifikater til offentligheden Certificate Transparency (CT) logfiler (RFC 6962) før browsere vil stole på det. Åbn https://crt.sh/?q=%25.ditdomæne.com eller Cloudflares Certificate Transparency Monitor for at se alle certifikater, der nogensinde er udstedt for dit domæne og dets underdomæner. Hvis du ser et certifikat udstedt af en ukendt CA, som du ikke har autoriseret, skal du straks inspicere din DNS-registrator og autoritative DNS-zone for uautoriserede ændringer, tilbagekalde slyngelcertifikatet med den udstedende CA og låse din DNS med CAA optegnelser (`0 issue "letsencrypt.org"`).

Hvad hvis min Kubernetes-klynge er cert-manager undlod at forny vores Ingress-certifikat, og ordren sidder fast Pending?

Løb kubectl få orden, udfordring -A og derefter kubectl beskriver udfordring -n . I 90 procent af Kubernetes cert-manager udfald, den cm-acme-http-solver-* midlertidig pod kører, men enten (1) Ingress-ressourcen har en forældet ingress-klasseannotation, så løserruten aldrig er knyttet til din load balancer, (2) en Kubernetes Netværkspolitik blokerer indgående trafik til solver-pod'en på port 8089, eller (3) et hårnåls-NAT / split-horizon DNS-problem forhindrer cert-managers interne selvtjek fra at nå din offentlige loadbalancer IP (kan rettes ved at bestå --dns01-rekursive-navneservere=8.8.8.8:53,1.1.1.1:53 til cert-manager implementeringsargumenter).

Kan jeg kopiere min /etc/letsencrypt/ mappe til en ny server under en nødmigrering i stedet for at genudstede?

Ja. Hvis din primære server døde, og du migrerer til en ny server, mens den er begrænset af Let's Encrypt, skal du bevare symbollinks, når du kopierer /etc/letsencrypt/ bruger tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (brug aldrig almindelig scp -r, som slår symbollinks ind /etc/letsencrypt/live/ ind i dublerede statiske filer og bryder fremtidige fornyelser). Udpak det arkiv på den nye server (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), peg Nginx/Apache til `/etc/letsencrypt/live/domain/fullchain.pem`, og dit eksisterende certifikat vil straks virke på den nye IP-adresse.

Relaterede guider

Kilder og officiel vejledning

  • Internet Engineering Task Force (IETF): RFC 8555 (Automatic Certificate Management Environment / ACME), RFC 8659 (DNS Certification Authority Authorization / CAA) og RFC 6797 (HTTP Strict Transport Security / HSTS).
  • National Institute of Standards and Technology (NIST) (USA): Særlig publikation 800-52 Rev. 2: Retningslinjer for valg, konfiguration og brug af Transport Layer Security (TLS) implementeringer & SP 1800-16: Sikring af webtransaktioner: TLS Server Certificate Management.
  • Internet Security Research Group (ISRG / Lad os kryptere officiel dokumentation): Reference for prisgrænser, duplikatcertifikatregler og ACME Challenge-fejlfinding.
  • Cybersikkerheds- og Infrastruktursikkerhedsagentur (CISA) (USA): Bindende operationelle direktiv 18-01: Forbedring af e-mail- og websikkerhed (HTTPS- og HSTS-implementeringsvejledning).
  • Nationalt Cybersikkerhedscenter (NCSC) (Storbritannien): Brug af TLS til at beskytte data perfekt i transit og vejledning til overvågning af certifikatgennemsigtighed.