Rate-Limit բլոկները¶

Արտակարգ իրավիճակների համարները տարբերվում են ըստ երկրների. Այս էջն օգտագործում է 911 համարը՝ Միացյալ Նահանգների և Կանադայի համար: Շատ այլ երկրներ օգտագործում են 112, 999 կամ մեկ այլ համար: Գտեք ձեր երկրի համարը.

Երբ արտադրական SSL/TLS (HTTPS) վկայագրի ժամկետը լրանում է, նույնիսկ մեկ վայրկյան անց notAfter UTC ժամադրոշմ՝ յուրաքանչյուր ժամանակակից զննարկիչ (Chrome, Safari, Firefox, Edge), բջջային հավելված (iOS App Transport Security, Android Network Security Config), webhook ընդունիչ (Stripe, Shopify, Twilio, GitHub), և վերին հոսքի API-ի հաճախորդն անմիջապես անջատում է կապը NET::ERR_CERT_DATE_INVALID կամ SSL_ERROR_RX_RECORD_TOO_LONG. Դեռ ավելի վատ, եթե ձեր տիրույթը ուղարկում է Strict-Transport-Security (HSTS) վերնագիր կամ կազմված է զննարկիչում HSTS Preload List, Chrome-ը և Safari-ն ամբողջությամբ հեռացնում են «Ընդլայնված -> Անցնել կայք (անապահով)» շրջանցման կոճակը, ինչը հանգեցնում է 100 տոկոսով դժվարին խափանումների բոլոր օգտատերերի համար ամբողջ աշխարհում: Հաճախ, ավտոմատացված նորացման cronjob (Certbot, acme.sh, Caddy, cert-manager, կամ AWS ACM) 30 օր լուռ ձախողվում է սահմանափակող DNS-ի պատճառով CAA ռեկորդ, կոտրված DNSSEC DS ռեկորդ, firewall արգելափակող նավահանգիստ 80 (HTTP-01 մարտահրավեր), կամ վեբ սերվեր (nginx / haproxy), որը թարմացրել է ֆայլը սկավառակի վրա (fullchain.pem), բայց երբեք չի վերաբեռնել իր հիշողության աշխատանքային գործընթացները: Եթե ձեր խափանումն առաջացել է տիրույթի ժամկետանց գրանցման կամ անուն սերվերների առևանգման պատճառով, այլ ոչ թե հենց X.509 վկայագրի, անմիջապես անցեք տիրույթի անվան առևանգում, ժամկետանց DNS և վեբ կայքի գրավում; եթե ձեր սերվերը լիովին անհասանելի է կամ սկավառակի տարածքը բացակայում է certbot չի կարող գրել /etc/letsencrypt, տես սերվերի սկավառակի 100% ամբողջական և զրոյական տարածքի վերականգնում կամ վեբ հոստինգի ճգնաժամ, միգրացիա և կրկնօրինակի վերականգնում. Եթե այս TLS անջատումը անջատում է հիվանդանոցի հեռաչափությունը, շտապ օգնության API-ները կամ հանրային անվտանգության ենթակառուցվածքը, զանգահարեք ձեր տեղական շտապ օգնության համարին (911 Միացյալ Նահանգներում և Կանադայում, 112 ամբողջ Եվրամիությունում, 999 Միացյալ Թագավորությունում) կամ դիմեք մեր միջազգային գրացուցակին շտապ օգնության համարները.

Արեք սա հիմա¶

Ստուգեք 10 վայրկյանում, արդյոք սկավառակի վկայականն իրականում արդեն թարմացվել է, և ձեր վեբ սերվերը կամ բեռնման հավասարակշռիչը պարզապես չհաջողվեց վերաբեռնել այն RAM-ում:

Համեմատեք ուղիղ TLS վարդակից հետ .pem ֆայլը սկավառակի վրա հենց հիմա.

# 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

Եթե սկավառակի վրա գտնվող ֆայլը ցույց է տալիս վավեր ապագա notAfter ամսաթիվը, իսկ կենդանի նավահանգիստը 443 ցույց է տալիս ժամկետանց ամսաթիվ. Ձեր ACME հաճախորդը (certbot / acme.sh) շաբաթներ առաջ հաջողվեց, բայց nginx, apache2, haproxy, կամ postfix երբեք չի վերաբեռնվել, կամ (haproxy / vault) պահանջում է fullchain.pem + privkey.pem միացված մեկ փաթեթի մեջ: Վազիր sudo nginx -t && sudo systemctl reload nginx (կամ sudo systemctl reload apache2 haproxy) և ձեր անջատումը կավարտվի 2 վայրկյանից:
ՄԻ վազիր certbot renew --force-renewal մի քանի անգամ մի օղակում, եթե նորացումը ձախողվի. Let's Encrypt-ը պարտադրում է խիստ տոկոսադրույքի սահմանաչափ՝ 5 կրկնօրինակ վկայական 7 օրվա ընթացքում և 5 ձախողված վավերացում յուրաքանչյուր հաշվի, յուրաքանչյուր հոսթի անվան, ժամում: Վազում --force-renewal հինգ անգամ խուճապի մեջ՝ առանց հիմքը շտկելու nginx վերաբեռնեք կամ DNS/firewall-ի սխալը կփակի ձեր տիրույթը Let's Encrypt-ի թողարկումից մինչև 7 օր:
** Եթե դուք հարվածում եք Let's Encrypt Rate Limit (429 Too Many Requests), փոխեք ձեր ACME հաճախորդը երկրորդ անվճար հանրային վկայականի մարմնի (ZeroSSL, Buypass Go SSL, կամ Google Trust Services) կամ անհապաղ ավելացրե՛ք «SAN» ենթադոմեյն**:
Յուրաքանչյուր ACME հաճախորդ (certbot, acme.sh, caddy, cert-manager) կարող է անվճար վստահելի վկայական պահանջել այլ CA-ից 30 վայրկյանում (--server https://acme.zerossl.com/v2/DV90 կամ https://api.buypass.com/acme/directory), ամբողջությամբ շրջանցելով Let's Encrypt-ի տոկոսադրույքի սահմանաչափը։
Որպես այլընտրանք, Let's Encrypt-ի «5 կրկնօրինակ վկայական 7 օրվա ընթացքում» սահմանաչափը վերաբերում է միայն առարկաների այլընտրանքային անունների ճիշտ նույն շարքին (SANs). Մեկ լրացուցիչ վավեր ենթադոմեյնի ավելացում (-d example.com -d www.example.com -d tlsfix1.example.com) այն դարձնում է ոչ կրկնօրինակ վկայական և անմիջապես շրջանցում է Կրկնվող վկայագրի դրույքաչափի սահմանաչափը:
** Ստուգեք, արդյոք DNS է CAA ռեկորդային կամ կոտրված DNSSEC արգելափակում է ձեր Վկայագրի մարմնի տրամադրումը (CAA record for example.com prevents issuance)**:
Հարցրեք ձեր տիրույթի սերտիֆիկացման մարմնի թույլտվությանը (CAA) գրառումներ. dig +short CAA example.com. Եթե ձեր DNS-ն ունի 0 issue "sectigo.com" կամ 0 issue "amazon.com" (կամ մայր տիրույթում), Եկեք գաղտնագրենք (letsencrypt.org) և ZeroSSL (sectigo.com) RFC 8659-ի կողմից արգելվում է թողարկել, քանի դեռ չեք ավելացնել 0 issue "letsencrypt.org" դեպի ձեր DNS գոտի:
** Եթե նավահանգիստ 80 (HTTP-01 մարտահրավեր) արգելափակված է firewall-ի, CDN-ի կամ ISP-ի կողմից, կամ եթե ձեր վեբ սերվերը հրաժարվում է գործարկել բացակայող վկայագրի պատճառով, օգտագործեք --standalone կամ --dns (DNS-01) վավերացում**:
Դադարեցրեք nginx/apache հակիրճ և վազիր sudo certbot certonly --standalone -d example.com, կամ օգտագործել --manual --preferred-challenges dns վավերացնել՝ կպցնելով ա _acme-challenge.example.com TXT ձայնագրեք ձեր DNS կոնսոլում՝ առանց պորտին հպելու 80.
Եթե ձեր կայքը գտնվում է Cloudflare-ի, AWS CloudFront-ի կամ Fastly-ի հետևում, ստուգեք՝ ժամկետանց վկայագիրը CDN Edge-ում է, թե ձեր Origin Server-ում (Error 526 Invalid SSL Certificate):
Cloudflare-ում, եթե ձեր ծագման սերվերի վկայագրի ժամկետը լրացել է, և Cloudflare-ը սահմանված է Full (Strict), օգտվողները տեսնում են Սխալ 526: Մինչ դուք ուղղում եք ծագման վկայագիրը, դուք կարող եք վերականգնել կայքի ուղիղ թրաֆիկը 5 վայրկյանում՝ ստեղծելով 15-ամյա Cloudflare Origin CA վկայագիր Cloudflare-ի վահանակում (կամ ժամանակավորապես փոխելով SSL/TLS ռեժիմը։ Full (Strict) դեպի Full սկզբնաղբյուրը փոխարինելու համար պահանջվող 10 րոպեի ընթացքում .pem ֆայլ):

Danger

Երբեք մի փորձեք «շտկել» HSTS Preload-ի կողպումը կարգավորելով Strict-Transport-Security: max-age=0 մինչ ձեր SSL/TLS վկայականը դեռ ժամկետանց է. RFC 6797-ը բացահայտորեն արգելում է բրաուզերներին մշակել կամ հարգել որևէ մեկը Strict-Transport-Security վերնագիր (ներառյալ max-age=0) անվստահելի, ինքնաստորագրված կամ ժամկետանց TLS կապի միջոցով կամ պարզ HTTP. Ավելին, եթե ձեր տիրույթն ունի includeSubDomains; preload կազմվել է Chromium/Firefox/Safari ստատիկ HSTS նախաբեռնված ցանկում, նույնիսկ max-age=0 վավեր կապի միջոցով չի հեռացնի նախապես բեռնված դրոշը առաջին այցելուների համար: HSTS-ով կողպված տիրույթի հասանելիությունը վերականգնելու միակ միջոցը 443 նավահանգստում վավեր, հանրության կողմից վստահված X.509 վկայականի տեղադրումն է։

Որոշման ծառ. ախտորոշում և ամրագրում է ժամկետանց արտադրության SSL/TLS վկայագիրը¶

Հետևեք այս որոշումների ծառին, որպեսզի մատնանշեք խափանումների ճշգրիտ շերտը (CDN Edge-ն ընդդեմ Origin Daemon Memory-ի ընդդեմ ACME Challenge-ի ընդդեմ CA Rate Limit-ի) և վերականգնելու HTTPS տրաֆիկը րոպեների ընթացքում:

flowchart TD
    Start["Օգտատերերը / API-ները հաղորդում են NET::ERR_CERT_DATE_INVALID կամ Cloudflare Սխալ 526"] --> CheckLive["Գործարկել՝ openssl s_client -servername domain -connect domain:443 | openssl x509 -noout -ամսաթվեր - թողարկող"]

    CheckLive --> WhereExpired{"Ո՞ր վկայականն է իրականում ժամկետանց:"}

    WhereExpired -->|"Սկավառակի fullchain.pem-ն ուժի մեջ է, բայց Live պորտ 443-ը ժամկետանց է"| StaleDaemon["Հնացած Daemon հիշողություն կամ Split Cert Store. Վերբեռնել nginx / apache2 / haproxy / postfix կամ վերակառուցել համակցված HAProxy PEM փաթեթը"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) ժամկետանց է"| CDNFix["Ստուգեք DNS CAA գրառումները CDN CA-ի համար (letsencrypt.org / pki.goog / digicert.com / amazon.com) և միացրեք համընդհանուր SSL կամ նորից վավերացրեք ACM-ը"]
    WhereExpired -->|"Origin Server fullchain.pem սկավառակի վրա ժամկետանց է"| DryRun["Գործարկել. sudo certbot renew --dry-run (կամ acme.sh --renew -d տիրույթը --debug)"]

    DryRun --> WhyFailed{"Ինչու՞ ACME-ի նորացումը ձախողվեց:"}

    WhyFailed -->|"429 Չափազանց շատ հարցումներ (գույքի սահմանաչափը գերազանցված է)"| RateLimit["Անմիջապես շրջանցեք. թողարկում ZeroSSL / Buypass / Google Trust ծառայություններից ԿԱՄ Ավելացրեք 1 լրացուցիչ ենթադոմեյն SAN (-d fix1.example.com)"]
    WhyFailed -->|"CAA գրառումը կանխում է թողարկումը կամ SERVFAIL (DNSSEC)"| CAADNS["Գործարկել՝ dig CAA example.com -> Ավելացնել 0 թողարկում «letsencrypt.org» (և «sectigo.com») կամ ուղղել կոտրված DNSSEC DS գրառումը Registrar-ում:"]
    WhyFailed -->|"Միացումը մերժված է / Timeout / 404 on /.well-known/acme-challenge/"| HttpBlock["Port 80-ն արգելափակված է կամ վերահղման հանգույց. բացեք TCP պորտը 80-ը Firewall-ում, բացառեք /.well-known/-ը Auth/Rewrite-ից կամ օգտագործեք DNS-01 Challenge-ը:"]
    WhyFailed -->|"Kubernetes-ի վկայական-մենեջերի Պատվերը մնացել է սպասման մեջ"| K8sFix["Գործարկել. kubectl նկարագրել մարտահրավերը -> Ստուգել Ingress դասի ծանոթագրությունը, HTTP01 լուծիչի pod ցանցի քաղաքականությունը կամ Webhook TLS"]

    StaleDaemon --> VerifyAll["Ստուգեք Chain & OCSP Stapling. openssl s_client -connect domain:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Փուլ 1. Հասկանալով, թե ինչու HSTS (`Strict-Transport-Security`) առաջացնում է ամբողջական խափանում¶

Երբ կայքը չի օգտագործում HSTS, ժամկետանց վկայականը ցուցադրում է միջքաղաքային նախազգուշացում (Your connection is not private) «Ընդլայնված -> Անցեք example.com (անապահով)» հղումով, որը թույլ է տալիս հուսահատ օգտվողներին սեղմել:

Այնուամենայնիվ, գրեթե բոլոր ժամանակակից արտադրական վեբ հավելվածները, բանկերը, SaaS հարթակները և .dev / .app / .page / .bank վերին մակարդակի տիրույթները կիրառում են HTTP խիստ տրանսպորտային անվտանգություն (HSTS, RFC 6797): 1. ** Դինամիկ HSTS (max-age=31536000). ցանկացած զննարկիչ, որն այցելել է ձեր կայք վերջին 365 օրվա ընթացքում, քեշ է պահել քաղաքականությունը Strict-Transport-Security: max-age=31536000; includeSubDomains. Մինչև այդ ժամանակաչափի ժամկետի ավարտը, զննարկիչը արգելում է օգտատիրոջը սեղմել վկայագրի որևէ սխալի վրա (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, կամ ERR_CERT_AUTHORITY_INVALID) 2. ** Ստատիկ HSTS Նախաբեռնում (preload ցուցակ կամ .dev / .app gTLD). Եթե ձեր տիրույթը ներկայացվել է hstspreload.org - կամ եթե ձեր տիրույթն օգտագործում է ռեգիստրով նախապես բեռնված TLD նման .dev, .app, .page, .new, .chrome, կամ .bank - Երկրի վրա Chrome-ի, Edge-ի, Firefox-ի, Safari-ի և Android WebView-ի յուրաքանչյուր պատճենը ունի ձեր տիրույթի կոշտ կոդավորումը իր երկուականի մեջ՝ որպես HSTS-ի կիրառում, նախքան օգտատերը երբևէ առաջին անգամ այցելել է ձեր կայք: 3. ** Ինչու includeSubDomains խախտում է ներքին գործիքները և բեմականացման սերվերները**. Եթե ձեր արմատային տիրույթը (example.com) ուղարկում է Strict-Transport-Security: max-age=31536000; includeSubDomains, յուրաքանչյուր ենթադոմեյն (vpn.example.com, internal-jira.example.com, printer.example.com) նույնպես արգելափակված է HSTS կոշտ ձախողման ռեժիմում: 4. ** Ինչու API և Webhook ինտեգրումներ (Stripe, Twilio, Slack, iOS ATS) անհապաղ ձախողվել**. սերվերից սերվեր TLS հաճախորդներ (libcurl, Python requests/urllib3, Node.js undici, Գնա crypto/tls, Java SSLContext) կատարել խիստ RFC 5280 notAfter լռելյայն վավերացում և չունի օգտագործողի «սեղմում» հասկացություն: TLS-ի խափանումների ժամանակ Stripe և Shopify վեբ-կեռիկներ կձախողվեն առաքումը և կմտնեն կրկնակի փորձարկման էքսպոնենցիոնալ հերթեր:

Փուլ 2. 60 վայրկյան ախտորոշում. Արդյո՞ք վկայագիրը իրականում արդեն թարմացվել է սկավառակի վրա:¶

Արտադրության մոտավորապես 35 տոկոսի դեպքում, Let's Encrypt outages, վկայագիրը իրականում թարմացվել է սկավառակի վրա շաբաթներ առաջ՝ certbot.timer կամ acme.sh, բայց գործող դեյմոնը դեռ սպասարկում է հին ժամկետանց վկայականը RAM-ից։

Քայլ 1. Համեմատեք ուղիղ ցանցի վարդակը սկավառակի վրա գտնվող ֆայլի հետ¶

Գործարկեք երկու հրամանները ձեր սերվերի վրա.

# 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. Ուղղեք 4 սովորական «Նորացված է սկավառակի վրա, ժամկետանց RAM-ում» ծուղակները¶

Ծառայություն / վստահված անձ	Ինչու է այն շարունակում ծառայել հին ժամկետանց վկայականը թարմացումից հետո	Անմիջապես և մշտապես շտկելու ճշգրիտ հրաման
`Nginx` / `Apache`	`certbot` օգտագործված `--webroot` կամ `--standalone` (կամ `dns-*` plugin) փոխարեն `--nginx`, այնպես որ, հետթարմացումից հետո վերաբեռնման ոչ մի կեռիկ երբևէ չի ազդարարել հիմնական գործընթացի մասին:	Վազիր `sudo nginx -t && sudo systemctl reload nginx`. Ավելացրեք մշտական տեղակայման կեռիկ `/etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh`: `systemctl reload nginx` (`sudo chmod +x` սցենարը):
`HAProxy`	HAProxy-ը պահանջում է `fullchain.pem` ԵՎ `privkey.pem` միացված է միասնական համակցված `.pem` ֆայլ (`combined.pem`) Certbot-ը թարմացվել է `fullchain.pem` և `privkey.pem`, բայց `combined.pem` դեռ 90 օրվա կրկնօրինակն է։	Վերակառուցեք փաթեթը և վերաբեռնեք HAProxy-ը. `sudo sh -c 'cat /etc/letsencrypt/live/example.com/fullchain.pem /etc/letsencrypt/live/example.com/privkey.pem > /etc/haproxy/certs/example.com.pem'` `sudo chmod 600 /etc/haproxy/certs/example.com.pem && sudo systemctl reload haproxy`
Կոտրված Symlink-ը `/etc/letsencrypt/live/`	Ինչ-որ մեկը ձեռքով պատճենել է `/etc/letsencrypt/archive/example.com/fullchain3.pem` մեջ `/etc/nginx/ssl/` մատնացույց անելու փոխարեն `nginx.conf` դեպի `/etc/letsencrypt/live/example.com/fullchain.pem` symlink, կամ Certbot-ը ստեղծել է կրկնօրինակ տոհմ անունով `/etc/letsencrypt/live/example.com-0001/`.	Վազիր `sudo certbot certificates` տեսնելու համար, թե `example.com-0001` ստեղծվել է. Կետ `ssl_certificate` մեջ `/etc/nginx/` ակտիվներին `/etc/letsencrypt/live/<lineage>/fullchain.pem` symlink և վերաբեռնել Nginx-ը:
Դոկեր կոնտեյներ (`nginx` / `traefik` / `postfix`)	Հյուրընկալող ՕՀ-ն թարմացվել է `/etc/letsencrypt/archive/example.com/fullchain4.pem` և թարմացրել է սիմհղումը, սակայն Docker կոնտեյները կապել է մեկ ֆայլի ինոդը (որն անջատված է/փոխարինվել է) կամ անվանատարածքի ներսում գտնվող կոնտեյների գործընթացը երբեք չի ստացվել։ `SIGHUP`.	Ամրացրեք ամբողջը `/etc/letsencrypt` գրացուցակ (երբեք մեկ `.pem` ֆայլ, քանի որ symlink թիրախները փոխվում են նորացման ժամանակ) և գործարկել `docker kill -s HUP <nginx_container>`.

Փուլ 3. DNS-ի շտկում `CAA` ռեկորդային բլոկներ և `DNSSEC` վավերացման ձախողումներ¶

Եթե դուք վազում եք sudo certbot renew --dry-run և տես. - 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. Ինչպես DNS `CAA` (RFC 8659) արգելափակում է վկայագրի նորացումը¶

Հավաստագրման յուրաքանչյուր հանրային մարմնի օրինական պահանջվում է CA/Browser ֆորումի ելակետային պահանջներով DNS հարցումներ կատարելու համար: CAA գրանցում է նախքան որևէ վկայական տալը: CA-ն քայլում է վերև DNS ծառից sub.app.example.com -> app.example.com -> example.com: - Եթե example.com ունի զրո CAA գրառումներ, ցանկացած CA թույլատրվում է թողարկել: - Եթե example.com ունի անգամ սինգլ CAA գրառում ** (օրինակ, 0 issue "amazon.com" ավելացվել է ավտոմատ կերպով, երբ ինչ-որ մեկը ստեղծեց AWS CloudFront բաշխում, կամ 0 issue "digicert.com"), Երկրի վրա գտնվող ցանկացած այլ Վկայական մարմնի խստիվ արգելվում է վկայական տալ example.com կամ դրա ենթադոմեյններից որևէ մեկը: - Ավելին, եթե դուք պահանջում եք ** Wildcard վկայագիր (*.example.com) և ձեր տիրույթը սահմանում է կոնկրետ 0 issuewild "ca.example" պիտակ, CA-ն ստուգում է issuewild սեփականություն, քան issue.

Ախտորոշիչ և ակնթարթային շտկում `CAA` բլոկներ:¶

Ստուգեք CAA գրառումներ ինչպես հոսթի անվան, այնպես էլ գագաթնակետային տիրույթի վրա.
```
dig +short CAA sub.example.com
dig +short CAA example.com
```
Նաև ստուգեք՝ արդյոք sub.example.com է CNAME մատնանշելով մեկ այլ տիրույթ (RFC 8659-ի համաձայն, CA-ները նույնպես ստուգում են CAA CNAME թիրախների վերաբերյալ գրառումներ):
Ձեր DNS մատակարարի վահանակում (Cloudflare, Route 53, Cloud DNS, Namecheap), մի ջնջեք առկա CAA գրառումներ, որոնք օգտագործվում են ձեր CDN-ի կամ AWS ACM-ի կողմից. փոխարենը, կցել լրացուցիչ CAA Let's Encrypt-ը և ձեր պահուստային 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"
```
(Նշում. ZeroSSL-ն օգտագործում է sectigo.com որպես դրա հիմքում ընկած CAA նույնացուցիչը և օգտագործում է Google Trust Services-ը pki.goog.)*
Սպասեք 60 վայրկյան, որպեսզի ձեր հեղինակավոր անունների սերվերները թարմացվեն (dig @ns1.yourdns.com CAA example.com) և անմիջապես նորից գործարկել sudo certbot renew. Քանի որ CA-ները կատարում են կենդանի ռեկուրսիվ որոնումներ՝ շրջանցելով հանրային քեշերը կրկնակի փորձի ժամանակ, թողարկումն անմիջապես հաջողվում է:

2. Ամրագրում `DNS problem: SERVFAIL looking up CAA` (`DNSSEC` անհամապատասխանություն)¶

Եկեք գաղտնագրենք, Google Trust Services-ը և ZeroSSL-ը խստորեն կիրառեն DNSSEC վավերացումը բոլոր DNS որոնումների վրա (A, AAAA, TXT, և CAA) Նույնիսկ եթե տիրույթն ունի no CAA գրառում, CA-ն պետք է ստանա ծածկագրային վավերական փաստաթուղթ NOERROR (դատարկ պատասխան) կամ NXDOMAIN (NSEC / NSEC3 գոյության վավերացված ժխտում) պատասխան. - Եթե ձեր տիրույթի ռեգիստրատորը հնացած է DS (Delegation Signer) գրանցում է DNS պրովայդերներին տեղափոխելուց հետո (օրինակ՝ GoDaddy-ից տեղափոխվելով Cloudflare կամ Route 53 առանց DNSSEC-ը նախ անջատելու), ռեկուրսիվ լուծիչներ, որոնք պարտադրում են DNSSEC վերադարձը SERVFAIL. - Ստուգել 5 վայրկյանում. Գործարկել delv @8.8.8.8 example.com CAA կամ փորձարկել ժամը dnsviz.net. Եթե dig @8.8.8.8 example.com վերադառնում է status: SERVFAIL մինչդեռ dig +cd @8.8.8.8 example.com (+cd = Անջատված է ստուգումը, DNSSEC-ի անտեսումը) վերադարձնում է ձեր IP հասցեն, ձեր DNSSEC շղթան կոտրված է: Անմիջապես մուտք գործեք ձեր տիրույթի ռեգիստրատոր և կամ հեռացրեք հնացածը DS ձայնագրել կամ պատճենել ընթացիկը DS պարամետրեր ձեր ակտիվ DNS հոսթից:

Փուլ 4. շրջանցելով Եկեք գաղտնագրենք տոկոսադրույքի սահմանները (`429 Too Many Requests`) ակտիվ անջատման ժամանակ¶

Քաոսային միջադեպի ժամանակ ինժեներները հաճախ վերագործարկում են բեռնարկղերը կամ վազում certbot մի քանի անգամ, մինչև Let's Encrypt-ը մերժի բոլոր հարցումները հետևյալով. - 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

Սպասման ժամանակը տատանվում է 1 ժամից (չհաջողված թույլտվությունների դեպքում) մինչև 7 օր (168 ժամ) (5 կրկնօրինակ վկայագրերի սահմանաչափի համար): Մի սպասեք 1 ժամ կամ 7 օր, քանի դեռ ձեր արտադրական կայքը չի աշխատում: Դուք ունեք երկու լիովին օրինական, անմիջական լուծում.

Լուծում A (լավագույն). 30 վայրկյանում փոխեք ACME վկայականի հեղինակությունը ZeroSSL, Buypass կամ Google Trust ծառայություններ:¶

ACME արձանագրությունը (RFC 8555) բաց ստանդարտ է: Յուրաքանչյուր հիմնական դիտարկիչ և օպերացիոն համակարգ վստահում է ZeroSSL-ին (Sectigo արմատ), Buypass Go SSL-ին (նորվեգական CA) և Google Trust Services-ին (pki.goog) նույնական է Let's Encrypt (ISRG Root X1) Նրանցից ոչ մեկը չի կիսում տոկոսադրույքի սահմանափակումները Let's Encrypt-ի հետ:

** Տարբերակ 1. Անմիջապես թողարկեք միջոցով Certbot օգտագործելով Buypass Go SSL (Հաշիվ/EAB բանալի չի պահանջվում, 180 օր վավերականություն)**: (Նշում. Buypass-ն աջակցում է բազմաբնույթ տիրույթի վկայագրերի մինչև 5 SANs, թեև ոչ wildcard *.example.com վկայականներ)
```
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. Անմիջապես թողարկեք միջոցով acme.sh (որը կանխադրված է ZeroSSL կամ փոխարկում է CA-ները --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. Թողարկել Google Trust Services-ի միջոցով (pki.goog) Հանրային ACME **: Google Cloud Console-ում (կամ միջոցով gcloud publicca external-account-keys create), ստեղծեք անվճար արտաքին հաշիվների կապում (EAB) սեղմեք 10 վայրկյանում և գործարկեք.
```
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. շրջանցեք Եկեք գաղտնագրենք «5 կրկնօրինակ վկայականների» սահմանը՝ ավելացնելով մեկ լրացուցիչ SAN հոսթի անուն:¶

Եկեք գաղտնագրենք 168-ժամյա կրկնօրինակի սահմանաչափը (too many certificates (5) already issued for this exact set of domains) հետևում է վկայագրի ՍԱՆ հոսթների անունների ճշգրիտ այբբենական շարքը, մինչդեռ գրանցված տիրույթի ընդհանուր սահմանաչափը շաբաթական 50 վկայական է: 1. Ստեղծեք անվնաս DNS A նույն սերվերին մատնանշող գրառում. tls-recovery-01.example.com -> <your_server_ip>. 2. Պահանջեք վկայագիրը ձեր բնօրինակ տիրույթներով գումարած նոր հոսթի անվանումով.

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

(Անցնելով --cert-name example.com թարմացնում է ձեր գոյությունը /etc/letsencrypt/live/example.com/ գրացուցակը տեղում, այնպես որ դուք նույնիսկ կարիք չունեք խմբագրելու nginx.conf.) Որովհետև {example.com, tls-recovery-01.example.com, www.example.com} տիրույթների բոլորովին նոր հավաքածու է, Let's Encrypt-ը թողարկում է վկայագիրը անմիջապես:

Փուլ 5. Կոտրված ամրացում `HTTP-01` մարտահրավերներ (`Port 80`) կամ օգտագործելով `DNS-01` վթարային վավերացում¶

Երբ certbot renew ձախողվում է Timeout during connect (likely firewall problem) կամ Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (կամ 403), CA վավերացման սերվերները չեն կարող հասնել ձեր HTTP մարտահրավեր նշանին TCP 80 պորտի վրա:

Ինչո՞ւ `HTTP-01` հանկարծակի ընդհատվում է 60 օր առաջ աշխատած սերվերների վրա¶

Cloud Security Group / UFW / iptables փակ Պորտ 80. ինչ-որ մեկը խստացրել է firewall-ը, որպեսզի թույլատրվի միայն միացք 443 (HTTPS), մոռանալով, որ RFC 8555 HTTP-01 վավերացումը միշտ սկսվում է պարզ HTTP 80 պորտից (չնայած այն կհետևի ա 301 վերահղում դեպի https:// նավահանգստի վրա 443)
** Կոտրված IPv6 (AAAA) Գրառում**. Ձեր տիրույթն ունի և՛ IPv4 (A) գրառում և IPv6 (AAAA) արձանագրել. Եկեք գաղտնագրենք **միշտ նախընտրում է IPv6 (AAAA) առաջին **. Եթե ձեր IPv6 հասցեն սխալ ուղղորդված է, արգելափակված է ip6tables, կամ կապված չէ Nginx-ում (listen [::]:80;), վավերացման ժամկետները սպառվում են, չնայած IPv4-ը լավ է աշխատում:
** Nginx / հավելվածի երթուղիչ (React / Next.js / Django / Rails) ընդհատումներ /.well-known/acme-challenge/**: Ձեր server արգելափակել 80 նավահանգստի վստահված անձանց ամբողջ երթևեկությունը (location / { proxy_pass http://localhost:3000; }) սպասարկելու փոխարեն հետին պլանի հավելվածին .well-known սկավառակից։

Երկու ակնթարթային շտկում կոտրվածների համար `HTTP-01` վավերացում¶

Ուղղել 1. Ավելացնել հատուկ բարձր առաջնահերթություն `/.well-known/acme-challenge/` արգելափակել Nginx-ում (Պորտ 80)¶

Համոզվեք, որ ձեր նավահանգիստը արգելափակված է 80-ում /etc/nginx/sites-enabled/ ծառայում է ACME խորհրդանիշներին անմիջապես /var/www/letsencrypt նախքան ցանկացած return 301 https://... կամ proxy_pass հրահանգ:

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. Շրջանցել Port 80-ը և վեբ սերվերները ամբողջությամբ ձեռնարկի միջոցով `DNS-01` (`TXT`) մարտահրավեր¶

Եթե 80 նավահանգիստն արգելափակված է հոսանքին հակառակ ISP/firewall-ի կողմից կամ ձեր բեռի հավասարակշռիչը չի կարող երթուղի անցնել .well-known մի քանի backend հանգույցների համար, վավերացրեք DNS-ի միջոցով 2 րոպեում.

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

Certbot-ը կդադարեցնի և կցուցադրի. Please deploy a DNS TXT record under the name: _acme-challenge.example.com with the following value: XyZ123... 1. Բացեք ձեր DNS վահանակը և ստեղծեք TXT ռեկորդը _acme-challenge հետ ա 60 երկրորդ TTL. 2. Սպասեք և հաստատեք երկրորդ տերմինալի պատուհանում նախքան Enter սեղմելը:

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

3. Մի անգամ dig տպում է ձեր ճշգրիտ նշանի տողը, սեղմեք Enter Certbot-ում: Ձեր վկայականը և անձնական բանալին կգրվեն /etc/letsencrypt/live/example.com/ անմիջապես. (Խափանումը լուծվելուց հետո տեղադրեք ավտոմատացված DNS հավելվածը, ինչպիսին է python3-certbot-dns-cloudflare կամ python3-certbot-dns-route53 այնպես որ ապագա թարմացումները ձեռքով չեն պահանջում TXT մուտք.)

Փուլ 6. Վերականգնումից հետո ստուգում (միջանկյալ շղթա, OCSP stapling և CDN մաքրում)¶

Արտակարգ իրավիճակների վկայականի փոխարինումից հետո տարածված սխալ cert.pem (միայն թերթիկի վկայականը) փոխարեն fullchain.pem (տերեւային վկայական + միջանկյալ CA վկայագիր): Սեղանի բրաուզերներ (Chrome, Firefox) հաճախ քողարկում են բացակայող միջանկյալ վկայականը AIA-ի միջոցով (Authority Information Access) հետապնդում կամ պահում է միջանկյալ նյութեր, մինչդեռ curl, Python, OpenSSL, Android հավելվածները և Stripe/Twilio վեբ-կեռիկներն անմիջապես ձախողվում են unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

Հաստատեք, որ ձեր սերվերն ուղարկում է միջանկյալ ամբողջ շղթան (fullchain.pem): Վազել:
```
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | grep -E "Verify return code|depth="
```
Դուք պետք է տեսնեք առնվազն երկու մակարդակ (depth=0 ձեր տիրույթը և depth=1 միջանկյալ CA, ինչպիսիք են Let's Encrypt E5/R11 կամ ZeroSSL RSA Domain Secure Site CA) և Verify return code: 0 (ok). Եթե տեսնեք Verify return code: 21 (unable to verify the first certificate), փոխեք ձեր վեբ սերվերի կազմաձևը cert.pem դեպի fullchain.pem.
** Մաքրել հնացած OCSP Stapling քեշը Nginx / Apache-ում **: Եթե ssl_stapling on; միացված է, վերաբեռնեք վեբ սերվերը և ստուգեք openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
Կարգավորեք բազմաշերտ SSL-ի ժամկետանց մոնիտորինգը (արտաքին TCP ստուգում + Պրոմեթևս blackbox_exporter): Երբեք մի ապավինեք բացառապես էլփոստի հիշեցումներին (Եկեք գաղտնագրենք դադարեցված ժամկետի ավարտի հիշեցման նամակները 2025 թվականին): Դիտեք կենդանի պորտ 443 վարդակից արտաքինից (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) և սահմանեք ամենօրյա քրոնի ստուգում sudo certbot renew --dry-run.

Տարածաշրջանային արտակարգ իրավիճակների համարներ և գործակալությունների արձանագրություններ¶

Թեև ժամկետանց TLS վկայականը սովորաբար լուծվում է ինժեներական թիմերի կողմից, վկայագրի խափանումը, որը խախտում է առողջապահական պորտալները, արտակարգ իրավիճակների ուղարկման վեբ-կեռիկներ, բանկային նույնականացում կամ պետական հանրային ենթակառուցվածք, կարող է առաջացնել կարգավորիչ միջադեպերի աշխատանքային հոսքեր.

Միացյալ Նահանգներ և Կանադա:
Կյանքի անվտանգություն / Կլինիկական / Դիսպետչերական անջատում. հավաքեք 911 եթե TLS վկայականի խափանումը խանգարում է հիվանդի հեռաչափությունը, էլեկտրոնային դեղատոմսը կամ շտապ օգնություն ուղարկելը:
Կիբերանվտանգության և ենթակառուցվածքների անվտանգության գործակալություն (CISA) (ԱՄՆ). CISA պարտադիր գործառնական հրահանգի (BOD) 18-01 համաձայն դաշնային քաղաքացիական գործակալությունները և կրիտիկական ենթակառուցվածքի օպերատորները, որոնք ենթարկվում են չարտոնված վկայականի թողարկման (CA-ի խախտում կամ BGP/DNS առևանգում) պետք է զեկուցեն 1-844-Say-CISA (1-844-729-2472) կամ cisa.gov/report.
Կիբերանվտանգության կանադական կենտրոն. Կապ 1-833-CYBER-88 (1-833-292-3788).
Միացյալ Թագավորություն:
Շտապ օգնության ծառայություններ. հավաքեք 999 եթե TLS-ի անջատումը ազդում է NHS-ի կարևոր կլինիկական համակարգերի կամ կյանքի անվտանգության վրա:
Կիբերանվտանգության ազգային կենտրոն (NCSC). Եթե ձեր տիրույթի համար տրված չթույլատրված վկայական հայտնաբերեք Վկայագրի թափանցիկությունում (crt.sh) տեղեկամատյաններ, որոնք ցույց են տալիս DNS-ի առևանգում, հաղորդում միջոցով ncsc.gov.uk.
Եվրամիություն:
Շտապ օգնության ծառայություններ. հավաքեք 112 ԵՄ անդամ բոլոր երկրներում:
** NIS2 դիրեկտիվ և eIDAS-ի որակավորված վեբ կայքի նույնականացման վկայագրեր (QWACs)**. NIS2 Հրահանգի հիմնական և կարևոր կազմակերպությունները, որոնք ունեն երկարատև հասանելիության խափանում կամ վնասված PKI բանալիները, պետք է ծանուցեն իրենց ազգային CSIRT-ին 24 ժամվա ընթացքում:
Ավստրալիա և Նոր Զելանդիա:
Շտապ օգնության ծառայություններ. հավաքեք 000 Ավստրալիայում կամ 111 Նոր Զելանդիայում; կապվեք ACSC-ի հետ (1300 CYBER1) ենթակառուցվածքային միջադեպերի համար:
Հնդկաստան և Ասիա-Խաղաղօվկիանոսյան:
** Հնդկաստան (CERT-In / Հավաստագրող մարմինների վերահսկիչ CCA)**: Հավաքեք 112 արտակարգ իրավիճակների արձագանքման համար; զեկուցել PKI-ի վտանգի կամ ենթակառուցվածքի զգալի խափանումների մասին incident@cert-in.org.in 6 ժամվա ընթացքում:

Հաճախակի տրվող հարցեր¶

Ինչո՞ւ ես կամ իմ օգտատերերը չենք կարող սեղմել «Ընդլայնված -> Անցնել կայք (անապահով)» Chrome-ում կամ Safari-ում այս անջատման ժամանակ:¶

Երբ ձեր տիրույթը ուղարկում է Խիստ-Տրանսպորտ-Անվտանգություն (HSTS) HTTP վերնագիր - կամ օգտագործում է վերին մակարդակի տիրույթ, ինչպիսին է .dev, .app, .էջ, կամ .բանկ որը կոշտ կոդավորված է զննարկիչի HSTS Preload List-ում. RFC 6797-ը պահանջում է, որ զննարկիչը ցանկացած ժամկետանց, ինքնստորագրված կամ անհամապատասխան վկայական վերաբերվի որպես չվերականգնվող ճակատագրական սխալի: Զննարկիչը միտումնավոր հեռացնում է «Ամեն դեպքում շարունակել» շրջանցման կոճակը՝ կանխելու ակտիվ Man-in-the-Middle (MitM) հարձակվողներին խաբել օգտատերերին՝ սեղմելով կեղծ վկայականը: Մինչ աշխատասեղանի Chrome-ի մշակողը կարող է մուտքագրել թաքնված ստեղնաշարի հաջորդականությունը սա անապահով է ուղղակիորեն սխալի էկրանին, որպեսզի շրջանցեն այն տեղական փորձարկման համար, իրական օգտվողները չեն կարող. դուք պետք է վավեր վկայական տեղադրեք 443 նավահանգստում:

Եկեք Encrypt-ը դադարեցրեց ժամկետի ավարտի մասին նախազգուշացնող նամակներ ուղարկելը, և իմ վկայականը սպառվեց առանց ծանուցման. ինչու՞ դա տեղի ունեցավ:¶

Եկեք Encrypt-ը պաշտոնապես դադարեցրեց իր ժամկետի ավարտի մասին ծանուցման էլփոստի ծառայությունը 2025 թվականի կեսերին՝ նվազեցնելու տվյալների պահպանման ծախսերը, և քանի որ ավտոմատացված ACME կարգավորումները պետք է ուղղակիորեն վերահսկեն նորացման առողջությունը: Ապագայում անակնկալներ կանխելու համար դուք պետք է վերահսկեք իրական TLS ձեռքսեղմման ժամկետի լրանալու ժամանակի դրոշմակնիքը՝ օգտագործելով արտաքին ժամանակի մոնիտորը (օրինակ՝ Պրոմեթևսը blackbox_exporter, Uptime Kuma, Better Stack կամ Datadog Synthetic TLS ստուգումներ) ծանուցում 21 օր, 14 օր և 7 օր առաջ ոչ հետո.

Ինչու է իմ կայքը լավ աշխատում Chrome-ում և Firefox-ում իմ նոութբուքի վրա, բայց ձախողվում է Android հեռախոսներում, `curl`, իսկ Stripe-ը վեբկապե՞ց այն բանից հետո, երբ ես թարմացրի վկայագիրը:¶

Դուք կարգավորել եք ձեր վեբ սերվերը (ssl_certificate Նգինքսում կամ SSLCertificateFile Apache-ով) մատնանշել cert.pem (միայն թերթիկի վկայականը) փոխարեն fullchain.pem (տերևի վկայականը միացված է միջանկյալ CA վկայականին): Սեղանի բրաուզերները, ինչպիսիք են Chrome-ը և Firefox-ը, ավտոմատ կերպով ներբեռնում են բացակայող միջանկյալ վկայագրերը հետին պլանում՝ օգտագործելով Իշխանության տեղեկատվության հասանելիություն (AIA) URL ձեր թերթիկի վկայագրի ներսում՝ թաքցնելով ձեր սերվերի սխալ կազմաձևումը: Այնուամենայնիվ, գանգուր, OpenSSL-ը, Android-ի համակարգի վստահության ստուգիչը, Python-ը և webhook սերվերները չեն իրականացնում AIA հետապնդում և անմիջապես մերժում են կապը չի կարող ստանալ տեղական թողարկողի վկայականը. Ուղղեք ձեր կազմաձևը fullchain.pem և վերաբեռնեք ձեր սերվերը:

Ինչպե՞ս կարող եմ ստուգել, արդյոք հաքեր կամ խարդախ ադմինիստրատորը թողարկել է չարտոնված SSL վկայագիր իմ տիրույթի համար:¶

Հանրության կողմից վստահված սերտիֆիկատների մարմիններից պահանջվում է գրանցել յուրաքանչյուր տրված վկայականը հանրությանը Վկայագրի թափանցիկության (CT) տեղեկամատյաններ (RFC 6962), նախքան բրաուզերները կվստահեն դրան: Բաց https://crt.sh/?q=%25.yourdomain.com կամ Cloudflare's Certificate Transparency Monitor՝ դիտելու ձեր տիրույթի և դրա ենթադոմեյնների համար երբևէ տրված բոլոր վկայականները: Եթե տեսնում եք անծանոթ CA-ի կողմից տրված վկայագիր, որը դուք չեք լիազորել, անհապաղ ստուգեք ձեր DNS ռեգիստրը և հեղինակավոր DNS գոտին չարտոնված փոփոխությունների համար, չեղարկեք ապօրինի վկայականը թողարկող CA-ի հետ և կողպեք ձեր DNS-ը CAA գրառումներ (`0 issue "letsencrypt.org"`)

Իսկ եթե իմ Kubernetes կլաստերը լինի `cert-manager` Չհաջողվեց թարմացնել մեր մուտքի վկայականը, և Պատվերը խրված է `Pending`?¶

Վազիր kubectl ստանալ պատվեր,մարտահրավեր -Ա իսկ հետո kubectl-ը նկարագրում է մարտահրավեր <մարտահրավեր-անուն> -n . Kubernetes-ի 90 տոկոսում վկայական-մենեջեր անջատումներ, ը սմ-ակմե-http-լուծիչ-* ժամանակավոր պատիճն աշխատում է, բայց կամ (1) Ingress ռեսուրսն ունի հնացած մուտքի դասի անոտացիա, այնպես որ լուծիչի երթուղին երբեք միացված չէ ձեր բեռի հավասարակշռողին, (2) Kubernetes Ցանցային քաղաքականություն արգելափակում է մուտքային երթևեկությունը դեպի լուծիչի պատիճ 8089 նավահանգստի վրա, կամ (3) սանրվածքի NAT / split-horizon DNS-ի խնդիրը կանխում է վկայական-մենեջերներքին ինքնաստուգում ձեր հանրային բեռնաչափի IP-ին հասնելու համար (շտկվում է անցնելով --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 դեպի վկայական-մենեջեր տեղակայման արկեր):

Կարող եմ պատճենել իմ `/etc/letsencrypt/` Թղթապանակ նոր սերվերի՞ն շտապ միգրացիայի ժամանակ՝ վերաթողարկման փոխարեն:¶

Այո՛։ Եթե ձեր հիմնական սերվերը մահացել է, և դուք տեղափոխվում եք նոր սերվեր, մինչդեռ արագությունը սահմանափակված է Let's Encrypt-ի կողմից, պահպանեք սիմհղումները պատճենելիս: /etc/letsencrypt/ օգտագործելով tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (երբեք մի օգտագործեք պարզ scp -r, որը վերածում է symlinks-ը /etc/letsencrypt/live/ կրկնօրինակ ստատիկ ֆայլերի մեջ և խախտում ապագա նորացումները): Արտահանեք այդ արխիվը նոր սերվերի վրա (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), կետ Nginx/Apache դեպի `/etc/letsencrypt/live/domain/fullchain.pem`, և ձեր առկա վկայականը անմիջապես կաշխատի նոր IP հասցեի վրա:

Առնչվող ուղեցույցներ¶

Աղբյուրներ և պաշտոնական ուղեցույց¶

Ինտերնետ ճարտարագիտության աշխատանքային խումբ (IETFRFC 8555 (Վկայականի կառավարման ավտոմատ միջավայր / ACME), RFC 8659 (DNS սերտիֆիկացման մարմնի թույլտվություն / CAA) և RFC 6797 (HTTP խիստ տրանսպորտային անվտանգություն / HSTS):
Ստանդարտների և տեխնոլոգիաների ազգային ինստիտուտ (NIST) (ԱՄՆ).
Ինտերնետ անվտանգության հետազոտական խումբ (ISRG / Եկեք գաղտնագրենք պաշտոնական փաստաթղթերը.
Կիբերանվտանգության և ենթակառուցվածքների անվտանգության գործակալություն (CISA) (ԱՄՆ).
Կիբերանվտանգության ազգային կենտրոն (NCSC) (Միացյալ Թագավորություն).

Արտադրության SSL/TLS վկայագրի ժամկետը լրացել է. շտկել HSTS-ի կոշտ ձախողումները և եկեք ծածկագրենք CAA/Rate-Limit բլոկները¶

Արեք սա հիմա¶

Որոշման ծառ. ախտորոշում և ամրագրում է ժամկետանց արտադրության SSL/TLS վկայագիրը¶

Փուլ 1. Հասկանալով, թե ինչու HSTS (Strict-Transport-Security) առաջացնում է ամբողջական խափանում¶

Փուլ 2. 60 վայրկյան ախտորոշում. Արդյո՞ք վկայագիրը իրականում արդեն թարմացվել է սկավառակի վրա:¶

Քայլ 1. Համեմատեք ուղիղ ցանցի վարդակը սկավառակի վրա գտնվող ֆայլի հետ¶

Քայլ 2. Ուղղեք 4 սովորական «Նորացված է սկավառակի վրա, ժամկետանց RAM-ում» ծուղակները¶

Փուլ 3. DNS-ի շտկում CAA ռեկորդային բլոկներ և DNSSEC վավերացման ձախողումներ¶

1. Ինչպես DNS CAA (RFC 8659) արգելափակում է վկայագրի նորացումը¶

Ախտորոշիչ և ակնթարթային շտկում CAA բլոկներ:¶

2. Ամրագրում DNS problem: SERVFAIL looking up CAA (DNSSEC անհամապատասխանություն)¶

Փուլ 4. շրջանցելով Եկեք գաղտնագրենք տոկոսադրույքի սահմանները (429 Too Many Requests) ակտիվ անջատման ժամանակ¶