Iċ-Ċertifikat SSL/TLS tal-Produzzjoni skada: L-iffissar ta' qtugħ iebes tal-HSTS u Ejja Encrypte CAA/Rate-Limit Blocks¶

Meta produzzjoni SSL/TLS (HTTPS) iċ-ċertifikat jiskadi - anke b'sekonda waħda wara tiegħu notAfter Timestamp UTC - kull browser modern (Chrome, Safari, Firefox, Edge), app mobbli (iOS App Transport Security, Android Network Security Config), riċevitur tal-webhook (Stripe, Shopify, Twilio, GitHub), u upstream API client immedjatament jaqta 'konnettività ma' NET::ERR_CERT_DATE_INVALID jew SSL_ERROR_RX_RECORD_TOO_LONG. Agħar minn hekk, jekk id-dominju tiegħek jibgħat il- Strict-Transport-Security (HSTS) header jew tiġi kkompilata fil-browser HSTS Preload List, Chrome u Safari ineħħu l-buttuna tal-bypass "Advanced -> Ipproċedi lejn is-sit (mhux sikur)" kompletament, li tirriżulta fi blackout 100 fil-mija hard-fail għal kull utent madwar id-dinja. Ħafna drabi, il-cronjob tat-tiġdid awtomatizzat (Certbot, acme.sh, Caddy, cert-manager, jew AWS ACM) ilu jonqos skiet għal 30 jum minħabba DNS restrittiv CAA rekord, DNSSEC miksur DS rekord, port li jimblokka firewall 80 (HTTP-01 sfida), jew web server (nginx / haproxy) li ġedded il-fajl fuq disk (fullchain.pem) iżda qatt ma reġgħet ikkargata l-proċessi tal-ħaddiema fil-memorja tagħha. Jekk il-qtugħ tiegħek kien ikkawżat minn reġistrazzjoni ta' dominju skaduta jew nameservers maħtufa aktar milli ċ-ċertifikat X.509 innifsu, aqleb immedjatament għal ħtif ta' isem ta' dominju, DNS skada, u teħid ta' kontroll tal-websajt; jekk is-server tiegħek ma jkunx jista' jintlaħaq kompletament jew barra mill-ispazju tad-diska hekk certbot ma tistax tikteb lil /etc/letsencrypt, ara server disk 100% irkupru sħiħ u żero spazju jew Web hosting kriżi, migrazzjoni, u restawr backup. Jekk dan il-qtugħ TLS jiskonnettja t-telemetrija tal-isptar, l-APIs tad-dispaċċ ta’ emerġenza, jew l-infrastruttura tas-sikurezza pubblika, ċempel in-numru lokali tal-emerġenza tiegħek (911 fl-Istati Uniti u l-Kanada, 112 madwar l-Unjoni Ewropea, 999 fir-Renju Unit) jew ikkonsulta d-direttorju internazzjonali tagħna ta’ numri ta' emerġenza.

Agħmel dan issa¶

1. Iċċekkja fi żmien 10 sekondi jekk iċ-ċertifikat fuq id-diska huwiex fil-fatt diġà mġedded, u s-server tal-web jew il-bilanċjar tat-tagħbija tiegħek sempliċement naqas milli jerġa' jgħabbih fir-RAM:
2. Qabbel is-sokit TLS ħaj mal- .pem fajl fuq disk bħalissa:

   # 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. Jekk il-fajl fuq disk juri futur validu notAfter data filwaqt li l-port ħaj 443 turi data skaduta: Il-klijent ACME tiegħek (certbot / acme.sh) irnexxielu ġimgħat ilu, iżda nginx, apache2, haproxy, jew postfix qatt ma ġiet mgħobbija mill-ġdid, jew (haproxy / vault) teħtieġ fullchain.pem + privkey.pem magħqudin f'qatta waħda. Mexxi sudo nginx -t && sudo systemctl reload nginx (jew sudo systemctl reload apache2 haproxy) u l-qtugħ tiegħek jintemm fi żmien 2 sekondi.
4. ** Tmexxix certbot renew --force-renewal ripetutament f'linja jekk it-tiġdid ifalli**: Let's Encrypt jinforza limitu strett tar-rata ta' 5 ċertifikati duplikati kull 7 ijiem u 5 validazzjonijiet falluti għal kull kont, għal kull hostname, fis-siegħa. Running --force-renewal ħames darbiet f'paniku mingħajr ma jiġi ffissat is-sottostanti nginx reload jew bug DNS/firewall se jissakkar id-dominju tiegħek barra mill-ħruġ Let's Encrypt għal sa 7 ijiem.
5. Jekk tolqot Let's Encrypt Rate Limit (429 Too Many Requests), taqleb il-klijent ACME tiegħek għat-tieni Awtorità taċ-Ċertifikati pubblika b'xejn (ZeroSSL, Buypass Go SSL, jew Google Trust Services) jew żid SAN subdominju li jintrema immedjatament:
6. Kull klijent ACME (certbot, acme.sh, caddy, cert-manager) jistgħu jitolbu ċertifikat ta' fiduċja b'xejn minn CA differenti fi 30 sekonda (--server https://acme.zerossl.com/v2/DV90 jew https://api.buypass.com/acme/directory), billi tevita kompletament il-limitu tar-rata ta' Let's Encrypt.
7. Inkella, il-limitu ta' "5 ċertifikati duplikati kull 7 ijiem" ta' Let's Encrypt japplika biss għall-eżatt l-istess sett ta' Ismijiet Alternattivi tas-Suġġetti (SANs). Żieda ta' sottodominju validu ieħor (-d example.com -d www.example.com -d tlsfix1.example.com) jagħmilha ċertifikat mhux duplikat u jevita l-limitu tar-rata taċ-Ċertifikat Duplikat immedjatament.
8. Iċċekkja jekk DNS CAA rekord jew miksur DNSSEC qed timblokka lill-Awtorità taċ-Ċertifikati tiegħek milli toħroġ (CAA record for example.com prevents issuance):
9. Staqsa l-Awtorizzazzjoni tal-Awtorità taċ-Ċertifikazzjoni tad-dominju tiegħek (CAA) rekords: dig +short CAA example.com. Jekk id-DNS tiegħek għandu 0 issue "sectigo.com" jew 0 issue "amazon.com" (jew fuq dominju ġenitur), Let's Encrypt (letsencrypt.org) u ZeroSSL (sectigo.com) huma pprojbiti mill-RFC 8659 milli joħorġu sakemm iżżid 0 issue "letsencrypt.org" għaż-żona DNS tiegħek.
10. Jekk port 80 (HTTP-01 sfida) hija mblukkata minn firewall, CDN, jew ISP, jew jekk is-server tal-web tiegħek jirrifjuta li jibda minħabba ċertifikat nieqes, uża --standalone jew --dns (DNS-01) validazzjoni:
11. Waqqaf nginx/apache fil-qosor u run sudo certbot certonly --standalone -d example.com, jew uża --manual --preferred-challenges dns biex tivvalida billi twaħħal a _acme-challenge.example.com TXT irreġistra fil-console DNS tiegħek mingħajr ma tmiss il-port 80.
12. Jekk is-sit tiegħek jinsab wara Cloudflare, AWS CloudFront, jew Fastly, ivverifika jekk iċ-ċertifikat skadut huwiex fuq is-CDN Edge jew fuq is-Server ta' l-Oriġini tiegħek (Error 526 Invalid SSL Certificate):
13. Fuq Cloudflare, jekk iċ-ċertifikat tas-server tal-oriġini tiegħek skada u Cloudflare huwa ssettjat għal Full (Strict), l-utenti jaraw Żball 526. Waqt li tirranġa ċ-ċertifikat tal-oriġini, tista’ tirrestawra t-traffiku tas-sit ħajjin f’5 sekondi billi tiġġenera ċertifikat tal-CA tal-Oriġini tal-Cloudflare ta’ 15-il sena fid-dashboard ta’ Cloudflare (jew taqleb temporanjament mill-mod SSL/TLS minn Full (Strict) biex Full għall-10 minuti li tieħu biex tissostitwixxi l-oriġini .pem fajl).

Siġra tad-deċiżjonijiet: id-dijanjosi u l-iffissar ta 'ċertifikat ta' produzzjoni SSL/TLS skadut¶

Segwi din is-siġra tad-deċiżjonijiet biex tindika s-saff eżatt tal-falliment (CDN Edge vs. Origin Daemon Memory vs. ACME Challenge vs. CA Rate Limit) u rrestawra t-traffiku HTTPS f'minuti:

flowchart TD
    Start["Utenti / APIs Rappurtaġġ NET::ERR_CERT_DATE_INVALID jew Cloudflare Error 526"] --> CheckLive["Mexxi: openssl s_client -servername domain -connect domain:443 | openssl x509 -noout -dates -emittent"]

    CheckLive --> WhereExpired{"Liema Ċertifikat Huwa Attwalment Skada?"}

    WhereExpired -->|"Disk fullchain.pem Huwa VALIDU, Iżda Live Port 443 IS SKADA"| StaleDaemon["Memorja ta' Daemon Qadim jew Aħżen Ċertifikat Split: Reload nginx / apache2 / haproxy / postfix, jew Ibni mill-ġdid HAProxy PEM Bundle Magħquda"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) Huwa Skada"| CDNFix["Iċċekkja DNS CAA Records għal CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) u Toggle Universal SSL jew Re-Validate ACM"]
    WhereExpired -->|"L-Oriġini Server fullchain.pem fuq Disk IS SKADA"| DryRun["Mexxi: sudo certbot renew --dry-run (jew acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"Għaliex falla t-tiġdid ACME?"}

    WhyFailed -->|"429 Wisq Talbiet (Limitu tar-Rata Inqabeż)"| RateLimit["Bypass Immedjatament: Ħruġ minn ZeroSSL / Buypass / Google Trust Services JEW Żid 1 SAN ta' Subdomain Extra (-d fix1.example.com)"]
    WhyFailed -->|"Ir-Rekord tas-CAA Jipprevjeni l-Ħruġ jew SERVFAIL (DNSSEC)"| CAADNS["Mexxi: ħaffer CAA example.com -> Żid 0 kwistjoni 'letsencrypt.org' (u 'sectigo.com') jew Waħħal Broken DNSSEC DS Record fir-Reġistratur"]
    WhyFailed -->|"Konnessjoni Miċħuda / Timeout / 404 fuq /.well-known/acme-challenge/"| HttpBlock["Port 80 Imblukkat jew Redirect Loop: Iftaħ il-Port TCP 80 fil-Firewall, Eskludi /.well-known/ minn Auth/Rewrite, jew Uża DNS-01 Challenge"]
    WhyFailed -->|"Kubernetes cert-manager Ordni Staġnati Pendenti"| K8sFix["Mexxi: kubectl iddeskrivi l-isfida -> Iċċekkja l-annotazzjoni tal-klassi Ingress, il-politika tan-netwerk tal-pod tas-solver HTTP01, jew Webhook TLS"]

    StaleDaemon --> VerifyAll["Ivverifika Katina & OCSP Stapling: openssl s_client -connect domain:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Fażi 1: Nifhmu għaliex HSTS (Strict-Transport-Security) tikkawża blackout totali hard-fail¶

Meta websajt ma tuża l-HSTS, ċertifikat skadut juri twissija interstizjali (Your connection is not private) b'rabta "Avvanzata -> Ipproċedi għal example.com (mhux sikur)" li tippermetti lill-utenti ddisprati li jikklikkjaw.

Madankollu, kważi l-applikazzjonijiet moderni kollha tal-web tal-produzzjoni, banek, pjattaformi SaaS, u .dev / .app / .page / .bank dominji tal-ogħla livell jinfurzaw HTTP Strict Transport Security (HSTS, RFC 6797): 1. HSTS Dinamika (max-age=31536000): Kwalunkwe browser li żar is-sit tiegħek fl-aħħar 365 jum daħħal il-politika fil-cache Strict-Transport-Security: max-age=31536000; includeSubDomains. Sakemm jiskadi dak it-tajmer, il-browser jipprojbixxi lill-utent milli jikklikkja permezz ta' kwalunkwe żball ta' ċertifikat (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, jew ERR_CERT_AUTHORITY_INVALID). 2. Preload HSTS statiku (preload lista jew .dev / .app gTLD): Jekk id-dominju tiegħek ġie sottomess lil hstspreload.org - jew jekk id-dominju tiegħek juża Reġistru-Preloaded TLD simili .dev, .app, .page, .new, .chrome, jew .bank - kull kopja ta' Chrome, Edge, Firefox, Safari, u Android WebView fid-Dinja għandha d-dominju tiegħek hardcoded fil-binarju tiegħu bħala infurzat bl-HSTS qabel ma l-utent qatt iżur is-sit tiegħek għall-ewwel darba. 3. Għaliex includeSubDomains ikisser għodod interni u servers ta' staging: Jekk id-dominju għeruq tiegħek (example.com) jibgħat Strict-Transport-Security: max-age=31536000; includeSubDomains, kull sottodominju (vpn.example.com, internal-jira.example.com, printer.example.com) huwa wkoll imsakkar fil-modalità hard-fail HSTS. 4. Għaliex l-API u l-integrazzjonijiet tal-Webhook (Stripe, Twilio, Slack, iOS ATS) ifalli immedjatament: Klijenti TLS minn server għal server (libcurl, Python requests/urllib3, Node.js undici, Mur crypto/tls, Java SSLContext) twettaq RFC 5280 stretta notAfter validazzjoni awtomatikament u m'għandhom l-ebda kunċett ta 'utent "click-through." Waqt qtugħ tat-TLS, il-webhooks ta' Stripe u Shopify se jfallu l-kunsinna u jidħlu fil-kjuwijiet esponenzjali ta' retry backoff.

Fażi 2: Id-dijanjostika ta' 60 sekonda - Iċ-ċertifikat huwa attwalment diġà mġedded fuq disk?¶

F'bejn wieħed u ieħor 35 fil-mija tal-qtugħ tal-produzzjoni Let's Encrypt, iċ-ċertifikat kien fil-fatt imġedded fuq disk ġimgħat ilu minn certbot.timer jew acme.sh, iżda d-daemon li qed jaħdem għadu qed iservi ċ-ċertifikat skada l-antik mir-RAM.

Pass 1: Qabbel is-socket tan-netwerk ħaj mal-fajl fuq id-diska¶

Mexxi ż-żewġ kmandi fuq is-server tiegħek:

# 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

Pass 2: Waħħal l-4 nases komuni "Mġedda fuq Disk, Skaduta fir-RAM".¶

Fażi 3: Iffissar tad-DNS CAA blokki tar-rekords u DNSSEC fallimenti tal-validazzjoni¶

Jekk tmexxi sudo certbot renew --dry-run u ara: - 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. Kif DNS CAA (RFC 8659) jimblokka t-tiġdid taċ-ċertifikat¶

Kull Awtorità taċ-Ċertifikati pubblika hija meħtieġa legalment mis-CA/Browser Forum Rekwiżiti tal-Linji Bażi biex tistaqsi d-DNS CAA rekords qabel ma jinħareġ xi ċertifikat. Is-CA timxi s-siġra DNS minn sub.app.example.com -> app.example.com -> example.com: - Jekk example.com għandha żero CAA rekords, kwalunkwe CA hija permessa toħroġ. - Jekk example.com għandha anke waħda CAA rekord (per eżempju, 0 issue "amazon.com" miżjud awtomatikament meta xi ħadd ħoloq distribuzzjoni AWS CloudFront, jew 0 issue "digicert.com"), kull Awtorità taċ-Ċertifikati oħra fid-Dinja hija strettament ipprojbita milli toħroġ ċertifikat għal example.com jew kwalunkwe mis-subdominji tiegħu. - Barra minn hekk, jekk qed titlob ċertifikat wildcard (*.example.com) u d-dominju tiegħek jiddefinixxi speċifika 0 issuewild "ca.example" tag, is-CA jiċċekkja l- issuewild proprjetà aktar milli issue.

Tiffissa dijanjostika u immedjata għal CAA blokki:¶

1. Iċċekkja CAA rekords kemm fuq l-isem tal-host kif ukoll fuq id-dominju tal-apex:

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

2. Iċċekkja wkoll jekk sub.example.com huwa a CNAME tipponta lejn dominju ieħor (Skond RFC 8659, CAs jiċċekkjaw ukoll il- CAA rekords fuq miri CNAME).
3. Fid-dashboard tal-fornitur tad-DNS tiegħek (Cloudflare, Route 53, Cloud DNS, Namecheap), tħassarx eżistenti CAA rekords użati mis-CDN jew l-AWS ACM tiegħek; minflok, ehmeż addizzjonali CAA rekords li jawtorizzaw lil Let's Encrypt u lill-CAs backup tiegħek:

   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 juża sectigo.com bħala l-identifikatur CAA sottostanti tagħha, u Google Trust Services juża pki.goog.)
4. Stenna 60 sekonda biex is-servers tal-isem awtorevoli tiegħek jaġġornaw (dig @ns1.yourdns.com CAA example.com) u mill-ġdid mill-ġdid sudo certbot renew. Peress li l-CAs iwettqu lookups rikursivi ħajjin billi jinjoraw il-caches pubbliċi meta jerġgħu jippruvaw, il-ħruġ jirnexxi immedjatament.

2. Iffissar DNS problem: SERVFAIL looking up CAA (DNSSEC nuqqas ta' qbil)¶

Ejja Encrypt, Google Trust Services, u ZeroSSL jinfurzaw b'mod strett il-validazzjoni DNSSEC fuq il-lokki DNS kollha (A, AAAA, TXT, u CAA). Anke jekk dominju għandu le CAA rekord, is-CA trid tirċievi kriptografikament valida NOERROR (tweġiba vojta) jew NXDOMAIN (NSEC / NSEC3 ċaħda awtentikata tal-eżistenza). - Jekk ir-reġistratur tad-dominju tiegħek ikollu reġistrat DS (Firmatur tad-Delegazzjoni) rekord wara li emigrajt fornituri tad-DNS (pereżempju, tiċċaqlaq minn GoDaddy għal Cloudflare jew Route 53 mingħajr ma tiddiżattiva DNSSEC l-ewwel), risolvers rikorsivi li jinfurzaw ir-ritorn DNSSEC SERVFAIL. - Ivverifika f'5 sekondi: Mexxi delv @8.8.8.8 example.com CAA jew test fi dnsviz.net. Jekk dig @8.8.8.8 example.com prospetti status: SERVFAIL filwaqt li dig +cd @8.8.8.8 example.com (+cd = Iċċekkja Disabled, tinjora DNSSEC) jirritorna l-indirizz IP tiegħek, il-katina DNSSEC tiegħek hija miksura. Idħol fir-reġistratur tad-dominju tiegħek immedjatament u jew neħħi l-qadim DS tirrekordja jew tikkopja l-kurrent DS parametri mill-host DNS attiv tiegħek.

Fażi 4: Injoraw il-Limiti tar-Rata Ejja Kriptaġġ (429 Too Many Requests) waqt qtugħ attiv¶

Waqt inċident kaotiku, l-inġiniera spiss jerġgħu jibdew il-kontenituri jew jiġru certbot ripetutament sakemm Let's Encrypt tirrifjuta t-talbiet kollha bi: - 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

Il-ħinijiet ta' stennija jvarjaw minn siegħa (għall-awtorizzazzjonijiet falluti) sa 7 ijiem (168 siegħa) (għall-limitu ta' 5 ċertifikati duplikati). Tistennix siegħa jew 7 ijiem waqt li s-sit tal-produzzjoni tiegħek ikun waqaf. Għandek żewġ soluzzjonijiet immedjati u kompletament leġittimi:

Soluzzjoni A (l-Aħjar): Aqleb l-Awtorità taċ-Ċertifikati ACME għal ZeroSSL, Buypass, jew Servizzi Fiduċjarji ta' Google fi 30 sekonda¶

Il-protokoll ACME (RFC 8555) huwa standard miftuħ. Kull brawżer ewlieni u sistema operattiva jafda ZeroSSL (Sectigo root), Buypass Go SSL (Norwegian CA), u Google Trust Services (pki.goog) b'mod identiku għal Let's Encrypt (ISRG Root X1). Ħadd minnhom ma jaqsam il-limiti tar-rata ma' Let's Encrypt.

• ** Għażla 1: Ħruġ immedjatament permezz Certbot bl-użu ta' Buypass Go SSL (l-ebda kont/ċavetta EAB meħtieġa, validità ta' 180 jum)**: (Nota: Buypass jappoġġja ċertifikati b'ħafna dominju sa 5 SANs, għalkemm mhux wildcard *.example.com ċertifikati)

  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
  

• ** Għażla 2: Ħruġ immedjatament permezz acme.sh (li default għal ZeroSSL jew jaqleb CAs ma --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
  

• ** Għażla 3: Ħruġ permezz ta' Google Trust Services (pki.goog) ACME Pubbliku**: Fil-Google Cloud Console (jew permezz gcloud publicca external-account-keys create), iġġenera Binding tal-Kont Estern b'xejn (EAB) iċċekkja f'10 sekondi u mexxi:

  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
  

Soluzzjoni B: Bypass il-limitu ta' "5 Ċertifikati Duplikati" Let's Encrypt billi żżid isem tal-host SAN ieħor¶

Ejja Encrypt tal-limitu duplikat ta' 168 siegħa (too many certificates (5) already issued for this exact set of domains) issegwi s-sett alfabetiku eżatt tal-ismijiet tal-host SAN fuq iċ-ċertifikat, filwaqt li l-limitu ġenerali tad-Dominju Reġistrat huwa 50 ċertifikat fil-ġimgħa. 1. Oħloq DNS li ma jagħmilx ħsara A rekord li jindika l-istess server: tls-recovery-01.example.com -> <your_server_ip>. 2. Itlob iċ-ċertifikat bid-dominji oriġinali tiegħek flimkien l-isem tal-host il-ġdid:

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

Fażi 5: Iffissar miksur HTTP-01 sfidi (Port 80) jew bl-użu DNS-01 validazzjoni ta' emerġenza¶

Meta certbot renew jonqos bi Timeout during connect (likely firewall problem) jew Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (jew 403), is-servers tal-validazzjoni CA ma jistgħux jilħqu t-token tal-isfida HTTP tiegħek fuq TCP port 80.

Għaliex HTTP-01 f'daqqa waqfiet fuq servers li ħadmu 60 jum ilu¶

1. Cloud Security Group / UFW / iptables Port magħluq 80: Xi ħadd imwebbes il-firewall biex jippermetti biss port 443 (HTTPS), u ninsew li RFC 8555 HTTP-01 validazzjoni dejjem tibda fuq il-port HTTP sempliċi 80 (għalkemm se ssegwi a 301 indirizza mill-ġdid lejn https:// fuq il-port 443).
2. IPv6 miksur (AAAA) Rekord: Id-dominju tiegħek għandu kemm IPv4 (A) rekord u IPv6 (AAAA) jirreġistra. Ejja Encrypt dejjem tippreferi l-IPv6 (AAAA) l-ewwel. Jekk l-indirizz IPv6 tiegħek huwa misrouted, imblukkat minn ip6tables, jew mhux marbut f'Nginx (listen [::]:80;), il-validazzjoni tiskadi minkejja li l-IPv4 jaħdem tajjeb.
3. Nginx / Applikazzjoni Router (React / Next.js / Django / Rails) jinterċetta /.well-known/acme-challenge/: Tiegħek server jimblokka fuq il-port 80 proxys it-traffiku kollu (location / { proxy_pass http://localhost:3000; }) għal app backend minflok isservi .well-known mid-diska.

Żewġ soluzzjonijiet immedjati għal miksur HTTP-01 validazzjoni¶

Waħħal 1: Żid prijorità għolja ddedikata /.well-known/acme-challenge/ blokk f'Nginx (Port 80)¶

Żgura l-blokk tal-port 80 tiegħek /etc/nginx/sites-enabled/ iservi tokens ACME direttament minn /var/www/letsencrypt qabel kwalunkwe return 301 https://... jew proxy_pass direttiva:

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

Waħħal 2: Bypass Port 80 u web servers kompletament b'manwal DNS-01 (TXT) sfida¶

Jekk il-port 80 huwa mblukkat minn ISP upstream/firewall jew il-bilanċjar tat-tagħbija tiegħek ma jistax rotta .well-known għal nodi backend multipli, ivvalida permezz tad-DNS f'2 minuti:

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

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

Fażi 6: Verifika ta' wara l-irkupru (Katina Intermedja, Stapling OCSP, u Purge CDN)¶

Żball komuni wara s-sostituzzjoni taċ-ċertifikat ta 'emerġenza huwa l-installazzjoni cert.pem (iċ-ċertifikat tal-weraq biss) minflok fullchain.pem (iċ-ċertifikat tal-weraq + ċertifikat intermedju tal-CA). Browsers tad-desktop (Chrome, Firefox) ħafna drabi jaħbu ċertifikat intermedju nieqes permezz tal-AIA (Authority Information Access) chasing jew cached intermedji, filwaqt li curl, Python, OpenSSL, apps Android, u Stripe/Twilio webhooks ifallu immedjatament ma unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• Ivverifika li s-server tiegħek jibgħat il-Katina Intermedja sħiħa (fullchain.pem): Mexxi:

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

  Trid tara mill-inqas żewġ livelli (depth=0 dominju tiegħek u depth=1 il-CA intermedju bħal Let's Encrypt E5/R11 jew ZeroSSL RSA Domain Secure Site CA) u Verify return code: 0 (ok). Jekk tara Verify return code: 21 (unable to verify the first certificate), ibdel il-konfigurazzjoni tas-server tal-web tiegħek minn cert.pem biex fullchain.pem.
• Ħarsa l-cache ta' stejpling OCSP friska f'Nginx / Apache: Jekk ssl_stapling on; hija attivata, erġa' tagħbija s-server tal-web u ċċekkja openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
• Kkonfigura l-monitoraġġ tal-iskadenza SSL b'ħafna saffi (Kontroll estern TCP + Prometheus blackbox_exporter): Qatt ma tistrieħ biss fuq tfakkiriet bl-email (Ejja Encrypt l-emails ta' tfakkira ta' skadenza li ma tkomplewx fl-2025). Immonitorja l-live port 443 socket esternament (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) u waqqaf cron check ta’ kuljum fuq sudo certbot renew --dry-run.

Numri ta' emerġenza reġjonali u protokolli ta' aġenzija¶

Filwaqt li ċertifikat TLS skadut normalment jiġi solvut minn timijiet ta' inġinerija, qtugħ ta' ċertifikat li jkisser portali tal-kura tas-saħħa, webhooks ta' dispaċċ ta' emerġenza, awtentikazzjoni bankarja, jew infrastruttura pubblika tal-gvern jistgħu jikkawżaw flussi ta' xogħol ta' inċidenti regolatorji:

• L-Istati Uniti u l-Kanada:
• Sikurezza tal-Ħajja / Klinika / Qtugħ tad-Dispaċċ: Ċempel 911 jekk falliment taċ-ċertifikat TLS jaqta' t-telemetrija tal-pazjent, il-preskrizzjoni elettronika, jew il-komunikazzjonijiet tad-dispaċċ ta' emerġenza.
• Aġenzija taċ-Ċibersigurtà u s-Sigurtà tal-Infrastruttura (CISA) (US): Aġenziji ċivili federali taħt Direttiva Operattiva Vinkolanti CISA (BOD) 18-01 u operaturi ta' infrastruttura kritika li jesperjenzaw ħruġ ta' ċertifikati mhux awtorizzat (kompromess CA jew ħtif BGP/DNS) għandhom jirrappurtaw lil 1-844-Say-CISA (1-844-729-2472) jew cisa.gov/report.
• Ċentru Kanadiż għas-Sigurtà Ċibernetika: Kuntatt 1-833-CYBER-88 (1-833-292-3788).
• Renju Unit:
• Servizzi ta' Emerġenza: Ċempel 999 jekk qtugħ TLS ikollu impatt fuq is-sistemi kliniċi kritiċi tal-NHS jew is-sigurtà tal-ħajja.
• Ċentru Nazzjonali tas-Sigurtà Ċibernetika (NCSC): Jekk tiskopri ċertifikat mhux awtorizzat maħruġ għad-dominju tiegħek fi Trasparenza taċ-Ċertifikat (crt.sh) zkuk li jindikaw il-ħtif tad-DNS, irrapporta permezz ncsc.gov.uk.
• Unjoni Ewropea:
• Servizzi ta' Emerġenza: Ċempel 112 fl-istati membri kollha tal-UE.
• Direttiva NIS2 u Ċertifikati ta' Awtentikazzjoni tal-Websajt Kwalifikati eIDAS (QWACs): Entitajiet essenzjali u importanti taħt id-Direttiva NIS2 li jesperjenzaw qtugħ fit-tul tad-disponibbiltà jew ċwievet PKI kompromessi għandhom jinnotifikaw is-CSIRT nazzjonali tagħhom fi żmien 24 siegħa.
• L-Awstralja u New Zealand:
• Servizzi ta' Emerġenza: Ċempel 000 fl-Awstralja jew 111 fi New Zealand; ikkuntattja lill-ACSC (1300 CYBER1) għal inċidenti infrastrutturali.
• L-Indja u l-Asja-Paċifiku:
• L-Indja (CERT-In / Kontrollur tal-Awtoritajiet ta' Ċertifikazzjoni CCA): Iċċempel 112 għal rispons ta' emerġenza; tirrapporta kompromess tal-PKI jew qtugħ sinifikanti tal-infrastruttura lil incident@cert-in.org.in fi żmien 6 sigħat.

Mistoqsijiet frekwenti¶

Għaliex ma nistax jien jew l-utenti tiegħi nikklikkjaw "Avvanzat -> Ipproċedi lejn is-sit (mhux sigur)" fi Chrome jew Safari waqt dan il-qtugħ?¶

Meta d-dominju tiegħek jibgħat il- Strict-Trasport-Sigurtà (HSTS) Header HTTP - jew juża dominju tal-ogħla livell bħal .dev, .app, .paġna, jew .bank li huwa hardcoded fil-browser HSTS Preload List - RFC 6797 jeħtieġ li l-brawżer jittratta kwalunkwe ċertifikat skadut, iffirmat minnu nnifsu, jew mhux imqabbel bħala żball fatali li ma jistax jiġi rkuprat. Il-browser intenzjonalment ineħħi l-buttuna ta' bypass "Ipproċedi xorta waħda" biex jipprevjeni attakkanti attivi Man-in-the-Middle (MitM) milli jqarrqu lill-utenti biex jikklikkjaw permezz ta' ċertifikat falsifikat. Filwaqt li żviluppatur fuq id-desktop Chrome jista 'jittajpja s-sekwenza tat-tastiera moħbija dan huwa mhux sikur direttament fuq l-iskrin tal-iżball biex tevitah lokalment għall-ittestjar, l-utenti reali ma jistgħux; trid tinstalla ċertifikat validu fuq il-port 443.

Ejja Encrypt waqfet tibgħat emails ta 'twissija ta' skadenza u ċ-ċertifikat tiegħi skada mingħajr avviż - għaliex ġara hekk?¶

Let's Encrypt irtirat uffiċjalment is-servizz tal-email tan-notifika tal-iskadenza tiegħu f'nofs l-2025 biex inaqqas l-overhead taż-żamma tad-dejta u minħabba li setups awtomatizzati tal-ACME għandhom jimmonitorjaw is-saħħa tat-tiġdid direttament. Biex tipprevjeni sorpriżi futuri, trid tissorvelja l-timestamp attwali tal-iskadenza tal-handshake TLS fuq in-netwerk billi tuża monitor tal-uptime estern (bħal Prometheus blackbox_exporter, Uptime Kuma, Better Stack, jew Datadog Synthetic TLS checks) twissija fi 21 jum, 14-il jum, u 7 ijiem qabel notWara.

Għaliex is-sit tiegħi jaħdem tajjeb fil-Chrome u Firefox fuq il-laptop tiegħi, iżda jfalli fuq it-telefowns Android, curl, u Stripe webhooks wara li aġġornajt iċ-ċertifikat?¶

Inti kkonfigurajt is-server tal-web tiegħek (ssl_certificate f'Nginx jew SSLCertificateFile fl-Apache) biex jindikaw cert.pem (iċ-ċertifikat tal-weraq biss) minflok fullchain.pem (iċ-ċertifikat tal-weraq miġbura maċ-ċertifikat Intermedju CA). Browsers tad-desktop bħal Chrome u Firefox iniżżlu awtomatikament iċ-ċertifikati intermedji nieqsa fl-isfond bl-użu tal- Aċċess għall-Informazzjoni tal-Awtorità (AIA) URL ġewwa ċ-ċertifikat tal-weraq tiegħek, taħbi l-konfigurazzjoni ħażina tas-server tiegħek. Madankollu, curl, OpenSSL, il-verifikatur tal-fiduċja tas-sistema ta' Android, Python, u s-servers tal-webhook ma jwettqux AIA chasing u immedjatament jirrifjutaw il-konnessjoni ma' ma tistax tikseb ċertifikat lokali tal-emittent. Ippunta l-konfigurazzjoni tiegħek lejn fullchain.pem u reload server tiegħek.

Kif niċċekkja jekk hacker jew amministratore diżonest ħareġ ċertifikat SSL mhux awtorizzat għad-dominju tiegħi?¶

Kull Awtorità taċ-Ċertifikati pubblikament fdata hija meħtieġa li tilloggja kull ċertifikat maħruġ għall-pubbliku Żkuk tat-Trasparenza taċ-Ċertifikat (CT). (RFC 6962) qabel ma l-browsers jafdawh. Miftuħa https://crt.sh/?q=%25.yourdomain.com jew il-Monitor tat-Trasparenza taċ-Ċertifikati ta' Cloudflare biex tara kull ċertifikat li qatt inħareġ għad-dominju tiegħek u s-sottodominji tiegħu. Jekk tara ċertifikat maħruġ minn CA mhux familjari li ma awtorizzatx, spezzjona immedjatament ir-reġistratur tad-DNS tiegħek u ż-żona awtorevoli tad-DNS għal modifiki mhux awtorizzati, irrevoka ċ-ċertifikat diżonest mas-CA tal-ħruġ, u illokkja d-DNS tiegħek b' CAA rekords (`0 issue "letsencrypt.org"`).

X'jiġri jekk il-cluster tiegħi tal-Kubernetes cert-manager naqas milli ġġedded iċ-ċertifikat tad-dħul tagħna u l-Ordni hija mwaħħla Pending?¶

Mexxi kubectl tikseb ordni, sfida -A u mbagħad kubectl jiddeskrivi l-isfida -n . F'90 fil-mija ta' Kubernetes cert-manager qtugħ, il cm-acme-http-solver-* il-pod temporanju qed jaħdem, iżda jew (1) ir-riżorsa ta' Ingress għandha annotazzjoni tal-klassi ta' ingress skaduta sabiex ir-rotta tas-solvent qatt ma tkun imwaħħla mal-balancer tat-tagħbija tiegħek, (2) a Kubernetes Politika tan-Netwerk qed jimblokka t-traffiku tad-dħul lejn is-solver pod fuq il-port 8089, jew (3) kwistjoni ta' NAT ta' hair-pin / split-horizon DNS tipprevjeni cert-managerl-awtoverifika interna ta' milli tilħaq l-IP pubbliku tal-bilanċjar tat-tagħbija tiegħek (li tista' tiġi ffissata billi tgħaddi --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 lill- cert-manager argumenti tal-iskjerament).

Nista 'kopja tiegħi /etc/letsencrypt/ folder għal server ġdid waqt migrazzjoni ta' emerġenza minflok ma terġa' toħroġ?¶

Iva. Jekk is-server primarju tiegħek miet u qed temigra għal server ġdid waqt li tkun limitata bir-rata minn Let's Encrypt, ippreserva symlinks meta tikkopja /etc/letsencrypt/ bl-użu tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (qatt tuża sempliċi scp -r, li jdawwar is-symlinks /etc/letsencrypt/live/ f’fajls statiċi duplikati u jkisser it-tiġdid futuri). Oħroġ dak l-arkivju fuq is-server il-ġdid (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), punt Nginx/Apache biex `/etc/letsencrypt/live/domain/fullchain.pem`, u ċ-ċertifikat eżistenti tiegħek jaħdem immedjatament fuq l-indirizz IP il-ġdid.

Gwidi relatati¶

• Ħtif tal-ismijiet tad-dominju, DNS skadut, u teħid ta' kontroll tal-websajt
• Disk tas-server 100% sħiħ (0 bytes ħielsa): database u rkupru ta 'spazju żero
• Google Workspace jew Microsoft 365 custom domain admin lockout u salvataġġ DNS TXT
• Web hosting kriżi, migrazzjoni, u restawr backup
• Ħtif tad-DNS, konfigurazzjoni mill-ġdid tal-WAN tar-router tal-ISP, u spoofing tal-portal captive
• Numri ta' emerġenza skond il-pajjiż

Sorsi u gwida uffiċjali¶

• Task Force tal-Inġinerija tal-Internet (IETF): RFC 8555 (Ambjent Awtomatiku tal-Ġestjoni taċ-Ċertifikati / ACME), RFC 8659 (Awtorizzazzjoni tal-Awtorità taċ-Ċertifikazzjoni DNS / CAA), u RFC 6797 (Sigurtà tat-Trasport strett HTTP / HSTS).
• Istitut Nazzjonali tal-Istandards u t-Teknoloġija (NIST) (L-Istati Uniti): Pubblikazzjoni Speċjali 800-52 Rev. 2: Linji Gwida għall-Għażla, Konfigurazzjoni, u Użu ta' Implimentazzjonijiet ta' Sigurtà ta' Saff ta' Trasport (TLS) & SP 1800-16: Żgurar ta' Transazzjonijiet Web: Ġestjoni taċ-Ċertifikati tas-Server TLS.
• Grupp ta' Riċerka dwar is-Sigurtà tal-Internet (ISRG / Let's Encrypt Dokumentazzjoni Uffiċjali): Referenza tal-Limiti tar-Rata, Regoli ta' Ċertifikat Duplikat, u Soluzzjoni ta' Problemi tal-Isfida ACME.
• Aġenzija taċ-Ċibersigurtà u s-Sigurtà tal-Infrastruttura (CISA) (L-Istati Uniti): Direttiva Operattiva Vinkolanti 18-01: Ittejjeb is-Sigurtà tal-Email u l-Web (Gwida għall-Implimentazzjoni HTTPS u HSTS).
• Ċentru Nazzjonali tas-Sigurtà Ċibernetika (NCSC) (Renju Unit): L-użu ta' TLS biex Jipproteġi d-Data Perfettament fi Transitu u Gwida għall-Monitoraġġ tat-Trasparenza taċ-Ċertifikati.