Baigėsi gamybos SSL / TLS sertifikato galiojimas: HSTS sudėtingų gedimų ištaisymas ir CAA / tarifo apribojimo blokų šifravimas¶

Kai gamybos SSL/TLS (HTTPS) sertifikato galiojimo laikas baigiasi - net praėjus vienai sekundei notAfter UTC laiko žyma - kiekviena šiuolaikinė naršyklė (Chrome, Safari, Firefox, Edge), programa mobiliesiems (iOS App Transport Security, Android Network Security Config), „Webhook“ imtuvas (Stripe, Shopify, Twilio, GitHub), o aukštesniojo srauto API klientas iš karto nutraukia ryšį su NET::ERR_CERT_DATE_INVALID arba SSL_ERROR_RX_RECORD_TOO_LONG. Dar blogiau, jei jūsų domenas siunčia Strict-Transport-Security (HSTS). Dažnai automatinio atnaujinimo cronjob (Certbot, acme.sh, Caddy, cert-manager, arba AWS ACM) tyliai sugenda 30 dienų dėl ribojančio DNS CAA įrašas, sugadintas DNSSEC DS įrašą, ugniasienės blokavimo prievadą 80 (HTTP-01 iššūkis) arba žiniatinklio serveris (nginx / haproxy), kuris atnaujino failą diske (fullchain.pem), bet niekada iš naujo neįkėlė savo atmintyje esančių darbuotojo procesų. Jei jūsų gedimą sukėlė pasibaigusi domeno registracija arba užgrobti vardų serveriai, o ne pats X.509 sertifikatas, nedelsdami perjunkite į domeno vardo užgrobimas, pasibaigęs DNS galiojimas ir svetainės perėmimas; jei jūsų serveris visiškai nepasiekiamas arba diske trūksta vietos certbot negaliu rašyti /etc/letsencrypt, matai serverio diskas yra 100% pilnas ir atkuriamas be vietos arba žiniatinklio prieglobos krizė, perkėlimas ir atsarginės kopijos atkūrimas. Jei dėl TLS užtemimo išjungiama ligoninės telemetrija, skubios pagalbos siuntimo API arba viešosios saugos infrastruktūra, skambinkite vietiniu pagalbos numeriu (911 JAV ir Kanadoje, 112 visoje Europos Sąjungoje, 999 Jungtinėje Karalystėje) arba kreipkitės į mūsų tarptautinį katalogą pagalbos numeriai.

Padarykite tai dabar¶

1. Patikrinkite po 10 sekundžių, ar diske esantis sertifikatas iš tikrųjų jau atnaujintas, o žiniatinklio serveriui arba apkrovos balansavimo priemonei tiesiog nepavyko jo iš naujo įkelti į RAM:
2. Palyginkite veikiančią TLS lizdą su .pem failas diske dabar:

   # 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. Jei failas diske rodo tinkamą ateitį notAfter data, kol gyvas uostas 443 rodo galiojimo pabaigos datą: Jūsų ACME klientas (certbot / acme.sh) pavyko prieš kelias savaites, bet nginx, apache2, haproxy, arba postfix niekada nebuvo įkeltas iš naujo arba (haproxy / vault) reikalauja fullchain.pem + privkey.pem sujungti į vieną ryšulį. Bėk sudo nginx -t && sudo systemctl reload nginx (arba sudo systemctl reload apache2 haproxy) ir jūsų gedimas baigsis po 2 sekundžių.
4. ** NEBĖKITE certbot renew --force-renewal pakartotinai, jei atnaujinimas nepavyksta**: „Encrypt“ taiko griežtą 5 pasikartojančių sertifikatų per 7 dienas ir 5 nepavykusių patvirtinimų vienai paskyrai, pagrindinio kompiuterio pavadinimui per valandą normos ribą. Bėgimas --force-renewal penkis kartus panikoje nesutvarkydamas pagrindo nginx Įkėlus iš naujo arba DNS / ugniasienės klaida užblokuos jūsų domeną nuo „Let's Encrypt“ išdavimo iki 7 dienų.
5. Jei pasieksite šifravimo greičio ribą (429 Too Many Requests), pakeiskite savo ACME klientą į antrą nemokamą viešą sertifikavimo įstaigą (ZeroSSL, Buypass Go SSL, arba Google Trust Services) arba nedelsdami pridėkite pašalintą subdomeną SAN:
6. Kiekvienas ACME klientas (certbot, acme.sh, caddy, cert-manager) gali paprašyti nemokamo patikimo sertifikato iš kitos CA per 30 sekundžių (--server https://acme.zerossl.com/v2/DV90 arba https://api.buypass.com/acme/directory), visiškai apeinant Let's Encrypt greičio limitą.
7. Arba „Let's Encrypt“ limitas „5 pasikartojantys sertifikatai per 7 dienas“ taikomas tik tam pačiam alternatyvių subjektų pavadinimų rinkiniui (SANs). Pridedamas vienas papildomas tinkamas padomenis (-d example.com -d www.example.com -d tlsfix1.example.com) paverčia jį nedublikatu sertifikatu ir iš karto apeina dublikato sertifikato normos limitą.
8. Patikrinkite, ar yra DNS CAA rekordas arba sulaužytas DNSSEC blokuoja jūsų sertifikavimo institucijai išduoti (CAA record for example.com prevents issuance):
9. Pateikite užklausą dėl savo domeno sertifikavimo institucijos įgaliojimo (CAA) įrašai: dig +short CAA example.com. Jei jūsų DNS turi 0 issue "sectigo.com" arba 0 issue "amazon.com" (arba pirminiame domene), užšifruokime (letsencrypt.org) ir ZeroSSL (sectigo.com) RFC 8659 draudžia išleisti, kol neįtrauksite 0 issue "letsencrypt.org" į savo DNS zoną.
10. Jei uostas 80 (HTTP-01 iššūkis) blokuoja ugniasienė, CDN arba IPT arba jei žiniatinklio serveris atsisako paleisti dėl trūkstamo sertifikato, naudokite --standalone arba --dns (DNS-01) patvirtinimas:
11. Sustok nginx/apache trumpai ir paleisti sudo certbot certonly --standalone -d example.com, arba naudoti --manual --preferred-challenges dns patvirtinti įklijuojant a _acme-challenge.example.com TXT įrašyti į savo DNS konsolę neliesdami prievado 80.
12. Jei jūsų svetainė yra už „Cloudflare“, „AWS CloudFront“ ar „Fastly“, patikrinkite, ar pasibaigusio sertifikato galiojimo laikas yra CDN Edge ar jūsų „Origin Server“ (Error 526 Invalid SSL Certificate):
13. „Cloudflare“, jei pasibaigė jūsų kilmės serverio sertifikato galiojimo laikas ir nustatyta „Cloudflare“. Full (Strict), vartotojai mato Klaidą 526. Taisydami kilmės sertifikatą, galite atkurti tiesioginį svetainės srautą per 5 sekundes sugeneravę 15 metų Cloudflare Origin CA sertifikatą Cloudflare prietaisų skydelyje (arba laikinai perjungę SSL/TLS režimą iš Full (Strict) į Full 10 minučių, kurių reikia norint pakeisti kilmę .pem failas).

Sprendimų medis: pasibaigusio gamybos SSL/TLS sertifikato diagnozavimas ir taisymas¶

Vykdykite šį sprendimų medį, kad nustatytumėte tikslų gedimo sluoksnį (CDN Edge vs. Origin Daemon Memory vs. ACME Challenge vs. CA Rate Limit) ir atkurkite HTTPS srautą per kelias minutes:

flowchart TD
    Start["Naudotojai / API ataskaitų teikimas NET::ERR_CERT_DATE_INVALID arba „Cloudflare“ klaida 526"] --> CheckLive["Vykdyti: openssl s_client -serverio vardas domenas -connect domenas:443 | openssl x509 -noout -dates -išdavėjas"]

    CheckLive --> WhereExpired{"Kuris sertifikatas iš tikrųjų pasibaigęs?"}

    WhereExpired -->|"Diskas fullchain.pem GALIOJA, bet „Live Port 443“ BAIGĖSI"| StaleDaemon["Pasenusi demono atmintis arba padalinta sertifikatų parduotuvė: iš naujo įkelkite nginx / apache2 / haproxy / postfix arba atkurkite kombinuotą HAProxy PEM paketą"]
    WhereExpired -->|"Baigėsi CDN Edge sertifikato (Cloudflare / CloudFront / Fastly) galiojimo laikas"| CDNFix["Patikrinkite CDN CA DNS CAA įrašus (letsencrypt.org / pki.goog / digicert.com / amazon.com) ir perjunkite universalųjį SSL arba iš naujo patvirtinkite ACM"]
    WhereExpired -->|"„Origin Server fullchain.pem“ diske BAIGĖSI"| DryRun["Vykdyti: sudo certbot renew --dry-run (arba acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"Kodėl ACME atnaujinimas nepavyko?"}

    WhyFailed -->|"429 per daug užklausų (viršytas normos limitas)"| RateLimit["Nedelsiant apeiti: „ZeroSSL“ / „Buypass“ / „Google Trust Services“ problema ARBA pridėkite 1 papildomą subdomeną SAN (-d fix1.example.com)"]
    WhyFailed -->|"CAA įrašas neleidžia išduoti arba SERVFAIL (DNSSEC)"| CAADNS["Vykdykite: dig CAA example.com -> Pridėkite 0 problemą „letsencrypt.org“ (ir „sectigo.com“) arba ištaisykite sugadintą DNSSEC DS įrašą registratoriuje"]
    WhyFailed -->|"Ryšys atmestas / skirtasis laikas / 404 /.well-known/acme-challenge/"| HttpBlock["80 prievadas užblokuotas arba peradresavimo ciklas: atidarykite TCP 80 prievadą ugniasienėje, išskirkite /.well-known/ iš autentifikavimo / perrašymo arba naudokite DNS-01 iššūkį"]
    WhyFailed -->|"Laukiama „Kubernetes“ sertifikatų valdytojo užsakymo"| K8sFix["Vykdyti: kubectl description challenge -> Check Ingress klasės anotacija, HTTP01 Solver pod tinklo politika arba Webhook TLS"]

    StaleDaemon --> VerifyAll["Patikrinkite grandinės ir OCSP susegimą: openssl s_client -connect domenas:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

1 etapas: supratimas, kodėl HSTS (Strict-Transport-Security) sukelia visišką elektros energijos tiekimo nutraukimą¶

Kai svetainė nenaudoja HSTS, pasibaigusiame sertifikate rodomas tarpinio puslapio įspėjimas (Your connection is not private).

Tačiau beveik visos šiuolaikinės gamybos žiniatinklio programos, bankai, SaaS platformos ir .dev / .app / .page / .bank aukščiausio lygio domenai vykdo HTTP Strict Transport Security (HSTS, RFC 6797): 1. ** Dinaminis HSTS (max-age=31536000): bet kuri naršyklė, apsilankiusi jūsų svetainėje per pastarąsias 365 dienas, išsaugojo politiką talpykloje Strict-Transport-Security: max-age=31536000; includeSubDomains. Kol nesibaigs laikmatis, naršyklė draudžia vartotojui spustelėti bet kokią sertifikato klaidą (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, arba ERR_CERT_AUTHORITY_INVALID). 2. Statinis HSTS išankstinis įkėlimas (preload sąrašą arba .dev / .app gTLD): jei jūsų domenas buvo pateiktas hstspreload.org - arba jei jūsų domenas naudoja iš anksto įkeltą registro ALD, pvz .dev, .app, .page, .new, .chrome, arba .bank - Kiekvienoje „Chrome“, „Edge“, „Firefox“, „Safari“ ir „Android WebView“ kopijoje „Earth“ jūsų domenas yra užkoduotas į dvejetainį kodą kaip HSTS, prieš vartotojui pirmą kartą apsilankant svetainėje. 3. ** Kodėl includeSubDomains pažeidžia vidinius įrankius ir sustojimo serverius: jei jūsų šakninis domenas (example.com) siunčia Strict-Transport-Security: max-age=31536000; includeSubDomains, kiekvienas padomenis (vpn.example.com, internal-jira.example.com, printer.example.com) taip pat yra užrakintas į HSTS sunkių gedimų režimą. 4. Kodėl API ir Webhook integracijos (Stripe, Twilio, Slack, iOS ATS) iš karto nepavyks: TLS klientai tarp serverių (libcurl, Python requests/urllib3, Node.js undici, Eik crypto/tls, Java SSLContext) atlikti griežtą RFC 5280 notAfter patvirtinimas pagal numatytuosius nustatymus ir neturi vartotojo „paspaudimo“ sąvokos. TLS nutrūkimo metu „Stripe“ ir „Shopify“ žiniatinklio kabliukai nepavyks pristatyti ir pateks į eksponentinę atsitraukimo pakartotinių bandymų eiles.

2 etapas: 60 sekundžių diagnostika - ar sertifikatas iš tikrųjų jau atnaujintas diske?¶

Maždaug 35 proc. gamybos Let's Encrypt nutrūkimų, sertifikatas iš tikrųjų buvo atnaujintas diske prieš kelias savaites certbot.timer arba acme.sh, tačiau veikiantis demonas vis dar aptarnauja seną pasibaigusio galiojimo sertifikatą iš RAM.

1 veiksmas: palyginkite tiesioginį tinklo lizdą su failu diske¶

Paleiskite abi komandas savo serveryje:

# 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

2 veiksmas: ištaisykite 4 įprastus spąstus „Atnaujinta diske, pasibaigęs galiojimo laikas RAM“.¶

3 etapas: DNS taisymas CAA įrašų blokai ir DNSSEC patvirtinimo nesėkmės¶

Jei bėgate sudo certbot renew --dry-run ir pamatyti: - 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. Kaip DNS CAA (RFC 8659) blocks certificate renewal¶

Kiekviena viešoji sertifikavimo institucija yra teisiškai įpareigota pagal CA / naršyklės forumo bazinius reikalavimus pateikti užklausą dėl DNS CAA įrašus prieš išduodant bet kokį sertifikatą. CA pereina ** DNS medžiu** nuo sub.app.example.com -> app.example.com -> example.com: - Jeigu example.com turi nulis CAA įrašus, leidžiama išduoti bet kuriai CA. - Jeigu example.com turi net vieną CAA įrašas (pvz., 0 issue "amazon.com" pridedamas automatiškai, kai kas nors sukūrė AWS CloudFront paskirstymą, arba 0 issue "digicert.com"), bet kuriai kitai sertifikavimo institucijai Žemėje griežtai draudžiama išduoti sertifikatą example.com arba bet kuris jo subdomenas. - Be to, jei prašote Wildcard sertifikato (*.example.com) ir jūsų domenas apibrėžia konkretų 0 issuewild "ca.example" žymą, CA patikrina issuewild turtas, o ne issue.

Diagnostika ir greitas pataisymas CAA blokai:¶

1. Patikrinkite CAA įrašai tiek pagrindinio kompiuterio pavadinime, tiek viršūnės domene:

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

2. Taip pat patikrinkite, ar sub.example.com yra a CNAME nukreipia į kitą domeną (Pagal RFC 8659 CA taip pat patikrina CAA įrašai apie CNAME taikinius).
3. DNS teikėjo prietaisų skydelyje (Cloudflare, Route 53, Cloud DNS, Namecheap) neištrinkite esamų CAA įrašai, kuriuos naudoja jūsų CDN arba AWS ACM; vietoj to pridėti papildomai CAA įrašai, suteikiantys teisę Let's Encrypt, ir jūsų atsarginės kopijos CA:

   example.com.  300  IN  CAA  0 issue "letsencrypt.org"
   example.com.  300  IN  CAA  0 issue "sectigo.com"
   example.com.  300  IN  CAA  0 issue "pki.goog"
   example.com.  300  IN  CAA  0 issuewild "letsencrypt.org"
   example.com.  300  IN  CAA  0 issuewild "sectigo.com"
   

4. (Pastaba: ZeroSSL naudoja sectigo.com kaip pagrindinį CAA identifikatorių, ir naudoja „Google Trust Services“. pki.goog.)*
5. Palaukite 60 sekundžių, kol jūsų autoritetingi vardų serveriai bus atnaujinti (dig @ns1.yourdns.com CAA example.com) ir nedelsdami paleiskite iš naujo sudo certbot renew. Kadangi CA atlieka tiesiogines rekursines paieškas, apeinant viešąsias talpyklas, kai bandoma pakartotinai, išdavimas pavyksta nedelsiant.

2. Tvirtinimas DNS problem: SERVFAIL looking up CAA (DNSSEC neatitikimas)¶

„Encrypt“, „Google Trust Services“ ir „ZeroSSL“ griežtai vykdys DNSSEC patvirtinimą visose DNS paieškose (A, AAAA, TXT, ir CAA). Net jei domenas turi nr CAA įrašas, CA turi gauti kriptografiškai galiojantį dokumentą NOERROR (tuščias atsakymas) arba NXDOMAIN (NSEC / NSEC3 patvirtintas egzistavimo neigimas) atsakymas. - Jei jūsų domeno registratorius yra pasenęs DS (Delegation Signer) record after you migrated DNS providers (for example, moving from GoDaddy to Cloudflare or Route 53 without disabling DNSSEC first), recursive resolvers that enforce DNSSEC return SERVFAIL. - Patvirtinti per 5 sekundes: paleisti delv @8.8.8.8 example.com CAA arba išbandyti adresu dnsviz.net. Jeigu dig @8.8.8.8 example.com grįžta status: SERVFAIL kol dig +cd @8.8.8.8 example.com (+cd = Patikrinimas išjungtas, ignoruojant DNSSEC) grąžina jūsų IP adresą, jūsų DNSSEC grandinė nutrūko. Nedelsdami prisijunkite prie domeno registratoriaus ir pašalinkite pasenusią informaciją DS įrašyti arba nukopijuoti srovę DS parametrus iš aktyvaus DNS pagrindinio kompiuterio.

4 etapas: apeinant Užšifruokime greičio ribas (429 Too Many Requests) aktyvaus gedimo metu¶

Chaotiško incidento metu inžinieriai dažnai iš naujo paleidžia konteinerius arba paleidžia certbot pakartotinai, kol Let's Encrypt atmeta visas užklausas: - 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

Laukimo laikas svyruoja nuo 1 valandos (nepavykus autorizacijai) iki 7 dienų (168 valandų) (5 pasikartojančių sertifikatų limitui). Nelaukite 1 valandos ar 7 dienų, kol jūsų gamybos vieta neveikia. Turite du visiškai teisėtus ir neatidėliotinus sprendimus:

Sprendimas A (geriausias): per 30 sekundžių perjunkite ACME sertifikavimo įstaigą į „ZeroSSL“, „Buypass“ arba „Google Trust Services“¶

ACME protokolas (RFC 8555) yra atviras standartas. Kiekviena pagrindinė naršyklė ir operacinė sistema pasitiki ZeroSSL (Sectigo root), Buypass Go SSL (Norvegijos CA) ir Google Trust Services (pki.goog) identiškai Let's Encrypt (ISRG Root X1). Nė vienas iš jų nesidalija greičio apribojimais su Let's Encrypt.

• 1 parinktis: iš karto išduokite per Certbot naudojant „Buypass Go SSL“ (nereikia paskyros / EAB rakto, galioja 180 dienų):
• (Pastaba: „Buypass“ palaiko kelių domenų sertifikatus iki 5 SAN, bet ne pakaitos simbolius *.example.com sertifikatai)*

  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
  

• 2 parinktis: iš karto išduokite per acme.sh (kuris pagal numatytuosius nustatymus yra ZeroSSL arba perjungia CA su --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
  

• 3 parinktis: problema per „Google Trust Services“ (pki.goog) Viešas ACME: „Google Cloud Console“ (arba per gcloud publicca external-account-keys create), sugeneruokite nemokamą išorinės paskyros susiejimą (EAB) įveskite 10 sekundžių ir paleiskite:

  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
  

B sprendimas: apeikite „5 pasikartojančių sertifikatų“ ribą, pridėdami vieną papildomą SAN prieglobos pavadinimą¶

Užšifruokime 168 valandų dublikatų limitą (too many certificates (5) already issued for this exact set of domains). 1. Sukurkite nekenksmingą DNS A record pointing to the same server: tls-recovery-01.example.com -> <your_server_ip>. 2. Pateikite sertifikato užklausą su originaliais domenais ir nauju prieglobos pavadinimu:

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

5 etapas: sugedęs tvirtinimas HTTP-01 iššūkiai (Port 80) arba naudojant DNS-01 avarinis patvirtinimas¶

Kada certbot renew nepavyksta su Timeout during connect (likely firewall problem) arba Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (arba 403), CA patvirtinimo serveriai negali pasiekti HTTP iššūkio prieigos rakto TCP prievade 80.

Kodėl HTTP-01 staiga nutrūksta serveriuose, kurie dirbo prieš 60 dienų¶

1. Debesų saugos grupė / UFW / iptables uždarytas 80 prievadas: kažkas užkardino užkardą, kad leistų tik prievadą 443 (HTTPS), pamiršdami, kad RFC 8555 HTTP-01 patvirtinimas visada prasideda nuo paprasto HTTP prievado 80 (nors jis bus atliktas po a 301 nukreipti į https:// uoste 443).
2. ** Sugedęs IPv6 (AAAA) Record**: Your domain has both an IPv4 (A) įrašas ir IPv6 (AAAA) įrašas. Let's Encrypt always prefers IPv6 (AAAA) pirmiausia. If your IPv6 address is misrouted, blocked by ip6tables, arba nesusietas Nginx (listen [::]:80;), patvirtinimo laikas baigiasi, nors IPv4 veikia gerai.
3. Nginx / Application Router (React / Next.js / Django / Rails) perima /.well-known/acme-challenge/: tavo server blokuoti 80 prievado tarpinius serverius visą srautą (location / { proxy_pass http://localhost:3000; }) į vidinę programą, o ne teikti .well-known iš disko.

Two instant fixes for broken HTTP-01 patvirtinimas¶

1 pataisymas: pridėkite specialų aukštą prioritetą /.well-known/acme-challenge/ blokas Nginx (Port 80)¶

Ensure your port 80 block in /etc/nginx/sites-enabled/ aptarnauja ACME žetonus tiesiai iš /var/www/letsencrypt prieš bet kokį return 301 https://... arba proxy_pass direktyva:

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

2 pataisymas: visiškai apeikite 80 prievadą ir žiniatinklio serverius naudodami vadovą DNS-01 (TXT) iššūkis¶

Jei 80 prievadą blokuoja IPT / ugniasienė arba jūsų apkrovos balansavimo priemonė negali nukreipti .well-known į kelis backend mazgus, patvirtinkite per DNS per 2 minutes:

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

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

6 etapas: patikrinimas po atkūrimo (tarpinė grandinė, OCSP susegimas ir CDN išvalymas)¶

Dažna klaida pakeitus avarinį sertifikatą yra įdiegimas cert.pem (tik lapo sertifikatas) vietoj fullchain.pem (lapo sertifikatas + tarpinis CA sertifikatas). Stalinio kompiuterio naršyklės (Chrome, Firefox) dažnai užmaskuoja trūkstamą tarpinį sertifikatą per AIA (Authority Information Access) persekioti arba talpykloje saugomi tarpiniai produktai, o curl, Python, OpenSSL, Android programos ir Stripe/Twilio webhooks iškart sugenda unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• Patikrinkite, ar jūsų serveris siunčia visą tarpinę grandinę (fullchain.pem): Vykdyti:

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

  Turite matyti bent du lygius (depth=0 jūsų domenas ir depth=1 tarpinė CA, pvz Let's Encrypt E5/R11 arba ZeroSSL RSA Domain Secure Site CA) ir Verify return code: 0 (ok). Jei matai Verify return code: 21 (unable to verify the first certificate), pakeiskite savo žiniatinklio serverio konfigūraciją iš cert.pem į fullchain.pem.
• Išvalyti pasenusią OCSP susegimo talpyklą naudojant Nginx / Apache: Jeigu ssl_stapling on; yra įjungtas, iš naujo įkelkite žiniatinklio serverį ir patikrinkite openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
• Konfigūruokite kelių sluoksnių SSL galiojimo pabaigos stebėjimą (išorinis TCP patikrinimas + Prometheus blackbox_exporter): Niekada nepasikliaukite vien priminimais el. paštu (2025 m. užšifruokime nutrauktus galiojimo pabaigos priminimus). Išoriškai stebėkite tiesioginį 443 prievado lizdą (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) ir įjunkite kasdienį cron patikrinimą sudo certbot renew --dry-run.

Regioniniai pagalbos numeriai ir agentūrų protokolai¶

Nors pasibaigusį TLS sertifikatą paprastai išsprendžia inžinierių komandos, sertifikato gedimas, kuris pažeidžia sveikatos priežiūros portalus, skubios pagalbos siuntimo žiniatinklio kabliukus, bankų autentifikavimą ar viešąją viešąją infrastruktūrą, gali suaktyvinti reguliavimo incidentų darbo eigą:

• Jungtinės Valstijos ir Kanada:
• Gyvybės sauga / klinikinis / išsiuntimo nutraukimas: skambinkite 911 jei dėl TLS sertifikato gedimo nutraukiamas paciento telemetrijos, el. recepto ar skubios pagalbos siuntimo ryšys.
• Kibernetinio saugumo ir infrastruktūros saugumo agentūra (CISA) (JAV): federalinės civilinės agentūros pagal CISA privalomąją veiklos direktyvą (BOD) 18-01 ir ypatingos svarbos infrastruktūros operatoriai, patiriantys neteisėtą sertifikatų išdavimą (CA kompromisas arba BGP/DNS užgrobimas), turėtų pranešti 1-844-Say-CISA (1-844-729-2472) arba cisa.gov/report.
• Kanados kibernetinio saugumo centras: Susisiekite su 1-833-CYBER-88 (1-833-292-3788).
• Jungtinė Karalystė:
• Skubios pagalbos tarnybos: skambinkite 999 jei TLS gedimas turi įtakos kritinėms NHS klinikinėms sistemoms arba gyvybės saugai.
• Nacionalinis kibernetinio saugumo centras (NCSC): jei sertifikato skaidrume aptiksite neteisėtą jūsų domenui išduotą sertifikatą (crt.sh) logs indicating DNS hijacking, report via ncsc.gov.uk.
• Europos Sąjunga:
• Skubios pagalbos tarnybos: skambinkite 112 visose ES valstybėse narėse.
• ** NIS2 direktyva ir eIDAS kvalifikuotos svetainės autentifikavimo sertifikatai (QWACs)**: Essential and important entities under the NIS2 Directive experiencing a prolonged availability outage or compromised PKI keys must notify their national CSIRT within 24 hours.
• Australija ir Naujoji Zelandija:
• Skubios pagalbos tarnybos: skambinkite 000 Australijoje arba 111 Naujojoje Zelandijoje; susisiekite su ACSC (1300 CYBER1) infrastruktūros incidentams.
• Indija ir Azijos ir Ramiojo vandenyno šalys:
• Indija (CERT-In / Tvirtinančių institucijų kontrolierius CCA): surinkite 112 avariniam reagavimui; pranešti apie PKI pažeidimą arba reikšmingus infrastruktūros sutrikimus incident@cert-in.org.in per 6 valandas.

Dažnai užduodami klausimai¶

Kodėl aš arba mano naudotojai negaliu spustelėti „Išplėstinė“ -> Pereiti į svetainę (nesaugu) naršyklėje „Chrome“ arba „Safari“ šio gedimo metu?¶

Kai jūsų domenas siunčia Griežtas transportas-saugumas (HSTS) HTTP antraštė - arba naudoja aukščiausio lygio domeną, pvz .dev, .app, .puslapis, arba .bankas that is hardcoded into the browser HSTS Preload List - RFC 6797 requires the browser to treat any expired, self-signed, or mismatched certificate as a non-recoverable fatal error. The browser intentionally removes the "Proceed anyway" bypass button to prevent active Man-in-the-Middle (MitM) attackers from tricking users into clicking through a spoofed certificate. Nors stalinio kompiuterio „Chrome“ kūrėjas gali įvesti paslėptą klaviatūros seką tai nesaugu tiesiai klaidos ekrane, kad būtų galima jį apeiti vietoje, kad būtų galima išbandyti, tikrieji vartotojai negali; 443 prievade turite įdiegti galiojantį sertifikatą.

„Encrypt“ nustojo siųsti įspėjimo apie galiojimo pabaigą el. laiškus ir mano sertifikato galiojimas baigėsi be įspėjimo - kodėl taip atsitiko?¶

Let's Encrypt officially retired its expiration notification email service in mid-2025 to reduce data retention overhead and because automated ACME setups should monitor renewal health directly. To prevent future surprises, you must monitor the actual TLS handshake expiration timestamp over the network using an external uptime monitor (such as Prometheus blackbox_eksportuotojas, Uptime Kuma, Better Stack arba Datadog Synthetic TLS patikros) perspėjimas 21 dieną, 14 dienų ir 7 dienas prieš ne po.

Kodėl mano svetainė gerai veikia naršyklėje „Chrome“ ir „Firefox“ nešiojamajame kompiuteryje, bet nepavyksta „Android“ telefonuose? curl, ir Stripe webhooks po to, kai atnaujinau sertifikatą?¶

Jūs sukonfigūravote savo žiniatinklio serverį (ssl_certificate Nginx arba SSLCertificateFile Apache) nurodyti cert.pem (tik lapo sertifikatas) vietoj fullchain.pem (lapo sertifikatas kartu su Vidutinio CA sertifikatu). Stalinių kompiuterių naršyklės, pvz., „Chrome“ ir „Firefox“, automatiškai atsisiunčia trūkstamus tarpinius sertifikatus fone, naudodamos Prieiga prie institucijos informacijos (AIA) URL lapo sertifikate, slepiantis netinkamą serverio konfigūraciją. Tačiau garbanoti, „OpenSSL“, „Android“ sistemos patikimumo tikrintuvas, „Python“ ir „webhook“ serveriai nevykdo AIA persekiojimo ir iš karto atmeta ryšį su nepavyko gauti vietinio leidėjo sertifikato. Nukreipkite savo konfigūraciją į fullchain.pem ir iš naujo įkelkite serverį.

Kaip patikrinti, ar įsilaužėlis arba nesąžiningas administratorius išdavė neteisėtą SSL sertifikatą mano domenui?¶

Kiekviena viešai patikima sertifikavimo institucija privalo viešai užregistruoti kiekvieną išduotą sertifikatą Sertifikato skaidrumo (CT) žurnalai (RFC 6962), kol naršyklės juo pasitikės. Atidaryti https://crt.sh/?q=%25.yourdomain.com arba Cloudflare Certificate Transparency Monitor, kad peržiūrėtumėte kiekvieną sertifikatą, kada nors išduotą jūsų domenui ir jo padomeniams. Jei matote nepažįstamos CA išduotą sertifikatą, kurio nesuteikėte įgaliojimo, nedelsdami patikrinkite savo DNS registratorių ir autoritetingąją DNS zoną, ar nėra neteisėtų pakeitimų, atšaukite nesąžiningą sertifikatą išdavusioje CA ir užrakinkite savo DNS naudodami CAA įrašai (`0 issue "letsencrypt.org"`).

Ką daryti, jei mano „Kubernetes“ klasteris cert-manager nepavyko pratęsti įėjimo sertifikato ir užsakymas įstrigo Pending?¶

Bėk kubectl gauti užsakymą, iššūkis -A ir tada kubectl aprašykite iššūkį -n . 90 procentų Kubernetes sertifikato vadybininkas gedimai, cm-acme-http-solver-* veikia laikinas blokas, bet arba (1) įvesties šaltinyje yra pasenusi įėjimo klasės anotacija, todėl sprendimo maršrutas niekada nebuvo prijungtas prie jūsų apkrovos balansavimo priemonės, (2) „Kubernetes“ Tinklo politika blokuoja patekimo srautą į 8089 prievadą esantį sprendėjų bloką arba (3) NAT/split-horizon DNS problema neleidžia sertifikato vadybininkasvidinė savitikra, kad nepasiektų viešo apkrovos balansavimo priemonės IP (pataisoma išlaikant --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 prie sertifikato vadybininkas dislokavimo args).

Ar galiu nukopijuoti savo /etc/letsencrypt/ aplanką į naują serverį avarinio perkėlimo metu, o ne iš naujo?¶

Taip. Jei jūsų pagrindinis serveris mirė ir perkeliate į naują serverį, kai greitį riboja Let's Encrypt, kopijuodami išsaugokite simbolių nuorodas /etc/letsencrypt/ naudojant tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (niekada nenaudokite paprasto scp -r, which turns symlinks in /etc/letsencrypt/live/ į pasikartojančius statinius failus ir nutraukia būsimus atnaujinimus). Išskleiskite tą archyvą į naują serverį (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), nukreipkite Nginx / Apache į `/etc/letsencrypt/live/domain/fullchain.pem`, o esamas sertifikatas iškart veiks nauju IP adresu.

Susiję vadovai¶

• Domeno vardo užgrobimas, pasibaigęs DNS galiojimas ir svetainės perėmimas
• Serverio diskas 100% pilnas (0 baitų nemokamai): duomenų bazės ir nulinės vietos atkūrimas
• „Google Workspace“ arba „Microsoft 365“ tinkinto domeno administratoriaus blokavimas ir DNS TXT gelbėjimas
• Žiniatinklio prieglobos krizė, perkėlimas ir atsarginės kopijos atkūrimas
• DNS užgrobimas, IPT maršrutizatoriaus WAN perkonfigūravimas ir fiksuoto portalo klastojimas
• Pagalbos numeriai pagal šalį

Šaltiniai ir oficialios rekomendacijos¶

• Interneto inžinerijos darbo grupė (IETF): RFC 8555 (automatinio sertifikatų valdymo aplinka / ACME), RFC 8659 (DNS sertifikavimo institucijos įgaliota / CAA) ir RFC 6797 (HTTP griežta transporto sauga / HSTS).
• Nacionalinis standartų ir technologijos institutas (NIST) (Jungtinės Valstijos): Specialusis leidinys 800-52, 2 red.: Transporto lygmens saugos (TLS) diegimo pasirinkimo, konfigūravimo ir naudojimo gairės ir SP 1800-16: žiniatinklio operacijų apsauga: TLS serverio sertifikatų valdymas.
• Internet Security Research Group (ISRG / Užšifruokime oficialią dokumentaciją): * Kainos ribų nuoroda, pasikartojančio sertifikato taisyklės ir ACME iššūkių trikčių šalinimas*.
• Kibernetinio saugumo ir infrastruktūros saugumo agentūra (CISA) (Jungtinės Valstijos): Įpareigojanti veiklos direktyva 18-01: Padidinkite el. pašto ir žiniatinklio saugą (HTTPS ir HSTS diegimo gairės).
• Nacionalinis kibernetinio saugumo centras (NCSC) (Jungtinė Karalystė): TLS naudojimas duomenims tobulai apsaugoti gabenant ir sertifikatų skaidrumo stebėjimo gairės.