Nag-expire na ang Sertipiko ng SSL/TLS ng Produksyon: Pag-aayos ng mga Hard-Fail Outage ng HSTS at Let's Encrypt CAA/Rate-Limit Blocks¶

Kapag ang isang produksyon SSL/TLS (HTTPS) certificate ay mag-e-expire - kahit na isang segundong lampas nito notAfter UTC timestamp - bawat modernong browser (Chrome, Safari, Firefox, Edge), mobile app (iOS App Transport Security, Android Network Security Config), webhook receiver (Stripe, Shopify, Twilio, GitHub), at ang upstream na API client ay agad na naghihiwalay ng koneksyon sa NET::ERR_CERT_DATE_INVALID o SSL_ERROR_RX_RECORD_TOO_LONG. Mas masahol pa, kung ipapadala ng iyong domain ang Strict-Transport-Security (HSTS) header o pinagsama-sama sa browser HSTS Preload List, tinanggal ng Chrome at Safari ang "Advanced -> Proceed to site (unsafe)" bypass button nang buo, na nagreresulta sa 100 porsyentong hard-fail blackout para sa bawat user sa buong mundo. Kadalasan, ang automated renewal cronjob (Certbot, acme.sh, Caddy, cert-manager, o AWS ACM) ay tahimik na nabigo sa loob ng 30 araw dahil sa isang mahigpit na DNS CAA record, isang sirang DNSSEC DS record, isang firewall blocking port 80 (HTTP-01 hamon), o isang web server (nginx / haproxy) na nag-renew ng file sa disk (fullchain.pem) ngunit hindi kailanman na-reload ang mga proseso ng manggagawang nasa memorya nito. Kung ang iyong pagkawala ay sanhi ng isang nag-expire na pagpaparehistro ng domain o mga na-hijack na nameserver sa halip na ang X.509 certificate mismo, lumipat kaagad sa pag-hijack ng domain name, nag-expire na DNS, at pagkuha ng website; kung ang iyong server ay ganap na hindi maabot o wala sa espasyo sa disk kaya certbot hindi maaaring sumulat sa /etc/letsencrypt, tingnan mo server disk 100% puno at zero-space recovery o krisis sa web hosting, migration, at backup na pagpapanumbalik. Kung hindi pinapagana ng TLS blackout na ito ang telemetry ng ospital, mga emergency dispatch API, o pampublikong imprastraktura ng kaligtasan, tawagan ang iyong lokal na numero ng emergency (911 sa Estados Unidos at Canada, 112 sa buong European Union, 999 sa United Kingdom) o kumonsulta sa aming internasyonal na direktoryo ng mga numerong pang-emergency.

Gawin ito ngayon¶

1. Suriin sa loob ng 10 segundo kung talagang na-renew na ang certificate sa disk, at nabigo lang na i-reload ito ng iyong web server o load balancer sa RAM:
2. Ihambing ang live na TLS socket laban sa .pem file sa disk ngayon:

   # 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. Kung ang file sa disk ay nagpapakita ng wastong hinaharap notAfter petsa habang ang live port 443 nagpapakita ng expired date: Ang iyong ACME client (certbot / acme.sh) nagtagumpay ilang linggo na ang nakalipas, ngunit nginx, apache2, haproxy, o postfix ay hindi kailanman na-reload, o (haproxy / vault) nangangailangan fullchain.pem + privkey.pem pinagsama-sama sa iisang bundle. Takbo sudo nginx -t && sudo systemctl reload nginx (o sudo systemctl reload apache2 haproxy) at matatapos ang iyong pagkawala sa loob ng 2 segundo.
4. HUWAG tumakbo certbot renew --force-renewal paulit-ulit sa isang loop kung nabigo ang pag-renew: Ang Let's Encrypt ay nagpapatupad ng mahigpit na limitasyon sa rate na 5 duplicate na certificate bawat 7 araw at 5 nabigong validation bawat account, bawat hostname, bawat oras. Tumatakbo --force-renewal limang beses sa isang gulat nang hindi inaayos ang pinagbabatayan nginx i-reload o i-lock ng DNS/firewall bug ang iyong domain mula sa pag-isyu ng Let's Encrypt nang hanggang 7 araw.
5. Kung naabot mo ang Let's Encrypt Rate Limit (429 Too Many Requests), ilipat ang iyong ACME client sa pangalawang libreng pampublikong Certificate Authority (ZeroSSL, Buypass Go SSL, o Google Trust Services) o magdagdag kaagad ng itinapon na subdomain na SAN:
6. Bawat kliyente ng ACME (certbot, acme.sh, caddy, cert-manager) ay maaaring humiling ng isang libreng pinagkakatiwalaang sertipiko mula sa ibang CA sa loob ng 30 segundo (--server https://acme.zerossl.com/v2/DV90 o https://api.buypass.com/acme/directory), ganap na lumalampas sa limitasyon ng rate ng Let's Encrypt.
7. Bilang kahalili, ang limitasyon ng Let's Encrypt na "5 duplicate na certificate kada 7 araw" ay nalalapat lamang sa eksaktong parehong hanay ng Mga Pangalan ng Alternatibong Paksa (SANs). Pagdaragdag ng isang karagdagang wastong subdomain (-d example.com -d www.example.com -d tlsfix1.example.com) ginagawa itong hindi duplicate na certificate at nilalampasan kaagad ang limitasyon sa rate ng Duplicate na Certificate.
8. Suriin kung isang DNS CAA record o nasira DNSSEC ay humahadlang sa iyong Certificate Authority mula sa pagbibigay (CAA record for example.com prevents issuance):
9. I-query ang Awtorisasyon ng Certification Authority ng iyong domain (CAA) mga talaan: dig +short CAA example.com. Kung mayroon ang iyong DNS 0 issue "sectigo.com" o 0 issue "amazon.com" (o sa isang parent domain), Let's Encrypt (letsencrypt.org) at ZeroSSL (sectigo.com) ay ipinagbabawal ng RFC 8659 na mag-isyu hanggang sa magdagdag ka 0 issue "letsencrypt.org" sa iyong DNS zone.
10. Kung port 80 (HTTP-01 hamon) ay hinarangan ng isang firewall, CDN, o ISP, o kung ang iyong web server ay tumangging magsimula dahil sa isang nawawalang cert, gamitin --standalone o --dns (DNS-01) pagpapatunay:
11. Tumigil ka nginx/apache saglit at tumakbo sudo certbot certonly --standalone -d example.com, o gamitin --manual --preferred-challenges dns upang patunayan sa pamamagitan ng pagdikit ng a _acme-challenge.example.com TXT record sa iyong DNS console nang hindi hinahawakan ang port 80.
12. Kung ang iyong site ay nasa likod ng Cloudflare, AWS CloudFront, o Fastly, i-verify kung ang nag-expire na certificate ay nasa CDN Edge o sa iyong Origin Server (Error 526 Invalid SSL Certificate):
13. Sa Cloudflare, kung nag-expire ang certificate ng iyong pinagmulan ng server at nakatakda ang Cloudflare sa Full (Strict), nakikita ng mga user ang Error 526. Habang inaayos mo ang origin certificate, maaari mong ibalik ang live na trapiko sa site sa loob ng 5 segundo sa pamamagitan ng pagbuo ng 15-taong Cloudflare Origin CA certificate sa Cloudflare dashboard (o pansamantalang paglipat ng SSL/TLS mode mula sa Full (Strict) sa Full para sa 10 minutong kinakailangan upang palitan ang pinanggalingan .pem file).

Decision tree: pag-diagnose at pag-aayos ng expired na production SSL/TLS certificate¶

Sundin ang decision tree na ito upang matukoy ang eksaktong failure layer (CDN Edge vs. Origin Daemon Memory vs. ACME Challenge vs. CA Rate Limit) at ibalik ang trapiko ng HTTPS sa ilang minuto:

flowchart TD
    Start["Pag-uulat ng Mga User / API NET::ERR_CERT_DATE_INVALID o Cloudflare Error 526"] --> CheckLive["Run: openssl s_client -servername domain -connect domain:443 | openssl x509 -noout -dates -issuer"]

    CheckLive --> WhereExpired{"Aling Sertipiko ang Talagang Nag-expire?"}

    WhereExpired -->|"Ang disk fullchain.pem ay VALID, Ngunit ang Live Port 443 ay EXPIRED"| StaleDaemon["Stale Daemon Memory o Split Cert Store: I-reload ang nginx / apache2 / haproxy / postfix, o Rebuild Combined HAProxy PEM Bundle"]
    WhereExpired -->|"Nag-expire na ang CDN Edge Cert (Cloudflare / CloudFront / Mabilis)."| CDNFix["Suriin ang DNS CAA Records para sa CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) at I-toggle ang Universal SSL o Re-Validate ang ACM"]
    WhereExpired -->|"Ang Origin Server fullchain.pem sa Disk ay EXPIRED"| DryRun["Run: sudo certbot renew --dry-run (o acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"Bakit Nabigo ang Pag-renew ng ACME?"}

    WhyFailed -->|"429 Masyadong Maraming Kahilingan (Lampas na sa Limit ng Rate)"| RateLimit["Bypass Kaagad: Isyu mula sa ZeroSSL / Buypass / Google Trust Services O Magdagdag ng 1 Dagdag na Subdomain SAN (-d fix1.example.com)"]
    WhyFailed -->|"Pinipigilan ng CAA Record ang Issuance o SERVFAIL (DNSSEC)"| CAADNS["Run: dig CAA example.com -> Add 0 issue 'letsencrypt.org' (at 'sectigo.com') o Ayusin ang Sirang DNSSEC DS Record sa Registrar"]
    WhyFailed -->|"Tinanggihan ang Koneksyon / Timeout / 404 sa /.well-known/acme-challenge/"| HttpBlock["Na-block o Redirect Loop ang Port 80: Buksan ang TCP Port 80 sa Firewall, Ibukod ang /.well-known/ mula sa Auth/Rewrite, o Gamitin ang DNS-01 Challenge"]
    WhyFailed -->|"Natigil ang Order ng Kubernetes cert-manager na Nakabinbin"| K8sFix["Run: kubectl describe challenge -> Suriin ang Ingress class annotation, HTTP01 solver pod network policy, o Webhook TLS"]

    StaleDaemon --> VerifyAll["I-verify ang Chain at OCSP Stapling: openssl s_client -connect domain:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Phase 1: Pag-unawa kung bakit HSTS (Strict-Transport-Security) ay nagdudulot ng kabuuang hard-fail blackout¶

Kapag ang isang website ay hindi gumagamit ng HSTS, ang isang nag-expire na certificate ay nagpapakita ng isang interstitial na babala (Your connection is not private) na may link na "Advanced -> Magpatuloy sa example.com (hindi ligtas)" na nagbibigay-daan sa mga desperadong user na mag-click.

Gayunpaman, halos lahat ng modernong produksyon ng web application, mga bangko, SaaS platform, at .dev / .app / .page / .bank ipinapatupad ng mga top-level na domain HTTP Strict Transport Security (HSTS, RFC 6797): 1. Dynamic na HSTS (max-age=31536000): Ang anumang browser na bumisita sa iyong site sa loob ng nakalipas na 365 araw ay nag-cache ng patakaran Strict-Transport-Security: max-age=31536000; includeSubDomains. Hanggang sa mag-expire ang timer na iyon, ang browser pinagbabawal ang user na mag-click sa anumang error sa certificate (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, o ERR_CERT_AUTHORITY_INVALID). 2. Static HSTS Preload (preload listahan o .dev / .app gTLD): Kung isinumite ang iyong domain sa hstspreload.org - o kung ang iyong domain ay gumagamit ng Registry-Preloaded TLD na tulad .dev, .app, .page, .new, .chrome, o .bank - bawat kopya ng Chrome, Edge, Firefox, Safari, at Android WebView sa Earth ay naka-hardcode ang iyong domain sa binary nito bilang ipinapatupad ng HSTS bago bumisita ang user sa iyong site sa unang pagkakataon. 3. Bakit includeSubDomains sinisira ang mga panloob na tool at staging server: Kung ang iyong root domain (example.com) nagpapadala Strict-Transport-Security: max-age=31536000; includeSubDomains, bawat subdomain (vpn.example.com, internal-jira.example.com, printer.example.com) ay naka-lock din sa HSTS hard-fail mode. 4. Bakit ang pagsasama ng API at Webhook (Stripe, Twilio, Slack, iOS ATS) nabigo kaagad: Server-to-server TLS clients (libcurl, sawa requests/urllib3, Node.js undici, Go crypto/tls, Java SSLContext) magsagawa ng mahigpit na RFC 5280 notAfter pagpapatunay bilang default at walang konsepto ng isang user na "click-through." Sa panahon ng TLS outage, ang Stripe at Shopify webhooks ay mabibigo sa paghahatid at papasok sa exponential backoff retry queue.

Phase 2: Ang 60-segundong diagnostic - Talaga bang na-renew na ang certificate sa disk?¶

Sa humigit-kumulang 35 porsiyento ng mga pagkawala ng produksyon na Let's Encrypt, ang certificate ay aktwal na na-renew sa disk ilang linggo na ang nakalipas ng certbot.timer o acme.sh, ngunit ang tumatakbong daemon ay naghahatid pa rin ng lumang nag-expire na sertipiko mula sa RAM.

Hakbang 1: Ihambing ang live network socket laban sa on-disk file¶

Patakbuhin ang parehong mga utos sa iyong 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

Hakbang 2: Ayusin ang 4 na karaniwang "Na-renew sa Disk, Nag-expire sa RAM" na mga traps¶

Phase 3: Pag-aayos ng DNS CAA mga bloke ng record at DNSSEC mga pagkabigo sa pagpapatunay¶

Kung tatakbo ka sudo certbot renew --dry-run at tingnan: - 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. Paano DNS CAA (RFC 8659) hinaharangan ang pag-renew ng sertipiko¶

Ang bawat pampublikong Awtoridad ng Sertipiko ay legal na inaatasan ng CA/Browser Forum Baseline Requirements na mag-query ng DNS CAA mga talaan bago mag-isyu ng anumang sertipiko. Ang CA ay naglalakad paakyat sa puno ng DNS mula sa sub.app.example.com -> app.example.com -> example.com: - Kung example.com ay may zero CAA records, anumang CA ay pinapayagang mag-isyu. - Kung example.com may kahit isang single CAA record (halimbawa, 0 issue "amazon.com" awtomatikong idinagdag kapag may gumawa ng pamamahagi ng AWS CloudFront, o 0 issue "digicert.com"), bawat ibang Certificate Authority sa Earth ay mahigpit na ipinagbabawal na mag-isyu ng certificate para sa example.com o alinman sa mga subdomain nito. - Higit pa rito, kung humihiling ka ng Wildcard certificate (*.example.com) at ang iyong domain ay tumutukoy ng isang partikular 0 issuewild "ca.example" tag, sinusuri ng CA ang issuewild ari-arian sa halip na issue.

Diagnostic at agarang pag-aayos para sa CAA mga bloke:¶

1. Suriin CAA mga tala sa parehong hostname at tuktok na domain:

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

2. Suriin din kung sub.example.com ay a CNAME na tumuturo sa isa pang domain (Bawat RFC 8659, tingnan din ng mga CA ang CAA mga tala sa mga target ng CNAME).
3. Sa dashboard ng iyong DNS provider (Cloudflare, Route 53, Cloud DNS, Namecheap), huwag tanggalin ang umiiral na CAA mga tala na ginagamit ng iyong CDN o AWS ACM; sa halip, magdagdag ng karagdagang CAA mga talaan na nagpapahintulot sa Let's Encrypt at sa iyong mga backup na CA:

   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"
   

   (Tandaan: ZeroSSL ay gumagamit sectigo.com bilang pinagbabatayan nitong CAA identifier, at ginagamit ng Google Trust Services pki.goog.)
4. Maghintay ng 60 segundo para mag-update ang iyong mga authoritative nameserver (dig @ns1.yourdns.com CAA example.com) at agad na muling tumakbo sudo certbot renew. Dahil nagsasagawa ang mga CA ng live na recursive lookup na lumalampas sa mga pampublikong cache sa muling pagsubok, agad na nagtagumpay ang pag-isyu.

2. Pag-aayos DNS problem: SERVFAIL looking up CAA (DNSSEC hindi tugma)¶

Ang Let's Encrypt, Google Trust Services, at ZeroSSL ay mahigpit na nagpapatupad ng DNSSEC validation sa lahat ng DNS lookup (A, AAAA, TXT, at CAA). Kahit na ang isang domain ay mayroong no CAA record, ang CA ay dapat makatanggap ng cryptographically valid NOERROR (walang laman na sagot) o NXDOMAIN (NSEC / NSEC3 authenticated denial of existence) tugon. - Kung ang iyong domain registrar ay may hawak na isang lipas na DS (Delegation Signer) record pagkatapos mong mag-migrate ng mga DNS provider (halimbawa, paglipat mula sa GoDaddy patungong Cloudflare o Route 53 nang hindi muna pinapagana ang DNSSEC), mga recursive na solver na nagpapatupad ng DNSSEC return SERVFAIL. - I-verify sa loob ng 5 segundo: Patakbuhin delv @8.8.8.8 example.com CAA o pagsubok sa dnsviz.net. Kung dig @8.8.8.8 example.com nagbabalik status: SERVFAIL habang dig +cd @8.8.8.8 example.com (+cd = Ibinabalik ng Checking Disabled, hindi pinapansin ang DNSSEC) ang iyong IP address, nasira ang iyong DNSSEC chain. Mag-log in kaagad sa iyong domain registrar at alisin ang lipas DS itala o kopyahin ang kasalukuyang DS mga parameter mula sa iyong aktibong DNS host.

Phase 4: Pag-bypass sa Let's Encrypt Rate Limits (429 Too Many Requests) sa panahon ng aktibong pagkasira¶

Sa panahon ng isang magulong insidente, ang mga inhinyero ay madalas na nag-restart ng mga lalagyan o tumatakbo certbot paulit-ulit hanggang sa tanggihan ng Let's Encrypt ang lahat ng mga kahilingan na may: - 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

Ang mga oras ng paghihintay ay mula 1 oras (para sa mga nabigong pahintulot) hanggang 7 araw (168 oras) (para sa 5 duplicate na limitasyon sa mga certificate). Huwag maghintay ng 1 oras o 7 araw habang hindi gumagana ang iyong production site. Mayroon kang dalawang ganap na lehitimong, agarang solusyon:

Workaround A (Pinakamahusay): Ilipat ang ACME Certificate Authority sa ZeroSSL, Buypass, o Google Trust Services sa loob ng 30 segundo¶

Ang ACME protocol (RFC 8555) ay isang bukas na pamantayan. Ang bawat pangunahing browser at operating system ay nagtitiwala ZeroSSL (Sectigo root), Buypass Go SSL (Norwegian CA), at Google Trust Services (pki.goog) kapareho ng Let's Encrypt (ISRG Root X1). Wala sa kanila ang nagbabahagi ng mga limitasyon sa rate sa Let's Encrypt.

• Pagpipilian 1: Mag-isyu kaagad sa pamamagitan ng Certbot gamit ang Buypass Go SSL (Walang kinakailangang account/EAB key, 180-araw na validity): (Tandaan: Sinusuportahan ng Buypass ang mga multi-domain na certificate hanggang sa 5 SAN, bagama't hindi wildcard *.example.com mga sertipiko)

  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
  

• Pagpipilian 2: Mag-isyu kaagad sa pamamagitan ng acme.sh (na nagde-default sa ZeroSSL o nagpapalit ng mga CA gamit ang --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
  

• Pagpipilian 3: Isyu sa pamamagitan ng Google Trust Services (pki.goog) Pampublikong ACME: Sa Google Cloud Console (o sa pamamagitan ng gcloud publicca external-account-keys create), bumuo ng isang libreng External Account Binding (EAB) key sa loob ng 10 segundo at tumakbo:

  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
  

Workaround B: I-bypass ang limitasyon ng Let's Encrypt "5 Duplicate Certificates" sa pamamagitan ng pagdaragdag ng dagdag na SAN hostname¶

Let's Encrypt's 168-hour duplicate limit (too many certificates (5) already issued for this exact set of domains) sinusubaybayan ang eksaktong alpabetikong hanay ng mga hostname ng SAN sa certificate, samantalang ang kabuuang limitasyon sa Rehistradong Domain ay 50 certificate bawat linggo. 1. Gumawa ng hindi nakakapinsalang DNS A record na tumuturo sa parehong server: tls-recovery-01.example.com -> <your_server_ip>. 2. Hilingin ang certificate sa iyong orihinal na mga domain plus ang bagong hostname:

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

Phase 5: Pag-aayos ng sira HTTP-01 mga hamon (Port 80) o gamit DNS-01 pang-emergency na pagpapatunay¶

kailan certbot renew nabigo sa Timeout during connect (likely firewall problem) o Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (o 403), hindi maabot ng mga CA validation server ang iyong HTTP challenge token sa TCP port 80.

Bakit HTTP-01 biglang nasira sa mga server na gumana 60 araw na ang nakalipas¶

1. Cloud Security Group / UFW / iptables isinara ang Port 80: May nagpatigas sa firewall upang payagan lamang ang port 443 (HTTPS), nakalimutan ang RFC 8555 na iyon HTTP-01 validation palaging nagsisimula sa plain HTTP port 80 (bagaman ito ay susunod sa a 301 i-redirect sa https:// sa port 443).
2. Sirang IPv6 (AAAA) Record: Ang iyong domain ay parehong may IPv4 (A) record at isang IPv6 (AAAA) talaan. Let's Encrypt laging mas pinipili ang IPv6 (AAAA) muna. Kung ang iyong IPv6 address ay mali ang ruta, hinarangan ni ip6tables, o hindi nakatali sa Nginx (listen [::]:80;), naubos ang validation kahit na gumagana nang maayos ang IPv4.
3. Nginx / Application Router (React / Next.js / Django / Rails) humarang /.well-known/acme-challenge/: Iyong server harangan sa port 80 ang lahat ng trapiko (location / { proxy_pass http://localhost:3000; }) sa isang backend app sa halip na ihatid .well-known mula sa disk.

Dalawang instant na pag-aayos para sa nasira HTTP-01 pagpapatunay¶

Ayusin 1: Magdagdag ng nakalaang mataas na priyoridad /.well-known/acme-challenge/ block sa Nginx (Port 80)¶

Tiyaking naka-block ang iyong port 80 /etc/nginx/sites-enabled/ naghahatid ng mga token ng ACME nang direkta mula sa /var/www/letsencrypt bago anuman return 301 https://... o proxy_pass direktiba:

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

Ayusin ang 2: I-bypass ang Port 80 at mga web server nang buo gamit ang isang manwal DNS-01 (TXT) hamon¶

Kung ang port 80 ay na-block ng isang upstream na ISP/firewall o hindi maaaring ruta ng iyong load balancer .well-known sa maraming backend node, i-validate sa pamamagitan ng DNS sa loob ng 2 minuto:

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

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

Phase 6: Pag-verify pagkatapos ng pagbawi (Intermediate Chain, OCSP Stapling, at CDN Purge)¶

Isang karaniwang pagkakamali pagkatapos ng pag-install ng emergency certificate cert.pem (ang sertipiko ng dahon lamang) sa halip na fullchain.pem (ang leaf certificate + intermediate CA certificate). Mga desktop browser (Chrome, Firefox) madalas na nagtatakip ng nawawalang intermediate na sertipiko sa pamamagitan ng AIA (Authority Information Access) humahabol o naka-cache na mga intermediate, habang curl, Python, OpenSSL, Android apps, at Stripe/Twilio webhooks ay nabigo kaagad sa unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• I-verify na ipinapadala ng iyong server ang kumpletong Intermediate Chain (fullchain.pem): Patakbuhin:

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

  Dapat mong makita ang hindi bababa sa dalawang antas (depth=0 iyong domain at depth=1 ang intermediate CA tulad ng Let's Encrypt E5/R11 o ZeroSSL RSA Domain Secure Site CA) at Verify return code: 0 (ok). Kung nakikita mo Verify return code: 21 (unable to verify the first certificate), baguhin ang config ng iyong web server mula sa cert.pem sa fullchain.pem.
• I-clear ang lipas na OCSP Stapling cache sa Nginx / Apache: Kung ssl_stapling on; ay pinagana, i-reload ang web server at suriin openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
• I-configure ang multi-layer SSL expiration monitoring (External TCP check + Prometheus blackbox_exporter): Huwag umasa lamang sa mga paalala sa email (Let's Encrypt discontinued expiration reminder emails in 2025). Subaybayan ang live port 443 socket sa labas (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) at magtakda ng pang-araw-araw na cron check sa sudo certbot renew --dry-run.

Mga panrehiyong numero ng emergency at mga protocol ng ahensya¶

Bagama't ang isang nag-expire na TLS certificate ay karaniwang niresolba ng mga engineering team, ang isang certificate outage na sumisira sa mga portal ng pangangalagang pangkalusugan, mga webhook ng emergency na pagpapadala, pagpapatotoo sa pagbabangko, o pampublikong imprastraktura ng pamahalaan ay maaaring mag-trigger ng mga daloy ng trabaho sa insidente ng regulasyon:

• Estados Unidos at Canada:
• Life-Safety / Clinical / Dispatch Outage: Dial 911 kung ang pagkabigo ng TLS certificate ay pumutol sa telemetry ng pasyente, e-prescribing, o emergency na komunikasyon sa pagpapadala.
• Cybersecurity at Infrastructure Security Agency (CISA) (US): Ang mga pederal na ahensyang sibilyan sa ilalim ng CISA Binding Operational Directive (BOD) 18-01 at mga kritikal na operator ng imprastraktura na nakakaranas ng hindi awtorisadong pag-isyu ng certificate (CA compromise o BGP/DNS hijacking) ay dapat mag-ulat sa 1-844-Say-CISA (1-844-729-2472) o cisa.gov/report.
• Canadian Center para sa Cyber Security: Makipag-ugnayan 1-833-CYBER-88 (1-833-292-3788).
• United Kingdom:
• Mga Serbisyong Pang-emergency: I-dial 999 kung ang isang TLS outage ay nakakaapekto sa mga kritikal na sistema ng NHS o kaligtasan ng buhay.
• National Cyber Security Center (NCSC): Kung matuklasan mo ang isang hindi awtorisadong certificate na ibinigay para sa iyong domain sa Certificate Transparency (crt.sh) mga log na nagpapahiwatig ng pag-hijack ng DNS, mag-ulat sa pamamagitan ng ncsc.gov.uk.
• European Union:
• Mga Serbisyong Pang-emergency: I-dial 112 sa lahat ng estadong miyembro ng EU.
• NIS2 Directive at eIDAS Qualified Website Authentication Certificates (QWACs): Ang mga mahahalaga at mahahalagang entity sa ilalim ng NIS2 Directive na nakakaranas ng matagal na pagkawala ng kakayahang magamit o nakompromiso ang mga key ng PKI ay dapat ipaalam sa kanilang pambansang CSIRT sa loob ng 24 na oras.
• Australia at New Zealand:
• Mga Serbisyong Pang-emergency: I-dial 000 sa Australia o 111 sa New Zealand; makipag-ugnayan sa ACSC (1300 CYBER1) para sa mga insidente sa imprastraktura.
• India at Asia-Pacific:
• India (CERT-In / Controller ng Mga Awtoridad na Nagpapatunay CCA): I-dial 112 para sa emergency na pagtugon; mag-ulat ng kompromiso ng PKI o makabuluhang pagkasira ng imprastraktura sa incident@cert-in.org.in sa loob ng 6 na oras.

Mga madalas itanong¶

Bakit hindi ko ma-click o ng aking mga user ang "Advanced -> Magpatuloy sa site (hindi ligtas)" sa Chrome o Safari sa panahon ng outage na ito?¶

Kapag ipinadala ng iyong domain ang Strict-Transport-Security (HSTS) HTTP header - o gumagamit ng top-level na domain tulad ng .dev, .app, .page, o .bangko na naka-hardcode sa browser na HSTS Preload List - Ang RFC 6797 ay nangangailangan ng browser na ituring ang anumang expired, self-signed, o hindi tugmang certificate bilang isang hindi mababawi na nakamamatay na error. Sinasadya ng browser na alisin ang "Magpatuloy pa rin" na bypass na button upang maiwasan ang mga aktibong Man-in-the-Middle (MitM) na umaatake na linlangin ang mga user na mag-click sa isang spoofed certificate. Habang ang isang developer sa desktop ay maaaring i-type ng Chrome ang nakatagong pagkakasunud-sunod ng keyboard ito ay ligtas direkta sa screen ng error upang i-bypass ito nang lokal para sa pagsubok, hindi magagawa ng mga tunay na user; dapat kang mag-install ng valid na certificate sa port 443.

Ang Let's Encrypt ay huminto sa pagpapadala ng mga email ng babala sa pag-expire at ang aking cert ay nag-expire nang walang abiso - bakit nangyari iyon?¶

Opisyal na itinigil ng Let's Encrypt ang serbisyong email nito sa pag-expire ng notification sa kalagitnaan ng 2025 upang bawasan ang overhead ng pagpapanatili ng data at dahil dapat direktang subaybayan ng mga naka-automate na ACME setup ang kalusugan ng pag-renew. Upang maiwasan ang mga sorpresa sa hinaharap, dapat mong subaybayan ang aktwal na TLS handshake expiration timestamp sa network gamit ang isang panlabas na uptime monitor (tulad ng Prometheus blackbox_exporter, Uptime Kuma, Better Stack, o Datadog Synthetic TLS checks) na nag-aalerto sa 21 araw, 14 na araw, at 7 araw bago hindiPagkatapos.

Bakit gumagana nang maayos ang aking site sa Chrome at Firefox sa aking laptop, ngunit nabigo sa mga Android phone, curl, at Stripe webhooks pagkatapos kong i-update ang certificate?¶

Na-configure mo ang iyong web server (ssl_certificate sa Nginx o SSLCertificateFile sa Apache) upang ituro cert.pem (ang sertipiko ng dahon lamang) sa halip na fullchain.pem (ang leaf certificate na kasama ng Intermediate CA certificate). Ang mga desktop browser tulad ng Chrome at Firefox ay awtomatikong nagda-download ng mga nawawalang intermediate na certificate sa background gamit ang Authority Information Access (AIA) URL sa loob ng iyong leaf cert, itinatago ang maling configuration ng iyong server. gayunpaman, kulot, OpenSSL, system trust verifier ng Android, Python, at webhook server ay hindi nagsasagawa ng AIA chasing at agad na tinatanggihan ang koneksyon sa hindi makakuha ng sertipiko ng lokal na tagabigay. Ituro ang iyong config sa fullchain.pem at i-reload ang iyong server.

Paano ko malalaman kung ang isang hacker o rogue admin ay nagbigay ng hindi awtorisadong SSL certificate para sa aking domain?¶

Ang bawat pinagkakatiwalaang publiko na Awtoridad ng Sertipiko ay kinakailangang i-log ang bawat ibinigay na sertipiko sa publiko Mga log ng Certificate Transparency (CT). (RFC 6962) bago ito pagkatiwalaan ng mga browser. Bukas https://crt.sh/?q=%25.yourdomain.com o ang Certificate Transparency Monitor ng Cloudflare upang tingnan ang bawat certificate na naibigay para sa iyong domain at sa mga subdomain nito. Kung makakita ka ng certificate na inisyu ng hindi pamilyar na CA na hindi mo pinahintulutan, agad na siyasatin ang iyong DNS registrar at authoritative DNS zone para sa hindi awtorisadong mga pagbabago, bawiin ang rogue certificate na may nag-isyu na CA, at i-lock down ang iyong DNS gamit ang CAA mga tala (`0 issue "letsencrypt.org"`).

Paano kung ang aking Kubernetes cluster cert-manager nabigo na i-renew ang aming Ingress certificate at ang Order ay natigil Pending?¶

Takbo kubectl makakuha ng order, hamon -A at pagkatapos inilalarawan ng kubectl ang hamon -n . Sa 90 porsiyento ng mga Kubernetes tagapamahala ng sertipiko outages, ang cm-acme-http-solver-* tumatakbo ang pansamantalang pod, ngunit alinman sa (1) ang mapagkukunan ng Ingress ay may hindi napapanahong annotation ng klase sa ingress kaya ang ruta ng solver ay hindi kailanman nakakabit sa iyong load balancer, (2) isang Kubernetes NetworkPolicy ay humaharang sa pagpasok ng trapiko sa solver pod sa port 8089, o (3) pinipigilan ng isang hair-pin NAT / split-horizon DNS na isyu tagapamahala ng sertipikoAng panloob na pagsusuri sa sarili mula sa pag-abot sa iyong pampublikong load balancer IP (fixable by passing --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 sa tagapamahala ng sertipiko deployment args).

Maaari ko bang kopyahin ang aking /etc/letsencrypt/ folder sa isang bagong server sa panahon ng isang emergency migration sa halip na muling i-isyu?¶

Oo. Kung namatay ang iyong pangunahing server at lumipat ka sa isang bagong server habang nililimitahan ang rate ng Let's Encrypt, panatilihin ang mga symlink kapag kumukopya /etc/letsencrypt/ gamit tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (huwag gumamit ng plain scp -r, na nagpapapasok ng mga symlink /etc/letsencrypt/live/ sa mga duplicate na static na file at sinisira ang mga pag-renew sa hinaharap). I-extract ang archive na iyon sa bagong server (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), ituro ang Nginx/Apache sa `/etc/letsencrypt/live/domain/fullchain.pem`, at ang iyong kasalukuyang certificate ay gagana kaagad sa bagong IP address.

Mga kaugnay na gabay¶

• Pag-hijack ng domain name, nag-expire na DNS, at pagkuha ng website
• Server disk 100% puno (0 bytes libre): database at zero-space recovery
• Google Workspace o Microsoft 365 custom domain admin lockout at DNS TXT rescue
• Krisis sa web hosting, paglipat, at backup na pagpapanumbalik
• DNS hijacking, ISP router WAN reconfiguration, at captive portal spoofing
• Mga numerong pang-emergency ayon sa bansa

Mga mapagkukunan at opisyal na patnubay¶

• Internet Engineering Task Force (IETF): RFC 8555 (Automatic Certificate Management Environment / ACME), RFC 8659 (DNS Certification Authority Authorization / CAA), at RFC 6797 (HTTP Strict Transport Security / HSTS).
• National Institute of Standards and Technology (NIST) (Estados Unidos): Espesyal na Publikasyon 800-52 Rev. 2: Mga Alituntunin para sa Pagpili, Pag-configure, at Paggamit ng Mga Pagpapatupad ng Transport Layer Security (TLS) at SP 1800-16: Pag-secure ng Mga Transaksyon sa Web: TLS Server Certificate Management.
• Internet Security Research Group (ISRG / I-encrypt Natin ang Opisyal na Dokumentasyon): Sanggunian sa Mga Limitasyon sa Rate, Mga Duplicate na Panuntunan sa Sertipiko, at Pag-troubleshoot ng Hamon sa ACME.
• Cybersecurity at Infrastructure Security Agency (CISA) (United States): Binding Operational Directive 18-01: Pahusayin ang Email at Web Security (HTTPS at HSTS Implementation Guidance).
• National Cyber ​​Security Center (NCSC) (United Kingdom): Paggamit ng TLS para Perpektong Protektahan ang Data sa Transit at Certificate Transparency Monitoring Guidance.