Framleiðslu SSL/TLS vottorð útrunnið: Laga HSTS harða bilun og dulkóða CAA/Rate Limit blokkir¶

Þegar framleiðslu SSL/TLS (HTTPS) vottorð rennur út - jafnvel um eina sekúndu framhjá því notAfter UTC tímastimpill - sérhver nútíma vafra (Chrome, Safari, Firefox, Edge), farsímaforrit (iOS App Transport Security, Android Network Security Config), vefhook móttakari (Stripe, Shopify, Twilio, GitHub), og andstreymis API viðskiptavinur slítur strax tengingu við NET::ERR_CERT_DATE_INVALID eða SSL_ERROR_RX_RECORD_TOO_LONG. Það sem verra er, ef lénið þitt sendir Strict-Transport-Security (HSTS) haus eða er safnað saman í vafrann HSTS Preload List, Chrome og Safari fjarlægja „Advanced -> Halda áfram á síðuna (óöruggt)“ framhjáhnappinn alveg, sem leiðir til 100% harðra mistaka fyrir alla notendur um allan heim. Oft, sjálfvirka endurnýjun cronjob (Certbot, acme.sh, Caddy, cert-manager, eða AWS ACM) hefur bilað hljóðlega í 30 daga vegna takmarkaðs DNS CAA met, bilað DNSSEC DS record, eldvegg sem hindrar höfn 80 (HTTP-01 áskorun), eða vefþjóni (nginx / haproxy) sem endurnýjaði skrána á disknum (fullchain.pem) en endurhlaði aldrei vinnuferla í minni. Ef bilun þín stafaði af útrunninni lénsskráningu eða rændum nafnaþjónum frekar en X.509 vottorðinu sjálfu skaltu skipta strax yfir í rænt lén, útrunnið DNS og yfirtaka vefsíðu; ef þjónninn þinn er algjörlega óaðgengilegur eða plásslaust pláss svo certbot getur ekki skrifað til /etc/letsencrypt, sjá miðlara diskur 100% fullur og núll-pláss bati eða vefhýsingarkreppa, flutningur og endurheimt öryggisafrits. Ef þetta TLS-myrkvun gerir fjarmælingu sjúkrahúsa óvirkt, API fyrir neyðarsendingar eða innviði almenningsöryggis skaltu hringja í neyðarnúmerið þitt (911 í Bandaríkjunum og Kanada, 112 víðsvegar um Evrópusambandið, 999 í Bretlandi) eða skoðaðu alþjóðlega skrá okkar yfir neyðarnúmer.

Gerðu þetta núna¶

1. ** Athugaðu eftir 10 sekúndur hvort skírteinið á disknum sé í raun þegar endurnýjað og vefþjónninn þinn eða hleðslujafnarinn hafi einfaldlega ekki tekist að endurhlaða því í vinnsluminni**:
2. Berðu saman lifandi TLS falsinn á móti .pem skrá á disk núna:

   # 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. Ef skráin á disknum sýnir gilda framtíð notAfter dagsetningu á meðan lifandi höfn 443 sýnir útrunna dagsetningu: ACME viðskiptavinur þinn (certbot / acme.sh) tókst fyrir vikum síðan, en nginx, apache2, haproxy, eða postfix var aldrei endurhlaðinn, eða (haproxy / vault) krefst fullchain.pem + privkey.pem sett saman í einn búnt. Hlaupa sudo nginx -t && sudo systemctl reload nginx (eða sudo systemctl reload apache2 haproxy) og rofinu lýkur eftir 2 sekúndur.
4. Ekki hlaupa certbot renew --force-renewal endurtekið í lykkju ef endurnýjun mistekst: Let's Encrypt framfylgir ströngum gjaldskrá sem nemur 5 tvíteknum vottorðum á 7 dögum og 5 misheppnuðum staðfestingum á reikning, fyrir hvert hýsilnafn, á klukkustund. Hlaupandi --force-renewal fimm sinnum í læti án þess að laga undirliggjandi nginx endurhlaða eða DNS/eldveggsvilla mun læsa léninu þínu fyrir Let's Encrypt útgáfu í allt að 7 daga.
5. Ef þú lendir á Let's Encrypt Rate Limit (429 Too Many Requests), skiptu ACME viðskiptavinum þínum yfir í annað ókeypis opinbert vottunarfyrirtæki (ZeroSSL, Buypass Go SSL, eða Google Trust Services) eða bættu strax við undirléni SAN:
6. Sérhver ACME viðskiptavinur (certbot, acme.sh, caddy, cert-manager) getur beðið um ókeypis traust vottorð frá öðru CA á 30 sekúndum (--server https://acme.zerossl.com/v2/DV90 eða https://api.buypass.com/acme/directory), framhjá gjaldskrá Let's Encrypt algjörlega.
7. Að öðrum kosti, Let's Encrypt's "5 tvítekin vottorð á 7 dögum" takmörk eiga aðeins við um nákvæmlega sama mengi valefnanafna fyrir efni (SANs). Bætir einu gildu undirléni við (-d example.com -d www.example.com -d tlsfix1.example.com) gerir það að vottorði sem ekki er afrit og framhjá takmörkunum fyrir afrit skírteina strax.
8. ** Athugaðu hvort DNS CAA met eða slegið DNSSEC er að koma í veg fyrir útgáfu vottorðastofnunarinnar (CAA record for example.com prevents issuance)**:
9. Spurðu um vottunarheimild lénsins þíns (CAA) skrár: dig +short CAA example.com. Ef DNS þitt hefur 0 issue "sectigo.com" eða 0 issue "amazon.com" (eða á móðurléni), Við skulum dulkóða (letsencrypt.org) og ZeroSSL (sectigo.com) er bannað af RFC 8659 að gefa út fyrr en þú bætir við 0 issue "letsencrypt.org" á DNS-svæðið þitt.
10. Ef höfn 80 (HTTP-01 áskorun) er læst af eldvegg, CDN eða ISP, eða ef vefþjónninn þinn neitar að ræsa sig vegna þess að vottorð vantar, notaðu --standalone eða --dns (DNS-01) staðfesting:
11. Hættu nginx/apache stutt og hlaupið sudo certbot certonly --standalone -d example.com, eða nota --manual --preferred-challenges dns að staðfesta með því að líma a _acme-challenge.example.com TXT taktu upp í DNS stjórnborðið þitt án þess að snerta tengið 80.
12. Ef vefsvæðið þitt situr fyrir aftan Cloudflare, AWS CloudFront eða Fastly skaltu ganga úr skugga um hvort útrunnið vottorð sé á CDN Edge eða á upprunaþjóninum þínum (Error 526 Invalid SSL Certificate):
13. Á Cloudflare, ef upprunamiðlaravottorðið þitt rann út og Cloudflare er stillt á Full (Strict), notendur sjá Villa 526. Á meðan þú lagar upprunavottorðið geturðu endurheimt umferð á vefsvæðinu á 5 sekúndum með því að búa til 15 ára Cloudflare Origin CA vottorð í Cloudflare mælaborðinu (eða skipta tímabundið um SSL/TLS stillingu frá Full (Strict) til Full í þær 10 mínútur sem það tekur að skipta um uppruna .pem skrá).

Ákvörðunartré: greina og laga útrunnið framleiðslu SSL/TLS vottorð¶

Fylgdu þessu ákvörðunartré til að finna nákvæmlega bilunarlagið (CDN Edge vs. Origin Daemon Memory vs. ACME Challenge vs. CA Rate Limit) og endurheimtu HTTPS umferð á nokkrum mínútum:

flowchart TD
    Start["Notendur / API skýrsla NET::ERR_CERT_DATE_INVALID eða Cloudflare Villa 526"] --> CheckLive["Keyra: openssl s_client -netþjónnafn lén -tengja lén:443 | openssl x509 -noout -dagsetningar -útgefandi"]

    CheckLive --> WhereExpired{"Hvaða skírteini er í raun útrunnið?"}

    WhereExpired -->|"Diskur fullchain.pem ER GILDUR, En Live Port 443 ER ÚTLUNIN"| StaleDaemon["Stale Daemon Memory eða Split Cert Store: Endurhlaða nginx / apache2 / haproxy / postfix, eða endurbyggja samsetta HAProxy PEM búnt"]
    WhereExpired -->|"CDN Edge vottorð (Cloudflare / CloudFront / Fastly) er útrunnið"| CDNFix["Athugaðu DNS CAA færslur fyrir CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) og kveiktu á Universal SSL eða endurstaðfestu ACM"]
    WhereExpired -->|"Uppruni þjónn fullchain.pem á diski ER ÚTLUNNINN"| DryRun["Keyra: sudo certbot renew --dry-run (eða acme.sh --renew -d lén --debug)"]

    DryRun --> WhyFailed{"Af hverju mistókst ACME endurnýjun?"}

    WhyFailed -->|"429 of margar beiðnir (gengismörk farið yfir)"| RateLimit["Farðu framhjá strax: Gefið út frá ZeroSSL / Buypass / Google Trust Services EÐA bættu við 1 auka SAN undirléns (-d fix1.example.com)"]
    WhyFailed -->|"CAA Record kemur í veg fyrir útgáfu eða SERVFAIL (DNSSEC)"| CAADNS["Keyra: grafa CAA example.com -> Bæta við 0 tölublaði 'letsencrypt.org' (og 'sectigo.com') eða laga bilaða DNSSEC DS skrá hjá dómritara"]
    WhyFailed -->|"Tenging hafnað / Timeout / 404 á /.well-known/acme-challenge/"| HttpBlock["Port 80 Lokað eða Redirect Loop: Opnaðu TCP Port 80 í Firewall, útilokaðu /.well-known/ frá Auth/Rewrite, eða notaðu DNS-01 Challenge"]
    WhyFailed -->|"Kubernetes vottunarstjóri pöntun fast í bið"| K8sFix["Keyra: kubectl describe challenge -> Athugaðu Ingress flokkaskýringarskýringar, HTTP01 lausnara pod netstefnu eða Webhook TLS"]

    StaleDaemon --> VerifyAll["Staðfestu keðju- og OCSP-heftingu: openssl s_client -tengja lén:443 -staða"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Áfangi 1: Að skilja hvers vegna HSTS (Strict-Transport-Security) veldur algjöru harðfelldu blackout¶

Þegar vefsíða notar ekki HSTS birtir útrunnið vottorð millivefsviðvörun (Your connection is not private) með "Advanced -> Halda áfram að example.com (óöruggt)" tengli sem gerir örvæntingarfullum notendum kleift að smella í gegnum.

Hins vegar, næstum öll nútíma framleiðslu vefforrit, bankar, SaaS pallur, og .dev / .app / .page / .bank efstu lén framfylgja HTTP ströngu flutningsöryggi (HSTS, RFC 6797): 1. Dynamísk HSTS (max-age=31536000): Allir vafrar sem hafa heimsótt síðuna þína á síðustu 365 dögum settu stefnuna í skyndiminni Strict-Transport-Security: max-age=31536000; includeSubDomains. Þar til þessi tímamælir rennur út bannar vafrinn notandanum að smella í gegnum hvaða vottorðsvillu sem er (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, eða ERR_CERT_AUTHORITY_INVALID). 2. Static HSTS Preload (preload lista eða .dev / .app gTLD): Ef lénið þitt var sent til hstspreload.org - eða ef lénið þitt notar Registry-Preloaded TLD eins og .dev, .app, .page, .new, .chrome, eða .bank - Hvert eintak af Chrome, Edge, Firefox, Safari og Android WebView á jörðinni hefur lénið þitt harðkóðað í tvöfalt sem HSTS-framfylgt áður en notandinn heimsækir síðuna þína í fyrsta skipti. 3. Af hverju includeSubDomains brýtur innri verkfæri og sviðsetningarþjóna: Ef rótarlénið þitt (example.com) sendir Strict-Transport-Security: max-age=31536000; includeSubDomains, hvert undirlén (vpn.example.com, internal-jira.example.com, printer.example.com) er einnig læst í HSTS hard-fail ham. 4. Af hverju API og Webhook samþættingar (Stripe, Twilio, Slack, iOS ATS) mistakast strax: TLS biðlarar miðlara til netþjóns (libcurl, Python requests/urllib3, Node.js undici, Farðu crypto/tls, Java SSLContext) framkvæma strangar RFC 5280 notAfter sannprófun sjálfgefið og hafa ekki hugmynd um notanda „smelli í gegnum“. Meðan á TLS rof stendur munu Stripe og Shopify vefhókar mistakast afhendingu og fara í veldisvísandi afturköllunarraðir.

2. áfangi: 60 sekúndna greiningin - Er vottorðið í raun þegar endurnýjað á disknum?¶

Í u.þ.b. 35 prósent af framleiðslu Let's Encrypt outages, var vottorðið í raun endurnýjað á disknum fyrir vikum síðan af certbot.timer eða acme.sh, en hlaupandi púkinn er enn að þjóna gamla útrunnu vottorðinu frá vinnsluminni.

Skref 1: Berðu saman netinnstunguna í beinni á móti skránni á disknum¶

Keyrðu báðar skipanirnar á þjóninum þínum:

# 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

Skref 2: Lagaðu 4 algengar „endurnýjaðar á diski, útrunnið í vinnsluminni“ gildrur¶

Stig 3: Lagfæring á DNS CAA plötublokkir og DNSSEC bilun í löggildingu¶

Ef þú hleypur sudo certbot renew --dry-run og sjáðu: - 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. Hvernig DNS CAA (RFC 8659) hindrar endurnýjun skírteina¶

Sérhver opinber vottunaraðili er lagalega skylt af CA/Browser Forum Baseline Requirements til að spyrjast fyrir um DNS CAA skrár áður en gefið er út vottorð. CA gengur upp DNS-tréð frá sub.app.example.com -> app.example.com -> example.com: - Ef example.com hefur núll CAA skrár, hvaða CA er heimilt að gefa út. - Ef example.com er með jafnvel einn CAA skrá (til dæmis, 0 issue "amazon.com" bætt sjálfkrafa við þegar einhver bjó til AWS CloudFront dreifingu, eða 0 issue "digicert.com"), hverjum öðrum vottunaraðilum á jörðinni er stranglega bannað að gefa út vottorð fyrir example.com eða eitthvað af undirlénum þess. - Ennfremur, ef þú ert að biðja um Wildcard vottorð (*.example.com) og lénið þitt skilgreinir tiltekið 0 issuewild "ca.example" merki, CA athugar issuewild eign frekar en issue.

Greining og skyndilausn fyrir CAA blokkir:¶

1. Athugaðu CAA skrár bæði á hýsingarheitinu og apex léninu:

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

2. Athugaðu líka hvort sub.example.com er a CNAME sem bendir á annað lén (Skv. RFC 8659 athuga CAs einnig CAA skrár á CNAME skotmörk).
3. Í mælaborði DNS þjónustuveitunnar (Cloudflare, Route 53, Cloud DNS, Namecheap), ekki eyða núverandi CAA skrár notaðar af CDN eða AWS ACM; í staðinn, bæta við viðbót CAA skrár sem heimila Let's Encrypt og öryggisafrits-CAs þín:

   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"
   

   (Athugið: ZeroSSL notar sectigo.com sem undirliggjandi CAA auðkenni þess, og Google Trust Services notar pki.goog.)
4. Bíddu í 60 sekúndur þar til viðurkenndir nafnaþjónar þínir uppfærist (dig @ns1.yourdns.com CAA example.com) og keyra strax aftur sudo certbot renew. Þar sem CAs framkvæma endurteknar leit í beinni útsendingu framhjá opinberum skyndiminni þegar reynt er aftur, tekst útgáfa strax.

2. Lagfæring DNS problem: SERVFAIL looking up CAA (DNSSEC misræmi)¶

Við skulum dulkóða, Google Trust Services og ZeroSSL framfylgja stranglega DNSSEC staðfestingu á öllum DNS uppflettingum (A, AAAA, TXT, og CAA). Jafnvel þó að lén hafi nr CAA skrá, verður CA að fá dulmálsgilt NOERROR (tómt svar) eða NXDOMAIN (NSEC / NSEC3 staðfest afneitun á tilveru) svar. - Ef skrásetjari léns þíns er gömul DS (Delegation Signer) skrá eftir að þú fluttir DNS-veitur (t.d. fluttir frá GoDaddy yfir í Cloudflare eða Route 53 án þess að slökkva á DNSSEC fyrst), endurkvæma upplausnartæki sem knýja fram DNSSEC endurkomu SERVFAIL. - Staðfestu eftir 5 sekúndur: Hlaupa delv @8.8.8.8 example.com CAA eða próf kl dnsviz.net. Ef dig @8.8.8.8 example.com skilar status: SERVFAIL á meðan dig +cd @8.8.8.8 example.com (+cd = Að haka við Óvirkt, hunsa DNSSEC) skilar IP tölu þinni, DNSSEC keðjan þín er biluð. Skráðu þig strax inn á lénsskrárstjórann þinn og fjarlægðu annað hvort gamalt DS taka upp eða afrita núverandi DS breytur frá virka DNS gestgjafanum þínum.

Áfangi 4: Framhjá við skulum dulkóða hraðamörk (429 Too Many Requests) meðan á virku straumi stendur¶

Í óskipulegu atviki endurræsa verkfræðingar oft gáma eða keyra certbot ítrekað þar til Let's Encrypt hafnar öllum beiðnum 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

Biðtími er á bilinu 1 klukkustund (fyrir misheppnaðar heimildir) til 7 dagar (168 klukkustundir) (fyrir hámarkið 5 tvítekin vottorð). Ekki bíða í 1 klukkustund eða 7 daga á meðan framleiðslusvæðið þitt er niðri. Þú hefur tvær fullkomlega lögmætar, tafarlausar lausnir:

Lausn A (best): Skiptu ACME vottunaryfirvöldum yfir í ZeroSSL, Buypass eða Google Trust Services á 30 sekúndum¶

ACME samskiptareglur (RFC 8555) er opinn staðall. Allir helstu vafrar og stýrikerfi treysta ZeroSSL (Sectigo root), Buypass Go SSL (norska CA) og Google Trust Services (pki.goog) eins og Let's Encrypt (ISRG Root X1). Ekkert þeirra deilir gengistakmörkunum með Let's Encrypt.

• Valkostur 1: Gefðu út strax í gegnum Certbot með Buypass Go SSL (Enginn reikningur/EAB lykill krafist, 180 daga gildistími): (Athugið: Buypass styður fjöllénaskírteini allt að 5 SAN, þó ekki jokertákn *.example.com vottorð)

  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
  

• Valkostur 2: Gefðu út strax í gegnum acme.sh (sem er sjálfgefið ZeroSSL eða skiptir 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
  

• Valkostur 3: Útgáfa í gegnum Google Trust Services (pki.goog) Public ACME: Í Google Cloud Console (eða í gegnum gcloud publicca external-account-keys create), búa til ókeypis utanaðkomandi reikningsbindingu (EAB) sláðu inn 10 sekúndur og keyrðu:

  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
  

Lausn B: Farðu framhjá mörkunum við skulum dulkóða „5 afrit skírteina“ með því að bæta við einu auka SAN hýsingarheiti¶

Við skulum dulkóða 168 klukkustunda tvítekningarmörk (too many certificates (5) already issued for this exact set of domains) fylgist með nákvæmu stafrófsröðuðu safni SAN hýsingarheita á vottorðinu, en heildarmörk skráð léns eru 50 vottorð á viku. 1. Búðu til skaðlaust DNS A skrá sem bendir á sama netþjón: tls-recovery-01.example.com -> <your_server_ip>. 2. Biddu um vottorðið með upprunalegu lénunum þínum auk nýja hýsingarheitinu:

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

Áfangi 5: Lagfæring biluð HTTP-01 áskoranir (Port 80) eða nota DNS-01 neyðarvottun¶

Hvenær certbot renew mistekst með Timeout during connect (likely firewall problem) eða Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (eða 403), CA staðfestingarþjónar geta ekki náð í HTTP áskorunarlykilinn þinn á TCP tengi 80.

Hvers vegna HTTP-01 bilar skyndilega á netþjónum sem virkuðu fyrir 60 dögum síðan¶

1. Cloud Security Group / UFW / iptables lokað port 80: Einhver herti eldvegginn til að leyfa aðeins port 443 (HTTPS), gleymir því að RFC 8555 HTTP-01 staðfesting hefst alltaf á venjulegu HTTP-tengi 80 (þó það muni fylgja a 301 beina til https:// á höfn 443).
2. Brotið IPv6 (AAAA) Skrá: Lénið þitt hefur bæði IPv4 (A) skrá og IPv6 (AAAA) skrá. Við skulum dulkóða ** kýs alltaf IPv6 (AAAA) fyrst**. Ef IPv6 vistfangið þitt er ranglega vísað, lokað af ip6tables, eða ekki bundið í Nginx (listen [::]:80;), staðfestingartími rennur út þrátt fyrir að IPv4 virki vel.
3. Nginx / Application Router (React / Next.js / Django / Rails) hlerar /.well-known/acme-challenge/: Þín server loka á port 80 umboð fyrir alla umferð (location / { proxy_pass http://localhost:3000; }) í bakendaforrit í stað þess að þjóna .well-known af diski.

Tvær skyndibætur fyrir bilað HTTP-01 löggildingu¶

Lagfæring 1: Bættu við sérstökum forgangi /.well-known/acme-challenge/ blokk í Nginx (Port 80)¶

Gakktu úr skugga um að port 80 þín lokist inn /etc/nginx/sites-enabled/ þjónar ACME tákn beint frá /var/www/letsencrypt áður hvaða return 301 https://... eða proxy_pass tilskipun:

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

Lagfæring 2: Framhjá port 80 og vefþjónum alveg með handbók DNS-01 (TXT) áskorun¶

Ef höfn 80 er læst af andstreymis ISP/eldvegg eða hleðslujafnari getur ekki leiðbeint .well-known til margra bakendahnúta, staðfestu í gegnum DNS á 2 mínútum:

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. áfangi: Sannprófun eftir bata (millikeðja, OCSP hefting og CDN hreinsun)¶

Algeng mistök eftir að neyðarskírteini hefur verið skipt út er uppsetning cert.pem (blaðaskírteinið eitt og sér) í staðinn fyrir fullchain.pem (blaðaskírteinið + millistig CA vottorð). Desktop vafrar (Chrome, Firefox) hylja oft vantað millivottorð í gegnum AIA (Authority Information Access) elta eða í skyndiminni milliefni, á meðan curl, Python, OpenSSL, Android öpp og Stripe/Twilio webhooks mistakast strax með unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• Staðfestu að þjónninn þinn sendi alla millikeðjuna (fullchain.pem): Hlaupa:

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

  Þú verður að sjá að minnsta kosti tvö stig (depth=0 lénið þitt og depth=1 millistig CA eins og Let's Encrypt E5/R11 eða ZeroSSL RSA Domain Secure Site CA) og Verify return code: 0 (ok). Ef þú sérð Verify return code: 21 (unable to verify the first certificate), breyttu stillingum vefþjónsins frá cert.pem til fullchain.pem.
• Hreinsaðu gamaldags OCSP heftunarskyndiminni í Nginx / Apache: Ef ssl_stapling on; er virkt skaltu endurhlaða vefþjóninn og athuga openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
• ** Stilltu margra laga SSL fyrningarvöktun (ytri TCP athuga + Prometheus blackbox_exporter)**: Treystu aldrei eingöngu á áminningar í tölvupósti (Við skulum dulkóða áminningartölvupóst sem hætt er að renna út árið 2025). Fylgstu með lifandi tengi 443 innstungunni að utan (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) og stilltu daglega cron check á sudo certbot renew --dry-run.

Svæðisbundin neyðarnúmer og samskiptareglur stofnunarinnar¶

Þó að útrunnið TLS vottorð sé venjulega leyst af verkfræðingateymum, getur truflun á vottorði sem brýtur heilsugáttir, neyðarsendingarvefkrókar, bankaauðkenning eða opinber innviði stjórnvalda komið af stað verkflæði reglugerðaratvika:

• Bandaríkin og Kanada:
• Lífsöryggi / klínískt / sendingarleysi: Hringdu 911 ef bilun í TLS vottorði lokar fjarmælingum sjúklings, rafrænum ávísunum eða neyðarsendingum.
• Stofnun netöryggis og innviðaöryggis (CISA) (Bandaríkin): Alríkisborgaraleg stofnanir samkvæmt CISA bindandi rekstrartilskipun (BOD) 18-01 og rekstraraðilar mikilvægra innviða sem verða fyrir óleyfilegri útgáfu skírteina (CA málamiðlun eða BGP/DNS ræning) ættu að tilkynna til 1-844-Say-CISA (1-844-729-2472) eða cisa.gov/report.
• Canadian Center for Cyber Security: Hafðu samband 1-833-CYBER-88 (1-833-292-3788).
• Bretland:
• Neyðarþjónusta: Hringdu í 999 ef bilun í TLS hefur áhrif á mikilvæg klínísk kerfi NHS eða lífsöryggi.
• National netöryggismiðstöð (NCSC): Ef þú uppgötvar óleyfilegt vottorð gefið út fyrir lénið þitt í Certificate Transparency (crt.sh) annálar sem gefa til kynna DNS-rán, tilkynntu um ncsc.gov.uk.
• Evrópusambandið:
• Neyðarþjónusta: Hringdu í 112 í öllum aðildarríkjum ESB.
• NIS2 tilskipun og eIDAS viðurkenndur auðkenningarvottorð fyrir vefsíðu (QWACs): Nauðsynlegir og mikilvægir aðilar samkvæmt NIS2-tilskipuninni sem verða fyrir langvarandi stöðvun á framboði eða hættu á PKI lyklum verða að tilkynna innlendum CSIRT innan 24 klukkustunda.
• Ástralía og Nýja Sjáland:
• Neyðarþjónusta: Hringdu í 000 í Ástralíu eða 111 á Nýja Sjálandi; hafðu samband við ACSC (1300 CYBER1) vegna innviðaatvika.
• Indland og Asíu-Kyrrahaf:
• Indland (CERT-In / Eftirlitsaðili vottunaryfirvalda CCA): Hringdu 112 fyrir neyðarviðbrögð; tilkynna PKI málamiðlun eða verulega truflun á innviðum til incident@cert-in.org.in innan 6 klst.

Algengar spurningar¶

Af hverju get ég eða notendur mínir ekki smellt á „Ítarlegt -> Halda áfram á síðuna (óöruggt)“ í Chrome eða Safari meðan á þessu bili stendur?¶

Þegar lénið þitt sendir Strangt-flutninga-öryggi (HSTS) HTTP haus - eða notar efstu lén eins og .dev, .app, .síðu, eða .banki sem er harðkóðaður í vafranum HSTS Preload List - RFC 6797 krefst þess að vafrinn meðhöndli öll útrunnið, sjálfundirritað eða missamlegt vottorð sem banvæna villu sem ekki er hægt að endurheimta. Vafrinn fjarlægir viljandi framhjáhnappinn „Halda samt áfram“ til að koma í veg fyrir að virkir Man-in-the-Middle (MitM) árásarmenn plati notendur til að smella í gegnum falsað vottorð. Þó að verktaki á skjáborði Chrome geti slegið inn falda lyklaborðsröðina þetta er óöruggt beint á villuskjáinn til að komast framhjá honum á staðnum til að prófa, raunverulegir notendur geta það ekki; þú verður að setja upp gilt vottorð á höfn 443.

Við skulum dulkóða hættu að senda viðvörunarpóst um fyrningu og vottorðið mitt rann út fyrirvaralaust - hvers vegna gerðist það?¶

Let's Encrypt hætti opinberlega að nota tölvupóstþjónustu sína um fyrningu tilkynninga um mitt ár 2025 til að draga úr kostnaði við varðveislu gagna og vegna þess að sjálfvirkar ACME uppsetningar ættu að fylgjast beint með endurnýjunarheilbrigði. Til að koma í veg fyrir að það komi á óvart í framtíðinni verður þú að fylgjast með raunverulegum tímastimpli TLS handabands sem rennur út á netinu með því að nota utanaðkomandi spennutímaskjá (eins og Prometheus blackbox_exporter, Uptime Kuma, Better Stack, eða Datadog Synthetic TLS eftirlit) viðvörun 21 dögum, 14 dögum og 7 dögum áður ekkiEftir.

Af hverju virkar síðan mín vel í Chrome og Firefox á fartölvunni minni, en mistekst í Android símum, curl, og Stripe webhooks eftir að ég uppfærði vottorðið?¶

Þú stilltir vefþjóninn þinn (ssl_vottorð í Nginx eða SSLCertificateFile í Apache) til að benda á cert.pem (blaðaskírteinið eitt og sér) í staðinn fyrir fullchain.pem (blaðaskírteinið sem fylgir millistigs CA vottorðinu). Skrifborðsvafrar eins og Chrome og Firefox hlaða sjálfkrafa niður vantandi millivottorðum í bakgrunni með því að nota Upplýsingaaðgangur yfirvalda (AIA) Vefslóð inni í blaðavottorðinu þínu, felur rangstillingu netþjónsins. Hins vegar, krulla, OpenSSL, Android System Traust Verifier, Python og webhook netþjónar framkvæma ekki AIA eltingu og hafna samstundis tengingu við ekki hægt að fá staðbundið útgefandaskírteini. Beindu stillingunni þinni á fullchain.pem og endurhlaða netþjóninn þinn.

Hvernig athuga ég hvort tölvuþrjótur eða fantur stjórnandi hafi gefið út óviðkomandi SSL vottorð fyrir lénið mitt?¶

Sérhver opinberlega traust vottorðsyfirvöld þurfa að skrá hvert útgefið vottorð til almennings Skírteini gagnsæi (CT) logs (RFC 6962) áður en vafrar munu treysta því. Opið https://crt.sh/?q=%25.yourdomain.com eða Cloudflare's Certificate Transparency Monitor til að skoða hvert vottorð sem gefið hefur verið út fyrir lénið þitt og undirlén þess. Ef þú sérð vottorð gefið út af ókunnugum CA sem þú veittir ekki heimild skaltu strax skoða DNS skrásetjarann þinn og opinbert DNS svæði fyrir óheimilar breytingar, afturkalla fantavottorðið með útgefanda CA og læsa DNS þínu með Flugmálastjórn skrár (`0 issue "letsencrypt.org"`).

Hvað ef Kubernetes þyrpingin mín er cert-manager tókst ekki að endurnýja Ingress vottorðið okkar og pöntunin er föst inni Pending?¶

Hlaupa kubectl fá pöntun, áskorun -A og svo kubectl lýsa áskorun <áskorun-nafn> -n . Í 90 prósent af Kubernetes vottunarstjóri truflanir, the cm-acme-http-solver-* tímabundið hólf er í gangi, en annaðhvort (1) Ingress tilföngin er með gamaldags inngönguskýringu þannig að lausnarleiðin er aldrei tengd álagsjafnaranum þínum, (2) Kubernetes Netstefna er að loka fyrir innkomu umferð til lausnarstöðvarinnar á port 8089, eða (3) hárnálna NAT / skiptan sjóndeildarhrings DNS vandamál kemur í veg fyrir vottunarstjóriinnri sjálfsskoðun frá því að ná opinberri hleðslujöfnunar IP-tölu (hægt að laga með því að standast --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 til vottunarstjóri dreifing args).

Get ég afritað mitt /etc/letsencrypt/ möppu á nýjan netþjón við neyðarflutning í stað þess að gefa út aftur?¶

Já. Ef aðalþjónninn þinn dó og þú ert að flytja yfir á nýjan netþjón á meðan gengistakmörkun er takmörkuð af Let's Encrypt, varðveittu tákntengla þegar þú afritar /etc/letsencrypt/ nota tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (aldrei nota venjulegt scp -r, sem gerir tákntengla inn /etc/letsencrypt/live/ í tvíteknar kyrrstæðar skrár og brýtur endurnýjun í framtíðinni). Dragðu það skjalasafn út á nýja netþjóninn (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), benda Nginx/Apache á `/etc/letsencrypt/live/domain/fullchain.pem`, og núverandi vottorð þitt mun virka strax á nýju IP tölunni.

Tengdir leiðsögumenn¶

• Ránun léns, útrunnið DNS og yfirtaka vefsíðu
• Miðlaradiskur 100% fullur (0 bæti laus): gagnagrunnur og endurheimt með núllplássi
• Google Workspace eða Microsoft 365 sérsniðið lénsstjórnendalokun og DNS TXT björgun
• Vefhýsingarkreppa, flutningur og endurheimt afritunar
• DNS ræning, WAN endurstilling ISP beini og skopstæling á fangagátt
• Neyðarnúmer eftir löndum

Heimildir og opinberar leiðbeiningar¶

• Verkefnahópur Internetverkfræði (IETF): RFC 8555 (Sjálfvirkt vottorðsstjórnunarumhverfi / ACME), RFC 8659 (DNS vottunarvaldsheimild / CAA) og RFC 6797 (HTTP Strict Transport Security / HSTS).
• National Institute of Standards and Technology (NIST) (Bandaríkin): Sérstök útgáfa 800-52 Rev. 2: Leiðbeiningar um val, uppsetningu og notkun á TLS-útfærslum (Transport Layer Security) & SP 1800-16: Öryggi vefviðskipta: TLS Server Certificate Management.
• Internet Security Research Group (ISRG / Við skulum dulkóða opinber skjöl): Tilvísun gjaldatakmarka, afrita skírteinareglur og ACME áskorun bilanaleit.
• Stofnun netöryggis og innviðaöryggis (CISA) (Bandaríkin): Bindandi rekstrartilskipun 18-01: Auka tölvupóst- og veföryggi (HTTPS og HSTS framkvæmdarleiðbeiningar).
• National netöryggismiðstöð (NCSC) (Bretland): Notkun TLS til að vernda gögn fullkomlega í flutningi og leiðbeiningar um eftirlit með gagnsæi skírteina.