El certificat SSL/TLS de producció ha caducat: es corregeixen les interrupcions de fallada d'HSTS i xifrem els blocs CAA/límit de velocitat¶

Quan un SSL/TLS de producció (HTTPS) caduca el certificat, fins i tot un segon després del seu notAfter Marca de temps UTC: tots els navegadors moderns (Chrome, Safari, Firefox, Edge), aplicació mòbil (iOS App Transport Security, Android Network Security Config), receptor webhook (Stripe, Shopify, Twilio, GitHub), i el client de l'API aigües amunt talla immediatament la connectivitat NET::ERR_CERT_DATE_INVALID o SSL_ERROR_RX_RECORD_TOO_LONG. Pitjor encara, si el vostre domini envia el Strict-Transport-Security (HSTS) o es compila al navegador Llista de precàrrega de HSTS, Chrome i Safari eliminen completament el botó de desviació "Avançat -> Anar al lloc (no segur)", la qual cosa comporta un apagament del 100% per a tots els usuaris del món. Sovint, el cronjob de renovació automatitzada (Certbot, acme.sh, Caddy, cert-manager, o AWS ACM) ha fallat en silenci durant 30 dies a causa d'un DNS restrictiu CAA registre, un DNSSEC trencat DS registre, un port de bloqueig del tallafoc 80 (HTTP-01 desafiament), o un servidor web (nginx / haproxy) que va renovar el fitxer al disc (fullchain.pem), però mai no va tornar a carregar els seus processos de treball en memòria. Si la vostra interrupció va ser causada per un registre de domini caducat o per servidors de noms segrestats en lloc del propi certificat X.509, canvieu immediatament a segrest de noms de domini, DNS caducat i presa de possessió del lloc web; si el vostre servidor és completament inaccessible o no té espai en disc certbot no pot escriure a /etc/letsencrypt, veure disc del servidor 100% ple i recuperació sense espai o crisi d'allotjament web, migració i restauració de còpies de seguretat. Si aquest apagament TLS desactiva la telemetria hospitalària, les API d'enviament d'emergències o la infraestructura de seguretat pública, truqueu al vostre número d'emergència local (911 als Estats Units i al Canadà, 112 a tota la Unió Europea, 999 al Regne Unit) o consulteu el nostre directori internacional de números d'emergència.

Fes això ara¶

1. Comproveu d'aquí a 10 segons si el certificat del disc ja està renovat i el vostre servidor web o equilibrador de càrrega simplement no ha pogut tornar a carregar-lo a la memòria RAM:
2. Compareu el sòcol TLS en directe amb el .pem fitxer al disc ara mateix:

   # 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. Si el fitxer del disc mostra un futur vàlid notAfter data mentre el port viu 443 mostra una data de caducitat: el vostre client ACME (certbot / acme.sh) va tenir èxit fa setmanes, però nginx, apache2, haproxy, o postfix mai es va tornar a carregar, o (haproxy / vault) requereix fullchain.pem + privkey.pem concatenats en un sol feix. Corre sudo nginx -t && sudo systemctl reload nginx (o sudo systemctl reload apache2 haproxy) i la vostra interrupció finalitzarà en 2 segons.
4. ** NO córrer certbot renew --force-renewal repetidament en un bucle si la renovació falla**: Let's Encrypt imposa un límit de tarifa estricte de 5 certificats duplicats per 7 dies i 5 validacions fallides per compte, per nom d'amfitrió, per hora. Córrer --force-renewal cinc vegades en pànic sense arreglar el subjacent nginx recarrega o l'error de DNS/tallafoc bloquejarà el teu domini fora de l'emissió de Let's Encrypt durant un màxim de 7 dies.
5. Si arribeu a un límit de taxa de xifrat (429 Too Many Requests), canvieu el vostre client ACME a una segona autoritat de certificació pública gratuïta (ZeroSSL, Buypass Go SSL, o Google Trust Services) o afegiu un subdomini SAN immediatament:
6. Cada client d'ACME (certbot, acme.sh, caddy, cert-manager) pot sol·licitar un certificat de confiança gratuït d'una CA diferent en 30 segons (--server https://acme.zerossl.com/v2/DV90 o https://api.buypass.com/acme/directory), obviant completament el límit de velocitat de Let's Encrypt.
7. D'altra banda, el límit de "5 certificats duplicats per 7 dies" de Let's Encrypt només s'aplica al exacte mateix conjunt de noms alternatius de subjecte (SANs). Afegeix un subdomini vàlid addicional (-d example.com -d www.example.com -d tlsfix1.example.com) el converteix en un certificat no duplicat i passa per alt el límit de tarifa de certificats duplicats immediatament.
8. Comproveu si un DNS CAA registre o trencat DNSSEC està bloquejant l'emissió de la vostra autoritat de certificació (CAA record for example.com prevents issuance)*:
9. Consulteu l'autorització de l'autoritat de certificació del vostre domini (CAA) registres: dig +short CAA example.com. Si el vostre DNS té 0 issue "sectigo.com" o 0 issue "amazon.com" (o en un domini principal), Let's Encrypt (letsencrypt.org) i ZeroSSL (sectigo.com) està prohibit per RFC 8659 d'emetre fins que n'afegiu 0 issue "letsencrypt.org" a la vostra zona DNS.
10. Si port 80 (HTTP-01 desafiament) està bloquejat per un tallafoc, CDN o ISP, o si el vostre servidor web es nega a iniciar-se perquè falta un certificat, feu servir --standalone o --dns (DNS-01) validació:
11. Atureu-vos nginx/apache breument i córrer sudo certbot certonly --standalone -d example.com, o utilitzar --manual --preferred-challenges dns per validar enganxant a _acme-challenge.example.com TXT grava a la teva consola DNS sense tocar el port 80.
12. Si el vostre lloc es troba darrere de Cloudflare, AWS CloudFront o Fastly, verifiqueu si el certificat caducat es troba al CDN Edge o al vostre servidor Origin (Error 526 Invalid SSL Certificate)*:
13. A Cloudflare, si el certificat del servidor d'origen ha caducat i Cloudflare està configurat com a Full (Strict), els usuaris veuen Error 526. Mentre arregleu el certificat d'origen, podeu restaurar el trànsit del lloc en directe en 5 segons generant un certificat de CA d'origen de Cloudflare de 15 anys al tauler de control de Cloudflare (o canviant temporalment el mode SSL/TLS de Full (Strict) a Full durant els 10 minuts que triga a substituir l'origen .pem fitxer).

Arbre de decisió: diagnòstic i correcció d'un certificat SSL/TLS de producció caducat¶

Seguiu aquest arbre de decisió per identificar la capa de fallada exacta (CDN Edge vs. Origin Daemon Memory vs. ACME Challenge vs. CA Rate Limit) i restaura el trànsit HTTPS en qüestió de minuts:

flowchart TD
    Start["Usuaris/API que informen NET::ERR_CERT_DATE_INVALID o error 526 de Cloudflare"] --> CheckLive["Executeu: openssl s_client -servername domain -connect domain:443 | openssl x509 -noout -dates -emissor"]

    CheckLive --> WhereExpired{"Quin certificat està realment caducat?"}

    WhereExpired -->|"El disc fullchain.pem és vàlid, però el port en directe 443 HA CADUCAT"| StaleDaemon["Memòria del dimoni obsolet o botiga de certificats dividits: torneu a carregar nginx / apache2 / haproxy / postfix o reconstruïu el paquet PEM HAProxy combinat"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) ha caducat"| CDNFix["Comproveu els registres DNS CAA per a CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) i Commuteu SSL universal o Re-validar ACM"]
    WhereExpired -->|"El servidor d'origen fullchain.pem al disc ha caducat"| DryRun["Executeu: sudo certbot renew --dry-run (o acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"Per què va fallar la renovació d'ACME?"}

    WhyFailed -->|"429 Massa sol·licituds (límit de tarifa superat)"| RateLimit["Ometre immediatament: problema de ZeroSSL / Buypass / Google Trust Services O Afegiu 1 SAN de subdomini addicional (-d fix1.example.com)"]
    WhyFailed -->|"El registre CAA evita l'emissió o SERVFAIL (DNSSEC)"| CAADNS["Executeu: excava CAA example.com -> Afegeix 0 problema 'letsencrypt.org' (i 'sectigo.com') o corregeix el registre DNSSEC DS trencat al registre"]
    WhyFailed -->|"Connexió rebutjada / Temps d'espera / 404 a /.well-known/acme-challenge/"| HttpBlock["Port 80 bloquejat o bucle de redirecció: obriu el port TCP 80 al tallafoc, excloeu /.well-known/ de l'autenticació/reescritura o utilitzeu el desafiament DNS-01"]
    WhyFailed -->|"Comanda del gestor de certificats de Kubernetes bloquejada en pendent"| K8sFix["Executar: kubectl describe challenge -> Comprova l'anotació de la classe d'entrada, la política de xarxa de pod de solucionador HTTP01 o Webhook TLS"]

    StaleDaemon --> VerifyAll["Verifiqueu el grapat de cadena i OCSP: openssl s_client -connect domain:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Fase 1: entendre per què HSTS (Strict-Transport-Security) provoca una apagada total de fallada¶

Quan un lloc web no utilitza HSTS, un certificat caducat mostra un avís intersticial (Your connection is not private) amb un enllaç "Avançat -> Anar a example.com (no segur)" que permet als usuaris desesperats fer clic.

Tanmateix, gairebé totes les aplicacions web de producció modernes, bancs, plataformes SaaS i .dev / .app / .page / .bank els dominis de primer nivell imposen Seguretat de transport estricta HTTP (HSTS, RFC 6797): 1. ** HSTS dinàmic (max-age=31536000): qualsevol navegador que hagi visitat el vostre lloc durant els darrers 365 dies ha guardat la política a la memòria cau Strict-Transport-Security: max-age=31536000; includeSubDomains. Fins que expiri aquest temporitzador, el navegador prohibeix que l'usuari faci clic a qualsevol error de certificat (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, o ERR_CERT_AUTHORITY_INVALID). 2. Precàrrega HSTS estàtica (preload llista o .dev / .app gTLD): si el vostre domini s'ha enviat a hstspreload.org - o si el vostre domini utilitza un TLD precarregat al registre com .dev, .app, .page, .new, .chrome, o .bank - Cada còpia de Chrome, Edge, Firefox, Safari i Android WebView on Earth té el vostre domini codificat en el seu binari com a HSTS aplicat abans que l'usuari visiti el vostre lloc per primera vegada. 3. ** Per què includeSubDomains trenca les eines internes i els servidors de prova: si el vostre domini arrel (example.com) envia Strict-Transport-Security: max-age=31536000; includeSubDomains, cada subdomini (vpn.example.com, internal-jira.example.com, printer.example.com) també està bloquejat en el mode d'error dur HSTS. 4. Per què les integracions d'API i Webhook (Stripe, Twilio, Slack, iOS ATS) falla immediatament: clients TLS de servidor a servidor (libcurl, Python requests/urllib3, Node.js undici, Vés crypto/tls, Java SSLContext) realitza un RFC 5280 estricte notAfter validació per defecte i no tenen cap concepte de "clic a través de l'usuari". Durant una interrupció de TLS, els webhooks de Stripe i Shopify fallaran en el lliurament i entraran en cues de reintents de retrocés exponencial.

Fase 2: el diagnòstic de 60 segons: el certificat ja s'ha renovat al disc?¶

En aproximadament el 35 per cent de les interrupcions de producció de Let's Encrypt, el certificat es va renovar al disc fa setmanes per certbot.timer o acme.sh, però el dimoni en execució encara ofereix l'antic certificat caducat des de la memòria RAM.

Pas 1: compareu el sòcol de xarxa en directe amb el fitxer del disc¶

Executeu les dues ordres al vostre servidor:

# 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

Pas 2: solucioneu les 4 trampes comunes "Renovat al disc, caducat a la memòria RAM".¶

Fase 3: arreglar DNS CAA blocs de registre i DNSSEC errors de validació¶

Si corres sudo certbot renew --dry-run i mira: - 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. Com DNS CAA (RFC 8659) bloqueja la renovació del certificat¶

Totes les autoritats de certificació públiques estan obligades legalment als requisits bàsics de CA/Fòrum del navegador per consultar DNS CAA registres abans d'emetre qualsevol certificat. L'AC camina pujant l'arbre DNS des de sub.app.example.com -> app.example.com -> example.com: - Si example.com té zero CAA registres, qualsevol CA pot emetre. - Si example.com té ** fins i tot un sol CAA registre** (per exemple, 0 issue "amazon.com" s'afegeix automàticament quan algú va crear una distribució AWS CloudFront o 0 issue "digicert.com"), Totes les altres autoritats de certificació de la Terra tenen estrictament prohibit emetre un certificat per example.com o qualsevol dels seus subdominis. - A més, si demaneu un Certificat de comodí (*.example.com) i el teu domini defineix un específic 0 issuewild "ca.example" l'etiqueta, la CA comprova el issuewild propietat més que issue.

Diagnòstic i reparació instantània CAA blocs:¶

1. Comproveu CAA registres tant al nom d'amfitrió com al domini àpex:

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

2. També comproveu si sub.example.com és a CNAME apuntant a un altre domini (d'acord amb la RFC 8659, les CA també comproven el CAA registres en objectius CNAME).
3. Al tauler del vostre proveïdor de DNS (Cloudflare, Route 53, Cloud DNS, Namecheap), no suprimiu els existents CAA registres utilitzats pel vostre CDN o AWS ACM; en lloc d'això, afegiu addicional CAA registres que autoritzen Let's Encrypt i les vostres CA de còpia de seguretat:

   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"
   

   (Nota: ZeroSSL utilitza sectigo.com com el seu identificador CAA subjacent i Google Trust Services utilitza pki.goog.)
4. Espereu 60 segons perquè els vostres servidors de noms autoritzats s'actualitzin (dig @ns1.yourdns.com CAA example.com) i torna a executar immediatament sudo certbot renew. Atès que les CA realitzen cerques recursives en directe sense passar per la memòria cau pública en tornar a intentar, l'emissió té èxit immediatament.

2. Fixació DNS problem: SERVFAIL looking up CAA (DNSSEC desajust)¶

Let's Encrypt, Google Trust Services i ZeroSSL apliquen estrictament la validació DNSSEC a totes les cerques de DNS (A, AAAA, TXT, i CAA). Encara que un domini tingui no CAA registre, la CA ha de rebre un registre criptogràficament vàlid NOERROR (resposta buida) o NXDOMAIN (NSEC / NSEC3 negació autenticada de l'existència) resposta. - Si el vostre registrador de domini té un registre obsolet DS Registre (signatari de delegació) després de migrar els proveïdors de DNS (per exemple, passar de GoDaddy a Cloudflare o Route 53 sense desactivar primer DNSSEC), solucions recursives que obliguen a la devolució de DNSSEC SERVFAIL. - Verificar en 5 segons: corre delv @8.8.8.8 example.com CAA o prova a dnsviz.net. Si dig @8.8.8.8 example.com torna status: SERVFAIL mentre dig +cd @8.8.8.8 example.com (+cd = Comprovant Desactivat, ignorant DNSSEC) retorna la vostra adreça IP, la vostra cadena DNSSEC està trencada. Inicieu sessió al vostre registrador de dominis immediatament i elimineu el obsolet DS gravar o copiar l'actual DS paràmetres del vostre host DNS actiu.

Fase 4: eludir els límits de taxa de xifratge (429 Too Many Requests) durant una interrupció activa¶

Durant un incident caòtic, els enginyers sovint reinicien contenidors o executen certbot repetidament fins que Let's Encrypt rebutgi totes les sol·licituds amb: - 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

Els temps d'espera van des d'1 hora (per a autoritzacions fallides) fins a 7 dies (168 hores) (per al límit de 5 certificats duplicats). No espereu ni 1 hora ni 7 dies mentre el vostre lloc de producció estigui inactiva. Teniu dues solucions immediates i completament legítimes:

Solució alternativa A (millor): canvieu l'autoritat de certificació ACME a ZeroSSL, Buypass o Google Trust Services en 30 segons¶

El protocol ACME (RFC 8555) és un estàndard obert. Tots els navegadors i sistemes operatius principals confien en ZeroSSL (arrel Sectigo), Buypass Go SSL (CA noruega) i Google Trust Services (pki.goog) de manera idèntica a Let's Encrypt (ISRG Root X1). Cap d'ells comparteix límits de tarifa amb Let's Encrypt.

• Opció 1: emet immediatament via Certbot utilitzant Buypass Go SSL (no cal cap compte/clau EAB, validesa de 180 dies): (Nota: Buypass admet certificats multidominis de fins a 5 SAN, encara que no commodin *.example.com certificats)

  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
  

• Opció 2: emet immediatament via acme.sh (que per defecte és ZeroSSL o canvia les CA amb --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
  

• Opció 3: emissió mitjançant Google Trust Services (pki.goog) ACME públic: A Google Cloud Console (o mitjançant gcloud publicca external-account-keys create), genereu una vinculació de comptes externs gratuïta (EAB) tecleu en 10 segons i executeu:

  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
  

Solució alternativa B: supereu el límit de "5 certificats duplicats" de Let's Encrypt afegint un nom d'amfitrió SAN addicional¶

Anem a xifrar el límit de duplicats de 168 hores (too many certificates (5) already issued for this exact set of domains) fa un seguiment del conjunt alfabètic exacte de noms d'amfitrió SAN al certificat, mentre que el límit general de domini registrat és de 50 certificats per setmana. 1. Creeu un DNS inofensiu A registre que apunta al mateix servidor: tls-recovery-01.example.com -> <your_server_ip>. 2. Sol·liciteu el certificat amb els vostres dominis originals a més el nou nom d'amfitrió:

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

Fase 5: Arreglar trencats HTTP-01 reptes (Port 80) o utilitzant DNS-01 validació d'emergència¶

Quan certbot renew falla amb Timeout during connect (likely firewall problem) o Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (o 403), els servidors de validació de CA no poden arribar al vostre testimoni de desafiament HTTP al port TCP 80.

Per què HTTP-01 es trenca sobtadament en servidors que funcionaven fa 60 dies¶

1. Grup de seguretat al núvol/UFW/ iptables port tancat 80: algú ha endurit el tallafoc per permetre només el port 443 (HTTPS), oblidant que RFC 8555 HTTP-01 validació sempre comença al port HTTP 80 simple (tot i que seguirà a 301 redirigeix a https:// al port 443).
2. IPv6 trencat (AAAA) Registre: el vostre domini té un IPv4 (A) registre i un IPv6 (AAAA) registre. Let's Encrypt sempre prefereix IPv6 (AAAA) primer. Si la vostra adreça IPv6 està mal encaminada, bloquejada per ip6tables, o no lligat a Nginx (listen [::]:80;), la validació s'esgota tot i que IPv4 funciona bé.
3. ** Nginx / Encaminador d'aplicacions (React / Next.js / Django / Rails) intercepcions /.well-known/acme-challenge/**: El teu server bloqueja tot el trànsit al port 80 proxy (location / { proxy_pass http://localhost:3000; }) a una aplicació de fons en lloc de servir .well-known des del disc.

Dues solucions instantànies per trencat HTTP-01 validació¶

Solució 1: afegiu una prioritat alta dedicada /.well-known/acme-challenge/ bloc a Nginx (port 80)¶

Assegureu-vos que el vostre port 80 entri /etc/nginx/sites-enabled/ serveix fitxes ACME directament des de /var/www/letsencrypt abans qualsevol return 301 https://... o proxy_pass directiva:

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

Solució 2: ignora completament el port 80 i els servidors web amb un manual DNS-01 (TXT) repte¶

Si el port 80 està bloquejat per un ISP/tallafoc amunt o el vostre equilibrador de càrrega no pot encaminar .well-known a diversos nodes de fons, valideu-lo mitjançant DNS en 2 minuts:

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: verificació posterior a la recuperació (cadena intermèdia, grapat OCSP i purga de CDN)¶

Un error comú després de la substitució del certificat d'emergència és la instal·lació cert.pem (només el certificat de la fulla) en comptes de fullchain.pem (el certificat de fulla + certificat de CA intermedi). Navegadors d'escriptori (Chrome, Firefox) sovint emmascara un certificat intermedi que falta mitjançant AIA (Authority Information Access) perseguint o emmagatzemat en memòria cau intermediaris, mentre curl, Python, OpenSSL, les aplicacions d'Android i els webhooks Stripe/Twilio fallen immediatament amb unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• Verifiqueu que el vostre servidor envia la cadena intermèdia completa (fullchain.pem)*: Executar:

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

  Heu de veure almenys dos nivells (depth=0 el teu domini i depth=1 el CA intermedi com ara Let's Encrypt E5/R11 o ZeroSSL RSA Domain Secure Site CA) i Verify return code: 0 (ok). Si veus Verify return code: 21 (unable to verify the first certificate), canvieu la configuració del vostre servidor web des de cert.pem a fullchain.pem.
• Esborra la memòria cau de grapat OCSP obsoleta a Nginx / Apache: Si ssl_stapling on; està habilitat, torneu a carregar el servidor web i comproveu openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
• Configura la supervisió de caducitat de SSL multicapa (comprovació TCP externa + Prometheus blackbox_exporter)*: No confieu mai únicament en els recordatoris per correu electrònic (Let's Encrypt els correus electrònics de recordatori de caducitat discontinuats el 2025). Superviseu el sòcol del port 443 en directe externament (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) i configureu un control cron diari sudo certbot renew --dry-run.

Números d'emergència regionals i protocols de l'agència¶

Tot i que els equips d'enginyeria solen resoldre un certificat TLS caducat, una interrupció del certificat que trenca els portals d'assistència sanitària, els webhooks d'enviament d'emergència, l'autenticació bancària o la infraestructura pública del govern pot desencadenar fluxos de treball d'incidències reguladores:

• Estats Units i Canadà:
• Seguretat de la vida / Clínica / Interrupció d'enviament: Marqueu 911 si un error del certificat TLS talla la telemetria del pacient, la recepta electrònica o les comunicacions d'enviament d'emergència.
• Agència de Ciberseguretat i Seguretat de les Infraestructures (CISA) (EUA): les agències civils federals sota la Directiva operativa vinculant (BOD) 18-01 de la CISA i els operadors d'infraestructures crítiques que experimentin l'emissió de certificats no autoritzats (compromis CA o segrest de BGP/DNS) haurien d'informar a 1-844-Say-CISA (1-844-729-2472) o cisa.gov/report.
• Centre Canadien per a la Ciberseguretat: contacte 1-833-CYBER-88 (1-833-292-3788).
• Regne Unit:
• Serveis d'emergència: Marqueu 999 si una interrupció del TLS afecta els sistemes clínics crítics del NHS o la seguretat de la vida.
• Centre Nacional de Ciberseguretat (NCSC): si descobreix un certificat no autoritzat emès per al teu domini a Certificate Transparency (crt.sh) registres que indiquen el segrest de DNS, informe mitjançant ncsc.gov.uk.
• Unió Europea:
• Serveis d'emergència: Marqueu 112 a tots els estats membres de la UE.
• Directiva NIS2 i certificats d'autenticació de llocs web qualificats eIDAS (QWACs): les entitats essencials i importants sota la Directiva NIS2 que pateixen una interrupció prolongada de la disponibilitat o les claus PKI compromeses han de notificar-ho al seu CSIRT nacional en un termini de 24 hores.
• Austràlia i Nova Zelanda:
• Serveis d'emergència: Marqueu 000 a Austràlia o 111 a Nova Zelanda; contacteu amb l'ACSC (1300 CYBER1) per incidències d'infraestructures.
• Índia i Àsia-Pacífic:
• ** Índia (CERT-In / Controlador d'Autoritats de Certificació CCA)**: Marqueu 112 per a resposta d'emergència; Informeu-hi el compromís de PKI o les interrupcions importants de la infraestructura incident@cert-in.org.in en 6 hores.

Preguntes freqüents¶

Per què no podem ni jo ni els meus usuaris fer clic a "Avançat -> Anar al lloc (no segur)" a Chrome o Safari durant aquesta interrupció?¶

Quan el teu domini envia el Estricte-Transport-Seguretat (HSTS) Capçalera HTTP - o utilitza un domini de primer nivell com ara .dev, .app, .pàgina, o .banc que està codificat en dur a la llista de precàrrega HSTS del navegador: la RFC 6797 requereix que el navegador tracti qualsevol certificat caducat, autofirmat o que no coincideixi com un error fatal no recuperable. El navegador elimina intencionadament el botó de derivació "Continua de totes maneres" per evitar que els atacants actius Man-in-the-Middle (MitM) enganyin els usuaris perquè facin clic a través d'un certificat falsificat. Mentre que un desenvolupador a l'escriptori Chrome pot escriure la seqüència de teclat oculta això és insegur directament a la pantalla d'error per evitar-lo localment per provar, els usuaris reals no poden; heu d'instal·lar un certificat vàlid al port 443.

Let's Encrypt va deixar d'enviar correus electrònics d'advertència de caducitat i el meu certificat va caducar sense previ avís: per què va passar això?¶

Let's Encrypt va retirar oficialment el seu servei de correu electrònic de notificació de caducitat a mitjans del 2025 per reduir la sobrecàrrega de retenció de dades i perquè les configuracions automatitzades d'ACME haurien de controlar directament la salut de la renovació. Per evitar sorpreses futures, heu de supervisar la marca de temps real de caducitat de l'enllaç TLS a la xarxa mitjançant un monitor de temps d'activitat extern (com Prometheus blackbox_exporter, Uptime Kuma, Better Stack o Datadog Synthetic TLS checks) alertant amb 21 dies, 14 dies i 7 dies abans noDesprés.

Per què el meu lloc funciona bé a Chrome i Firefox al meu ordinador portàtil, però falla als telèfons Android? curl, i els webhooks de Stripe després d'actualitzar el certificat?¶

Has configurat el teu servidor web (certificat_ssl en Nginx o SSLCertificateFile a Apache) per assenyalar cert.pem (només el certificat de la fulla) en comptes de fullchain.pem (el certificat de fulla inclòs amb el certificat de CA intermedi). Els navegadors d'escriptori com Chrome i Firefox descarreguen automàticament els certificats intermedis que falten en segon pla mitjançant el Accés a la informació de l'autoritat (AIA) URL dins del vostre certificat de fulla, amagant la configuració incorrecta del vostre servidor. No obstant això, rínxol, OpenSSL, el verificador de confiança del sistema d'Android, Python i els servidors webhook no realitzen la persecució AIA i rebutgen immediatament la connexió amb no es pot obtenir el certificat de l'emissor local. Apunta la teva configuració a fullchain.pem i torneu a carregar el vostre servidor.

Com puc comprovar si un pirata informàtic o un administrador canalla ha emès un certificat SSL no autoritzat per al meu domini?¶

Totes les autoritats de certificació de confiança pública han de registrar tots els certificats emesos en públic Registres de transparència del certificat (CT). (RFC 6962) abans que els navegadors hi confiïn. Obert https://crt.sh/?q=%25.yourdomain.com o el Monitor de transparència de certificats de Cloudflare per veure tots els certificats emesos per al vostre domini i els seus subdominis. Si veieu un certificat emès per una CA desconeguda que no vau autoritzar, inspeccioneu immediatament el vostre registrador de DNS i la zona de DNS autoritzada per si hi ha modificacions no autoritzades, revoqueu el certificat no autoritzat amb la CA emissora i bloquegeu el vostre DNS amb CAA registres (`0 issue "letsencrypt.org"`).

Què passa si el meu clúster de Kubernetes? cert-manager no s'ha pogut renovar el nostre certificat d'entrada i la comanda està bloquejada Pending?¶

Corre kubectl obtenir ordre, desafiament -A i després kubectl descriu el desafiament -n . En el 90 per cent de Kubernetes certificat-gerent talls, el cm-acme-http-solver-* El pod temporal s'està executant, però (1) el recurs Ingress té una anotació de classe d'entrada obsoleta, de manera que la ruta del solucionador mai no s'adjunta al vostre equilibrador de càrrega, (2) un Kubernetes Política de xarxa està bloquejant el trànsit d'entrada al pod de solucionador al port 8089, o (3) un problema de DNS NAT / horitzó dividit impedeix certificat-gerentL'autocomprovació interna de l'usuari no arriba a la vostra IP pública d'equilibri de càrrega (que es pot arreglar passant --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 al certificat-gerent arguments de desplegament).

Puc copiar el meu? /etc/letsencrypt/ carpeta a un servidor nou durant una migració d'emergència en lloc de tornar a emetre?¶

Sí. Si el vostre servidor principal s'ha mort i esteu migrant a un nou servidor mentre la tarifa està limitada per Let's Encrypt, conserveu els enllaços simbòlics quan copieu /etc/letsencrypt/ utilitzant tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (no utilitzeu mai simple scp -r, que converteix els enllaços simbòlics /etc/letsencrypt/live/ en fitxers estàtics duplicats i trenca les renovacions futures). Extreu aquest arxiu al nou servidor (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), apunta Nginx/Apache a `/etc/letsencrypt/live/domain/fullchain.pem`, i el vostre certificat existent funcionarà immediatament a la nova adreça IP.

Guies relacionades¶

• Segrest de noms de domini, DNS caducat i presa de possessió del lloc web
• Disc del servidor 100% ple (0 bytes lliures): recuperació de base de dades i espai zero
• Bloqueig d'administrador de domini personalitzat de Google Workspace o Microsoft 365 i rescat de DNS TXT
• Crisi d'allotjament web, migració i restauració de còpies de seguretat
• Segrest de DNS, reconfiguració de WAN de l'encaminador ISP i falsificació de portal captiu
• Números d'emergència per països

Fonts i orientació oficial¶

• Grup de treball d'enginyeria d'Internet (IETF): RFC 8555 (Entorn de gestió automàtica de certificats / ACME), RFC 8659 (Autorització de l'autoritat de certificació DNS / CAA) i RFC 6797 (Seguretat del transport estricte HTTP / HSTS).
• Institut Nacional d'Estàndards i Tecnologia (NIST) (Estats Units): Publicació especial 800-52 Rev. 2: Directrius per a la selecció, configuració i ús d'implementacions de seguretat de la capa de transport (TLS) i SP 1800-16: Seguretat de transaccions web: gestió de certificats de servidor TLS.
• Grup de recerca de seguretat a Internet (ISRG / Encriptem la documentació oficial): Referència de límits de tarifes, regles de certificats duplicats i resolució de problemes del desafiament ACME.
• Agència de Ciberseguretat i Seguretat de les Infraestructures (CISA) (Estats Units): Directiva operativa vinculant 18-01: Millora de la seguretat del correu electrònic i del web (guia d'implementació HTTPS i HSTS).
• Centre Nacional de Ciberseguretat (NCSC) (Regne Unit): Utilització de TLS per protegir les dades perfectament en trànsit i Guia de seguiment de la transparència dels certificats.