Certifikata SSL/TLS e prodhimit ka skaduar: Rregullimi i ndërprerjeve të dështimit të vështirë të HSTS dhe Le të kodojmë blloqet CAA/Rate-Limit¶

Kur një SSL/TLS prodhimi (HTTPS) certifikata skadon - edhe nga një sekondë e vetme pas saj notAfter Vula kohore UTC - çdo shfletues modern (Chrome, Safari, Firefox, Edge), aplikacioni celular (iOS App Transport Security, Android Network Security Config), marrës webhook (Stripe, Shopify, Twilio, GitHub), dhe klienti në rrjedhën e sipërme API ndërpret menjëherë lidhjen me NET::ERR_CERT_DATE_INVALID ose SSL_ERROR_RX_RECORD_TOO_LONG. Më keq akoma, nëse domeni juaj dërgon Strict-Transport-Security (HSTS) header ose kompilohet në shfletuesin HSTS Preload List, Chrome dhe Safari heqin plotësisht butonin e anashkalimit "Advanced -> Proceed to site (i pasigurt)", duke rezultuar në një ndërprerje 100 përqind të dështimit të vështirë për çdo përdorues në mbarë botën. Shpesh, kronjobi i automatizuar i rinovimit (Certbot, acme.sh, Caddy, cert-manager, ose AWS ACM) ka dështuar në heshtje për 30 ditë për shkak të një DNS kufizuese CAA rekord, një DNSSEC i thyer DS rekord, një port bllokues i murit të zjarrit 80 (HTTP-01 sfidë), ose një server në internet (nginx / haproxy) që rinovoi skedarin në disk (fullchain.pem) por kurrë nuk i ringarkoi proceset e tij të punës në memorie. Nëse ndërprerja juaj është shkaktuar nga një regjistrim domeni i skaduar ose nga serverët e emrave të rrëmbyer në vend të vetë certifikatës X.509, kaloni menjëherë te rrëmbimi i emrit të domenit, DNS i skaduar dhe marrja e faqes në internet; nëse serveri juaj është plotësisht i paarritshëm ose nuk ka hapësirë në disk kështu certbot nuk mund t'i shkruaj /etc/letsencrypt, shih Rikuperimi i diskut i serverit 100% i plotë dhe me hapësirë zero ose Kriza e mbajtjes në internet, migrimi dhe restaurimi i rezervave. Nëse kjo ndërprerje TLS çaktivizon telemetrinë e spitalit, API-të e dërgimit të urgjencës ose infrastrukturën e sigurisë publike, telefononi numrin tuaj të urgjencës lokale (911 në Shtetet e Bashkuara dhe Kanada, 112 në të gjithë Bashkimin Evropian, 999 në Mbretërinë e Bashkuar) ose konsultohuni me drejtorinë tonë ndërkombëtare të numrat e urgjencës.

Bëje këtë tani¶

1. Kontrolloni për 10 sekonda nëse certifikata në disk është rinovuar tashmë dhe serveri juaj i internetit ose balancuesi i ngarkesës thjesht nuk e rifreskuan atë në RAM:
2. Krahasoni prizën e drejtpërdrejtë TLS me .pem skedar në disk tani:

   # 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. Nëse skedari në disk tregon një të ardhme të vlefshme notAfter datë ndërsa port live 443 tregon një datë të skadimit: Klienti juaj ACME (certbot / acme.sh) pati sukses javë më parë, por nginx, apache2, haproxy, ose postfix nuk u ringarkua kurrë, ose (haproxy / vault) kërkon fullchain.pem + privkey.pem të bashkuara në një pako të vetme. Vraponi sudo nginx -t && sudo systemctl reload nginx (ose sudo systemctl reload apache2 haproxy) dhe ndërprerja juaj do të përfundojë për 2 sekonda.
4. ** MOS vraponi certbot renew --force-renewal në mënyrë të përsëritur në një cikli nëse rinovimi dështon**: Let's Encrypt zbaton një kufi të rreptë tarifash prej 5 certifikata të kopjuara për 7 ditë dhe 5 vërtetime të dështuara për llogari, për emër hosti, në orë. Vrapimi --force-renewal pesë herë në panik pa e rregulluar bazën nginx ringarkoni ose defekti DNS/firewall do të bllokojë domenin tuaj nga lëshimi i Let's Encrypt për deri në 7 ditë.
5. Nëse goditni një kufi të normës Let's Encrypt (429 Too Many Requests), kaloni klientin tuaj ACME në një Autoritet të dytë publik falas të Certifikatave (ZeroSSL, Buypass Go SSL, ose Google Trust Services) ose shtoni menjëherë një nëndomain të hedhur SAN:
6. Çdo klient ACME (certbot, acme.sh, caddy, cert-manager) mund të kërkojë një certifikatë të besueshme falas nga një CA tjetër në 30 sekonda (--server https://acme.zerossl.com/v2/DV90 ose https://api.buypass.com/acme/directory), duke anashkaluar plotësisht kufirin e normës së Let's Encrypt.
7. Përndryshe, kufiri i Let's Encrypt "5 certifikata të kopjuara për 7 ditë" vlen vetëm për të njëjtin grup të Emrave Alternativë të Subjekteve (SANs). Shtimi i një nëndomain shtesë të vlefshëm (-d example.com -d www.example.com -d tlsfix1.example.com) e bën atë një certifikatë jo dublikatë dhe anashkalon menjëherë kufirin e tarifës së certifikatës së dublikuar.
8. Kontrollo nëse një DNS CAA rekord apo thyer DNSSEC po bllokon Autoritetin tuaj të Certifikatës që të lëshojë (CAA record for example.com prevents issuance):
9. Kërkoni autorizimin e Autoritetit të Certifikimit të domenit tuaj (CAA) regjistron: dig +short CAA example.com. Nëse DNS juaj ka 0 issue "sectigo.com" ose 0 issue "amazon.com" (ose në një domen prind), Le të Enkriptojmë (letsencrypt.org) dhe ZeroSSL (sectigo.com) janë të ndaluara nga RFC 8659 të lëshohen derisa të shtoni 0 issue "letsencrypt.org" në zonën tuaj DNS.
10. Nëse port 80 (HTTP-01 sfidë) është bllokuar nga një mur zjarri, CDN ose ISP, ose nëse serveri juaj i uebit refuzon të fillojë për shkak të një certifikate që mungon, përdorni --standalone ose --dns (DNS-01) vërtetimi:
11. Ndalo nginx/apache shkurt dhe vraponi sudo certbot certonly --standalone -d example.com, ose përdorni --manual --preferred-challenges dns për të vërtetuar duke ngjitur a _acme-challenge.example.com TXT regjistroni në konsolën tuaj DNS pa prekur portën 80.
12. Nëse faqja juaj qëndron pas Cloudflare, AWS CloudFront ose Fastly, verifikoni nëse certifikata e skaduar është në CDN Edge ose në serverin tuaj të origjinës (Error 526 Invalid SSL Certificate):
13. Në Cloudflare, nëse certifikata e serverit tuaj të origjinës ka skaduar dhe Cloudflare është caktuar në Full (Strict), përdoruesit shohin Gabim 526. Ndërsa rregulloni certifikatën e origjinës, mund të rivendosni trafikun e drejtpërdrejtë të sajtit në 5 sekonda duke gjeneruar një certifikatë Cloudflare Origin CA 15-vjeçare në panelin e kontrollit të Cloudflare (ose duke kaluar përkohësisht modalitetin SSL/TLS nga Full (Strict) te Full për 10 minutat që duhen për të zëvendësuar origjinën .pem dosje).

Pema e vendimeve: diagnostikimi dhe rregullimi i një certifikate prodhimi SSL/TLS të skaduar¶

Ndiqni këtë pemë vendimi për të përcaktuar me saktësi shtresën e dështimit (CDN Edge kundër Origin Daemon Memory kundër ACME Challenge kundër CA Rate Limit) dhe rivendosni trafikun HTTPS në minuta:

flowchart TD
    Start["Përdoruesit / API-të që raportojnë NET::ERR_CERT_DATE_INVALID ose Gabim Cloudflare 526"] --> CheckLive["Ekzekutoni: openssl s_client -domeni emri i serverit -lidh domenin:443 | openssl x509 -noout -data -lëshues"]

    CheckLive --> WhereExpired{"Cila certifikatë ka skaduar në të vërtetë?"}

    WhereExpired -->|"Disku fullchain.pem është i vlefshëm, por porta e drejtpërdrejtë 443 është e skaduar"| StaleDaemon["Memoria e vjetër e Daemon ose Dyqani i Certeve të Split: Rifresko nginx / apache2 / haproxy / postfix, ose Rindërto paketën e kombinuar HAProxy PEM"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) ka skaduar"| CDNFix["Kontrolloni të dhënat e DNS CAA për CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) dhe Ndryshoni SSL Universal ose Ri-Verifikuar ACM"]
    WhereExpired -->|"Serveri i origjinës fullchain.pem në disk është skaduar"| DryRun["Ekzekuto: sudo certbot rinovon --dry-run (ose acme.sh --rinovo domenin -d --debug)"]

    DryRun --> WhyFailed{"Pse dështoi rinovimi ACME?"}

    WhyFailed -->|"429 shumë kërkesa (kufiri i tarifës u tejkalua)"| RateLimit["Anashkaloni menjëherë: Lëshim nga ZeroSSL / Buypass / Shërbimet e Google Trust OSE Shto 1 nëndomain shtesë SAN (-d fix1.example.com)"]
    WhyFailed -->|"Regjistrimi i AAC-së parandalon lëshimin ose SERVFAIL (DNSSEC)"| CAADNS["Ekzekutoni: dig CAA example.com -> Shto 0 çështje 'letsencrypt.org' (dhe 'sectigo.com') ose Rregullo rekordin e thyer DNSSEC DS në Regjistrues"]
    WhyFailed -->|"Lidhja u refuzua / Kohëzgjatja / 404 në /.i mirënjohur/acme-challenge/"| HttpBlock["Porta 80 e bllokuar ose e ridrejtuar: Hapni Portin TCP 80 në Firewall, përjashtoni /.mirë njohur/ nga Auth/Rishkrimi ose përdorni sfidën DNS-01"]
    WhyFailed -->|"Porosia e menaxherit certifikues të Kubernetes është në pritje"| K8sFix["Ekzekuto: kubectl përshkruaj sfidën -> Kontrollo shënimin e klasës hyrëse, politikën e rrjetit të pod zgjidhjes HTTP01 ose Webhook TLS"]

    StaleDaemon --> VerifyAll["Verifiko lidhjen e zinxhirit dhe OCSP: openssl s_client -connect domain:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Faza 1: Kuptimi pse HSTS (Strict-Transport-Security) shkakton një ndërprerje të plotë të dështimit¶

Kur një faqe interneti nuk përdor HSTS, një certifikatë e skaduar shfaq një paralajmërim intersticial (Your connection is not private) me një lidhje "E avancuar -> Vazhdoni te shembull.com (i pasigurt)" që lejon përdoruesit e dëshpëruar të klikojnë.

Sidoqoftë, pothuajse të gjitha aplikacionet moderne të prodhimit në internet, bankat, platformat SaaS dhe .dev / .app / .page / .bank domenet e nivelit të lartë zbatojnë Sigurinë e rreptë të transportit HTTP (HSTS, RFC 6797): 1. HSTS dinamike (max-age=31536000): Çdo shfletues që ka vizituar faqen tuaj brenda 365 ditëve të fundit e ka ruajtur në memorien e fshehtë politikën Strict-Transport-Security: max-age=31536000; includeSubDomains. Derisa të skadojë ai kohëmatës, shfletuesi e ndalon përdoruesin të klikojë përmes ndonjë gabimi të certifikatës (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, ose ERR_CERT_AUTHORITY_INVALID). 2. Parangarkesa statike HSTS (preload listë ose .dev / .app gTLD): Nëse domeni juaj iu dorëzua hstspreload.org - ose nëse domeni juaj përdor një TLD të Parangarkuar nga Regjistri .dev, .app, .page, .new, .chrome, ose .bank - çdo kopje e Chrome, Edge, Firefox, Safari dhe Android WebView në Tokë e ka domenin tuaj të koduar në binarin e tij si HSTS-zbatuar përpara se përdoruesi të vizitojë faqen tuaj për herë të parë. 3. Pse includeSubDomains prish mjetet e brendshme dhe serverët e vendosjes: Nëse domeni juaj rrënjësor (example.com) dërgon Strict-Transport-Security: max-age=31536000; includeSubDomains, çdo nëndomain (vpn.example.com, internal-jira.example.com, printer.example.com) është gjithashtu i kyçur në modalitetin e dështimit të vështirë HSTS. 4. Pse integrimet API dhe Webhook (Stripe, Twilio, Slack, iOS ATS) dështojnë menjëherë: Klientët TLS server-to-server (libcurl, Python requests/urllib3, Node.js undici, Shko crypto/tls, Java SSLContext) kryeni RFC 5280 strikte notAfter vlefshmëri si parazgjedhje dhe nuk kanë koncept të një përdoruesi "klikoni". Gjatë një ndërprerjeje të TLS, Stripe dhe Shopify webhooks do të dështojnë në dorëzim dhe do të hyjnë në radhët eksponenciale të riprovës.

Faza 2: Diagnostifikimi prej 60 sekondash - A është vërtetuar tashmë certifikata e rinovuar në disk?¶

Në afërsisht 35 përqind të prodhimit Let's Encrypt ndërprerjet, certifikata në fakt u rinovua në disk javë më parë nga certbot.timer ose acme.sh, por daemon i ekzekutimit po shërben ende certifikatën e vjetër të skaduar nga RAM.

Hapi 1: Krahasoni prizën e drejtpërdrejtë të rrjetit me skedarin në disk¶

Ekzekutoni të dy komandat në serverin tuaj:

# 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

Hapi 2: Rregulloni 4 kurthe të zakonshme "I rinovuar në disk, i skaduar në RAM"¶

Faza 3: Rregullimi i DNS CAA blloqe regjistrimi dhe DNSSEC dështimet e vërtetimit¶

Nëse vraponi sudo certbot renew --dry-run dhe shiko: - 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. Si DNS CAA (RFC 8659) bllokon rinovimin e certifikatës¶

Çdo Autoritet publik Certifikues kërkohet ligjërisht nga Kërkesat bazë të Forumit CA/Browser për të kërkuar DNS CAA regjistron përpara se të lëshojë ndonjë certifikatë. CA ecën lart pemës DNS nga sub.app.example.com -> app.example.com -> example.com: - Nëse example.com ka zero CAA regjistrime, çdo AK lejohet të lëshojë. - Nëse example.com ka ** edhe një të vetme CAA rekord ** (për shembull, 0 issue "amazon.com" shtohet automatikisht kur dikush krijoi një shpërndarje AWS CloudFront, ose 0 issue "digicert.com"), çdo Autoritet tjetër Certifikues në Tokë është rreptësisht i ndaluar të lëshojë një certifikatë për example.com ose ndonjë nga nëndomenet e tij. - Për më tepër, nëse po kërkoni një certifikatë Wildcard (*.example.com) dhe domeni juaj përcakton një specifikë 0 issuewild "ca.example" etiketë, AK-ja kontrollon issuewild prona e jo issue.

Diagnostikimi dhe rregullimi i menjëhershëm për CAA blloqe:¶

1. Kontrollo CAA regjistron si në emrin e hostit ashtu edhe në domenin apex:

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

2. Kontrolloni gjithashtu nëse sub.example.com është një CNAME duke treguar një domen tjetër (Për RFC 8659, CA-të kontrollojnë gjithashtu CAA regjistrime në objektivat CNAME).
3. Në pultin e ofruesit tuaj DNS (Cloudflare, Route 53, Cloud DNS, Namecheap), mos e fshini ekzistuesin CAA regjistrimet të përdorura nga CDN ose AWS ACM juaj; në vend të kësaj, shtoj shtesë CAA të dhënat që autorizojnë Let's Encrypt dhe CA-të tuaja rezervë:

   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"
   

   (Shënim: ZeroSSL përdor sectigo.com si identifikuesin e tij themelor të AAC-së dhe që përdor Shërbimet e Mirëbesimit të Google pki.goog.)
4. Prisni 60 sekonda që serverët tuaj të autorizuar të emrave të përditësohen (dig @ns1.yourdns.com CAA example.com) dhe ridrejtojeni menjëherë sudo certbot renew. Meqenëse CA-të kryejnë kërkime rekursive të drejtpërdrejta duke anashkaluar memoriet e fshehta publike në riprovim, lëshimi ka sukses menjëherë.

2. Fiksimi DNS problem: SERVFAIL looking up CAA (DNSSEC mospërputhje)¶

Le të Encrypt, Google Trust Services dhe ZeroSSL të zbatojnë rreptësisht vlefshmërinë DNSSEC në të gjitha kërkimet e DNS (A, AAAA, TXT, dhe CAA). Edhe nëse një domen ka nr CAA rekord, AK duhet të marrë një të vlefshme kriptografike NOERROR (përgjigje boshe) ose NXDOMAIN (NSEC / NSEC3 mohim i vërtetuar i ekzistencës) përgjigje. - Nëse regjistruesi juaj i domenit ka një ngecje DS (Nënshkruesi i delegacionit) regjistro pasi keni migruar ofruesit DNS (për shembull, duke lëvizur nga GoDaddy në Cloudflare ose Route 53 pa çaktivizuar fillimisht DNSSEC), zgjidhës rekurzivë që zbatojnë kthimin e DNSSEC SERVFAIL. - **Verifiko në 5 sekonda **: Vazhdo delv @8.8.8.8 example.com CAA ose testoni në dnsviz.net. Nëse dig @8.8.8.8 example.com kthehet status: SERVFAIL ndërsa dig +cd @8.8.8.8 example.com (+cd = Kontrollimi i çaktivizuar, injorimi i DNSSEC) kthen adresën tuaj IP, zinxhiri juaj DNSSEC është i prishur. Hyni menjëherë në regjistruesin tuaj të domenit dhe ose hiqni atë të ndenjur DS regjistroni ose kopjoni rrymën DS parametrat nga hosti juaj aktiv DNS.

Faza 4: Duke anashkaluar Le të kodojmë kufijtë e normës (429 Too Many Requests) gjatë një ndërprerjeje aktive¶

Gjatë një incidenti kaotik, inxhinierët shpesh rinisin kontejnerët ose vrapojnë certbot në mënyrë të përsëritur derisa Let's Encrypt të refuzojë të gjitha kërkesat me: - 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

Kohët e pritjes variojnë nga 1 orë (për autorizimet e dështuara) deri në 7 ditë (168 orë) (për kufirin e 5 certifikatave dublikatë). Mos prisni 1 orë ose 7 ditë ndërkohë që faqja juaj e prodhimit është në funksion. Ju keni dy zgjidhje krejtësisht të ligjshme dhe të menjëhershme:

Zgjidhja A (më e mira): Kalo Autoritetin e Certifikatës ACME në Shërbimet ZeroSSL, Buypass ose Google Trust në 30 sekonda¶

Protokolli ACME (RFC 8555) është një standard i hapur. Çdo shfletues dhe sistem operativ kryesor i beson ZeroSSL (rrënja Sectigo), Buypass Go SSL (CA norvegjeze) dhe Shërbimet e Trustit të Google (pki.goog) në mënyrë identike me Let's Encrypt (ISRG Root X1). Asnjë prej tyre nuk ndajnë kufijtë e normës me Let's Encrypt.

• ** Opsioni 1: Lësho menjëherë nëpërmjet Certbot duke përdorur Buypass Go SSL (Nuk kërkohet llogari/çelës EAB, vlefshmëri 180-ditore)**: (Shënim: Buypass mbështet çertifikatat me shumë domene deri në 5 SAN, ndonëse jo wildcard *.example.com çertifikata)

  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
  

• ** Opsioni 2: Lësho menjëherë nëpërmjet acme.sh (i cili parazgjedhur është ZeroSSL ose ndërron CA me --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
  

• ** Opsioni 3: Lëshimi nëpërmjet Shërbimeve të Mirëbesimit të Google (pki.goog) ACME publike **: Në Google Cloud Console (ose nëpërmjet gcloud publicca external-account-keys create), gjeneroni një lidhje falas të llogarisë së jashtme (EAB) shtypni në 10 sekonda dhe ekzekutoni:

  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
  

Zgjidhja B: Anashkaloni kufirin Let's Encrypt "5 Certifikata Dublikate" duke shtuar një emër pritës shtesë SAN¶

Le të kodojmë kufirin e kopjuar prej 168 orësh (too many certificates (5) already issued for this exact set of domains) gjurmon ** grupin e saktë alfabetik të emrave të hosteve SAN** në certifikatë, ndërsa kufiri i përgjithshëm i Domenit të Regjistruar është 50 certifikata në javë. 1. Krijo një DNS të padëmshme A rekord që tregon të njëjtin server: tls-recovery-01.example.com -> <your_server_ip>. 2. Kërkoni certifikatën me domenet tuaja origjinale plus emrin e ri të hostit:

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

Faza 5: Rregullimi i thyer HTTP-01 sfidat (Port 80) ose duke përdorur DNS-01 vlefshmëria emergjente¶

Kur certbot renew dështon me Timeout during connect (likely firewall problem) ose Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (ose 403), serverët e vlefshmërisë CA nuk mund të arrijnë tokenin tuaj të sfidës HTTP në portën TCP 80.

Pse HTTP-01 papritmas prishet në serverët që funksionuan 60 ditë më parë¶

1. Cloud Security Group / UFW / iptables Porta e mbyllur 80: Dikush forcoi murin e zjarrit për të lejuar vetëm portin 443 (HTTPS), duke harruar se RFC 8555 HTTP-01 vlefshmëria fillon gjithmonë në portën e thjeshtë HTTP 80 (megjithëse do të pasojë a 301 ridrejtuar në https:// në port 443).
2. ** IPv6 e prishur (AAAA) Regjistrimi**: Domeni juaj ka edhe një IPv4 (A) regjistrim dhe një IPv6 (AAAA) rekord. Le të Enkriptojmë **preferon gjithmonë IPv6 (AAAA) së pari **. Nëse adresa juaj IPv6 është e gabuar, e bllokuar nga ip6tables, ose jo i lidhur në Nginx (listen [::]:80;), koha e vlefshmërisë përfundon edhe pse IPv4 funksionon mirë.
3. Nginx / Ruteri i aplikacionit (React / Next.js / Django / Rails) përgjimet /.well-known/acme-challenge/: E juaja server bllokoni në portin 80 proxies të gjithë trafikun (location / { proxy_pass http://localhost:3000; }) në një aplikacion mbështetës në vend që të shërbeni .well-known nga disku.

Dy rregullime të menjëhershme për prishjen HTTP-01 vërtetimi¶

Rregullimi 1: Shtoni një prioritet të lartë të dedikuar /.well-known/acme-challenge/ bllokimi në Nginx (Port 80)¶

Sigurohuni që porta juaj 80 të bllokohet /etc/nginx/sites-enabled/ shërben shenjat ACME direkt nga /var/www/letsencrypt përpara çdo return 301 https://... ose proxy_pass direktiva:

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

Rregullimi 2: Anashkaloni plotësisht Portin 80 dhe serverët e uebit me një manual DNS-01 (TXT) sfidë¶

Nëse porta 80 është e bllokuar nga një ISP/firewall në rrjedhën e sipërme ose balancuesi juaj i ngarkesës nuk mund të drejtohet .well-known në nyje të shumta mbështetëse, vërtetojeni nëpërmjet DNS në 2 minuta:

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

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

Faza 6: Verifikimi pas rikuperimit (Zinxhiri i ndërmjetëm, OCSP Stapling dhe pastrimi CDN)¶

Një gabim i zakonshëm pas instalimit të certifikatës së urgjencës cert.pem (vetëm certifikatën e fletës) në vend të fullchain.pem (çertifikata e fletëve + certifikata e ndërmjetme CA). Shfletuesit e desktopit (Chrome, Firefox) shpesh maskojnë një certifikatë të ndërmjetme që mungon nëpërmjet AIA (Authority Information Access) ndjekja ose ruajtja e ndërmjetmeve, ndërsa curl, Python, OpenSSL, aplikacionet Android dhe uebgrepat Stripe/Twilio dështojnë menjëherë me unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• ** Verifikoni që serveri juaj dërgon zinxhirin e plotë të ndërmjetëm (fullchain.pem)**: Vraponi:

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

  Duhet të shihni të paktën dy nivele (depth=0 domeni juaj dhe depth=1 AK e ndërmjetme si p.sh Let's Encrypt E5/R11 ose ZeroSSL RSA Domain Secure Site CA) dhe Verify return code: 0 (ok). Nëse shihni Verify return code: 21 (unable to verify the first certificate), ndryshoni konfigurimin e serverit tuaj të internetit nga cert.pem te fullchain.pem.
• Pastroni memorien e ndenjur të OCSP Stapling në Nginx / Apache: Nëse ssl_stapling on; është aktivizuar, ringarkoni ueb serverin dhe kontrolloni openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
• Konfiguro monitorimin e skadimit të SSL me shumë shtresa (kontrolli i jashtëm i TCP + Prometheus blackbox_exporter): Asnjëherë mos u mbështetni vetëm në kujtesën e emailit (Le të kodojmë emailet rikujtuese të ndërprera të skadimit në 2025). Monitoroni folenë e portit live 443 nga jashtë (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) dhe vendosni një kontroll ditor të cron sudo certbot renew --dry-run.

Numrat rajonalë të urgjencës dhe protokollet e agjencive¶

Ndërsa një certifikatë TLS e skaduar zakonisht zgjidhet nga ekipet inxhinierike, një ndërprerje e certifikatës që thyen portalet e kujdesit shëndetësor, lidhjet në internet të dërgimit të urgjencës, vërtetimi bankar ose infrastruktura publike e qeverisë mund të shkaktojë flukse pune të incidenteve rregullatore:

• Shtetet e Bashkuara dhe Kanadaja:
• **Siguria e jetës / Ndërprerja klinike / Dispetch **: Telefono 911 nëse një dështim i certifikatës TLS ndërpret telemetrinë e pacientit, recetat elektronike ose komunikimet e dërgimit të urgjencës.
• Agjencia e Sigurisë Kibernetike dhe Sigurisë së Infrastrukturës (CISA) (SHBA): Agjencitë civile federale sipas Direktivës Operacionale Detyruese CISA (BOD) 18-01 dhe operatorët kritikë të infrastrukturës që përjetojnë lëshimin e paautorizuar të certifikatës (kompromisi CA ose rrëmbimi i BGP/DNS) duhet të raportojnë te 1-844-Say-CISA (1-844-729-2472) ose cisa.gov/report.
• Qendra Kanadeze për Sigurinë Kibernetike: Kontaktoni 1-833-CYBER-88 (1-833-292-3788).
• Mbretëria e Bashkuar:
• Shërbimet e urgjencës: Telefono 999 nëse një ndërprerje e TLS ndikon në sistemet kritike klinike të NHS ose sigurinë e jetës.
• Qendra Kombëtare e Sigurisë Kibernetike (NCSC): Nëse zbuloni një certifikatë të paautorizuar të lëshuar për domenin tuaj në Transparencën e Certifikatës (crt.sh) regjistrat që tregojnë rrëmbimin e DNS, raportoni nëpërmjet ncsc.gov.uk.
• Bashkimi Evropian:
• Shërbimet e urgjencës: Telefono 112 në të gjitha shtetet anëtare të BE-së.
• Direktiva NIS2 dhe Certifikatat e Autentifikimit të Uebsajtit të Kualifikuar eIDAS (QWACs): Subjektet thelbësore dhe të rëndësishme sipas Direktivës NIS2 që përjetojnë një ndërprerje të zgjatur të disponueshmërisë ose të komprometuar çelësat PKI duhet të njoftojnë CSIRT-në e tyre kombëtare brenda 24 orëve.
• Australi dhe Zelanda e Re:
• Shërbimet e urgjencës: Telefono 000 në Australi ose 111 në Zelandën e Re; kontaktoni ACSC (1300 CYBER1) për incidente në infrastrukturë.
• **India dhe Azia-Paqësori **:
• ** Indi (CERT-In / Kontrollues i Autoriteteve Certifikuese CCA)**: Telefono 112 për përgjigje emergjente; raportoni kompromisin e PKI-së ose ndërprerjet e rëndësishme të infrastrukturës incident@cert-in.org.in brenda 6 orëve.

Pyetjet e bëra shpesh¶

Pse unë ose përdoruesit e mi nuk mund të klikojmë "E avancuar -> Vazhdo te sajti (i pasigurt)" në Chrome ose Safari gjatë këtij ndërprerjeje?¶

Kur domeni juaj dërgon Strikte-Transporti-Siguria (HSTS) Titulli HTTP - ose përdor një domen të nivelit të lartë si p.sh .dev, .app, .faqe, ose .bankë e cila është e koduar në listën e parangarkesës HSTS të shfletuesit - RFC 6797 kërkon që shfletuesi të trajtojë çdo certifikatë të skaduar, të vetë-nënshkruar ose të papërputhshme si një gabim fatal të pa rikuperueshëm. Shfletuesi heq qëllimisht butonin e anashkalimit "Vazhdo gjithsesi" për të parandaluar sulmuesit aktivë Man-in-the-Middle (MitM) që të mashtrojnë përdoruesit që të klikojnë përmes një certifikate të falsifikuar. Ndërsa një zhvillues në desktopin Chrome mund të shtypë sekuencën e fshehur të tastierës kjo është e pasigurt direkt në ekranin e gabimit për ta anashkaluar atë në nivel lokal për testim, përdoruesit e vërtetë nuk munden; duhet të instaloni një certifikatë të vlefshme në portin 443.

Le të Encrypt ndaloi dërgimin e emaileve paralajmëruese të skadimit dhe certifikata ime skadoi pa paralajmërim - pse ndodhi kjo?¶

Let's Encrypt tërhoqi zyrtarisht shërbimin e email-it të njoftimit të skadimit në mesin e vitit 2025 për të reduktuar shpenzimet e ruajtjes së të dhënave dhe për shkak se konfigurimet e automatizuara ACME duhet të monitorojnë drejtpërdrejt shëndetin e rinovimit. Për të parandaluar surprizat e ardhshme, duhet të monitoroni vulën kohore aktuale të skadimit të shtrëngimit të duarve TLS përmes rrjetit duke përdorur një monitor të jashtëm të kohës së funksionimit (si p.sh. Prometheus kutia e zezë_eksportues, Kontrollet Kuma në kohën e duhur, Better Stack ose Datadog Synthetic TLS) duke sinjalizuar në 21 ditë, 14 ditë dhe 7 ditë përpara joPas.

Pse faqja ime funksionon mirë në Chrome dhe Firefox në laptopin tim, por dështon në telefonat Android, curl, dhe Stripe uebhooks pasi kam përditësuar certifikatën?¶

Ju konfiguruat serverin tuaj të internetit (ssl_certificate në Nginx ose SSLCcertificateFile në Apache) për të treguar vërtetim.pem (vetëm certifikatën e fletës) në vend të zinxhir i plotë.pem (çertifikata e fletës së bashku me certifikatën e ndërmjetme CA). Shfletuesit e desktopit si Chrome dhe Firefox shkarkojnë automatikisht certifikatat e ndërmjetme që mungojnë në sfond duke përdorur Qasja në informacionin e autoritetit (AIA) URL brenda certifikatës suaj të fletës, duke fshehur konfigurimin e gabuar të serverit tuaj. Megjithatë, kaçurrela, OpenSSL, verifikuesi i besimit të sistemit të Android, serverët Python dhe webhook nuk kryejnë ndjekje AIA dhe refuzojnë menjëherë lidhjen me në pamundësi për të marrë certifikatën e lëshuesit lokal. Drejtoni konfigurimin tuaj te zinxhir i plotë.pem dhe ringarkoni serverin tuaj.

Si mund të kontrolloj nëse një haker ose administrator mashtrues ka lëshuar një certifikatë të paautorizuar SSL për domenin tim?¶

Çdo Autoritet Certifikues i besuar publikisht kërkohet të regjistrojë çdo certifikatë të lëshuar në publik Regjistrat e Transparencës së Certifikatës (CT). (RFC 6962) përpara se shfletuesit t'i besojnë. Hapur https://crt.sh/?q=%25.yourdomain.com ose Monitoruesi i Transparencës së Certifikatës së Cloudflare për të parë çdo certifikatë të lëshuar ndonjëherë për domenin tuaj dhe nënfushat e tij. Nëse shihni një certifikatë të lëshuar nga një CA të panjohur që nuk e keni autorizuar, inspektoni menjëherë regjistruesin tuaj DNS dhe zonën autoritare DNS për modifikime të paautorizuara, anuloni certifikatën mashtruese me CA-në lëshuese dhe mbyllni DNS-në tuaj me AAC rekorde (`0 issue "letsencrypt.org"`).

Po sikur grupi im i Kubernetes cert-manager dështoi të rinovojë certifikatën tonë të hyrjes dhe Urdhri është bllokuar Pending?¶

Vraponi kubectl marr porosi,sfidë -A dhe pastaj kubectl përshkruaj sfidën -n . Në 90 për qind të Kubernetes cert-menaxher ndërprerjet, të cm-acme-http-zgjidhës-* pod i përkohshëm po funksionon, por ose (1) burimi Ingress ka një shënim të vjetëruar të klasës hyrëse, kështu që rruga e zgjidhësit nuk është bashkangjitur kurrë me balancuesin tuaj të ngarkesës, (2) një Kubernetes Politika e Rrjetit po bllokon trafikun e hyrjes në podin e zgjidhjes në portën 8089, ose (3) parandalon një problem NAT / ndarje e horizontit DNS cert-menaxherVetëkontrolli i brendshëm nga arritja e IP-së tuaj publike të balancuesit të ngarkesës (i rregullueshëm duke kaluar --dns01-rekursive-nameservers=8.8.8.8:53,1.1.1.1:53 te cert-menaxher args vendosjes).

A mund ta kopjoj timen /etc/letsencrypt/ dosje në një server të ri gjatë një migrimi urgjent në vend që të ri-lëshohet?¶

po. Nëse serveri juaj primar ka vdekur dhe po migroni në një server të ri ndërsa norma është e kufizuar nga Let's Encrypt, ruani lidhjet e simboleve gjatë kopjimit /etc/letsencrypt/ duke përdorur tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (mos përdorni kurrë të thjeshtë scp -r, e cila i kthen lidhjet simbolike /etc/letsencrypt/live/ në skedarë të kopjuar statikë dhe prish rinovimet e ardhshme). Ekstraktoni atë arkiv në serverin e ri (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), pika Nginx/Apache në `/etc/letsencrypt/live/domain/fullchain.pem`, dhe certifikata juaj ekzistuese do të funksionojë menjëherë në adresën e re IP.

Udhëzues të lidhur¶

• Rrëmbimi i emrit të domenit, DNS i skaduar dhe marrja e faqes në internet
• Disku i serverit 100% i mbushur (0 bajt falas): baza e të dhënave dhe rikuperimi i hapësirës zero
• Google Workspace ose bllokimi i personalizuar i administratorit të domenit të Microsoft 365 dhe shpëtimi DNS TXT
• Kriza e mbajtjes së uebit, migrimi dhe restaurimi i rezervave
• Rrëmbimi i DNS-së, rikonfigurimi i rrugëzuesit të ISP-së në WAN dhe mashtrimi i portalit të kapur
• Numrat e urgjencës sipas vendit

Burimet dhe udhëzimet zyrtare¶

• Task Forca e Inxhinierisë së Internetit (IETF): RFC 8555 (Automatic Certificate Management Environment / ACME), RFC 8659 (Autorizimi i Autoritetit të Certifikimit DNS / CAA) dhe RFC 6797 (HTTP Strict Transport Security / HSTS).
• Instituti Kombëtar i Standardeve dhe Teknologjisë (NIST) (Shtetet e Bashkuara): Publikimi special 800-52 Rev. 2: Udhëzime për Zgjedhjen, Konfigurimin dhe Përdorimin e Zbatimeve të Sigurisë së Shtresës së Transportit (TLS) & SP 1800-16: Sigurimi i transaksioneve në ueb: Menaxhimi i certifikatës së serverit TLS.
• Grupi i Kërkimit të Sigurisë në Internet (ISRG / Le të kodojmë dokumentacionin zyrtar): Referenca e kufijve të normës, Rregullat e kopjimit të certifikatës dhe Zgjidhja e problemeve të sfidës ACME.
• Agjencia e Sigurisë Kibernetike dhe Sigurisë së Infrastrukturës (CISA) (Shtetet e Bashkuara): Direktiva Operacionale Detyruese 18-01: Përmirësimi i Sigurisë së Email-it dhe Uebit (Udhëzimet për Zbatimin e HTTPS dhe HSTS).
• Qendra Kombëtare e Sigurisë Kibernetike (NCSC) (Mbretëria e Bashkuar): Përdorimi i TLS për të mbrojtur në mënyrë perfekte të dhënat në tranzit dhe Udhëzimet për monitorimin e transparencës së certifikatave.