Cheti cha Uzalishaji cha SSL/TLS Kimeisha Muda: Kurekebisha Mizimio ya HSTS Iliyoshindikana na Tusimbe Vizuizi vya CAA/Kiwango-Kikomo¶

Wakati uzalishaji wa SSL/TLS (HTTPS) cheti kinaisha muda wake - hata kwa sekunde moja kupita yake notAfter Muhuri wa wakati wa UTC - kila kivinjari cha kisasa (Chrome, Safari, Firefox, Edge), programu ya simu (iOS App Transport Security, Android Network Security Config), kipokeaji cha mtandao (Stripe, Shopify, Twilio, GitHub), na mteja wa API ya juu hukata muunganisho mara moja NET::ERR_CERT_DATE_INVALID au SSL_ERROR_RX_RECORD_TOO_LONG. Mbaya zaidi, ikiwa kikoa chako kitatuma faili ya Strict-Transport-Security (HSTS) kichwa au imekusanywa kwenye kivinjari HSTS Orodha ya Upakiaji, Chrome na Safari huondoa kitufe cha "Advanced -> Nenda kwenye tovuti (si salama)" kabisa, na kusababisha kukatika kwa asilimia 100 kwa kila mtumiaji duniani kote. Mara nyingi, cronjob ya upyaji otomatiki (Certbot, acme.sh, Caddy, cert-manager, au AWS ACM) imekuwa ikishindwa kimya kimya kwa siku 30 kwa sababu ya DNS yenye vizuizi CAA rekodi, DNSSEC iliyovunjika DS rekodi, bandari ya kuzuia firewall 80 (HTTP-01 changamoto), au seva ya wavuti (nginx / haproxy) ambayo ilifanya upya faili kwenye diski (fullchain.pem) lakini haikupakia tena michakato yake ya kumbukumbu ya mfanyakazi. Ikiwa kukatika kwako kulisababishwa na usajili wa kikoa ulioisha muda wake au seva za majina zilizotekwa nyara badala ya cheti chenyewe cha X.509, badilisha mara moja hadi utekaji nyara wa jina la kikoa, DNS iliyoisha muda wake, na unyakuzi wa tovuti; ikiwa seva yako haipatikani kabisa au iko nje ya nafasi ya diski hivyo certbot hawezi kuandika kwa /etc/letsencrypt, tazama diski ya seva 100% imejaa na urejeshaji wa nafasi ya sifuri au mgogoro wa mwenyeji wa wavuti, uhamiaji, na urejesho wa chelezo. Ikiwa kukatika huku kwa TLS kutazima telemetry ya hospitali, API za kutuma dharura, au miundombinu ya usalama wa umma, piga simu kwa nambari ya dharura ya eneo lako (911 nchini Marekani na Kanada, 112 katika Umoja wa Ulaya, 999 nchini Uingereza) au wasiliana na saraka yetu ya kimataifa ya nambari za dharura.

Fanya hivi sasa¶

1. Angalia baada ya sekunde 10 ikiwa cheti kwenye diski tayari kimesasishwa, na seva yako ya wavuti au kisawazisha cha upakiaji kilishindwa kukipakia upya kwenye RAM:
2. Linganisha tundu la TLS moja kwa moja dhidi ya .pem faili kwenye diski hivi sasa:

   # 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. Ikiwa faili kwenye diski inaonyesha siku zijazo halali notAfter tarehe wakati bandari ya moja kwa moja 443 inaonyesha tarehe ya mwisho wa matumizi: Mteja wako wa ACME (certbot / acme.sh) ilifanikiwa wiki zilizopita, lakini nginx, apache2, haproxy, au postfix haikupakiwa tena, au (haproxy / vault) inahitaji fullchain.pem + privkey.pem kuunganishwa katika kifungu kimoja. Kimbia sudo nginx -t && sudo systemctl reload nginx (au sudo systemctl reload apache2 haproxy) na kukatika kwako kutaisha baada ya sekunde 2.
4. USIEMBIE certbot renew --force-renewal mara kwa mara katika mzunguko ikiwa usasishaji utashindikana: Hebu Tusimbe kwa njia fiche kikomo kali cha kiwango cha Vyeti 5 rudufu kwa siku 7 na uthibitishaji 5 ambao haujafaulu kwa kila akaunti, kwa kila jina la mpangishaji, kwa saa. Kukimbia --force-renewal mara tano kwa hofu bila kurekebisha msingi nginx pakia upya au hitilafu ya DNS/firewall itafunga kikoa chako nje ya utoaji wa Hebu Tusimba kwa Fiche kwa hadi siku 7.
5. Ukigonga Kikomo cha Kiwango cha Wacha Tusimbe kwa Njia Fiche (429 Too Many Requests), badilisha mteja wako wa ACME hadi Mamlaka ya Cheti cha pili cha umma bila malipo (ZeroSSL, Buypass Go SSL, au Google Trust Services) au ongeza kikoa kidogo cha SAN mara moja:
6. Kila mteja wa ACME (certbot, acme.sh, caddy, cert-manager) inaweza kuomba cheti cha kuaminiwa bila malipo kutoka kwa CA tofauti katika sekunde 30 (--server https://acme.zerossl.com/v2/DV90 au https://api.buypass.com/acme/directory), ikipita kabisa kikomo cha kiwango cha Let's Encrypt.
7. Vinginevyo, kikomo cha Hebu Tufiche "cheti rudufu 5 kwa siku 7" kinatumika tu kwa seti sawa kabisa ya Majina Mbadala ya Mada (SANs). Kuongeza kikoa kimoja cha ziada halali (-d example.com -d www.example.com -d tlsfix1.example.com) huifanya kuwa cheti kisicho nakala na kupita kikomo cha kiwango cha Cheti cha Nakala mara moja.
8. Angalia ikiwa DNS CAA rekodi au kuvunjwa DNSSEC inazuia Mamlaka ya Cheti chako kutoa (CAA record for example.com prevents issuance):
9. Hoji Uidhinishaji wa Mamlaka ya Uidhinishaji wa kikoa chako (CAArekodi): dig +short CAA example.com. Ikiwa DNS yako ina 0 issue "sectigo.com" au 0 issue "amazon.com" (au kwenye kikoa cha mzazi), Wacha Tusimba (letsencrypt.org) na ZeroSSL (sectigo.com) zimekatazwa na RFC 8659 kutoa hadi uongeze 0 issue "letsencrypt.org" kwa eneo lako la DNS.
10. Ikiwa bandari 80 (HTTP-01 challenge) imezuiwa na ngome, CDN, au ISP, au seva yako ya wavuti ikikataa kuanza kwa sababu ya cheti kinachokosekana, tumia. --standalone au --dns (DNS-01) uthibitisho:
11. Acha nginx/apache kwa muda mfupi na kukimbia sudo certbot certonly --standalone -d example.com, au kutumia --manual --preferred-challenges dns kuthibitisha kwa kubandika a _acme-challenge.example.com TXT rekodi kwenye koni yako ya DNS bila kugusa mlango 80.
12. Kama tovuti yako iko nyuma ya Cloudflare, AWS CloudFront, au Haraka, thibitisha ikiwa cheti kilichoisha muda kiko kwenye CDN Edge au kwenye Seva yako ya Mwanzo (Error 526 Invalid SSL Certificate):
13. Kwenye Cloudflare, ikiwa cheti chako cha seva asili kimeisha muda na Cloudflare imewekwa Full (Strict), watumiaji wanaona Hitilafu 526. Unaporekebisha cheti cha asili, unaweza kurejesha trafiki ya tovuti moja kwa moja katika sekunde 5 kwa kutoa cheti cha miaka 15 Cloudflare Origin CA kwenye dashibodi ya Cloudflare (au kubadilisha kwa muda modi ya SSL/TLS kutoka Full (Strict) kwa Full kwa dakika 10 inachukua kuchukua nafasi ya asili .pem faili).

Mti wa uamuzi: kuchunguza na kurekebisha cheti cha uzalishaji cha SSL/TLS ambacho muda wake umekwisha¶

Fuata mti huu wa uamuzi ili kubainisha safu kamili ya kutofaulu (CDN Edge dhidi ya Kumbukumbu ya Daemon Asili dhidi ya ACME Challenge dhidi ya Kikomo cha Kiwango cha CA) na urejeshe trafiki ya HTTPS kwa dakika chache:

flowchart TD
    Start["Watumiaji / API zinazoripoti NET::ERR_CERT_DATE_INVALID au Hitilafu ya Cloudflare 526"] --> CheckLive["Endesha: openssl s_client -servername domain -connect domain:443 | openssl x509 -noout -tarehe -toa"]

    CheckLive --> WhereExpired{"Ni Cheti Gani Kimeisha Muda wake?"}

    WhereExpired -->|"Diski fullchain.pem NI HALALI, Lakini Bandari ya Moja kwa Moja ya 443 IMEMALIZIKA"| StaleDaemon["Kumbukumbu ya Daemon ya Stale au Duka la Cert ya Mgawanyiko: Pakia upya nginx / apache2 / haproxy / postfix, au Unda Upya Kifungu cha HAProxy PEM kilichounganishwa"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) Imeisha Muda wake"| CDNFix["Angalia Rekodi za DNS CAA za CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) na Geuza Universal SSL au Thibitisha Upya ACM"]
    WhereExpired -->|"Seva Asili fullchain.pem kwenye Diski IMEMALIZIKA"| DryRun["Endesha: sudo certbot upya --dry-run (au acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"Kwa nini Usasishaji wa ACME Umeshindwa?"}

    WhyFailed -->|"Maombi 429 Nyingi Sana (Kikomo cha Kiwango Kimezidi)"| RateLimit["Bypass Mara Moja: Toleo kutoka kwa ZeroSSL / Buypass / Huduma za Uaminifu za Google AU Ongeza Kikoa Kidogo 1 cha Ziada SAN (-d fix1.example.com)"]
    WhyFailed -->|"Rekodi ya CAA Inazuia Utoaji au SERVFAIL (DNSSEC)"| CAADNS["Endesha: dig CAA example.com -> Ongeza suala 0 'letsencrypt.org' (na 'sectigo.com') au Rekebisha Rekodi Iliyovunjika ya DNSSEC DS kwa Msajili."]
    WhyFailed -->|"Muunganisho Umekataliwa / Muda umekwisha / 404 kwenye /.well-known/acme-challenge/"| HttpBlock["Mlango wa 80 Umezuiwa au Uelekeze Upya Kitanzi: Fungua Mlango wa TCP 80 kwenye Firewall, Usijumuishe /.well-known/ kutoka kwa Auth/Andika Upya, au Tumia DNS-01 Challenge"]
    WhyFailed -->|"Agizo la meneja wa Kubernetes Limekwama"| K8sFix["Endesha: kubectl elezea changamoto -> Angalia ufafanuzi wa darasa la Ingress, sera ya mtandao ya kisuluhishi cha HTTP01, au Webhook TLS"]

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

Awamu ya 1: Kuelewa kwa nini HSTS (Strict-Transport-Security) husababisha kukatika kwa umeme kwa kushindwa kabisa¶

Wakati tovuti haitumii HSTS, cheti kilichoisha muda wake kinaonyesha onyo la kati (Your connection is not private) iliyo na "Advanced -> Nenda kwa example.com (si salama)" kiungo kinachoruhusu watumiaji waliokata tamaa kubofya.

Walakini, karibu maombi yote ya kisasa ya wavuti ya uzalishaji, mabenki, majukwaa ya SaaS, na .dev / .app / .page / .bank vikoa vya kiwango cha juu hutekeleza Usalama Mkali wa Usafiri wa HTTP (HSTS, RFC 6797): 1. Dynamic HSTS (max-age=31536000): Kivinjari chochote ambacho kimetembelea tovuti yako ndani ya siku 365 zilizopita kiliweka akiba ya sera Strict-Transport-Security: max-age=31536000; includeSubDomains. Hadi kipima muda hicho kitakapoisha, kivinjari kinakataza mtumiaji kubofya kosa lolote la cheti (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, au ERR_CERT_AUTHORITY_INVALID) 2. ** Upakiaji wa awali wa HSTS (preload orodha au .dev / .app gTLD)**: Ikiwa kikoa chako kiliwasilishwa kwa hstspreload.org - au ikiwa kikoa chako kinatumia TLD Iliyopakiwa awali ya Usajili kama vile .dev, .app, .page, .new, .chrome, au .bank - kila nakala ya Chrome, Edge, Firefox, Safari, na Android WebView on Earth ina kikoa chako kikiwa na mfumo wa mfumo wa jozi kama inavyotekelezwa na HSTS kabla ya mtumiaji kutembelea tovuti yako kwa mara ya kwanza. 3. **Kwa nini includeSubDomains inavunja zana za ndani na seva za kuweka : Ikiwa kikoa chako cha mizizi (example.com) hutuma Strict-Transport-Security: max-age=31536000; includeSubDomains, kila kikoa (vpn.example.com, internal-jira.example.com, printer.example.com) pia imefungwa katika hali ya kushindwa kwa bidii ya HSTS. 4. ** Kwa nini API na miunganisho ya Webhook (Stripe, Twilio, Slack, iOS ATS) kushindwa mara moja: Wateja wa TLS wa Seva hadi seva (libcurl, Chatu requests/urllib3, Node.js undici, Nenda crypto/tls, Java SSLContext) fanya RFC 5280 kali notAfter uthibitisho kwa chaguo-msingi na hawana dhana ya mtumiaji "click-through." Wakati TLS imezimika, Stripe na Shopify webbooks zitashindwa kufikishwa na kuingia kwenye foleni kubwa za kujaribu tena.

Awamu ya 2: Uchunguzi wa sekunde 60 - Je, cheti tayari kimesasishwa kwenye diski?¶

Takriban asilimia 35 ya uzalishaji wa Let's Encrypt kukatika, cheti kilisasishwa kwenye diski wiki zilizopita na certbot.timer au acme.sh, lakini daemon inayoendesha bado inatumikia cheti cha zamani kilichoisha muda kutoka kwa RAM.

Hatua ya 1: Linganisha tundu la mtandao wa moja kwa moja dhidi ya faili ya kwenye diski¶

Endesha amri zote mbili kwenye seva yako:

# 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

Hatua ya 2: Rekebisha mitego 4 ya kawaida "Imesasishwa kwenye Diski, Imeisha muda wa RAM".¶

Awamu ya 3: Kurekebisha DNS CAA rekodi vitalu na DNSSEC kushindwa kwa uthibitishaji¶

Ikiwa unakimbia sudo certbot renew --dry-run na tazama: - 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. Jinsi DNS CAA (RFC 8659) inazuia usasishaji wa cheti¶

Kila Mamlaka ya Cheti cha Umma inahitajika kisheria na Masharti ya Msingi ya CA/Browser Forum ili kuuliza DNS CAA rekodi kabla ya kutoa cheti chochote. CA inatembea juu ya mti wa DNS kutoka sub.app.example.com -> app.example.com -> example.com: - Kama example.com ina sifuri CAA kumbukumbu, CA yoyote inaruhusiwa kutoa. - Kama example.com ina **hata moja CAA rekodi ** (kwa mfano, 0 issue "amazon.com" iliongezwa kiotomatiki mtu alipounda usambazaji wa AWS CloudFront, au 0 issue "digicert.com"), kila Mamlaka nyingine ya Cheti Duniani imepigwa marufuku kabisa kutoa cheti cha example.com au kikoa chake kidogo. - Zaidi ya hayo, ikiwa unaomba cheti cha Wildcard (*.example.com) na kikoa chako kinafafanua maalum 0 issuewild "ca.example" tag, CA inakagua issuewild mali badala ya issue.

Utambuzi na marekebisho ya papo hapo kwa CAA vitalu:¶

1. Angalia CAA rekodi kwenye jina la mwenyeji na kikoa cha kilele:

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

2. Pia angalia kama sub.example.com ni a CNAME akielekeza kwenye kikoa kingine (Per RFC 8659, CAs pia angalia CAA rekodi kwenye malengo ya CNAME).
3. Katika dashibodi ya mtoa huduma wako wa DNS (Cloudflare, Route 53, Cloud DNS, Namecheap), usifute zilizopo CAA rekodi zinazotumiwa na CDN au AWS ACM yako; badala yake, **ongeza ** nyongeza CAA rekodi zinazoidhinisha Hebu Tusimbe kwa Njia Fiche na CA zako mbadala:

   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"
   

   (Kumbuka: ZeroSSL hutumia sectigo.com kama kitambulisho chake cha msingi cha CAA, na matumizi ya Huduma za Google Trust pki.goog.)
4. Subiri sekunde 60 kwa seva zako zilizoidhinishwa kusasisha (dig @ns1.yourdns.com CAA example.com) na mara moja endesha tena sudo certbot renew. Kwa kuwa CAs hufanya ukaguzi wa moja kwa moja unaojirudia kwa kupita akiba za umma wakati wa kujaribu tena, utoaji utafaulu mara moja.

2. Kurekebisha DNS problem: SERVFAIL looking up CAA (DNSSEC kutolingana)¶

Hebu Tusimba, Huduma za Google Trust, na ZeroSSL tutekeleze kwa uthabiti uthibitishaji wa DNSSEC kwenye utafutaji wote wa DNS (A, AAAA, TXT, na CAA) Hata kama kikoa kina no CAA rekodi, CA lazima ipokee kriptografia halali NOERROR (jibu tupu) au NXDOMAIN (NSEC / NSEC3 kuthibitishwa kukataa kuwepo) majibu. - Iwapo msajili wako wa kikoa anashikilia uchakavu DS (Msaini wa Ujumbe) rekodi baada ya kuwahamisha watoa huduma wa DNS (kwa mfano, kuhama kutoka GoDaddy hadi Cloudflare au Route 53 bila kuzima DNSSEC kwanza), visuluhishi vinavyojirudia vinavyotekeleza urejeshaji wa DNSSEC SERVFAIL. - Thibitisha baada ya sekunde 5: Endesha delv @8.8.8.8 example.com CAA au jaribu kwa dnsviz.net. Kama dig @8.8.8.8 example.com anarudi status: SERVFAIL wakati dig +cd @8.8.8.8 example.com (+cd = Kuangalia Kumezimwa, kupuuza DNSSEC) hurejesha anwani yako ya IP, msururu wako wa DNSSEC umevunjika. Ingia kwenye msajili wa kikoa chako mara moja na ama uondoe zamani DS rekodi au nakili mkondo DS vigezo kutoka kwa seva pangishi yako ya DNS inayotumika.

Awamu ya 4: Kupita Hebu Tusimbe Vikomo vya Viwango (429 Too Many Requests) wakati wa kukatika kwa shughuli¶

Wakati wa tukio la machafuko, wahandisi mara nyingi huwasha tena vyombo au kukimbia certbot mara kwa mara hadi Let's Encrypt ikatae maombi yote na: - 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

Muda wa kusubiri ni kati ya saa 1 (kwa uidhinishaji usiofanikiwa) hadi siku 7 (saa 168) (kwa kikomo cha vyeti 5 vinavyorudiwa). Usingoje saa 1 au siku 7 tovuti yako ya utayarishaji ikiwa chini. Una suluhisho mbili halali kabisa na za haraka:

Njia A (Bora zaidi): Badilisha Mamlaka ya Cheti cha ACME hadi ZeroSSL, Buypass, au Huduma za Google Trust ndani ya sekunde 30¶

Itifaki ya ACME (RFC 8555) ni kiwango kilicho wazi. Kila kivinjari kikuu na mfumo wa uendeshaji unaamini ZeroSSL (Sectigo root), Buypass Go SSL (Norwegian CA), na Huduma za Google Trust (pki.goog) sawa na Hebu Tusimbe (ISRG Root X1) Hakuna hata mmoja wao anayeshiriki viwango vya viwango na Let's Encrypt.

• Chaguo 1: Toa mara moja kupitia Certbot kwa kutumia Buypass Go SSL (Hakuna akaunti/ufunguo wa EAB unaohitajika, uhalali wa siku 180): (Kumbuka: Buypass inasaidia vyeti vya vikoa vingi hadi SAN 5, ingawa si kadi-mwitu *.example.com vyeti)

  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
  

• Chaguo la 2: Toa mara moja kupitia acme.sh (ambayo inabadilika kuwa ZeroSSL au kubadili CA kwa --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
  

• Chaguo la 3: Toleo kupitia Huduma za Google Trust (pki.goog) ACME ya Umma: Katika Google Cloud Console (au kupitia gcloud publicca external-account-keys create), toa Ufungaji wa Akaunti ya Nje bila malipo (EAB) ufunguo katika sekunde 10 na kukimbia:

  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
  

Suluhu B: Pitisha kikomo cha Hebu Tusimbe "Vyeti 5" kwa kuongeza jina moja la ziada la mwenyeji wa SAN¶

Hebu Tufiche kikomo cha nakala cha saa 168 (too many certificates (5) already issued for this exact set of domains) hufuatilia seti kamili ya alfabeti ya majina ya wapangishaji SAN kwenye cheti, ilhali kikomo cha jumla cha Kikoa Kilichosajiliwa ni Vyeti 50 kwa wiki. 1. Unda DNS isiyo na madhara A rekodi inayoelekeza kwa seva hiyo hiyo: tls-recovery-01.example.com -> <your_server_ip>. 2. Omba cheti na vikoa vyako asili pamoja na jina jipya la mpangishaji:

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

Awamu ya 5: Kurekebisha kuvunjika HTTP-01 changamoto (Port 80) au kutumia DNS-01 uthibitisho wa dharura¶

Wakati certbot renew inashindwa na Timeout during connect (likely firewall problem) au Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (au 403), seva za uthibitishaji wa CA haziwezi kufikia tokeni yako ya changamoto ya HTTP kwenye TCP port 80.

Kwa nini HTTP-01 ghafla huvunjika kwenye seva ambazo zilifanya kazi siku 60 zilizopita¶

1. ** Kikundi cha Usalama cha Wingu / UFW / iptables imefungwa Bandari 80**: Mtu aliimarisha ngome ili kuruhusu mlango pekee 443 (HTTPS), na kusahau kwamba RFC 8555 HTTP-01 uthibitisho kila mara huanza kwenye bandari HTTP 80 (ingawa itafuata a 301 elekeza kwa https:// kwenye bandari 443)
2. IPv6 Iliyovunjika (AAAA) Rekodi: Kikoa chako kina IPv4 (A) rekodi na IPv6 (AAAA) rekodi. Hebu Tusimbe Siku zote tunapendelea IPv6 (AAAA) kwanza. Ikiwa anwani yako ya IPv6 imepotoshwa, itazuiwa na ip6tables, au haijafungwa kwa Nginx (listen [::]:80;), muda wa uthibitishaji umeisha ingawa IPv4 inafanya kazi vizuri.
3. ** Nginx / Njia ya Maombi (React / Next.js / Django / Rails) kuingilia /.well-known/acme-challenge/**: yako server zuia kwenye bandari proksi 80 trafiki yote (location / { proxy_pass http://localhost:3000; }) kwa programu ya nyuma badala ya kutumikia .well-known kutoka kwa diski.

Marekebisho mawili ya papo hapo kwa kuvunjwa HTTP-01 uthibitisho¶

Rekebisha 1: Ongeza kipaumbele maalum kilichowekwa /.well-known/acme-challenge/ block katika Nginx (Port 80)¶

Hakikisha bandari yako ya 80 inazuia ndani /etc/nginx/sites-enabled/ hutumikia tokeni za ACME moja kwa moja kutoka /var/www/letsencrypt kabla yoyote return 301 https://... au proxy_pass maelekezo:

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

Kurekebisha 2: Bypass Port 80 na seva za wavuti kabisa na mwongozo DNS-01 (TXT) changamoto¶

Ikiwa port 80 imezuiwa na ISP/firewall ya juu ya mkondo au kisawazisha chako cha upakiaji hakiwezi kuelekeza .well-known kwa nodi nyingi za nyuma, thibitisha kupitia DNS katika dakika 2:

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

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

Awamu ya 6: Uthibitishaji wa baada ya urejeshaji (Msururu wa Kati, Ufungaji wa OCSP, na Usafishaji wa CDN)¶

Hitilafu ya kawaida baada ya kubadilisha cheti cha dharura ni kusakinisha cert.pem (cheti cha majani peke yake) badala ya fullchain.pem (cheti cha majani + cheti cha kati cha CA). Vivinjari vya eneo-kazi (Chrome, Firefox) mara nyingi hufunika cheti cha kati kinachokosekana kupitia AIA (Authority Information Access) kukimbiza au kufungia kati, wakati curl, Python, OpenSSL, programu za Android, na vijiti vya wavuti vya Stripe/Twilio vinashindwa mara moja na unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• Thibitisha kuwa seva yako inatuma Msururu kamili wa Kati (fullchain.pem): Endesha:

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

  Lazima uone angalau ngazi mbili (depth=0 kikoa chako na depth=1 CA ya kati kama vile Let's Encrypt E5/R11 au ZeroSSL RSA Domain Secure Site CA) na Verify return code: 0 (ok). Ukiona Verify return code: 21 (unable to verify the first certificate), badilisha usanidi wako wa seva ya wavuti kutoka cert.pem kwa fullchain.pem.
• Futa kashe ya zamani ya OCSP ya Ufungaji katika Nginx / Apache: Kama ssl_stapling on; imewashwa, pakia upya seva ya wavuti na uangalie openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
• Sanidi ufuatiliaji wa kuisha kwa SSL wa tabaka nyingi (Cheki TCP ya Nje + Prometheus blackbox_exporter): Kamwe usitegemee vikumbusho vya barua pepe pekee (Hebu Tusimbe kwa njia fiche barua pepe za vikumbusho vya kumalizika muda wake mwaka wa 2025). Fuatilia tundu la moja kwa moja la bandari 443 nje (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) na uweke ukaguzi wa kila siku wa cron sudo certbot renew --dry-run.

Nambari za dharura za kikanda na itifaki za wakala¶

Ingawa cheti cha TLS kilichoisha muda wake kwa kawaida hutatuliwa na timu za wahandisi, hitilafu ya cheti ambayo inavunja lango la huduma ya afya, utumaji wa mtandao wa dharura, uthibitishaji wa benki, au miundombinu ya umma ya serikali inaweza kusababisha mtiririko wa matukio ya udhibiti:

• Marekani na Kanada:
• Usalama wa Maisha / Kliniki / Kukatika kwa Usambazaji: Piga 911 ikiwa kutofaulu kwa cheti cha TLS kutakatisha mawasiliano ya mgonjwa, maagizo ya kielektroniki, au mawasiliano ya dharura.
• Wakala wa Usalama wa Mtandao na Miundombinu (CISA) (Marekani): Mashirika ya kiraia ya shirikisho chini ya Agizo la Uendeshaji Linalofunga CISA (BOD) 18-01 na waendeshaji muhimu wa miundombinu wanaokumbana na utoaji wa cheti ambacho hakijaidhinishwa (maelewano ya CA au utekaji nyara wa BGP/DNS) wanapaswa kuripoti kwa 1-844-Say-CISA (1-844-729-2472) au cisa.gov/report.
• Kituo cha Kanada cha Usalama wa Mtandao: Wasiliana 1-833-CYBER-88 (1-833-292-3788).
• Uingereza:
• Huduma za Dharura: Piga 999 ikiwa kukatika kwa TLS kutaathiri mifumo muhimu ya kimatibabu ya NHS au usalama wa maisha.
• Kituo cha Usalama cha Mtandao cha Kitaifa (NCSC): Ukigundua cheti kisichoidhinishwa kilichotolewa kwa kikoa chako katika Uwazi wa Cheti (crt.sh) kumbukumbu zinazoonyesha utekaji nyara wa DNS, ripoti kupitia ncsc.gov.uk.
• Umoja wa Ulaya:
• Huduma za Dharura: Piga 112 katika nchi zote wanachama wa EU.
• Maelekezo ya NIS2 & Vyeti Vilivyohitimu vya Uthibitishaji wa Tovuti ya eIDAS (QWACs): Huluki muhimu na muhimu chini ya Maelekezo ya NIS2 yanayopata hitilafu ya muda mrefu ya upatikanaji au funguo za PKI zilizoathirika lazima ziarifu CSIRT yao ya kitaifa ndani ya saa 24.
• Australia na New Zealand:
• Huduma za Dharura: Piga 000 nchini Australia au 111 huko New Zealand; wasiliana na ACSC (1300 CYBER1) kwa matukio ya miundombinu.
• India na Asia-Pacific:
• India (CERT-In / Mdhibiti wa Mamlaka zinazoidhinisha CCA): Piga 112 kwa majibu ya dharura; ripoti maelewano ya PKI au kukatika kwa miundombinu muhimu kwa incident@cert-in.org.in ndani ya masaa 6.

Maswali yanayoulizwa mara kwa mara¶

Kwa nini mimi au watumiaji wangu siwezi kubofya "Advanced -> Nenda kwenye tovuti (isiyo salama)" katika Chrome au Safari wakati wa hitilafu hii?¶

Wakati kikoa chako kinatuma faili ya Mkali-Usafiri-Usalama (HSTS) Kichwa cha HTTP - au hutumia kikoa cha kiwango cha juu kama .dev, .programu, .ukurasa, au .benki ambayo imewekwa msimbo ngumu kwenye kivinjari Orodha ya Upakiaji ya awali ya HSTS - RFC 6797 inahitaji kivinjari kutibu cheti chochote kilichopitwa na wakati, chenye kujitia saini au kisicholingana kama hitilafu mbaya isiyoweza kurekebishwa. Kivinjari huondoa kwa makusudi kitufe cha "Endelea hata hivyo" ili kuzuia wavamizi amilifu wa Man-in-the-Middle (MitM) kuwahadaa watumiaji ili kubofya cheti kilichoibiwa. Wakati msanidi kwenye eneo-kazi Chrome anaweza kuandika mlolongo wa kibodi uliofichwa hii si salama moja kwa moja kwenye skrini ya makosa ili kuipita ndani kwa majaribio, watumiaji halisi hawawezi; lazima usakinishe cheti halali kwenye bandari 443.

Hebu Fiche tuliacha kutuma barua pepe za onyo la kumalizika muda wake na cheti changu kiliisha muda bila taarifa - kwa nini hiyo ilifanyika?¶

Let's Encrypt ilisitisha rasmi huduma yake ya barua pepe ya taarifa ya kumalizika muda wake katikati ya 2025 ili kupunguza uhifadhi wa data na kwa sababu usanidi otomatiki wa ACME unapaswa kufuatilia usasishaji wa afya moja kwa moja. Ili kuzuia mshangao wa siku zijazo, ni lazima ufuatilie muhuri halisi wa muda wa kumalizika kwa kupeana mkono kwa TLS kwenye mtandao kwa kutumia kifuatiliaji cha muda cha nje (kama vile Prometheus blackbox_nje, Uptime Kuma, Better Stack, au Datadog Synthetic TLS hundi) ikitoa taarifa siku 21, siku 14 na siku 7 kabla. siBaadaye.

Kwa nini tovuti yangu inafanya kazi vizuri katika Chrome na Firefox kwenye kompyuta yangu ndogo, lakini inashindwa kwenye simu za Android, curl, na Stripe webbhooks baada ya kusasisha cheti?¶

Umesanidi seva yako ya wavuti (ssl_cheti katika Nginx au SSLcertificateFile katika Apache) kuashiria cert.pem (cheti cha majani peke yake) badala ya fullchain.pem (cheti cha majani kilichowekwa pamoja na cheti cha Kati cha CA). Vivinjari vya eneo-kazi kama vile Chrome na Firefox hupakua kiotomatiki cheti cha kati zinazokosekana chinichini kwa kutumia Ufikiaji wa Taarifa za Mamlaka (AIA) URL ndani ya cheti chako cha majani, ikificha usanidi wako mbaya wa seva. Hata hivyo, pinda, OpenSSL, kithibitishaji cha uaminifu cha mfumo wa Android, Python, na seva za mtandao hazitekelezi AIA na kukataa mara moja muunganisho na haiwezi kupata cheti cha mtoaji wa ndani. Elekeza usanidi wako kwa fullchain.pem na upakie upya seva yako.

Je, nitaangaliaje kama mdukuzi au msimamizi mbovu alitoa cheti cha SSL kisichoidhinishwa kwa kikoa changu?¶

Kila Mamlaka ya Cheti inayoaminika hadharani inahitajika kuweka kila cheti kilichotolewa kwa umma Kumbukumbu za Uwazi wa Cheti (CT). (RFC 6962) kabla ya vivinjari kuiamini. Fungua https://crt.sh/?q=%25.yourdomain.com au Kifuatilia Uwazi cha Cheti cha Cloudflare ili kuona kila cheti kilichowahi kutolewa kwa ajili ya kikoa chako na vikoa vyake vidogo. Ukiona cheti kilichotolewa na CA usiyoifahamu ambayo hukuidhinisha, kagua mara moja msajili wako wa DNS na eneo lililoidhinishwa la DNS kwa marekebisho ambayo hayajaidhinishwa, batilisha cheti chafu kilicho na CA iliyotolewa, na ufunge DNS yako kwa kutumia. CAA kumbukumbu (`0 issue "letsencrypt.org"`)

Nini ikiwa nguzo yangu ya Kubernetes cert-manager imeshindwa kufanya upya cheti chetu cha Ingress na Agizo limekwama Pending?¶

Kimbia kubectl pata agizo,changamoto -A na kisha kubectl eleza changamoto -n . Katika asilimia 90 ya Kubernetes meneja wa cheti kukatika, cm-acme-http-solver-* ganda la muda linaendelea, lakini ama (1) rasilimali ya Ingress ina maelezo ya kizamani ya darasa la ingress kwa hivyo njia ya kisuluhishi haijawahi kuambatishwa kwenye sawazisha la mzigo wako, (2) Kubernetes. Sera ya Mtandao inazuia uingiaji wa trafiki kwenye ganda la kisuluhishi kwenye bandari 8089, au (3) tatizo la NAT/mgawanyiko wa upeo wa macho huzuia tatizo la DNS. meneja wa chetiukaguzi wa ndani wa kibinafsi kutoka kufikia IP yako ya kusawazisha mzigo wa umma (inaweza kurekebishwa kwa kupita --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 kwa meneja wa cheti args za kupeleka).

Je, ninaweza kunakili yangu /etc/letsencrypt/ folda kwa seva mpya wakati wa uhamishaji wa dharura badala ya kutoa tena?¶

Ndiyo. Ikiwa seva yako ya msingi ilikufa na unahamia seva mpya huku kiwango kikiwa kimepunguzwa na Let's Encrypt, hifadhi ulinganifu unaponakili. /etc/letsencrypt/ kutumia tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (kamwe usitumie wazi scp -r, ambayo hugeuza ulinganifu ndani /etc/letsencrypt/live/ katika nakala za faili tuli na huvunja usasishaji wa siku zijazo). Toa kumbukumbu hiyo kwenye seva mpya (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), elekeza Nginx/Apache kwa `/etc/letsencrypt/live/domain/fullchain.pem`, na cheti chako kilichopo kitafanya kazi mara moja kwenye anwani mpya ya IP.

Miongozo inayohusiana¶

• Utekaji nyara wa jina la kikoa, DNS iliyoisha muda wake na unyakuzi wa tovuti
• Disk ya seva 100% imejaa (baiti 0 bila malipo): hifadhidata na uokoaji wa nafasi ya sifuri
• Kufunga nje kwa msimamizi wa kikoa cha Google Workspace au Microsoft 365 na uokoaji wa DNS TXT
• Shida ya upangishaji wa wavuti, uhamiaji, na urejeshaji wa chelezo
• Utekaji nyara wa DNS, usanidi upya wa WAN wa kipanga njia cha ISP, na udukuzi wa lango
• Nambari za dharura kwa nchi

Vyanzo na mwongozo rasmi¶

• Kikosi Kazi cha Uhandisi wa Mtandao (IETF): RFC 8555 (Mazingira ya Usimamizi wa Cheti Kiotomatiki / ACME), RFC 8659 (Uidhinishaji wa Mamlaka ya Vyeti vya DNS / CAA), na RFC 6797 (Usalama Mkali wa Usafiri wa HTTP / HSTS).
• Taasisi ya Kitaifa ya Viwango na Teknolojia (NIST) (Marekani): Chapisho Maalum la 800-52 Ufu. 2: Mwongozo wa Uteuzi, Usanidi, na Matumizi ya Utekelezaji wa Usalama wa Tabaka la Usafiri (TLS) & SP 1800-16: Kulinda Miamala ya Wavuti: Usimamizi wa Cheti cha Seva ya TLS.
• Kikundi cha Utafiti wa Usalama wa Mtandao (ISRG / Hebu Tusimbe Nyaraka Rasmi): Rejelea ya Vikomo vya Kadiri, Sheria za Cheti Nakala, na Utatuzi wa Shindano la ACME.
• Wakala wa Usalama wa Mtandao na Miundombinu (CISA) (Marekani): Kufunga Maelekezo ya Utendaji 18-01: Imarisha Usalama wa Barua Pepe na Wavuti (Mwongozo wa Utekelezaji wa HTTPS na HSTS).
• Kituo cha Kitaifa cha Usalama wa Mtandao (NCSC) (Uingereza): Kutumia TLS Kulinda Data Kikamilifu Katika Usafiri na Mwongozo wa Ufuatiliaji wa Uwazi wa Cheti.