Skip to content

Мӯҳлати шаҳодатномаи истеҳсолии SSL/TLS ба охир расид: Ислоҳи қатъи нокомии HSTS ва биёед блокҳои CAA/Меъёриро рамзгузорӣ кунем

Рақамҳои ёрии таъҷилӣ вобаста ба кишвар фарқ мекунанд. Ин саҳифа 911-ро истифода мебарад, рақам барои Иёлоти Муттаҳида ва Канада. Бисёре аз кишварҳои дигар 112, 999 ё рақами дигарро истифода мебаранд. Рақами кишвари худро пайдо кунед.

Вақте ки истеҳсоли SSL/TLS (HTTPS) мӯҳлати сертификат ба охир мерасад - ҳатто як сония гузаштани он notAfter Тамғаи вақти UTC - ҳар як браузери муосир (Chrome, Safari, Firefox, Edge), барномаи мобилӣ (iOS App Transport Security, Android Network Security Config), қабулкунандаи вебхук (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 тугмаи гузариши "Advanced -> Гузаштан ба сайт (хатарнок)"-ро комилан хориҷ мекунанд, ки дар натиҷа барои ҳар як корбар дар саросари ҷаҳон 100% нокомӣ мешавад. Аксар вақт, cronjob навсозии автоматӣ (Certbot, acme.sh, Caddy, cert-manager, ё AWS ACM) аз сабаби DNS маҳдудкунанда дар тӯли 30 рӯз хомӯшона ноком мешавад CAA сабт, як DNSSEC шикаста DS сабт, бандари бастани девор 80 (HTTP-01 мушкилот) ё сервери веб (nginx / haproxy) ки файлро дар диск нав кард (fullchain.pem) аммо ҳеҷ гоҳ равандҳои коргари дар хотираи худро дубора бор накардааст. Агар қатъи шумо на аз худи сертификати X.509 бақайдгирии мӯҳлати гузаштаи домен ё рабудашудаи ном-серверҳо ба амал омада бошад, фавран ба дуздии номи домен, DNS-и мӯҳлаташ гузашта ва гирифтани вебсайт; агар сервери шумо комилан дастнорас бошад ё фазои диск холӣ бошад certbot навишта наметавонад /etc/letsencrypt, бинед диски сервер 100% пурра ва барқарорсозии фазои сифр ё бӯҳрони хостинги веб, муҳоҷират ва барқарорсозии нусхабардорӣ. Агар ин қатъшавии TLS телеметрияи беморхона, API-ҳои фиристодани ҳолати фавқулодда ё инфрасохтори амнияти ҷамъиятиро ғайрифаъол созад, ба рақами фавқулоддаи маҳаллии худ занг занед (911 дар Иёлоти Муттаҳида ва Канада, 112 дар саросари Иттиҳоди Аврупо, 999 дар Британияи Кабир) ё ба феҳристи байналмилалии мо муроҷиат кунед рақамҳои фавқулодда.

Ҳоло ин корро кунед

  1. Дар 10 сония санҷед, ки оё сертификат дар диск воқеан нав карда шудааст ва веб-сервери шумо ё мувозинати сарбории шумо онро ба RAM дубора бор карда натавонист:
  2. Васлаки зиндаи 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
    
  3. Агар файл дар диск ояндаи дурустро нишон диҳад 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 сония хотима меёбад.
  4. Дававед certbot renew --force-renewal такроран дар як давр, агар навсозӣ ноком шавад: Let's Encrypt маҳдудияти қатъии меъёри 5 сертификати такрорӣ дар 7 рӯз ва 5 санҷиши ноком барои як ҳисоб, як номи мизбон, дар як соат ҷорӣ мекунад. Давидан --force-renewal панч маротиба дар вохима бе ислохи асосй nginx дубора бор кунед ё хатои DNS/сипар домени шуморо аз додани Let's Encrypt то 7 рӯз маҳкам мекунад.
  5. Агар шумо ба Лимити Меъёри Рамзгузорӣ (429 Too Many Requests), муштарии ACME-и худро ба мақоми дуюми ҷамъиятии сертификатсияҳо иваз кунед (ZeroSSL, Buypass Go SSL, ё Google Trust Services) ё илова кардани зердомени SAN фавран:
  6. Ҳар як муштарии ACME (certbot, acme.sh, caddy, cert-manager) метавонад дар давоми 30 сония аз CA-и дигар сертификати боэътимоди ройгонро талаб кунад (--server https://acme.zerossl.com/v2/DV90 ё https://api.buypass.com/acme/directory), комилан канорагирӣ аз маҳдудияти суръати Let's Encrypt.
  7. Интихобан, маҳдудияти "5 сертификатҳои такрорӣ дар 7 рӯз" -и Let's Encrypt танҳо ба маҷмӯи ҳамон номҳои алтернативии субъектҳо (SANs). Илова кардани як зердомени эътибори иловагӣ (-d example.com -d www.example.com -d tlsfix1.example.com) онро шаҳодатномаи такрорнашаванда месозад ва маҳдудияти меъёри Шаҳодатномаи такрориро фавран убур мекунад.
  8. ** Санҷед, ки оё DNS CAA рекорд ё шикаста DNSSEC Макомоти сертификатсияи шуморо аз додани (CAA record for example.com prevents issuance)**:
  9. Дар бораи ваколати Сертификатсияи домени худ пурсед (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-и худ.
  10. ** Агар порт 80 (HTTP-01 мушкилот) аз ҷониби брандмауэр, CDN ё ISP баста шудааст ё агар веб-сервери шумо бо сабаби набудани сертификат оғоз карданро рад кунад, истифода баред --standalone ё --dns (DNS-01) тасдиқи**:
  11. Истед nginx/apache мухтасар ва давидан sudo certbot certonly --standalone -d example.com, ё истифода баред --manual --preferred-challenges dns бо гузоштан тасдиқ кардан а _acme-challenge.example.com TXT ба консоли DNS-и худ бидуни ламс кардани порт сабт кунед 80.
  12. Агар сайти шумо дар паси Cloudflare, AWS CloudFront ё Fastly ҷойгир бошад, санҷед, ки сертификати мӯҳлаташ гузашта дар CDN Edge ё дар сервери Origin (Error 526 Invalid SSL Certificate):
  13. Дар Cloudflare, агар сертификати сервери ибтидоии шумо ба охир расад ва Cloudflare муқаррар карда шавад Full (Strict), корбарон Хатои 526-ро мебинанд. Ҳангоми ислоҳ кардани шаҳодатномаи пайдоиш, шумо метавонед трафики зиндаи сайтро дар тӯли 5 сония тавассути тавлиди шаҳодатномаи 15-солаи Cloudflare Origin CA дар панели Cloudflare барқарор кунед (ё муваққатан иваз кардани режими SSL/TLS аз Full (Strict) ба Full барои 10 дақиқа иваз кардани ибтидо лозим аст .pem файл).

Danger

Ҳеҷ гоҳ кӯшиш накунед, ки қуфлбандии пешакии HSTS-ро тавассути танзим "ислоҳ" кунед Strict-Transport-Security: max-age=0 дар ҳоле ки мӯҳлати шаҳодатномаи SSL/TLS-и шумо ҳанӯз ба охир расидааст: RFC 6797 ба таври возеҳ ба браузерҳо коркард ё эҳтиром кардани ҳама гуна маълумотро манъ мекунад Strict-Transport-Security сарлавҳа (аз ҷумла max-age=0) тавассути пайвасти TLS беэътимод, худ имзошуда ё мӯҳлаташ гузашта ё аз болои оддӣ HTTP. Ғайр аз он, агар домени шумо дошта бошад includeSubDomains; preload ба рӯйхати пешакии статикии HSTS Chromium/Firefox/Safari тартиб дода шудааст, ҳатто max-age=0 бар пайвасти дуруст парчами пешакиро барои меҳмонони бори аввал нест намекунад. Ягона роҳи барқарор кардани дастрасӣ ба домени аз ҷониби HSTS қулфшуда насб кардани сертификати боэътимоди X.509 дар порти 443 мебошад.


Дарахти қарор: ташхис ва ислоҳ кардани шаҳодатномаи истеҳсолии 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 домен -пайваст кардани домен:443 | openssl x509 -noout -санаҳои - эмитент"]

    CheckLive --> WhereExpired{"Кадом сертификат воқеан гузаштааст?"}

    WhereExpired -->|"Диски fullchain.pem ЭЪТИБОР АСТ, Аммо Порти Зиндагӣ 443 Мӯҳлаташ гузаштааст"| StaleDaemon["Хотираи кӯҳнаи Демон ё Дӯкони сертификатсия: 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 fullchain.pem дар диск ба охир расид"| DryRun["Иҷро кунед: sudo certbot renew --dry-run (ё acme.sh --renew -d домен --debug)"]

    DryRun --> WhyFailed{"Чаро навсозии ACME ноком шуд?"}

    WhyFailed -->|"429 Дархостҳои аз ҳад зиёд (Меъёри меъёр гузаштааст)"| RateLimit["Ба таври фаврӣ гузаред: Масъала аз ZeroSSL / Buypass / Google Trust Services Ё илова 1 зердомени иловагии SAN (-d fix1.example.com)"]
    WhyFailed -->|"Сабти CAA аз додани ё SERVFAIL (DNSSEC) пешгирӣ мекунад"| CAADNS["Иҷро кунед: dig CAA example.com -> Иловаи 0 нашри 'letsencrypt.org' (ва 'sectigo.com') ё Ислоҳи сабти вайроншудаи DNSSEC DS дар Бақайдгиранда"]
    WhyFailed -->|"Пайвастшавӣ рад карда шуд / Вақтхушӣ / 404 дар /.well-known/acme-challenge/"| HttpBlock["Порти 80 басташуда ё масири масир: Порти TCP 80-ро дар Сипар кушоед, /.well-known/-ро аз Auth/Rewrite хориҷ кунед ё даъвати DNS-01-ро истифода баред"]
    WhyFailed -->|"Фармоиши менеҷери сертификати Kubernetes дар интизор аст"| K8sFix["Иҷро кунед: kubectl даъватро тавсиф кунед -> Аннотацияи синфи Ingress, сиёсати шабакаи ҳалкунандаи HTTP01 ё Webhook TLS-ро тафтиш кунед"]

    StaleDaemon --> VerifyAll["Тасдиқи занҷир ва Stapling OCSP: openssl s_client -connect домен:443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Марҳилаи 1: Фаҳмидани чаро HSTS (Strict-Transport-Security) боиси катъ шудани куллй мегардад

Вақте ки вебсайт HSTS-ро на истифода намебарад, шаҳодатномаи мӯҳлаташ гузашта огоҳии фосилавӣ (Your connection is not private) бо истиноди "Advanced -> Гузаштан ба 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 тасдиқи бо нобаёнӣ ва ҳеҷ консепсияи корбар "клик-through" надоранд. Ҳангоми қатъ шудани TLS, вебхукҳои Stripe ва Shopify интиқолро ноком мекунанд ва ба навбатҳои такрории экспоненсиалӣ ворид мешаванд.


Марҳилаи 2: Ташхиси 60 сония - Оё шаҳодатнома воқеан дар диск нав карда шудааст?

Тақрибан дар 35 фоизи истеҳсолот Биёед Қатъҳоро рамзгузорӣ кунем, сертификат воқеан дар диск ҳафтаҳо пеш аз ҷониби навсозӣ карда шуд. 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-* плагин) ба ҷои --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
Аломати шикаста дар /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-ро аз нав бор кунед.
** Контейнери Docker (nginx / traefik / postfix)** OS мизбон нав карда шуд /etc/letsencrypt/archive/example.com/fullchain4.pem ва истинодро навсозӣ кард, аммо контейнери Docker inode-и ягонаи файлро пайваст мекунад (ки ҷудошуда/иваз карда шудааст) ё раванди контейнер дар дохили фазои ном ҳеҷ гоҳ гирифта нашудааст SIGHUP. Ҳамаро пайваст кунед /etc/letsencrypt директория (ҳеҷ гоҳ ягона .pem файл, зеро ҳадафҳои рамзӣ ҳангоми навсозӣ тағир меёбанд) ва иҷро кунед 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 блокҳо:

  1. Санҷед CAA сабтҳоро ҳам дар номи мизбон ва ҳам домени apex:
    dig +short CAA sub.example.com
    dig +short CAA example.com
    
  2. Ҳамчунин тафтиш кунед, ки оё sub.example.com а аст CNAME ба домени дигар ишора мекунад (Тибқи RFC 8659, CAҳо инчунин CAA сабтҳо дар бораи ҳадафҳои CNAME).
  3. Дар панели провайдери 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"
    
  4. (Эзоҳ: ZeroSSL истифода мебарад sectigo.com ҳамчун идентификатори асосии CAA ва Google Trust Services истифода мебарад pki.goog.)*
  5. 60 сония мунтазир бошед, то серверҳои номҳои бонуфузи шумо навсозӣ шаванд (dig @ns1.yourdns.com CAA example.com) ва фавран аз нав кор кардан sudo certbot renew. Азбаски CA-ҳо ҳангоми кӯшиши такрорӣ ҷустуҷӯҳои рекурсивии мустақимро иҷро мекунанд, ки аз кэшҳои ҷамъиятӣ ҳангоми кӯшиши такрорӣ канорагирӣ мекунанд, эмиссия фавран муваффақ мешавад.

2. Ислоҳ DNS problem: SERVFAIL looking up CAA (DNSSEC номувофиқӣ)

Биёед рамзгузорӣ кунем, Google Trust Services ва ZeroSSL дар ҳама ҷустуҷӯҳои DNS (A, AAAA, TXT, ва CAA). Ҳатто агар домен дорои ** нест CAA сабт**, CA бояд криптографии эътибор гирад NOERROR (ҷавоби холӣ) ё NXDOMAIN (NSEC / NSEC3 радди тасдиқшудаи мавҷудият) ҷавоб. - Агар бақайдгирии домени шумо кӯҳна дошта бошад DS (Имзокунандаи ҳайат) пас аз интиқоли провайдерҳои 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 (беҳтарин): Мақодири сертификати ACME-ро ба ZeroSSL, Buypass ё Google Trust Services дар тӯли 30 сония иваз кунед

Протоколи ACME (RFC 8555) стандарти кушода аст. Ҳар як браузери асосӣ ва системаи амалиётӣ ба ZeroSSL (Sectigo root), Buypass Go SSL (Norwegian CA) ва Google Trust Services (pki.goog) айнан ба Let's Encrypt (ISRG Root X1). Ҳеҷ яке аз онҳо маҳдудиятҳои меъёрро бо Let's Encrypt мубодила намекунанд.

  • ** Варианти 1: Интишори фаврӣ тавассути Certbot бо истифода аз Buypass Go SSL (Ҳеҷ ҳисоб/калиди EAB лозим нест, эътибори 180 рӯз)**: (Эзоҳ: Buypass сертификатҳои бисёрдомениро то 5 SAN дастгирӣ мекунад, гарчанде ки аломати ваҳшӣ нестанд *.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 (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) маҷмӯи алифбои дақиқи номҳои ҳостҳои SAN-ро дар сертификат пайгирӣ мекунад, дар ҳоле ки маҳдудияти умумии домени ба қайд гирифташуда 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} маҷмӯи нави доменҳо мебошад, Бигзор Шифргузорем сертификатро фавран медиҳад.


Марҳилаи 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 рӯз пеш кор мекарданд, вайрон мешавад

  1. Гурӯҳи амнияти абрӣ / UFW / iptables бастаи Порт 80: Касе девори деворро сахт кард, то танҳо ба порт иҷозат диҳад 443 (HTTPS), фаромӯш кардани он, ки RFC 8555 HTTP-01 тасдиқ ҳамеша дар бандари оддии HTTP 80 оғоз мешавад (гарчанде ки он a 301 равона кардан ба https:// дар бандар 443).
  2. ** IPv6 шикаста (AAAA) Сабт**: Домени шумо ҳам IPv4 (A) сабт ва IPv6 (AAAA) сабт. Биёед рамзгузорӣ кунем ** ҳамеша IPv6-ро афзалтар медонад (AAAA) аввал**. Агар суроғаи IPv6-и шумо масир нодуруст бошад, аз ҷониби ip6tables, ё дар Nginx баста нашудаанд (listen [::]:80;), вақти тасдиқкунӣ тамом мешавад, гарчанде ки IPv4 хуб кор мекунад.
  3. ** 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: Порт 80 ва веб-серверҳоро бо дастур пурра аз байн баред DNS-01 (TXT) даъват

Агар бандари 80 аз ҷониби провайдери болооб/брандмауэр масдуд шуда бошад ё тавозуни сарбории шумо масир карда наметавонад .well-known ба гиреҳҳои сершумори пуштибонӣ, тавассути 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: Тафтиши пас аз барқарорсозӣ (Занҷири мобайнӣ, Stapling OCSP ва CDN Purge)

Хатогии маъмул пас аз иваз кардани шаҳодатномаи фавқулодда насб кардан аст 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 берунӣ + Prometheus 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 дучор мешаванд, бояд дар давоми 24 соат CSIRT-и миллии худро огоҳ созанд.
  • Австралия ва Зеландияи Нав:
  • Хизматҳои фавқулодда: Рақам 000 дар Австралия ё 111 дар Зеландияи Нав; бо ACSC тамос гиред (1300 CYBER1) барои ходисахои инфраструктура.
  • Ҳиндустон ва Осиё-Уқёнуси Ором:
  • ** Ҳиндустон (CERT-In / Назоратчии мақомоти сертификатсия CCA)**: Рақам 112 барои вокуниш ба ҳолати фавқулодда; дар бораи созиш ё қатъи назарраси инфрасохтори PKI хабар диҳед incident@cert-in.org.in дар давоми 6 соат.

Саволҳои зуд-зуд додашаванда

Чаро ман ё корбарони ман наметавонам дар ин қатъкунӣ дар Chrome ё Safari "Advanced -> Гузаштан ба сайт (хавфнок)" -ро клик кунем?

Вақте ки домени шумо мефиристад Қатъӣ-Нақлиёт-Бехатарӣ (HSTS) Сарлавҳаи HTTP - ё домени сатҳи болоро истифода мебарад .dev, .app, .саҳифа, ё .бонк ки дар браузери HSTS Preload List рамзгузорӣ шудааст - RFC 6797 аз браузер талаб мекунад, ки ҳама гуна шаҳодатномаи мӯҳлаташ гузашта, худ имзошуда ё номувофиқро ҳамчун хатои марговар баргардониданашаванда ҳисоб кунад. Браузер қасдан тугмаи "Ба ҳар ҳол идома диҳед" -ро хориҷ мекунад, то ҳамлагарони фаъоли Man-in-the-Middle (MitM)-ро аз фиреби корбарон барои пахш кардани сертификати қалбакӣ пешгирӣ кунанд. Дар ҳоле ки як таҳиягар дар мизи кории Chrome метавонад пайдарпайии клавиатураи пинҳониро нависед ин бехатар аст бевосита дар экрани хатогӣ барои гузаштан аз он ба таври маҳаллӣ барои санҷиш, корбарони воқеӣ наметавонанд; шумо бояд сертификати дурустро дар порти 443 насб кунед.

Let's Encrypt фиристодани мактубҳои огоҳкунандаи мӯҳлатро қатъ кард ва мӯҳлати сертификати ман бидуни огоҳӣ ба охир расид - чаро ин тавр шуд?

Биёед Encrypt хидмати почтаи электронии огоҳинома дар охири соли 2025-ро ба таври расмӣ истеъфо дод, то хароҷоти нигоҳдории маълумотро кам кунад ва азбаски танзимоти автоматии ACME бояд саломатии таҷдидро мустақиман назорат кунад. Барои пешгирии сюрпризҳои оянда, шумо бояд тамғаи воқеии анҷоми дастфишори дастфишори TLS-ро тавассути шабака бо истифода аз монитори берунии вақти корӣ (ба монанди Prometheus) назорат кунед. blackbox_exporter, Uptime Kuma, Better Stack ё Datadog Synthetic TLS чекҳои) огоҳӣ дар 21 рӯз, 14 рӯз ва 7 рӯз пеш аз он не Баъд аз.

Чаро сайти ман дар Chrome ва Firefox дар ноутбуки ман хуб кор мекунад, аммо дар телефонҳои Android ноком мешавад, curl, ва Webhooks Stripe пас аз навсозии сертификат?

Шумо веб-сервери худро танзим кардаед (ssl_certificate дар Nginx ё SSLCertificateFile дар Apache) ишора кардан cert.pem (танҳо шаҳодатномаи барг) ба ҷои fullchain.pem (шаҳодатномаи барге, ки бо шаҳодатномаи миёнаравии CA баста шудааст). Браузерҳои мизи корӣ ба монанди Chrome ва Firefox ба таври худкор сертификатҳои мобайнии гумшударо дар замина бо истифода аз Дастрасии иттилооти мақомот (AIA) URL дар дохили сертификати баргеи шумо, ки конфигуратсияи нодурусти сервери шуморо пинҳон мекунад. Бо вуҷуди ин, поймол кардан, OpenSSL, санҷиши эътимоди системаи Android, серверҳои Python ва вебхук таъқиби AIA-ро иҷро намекунанд ва пайвастшавиро фавран рад мекунанд шаҳодатномаи эмитенти маҳаллиро гирифта наметавонад. Конфигуратсияи худро ба он ишора кунед fullchain.pem ва сервери худро аз нав бор кунед.

Чӣ тавр ман метавонам тафтиш кунам, ки ҳакер ё маъмури фиребгар барои домени ман шаҳодатномаи SSL-и беиҷозат додааст?

Ҳар як мақомоти эътимодбахши сертификатсия вазифадор аст, ки ҳар як шаҳодатномаи додашударо ба омма сабт кунад Гузоришҳои шаффофияти сертификатҳо (CT). (RFC 6962) пеш аз он ки браузерҳо ба он эътимод кунанд. Кушода https://crt.sh/?q=%25.yourdomain.com ё Монитори шаффофияти сертификати Cloudflare барои дидани ҳар як сертификате, ки барои домени шумо ва зердоменҳои он дода шудааст, дидан кунед. Агар шумо шаҳодатномаи аз ҷониби CA-и ношинос додашударо бубинед, ки ба он иҷозат надодаед, фавран бақайдгирандаи DNS ва минтақаи бонуфузи DNS-и худро барои тағироти беиҷозат тафтиш кунед, шаҳодатномаи қаллобиро бо CA-и додашуда лағв кунед ва DNS-и худро бо ёрии он қулф кунед. CAA сабтҳо (`0 issue "letsencrypt.org"`).

Чӣ мешавад, агар кластери ман Kubernetes cert-manager шаҳодатномаи воридшавии моро нав карда натавонист ва фармоиш дар он часпидааст Pending?

Давидан kubectl фармоиш гирифта, даъват -А ва баъд kubectl мушкилотро тасвир мекунад -n . Дар 90 фоизи Кубернетес сертификат-мудир қатъ, cm-acme-http-halver-* поди муваққатӣ кор мекунад, аммо ё (1) манбаи Ingress дорои шарҳи кӯҳнаи синфи вуруд аст, бинобар ин, масири ҳалкунанда ҳеҷ гоҳ ба баланси сарбории шумо пайваст нашудааст, (2) Kubernetes Сиёсати шабакавӣ трафики воридшавиро ба подкали ҳалкунанда дар бандари 8089 бозмедорад ё (3) масъалаи NAT/уфуқи тақсимшудаи DNS пешгирӣ мекунад сертификат-мудирСанҷиши дохилии худ аз расидан ба IP тавозуни сарбории ҷамъиятии шумо (бо гузариш ислоҳ карда мешавад --dns01-recursive-nameservers = 8.8.8.8:53,1.1.1.1:53 ба сертификат-мудир густариши args).

Оё ман метавонам худро нусхабардорӣ кунам /etc/letsencrypt/ папка ба сервери нав ҳангоми муҳоҷирати фавқулодда ба ҷои дубора интишор кардан?

Бале. Агар сервери ибтидоии шумо фавтида бошад ва шумо ба сервери нав кӯчида истодаед, дар ҳоле ки суръати аз ҷониби Let's Encrypt маҳдуд аст, ҳангоми нусхабардорӣ истинодҳои рамзиро нигоҳ доред. /etc/letsencrypt/ истифода бурдан tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (ҳеҷ гоҳ оддӣ истифода набаред scp -r, ки истинодҳои символиро ба ворид месозад /etc/letsencrypt/live/ ба файлҳои статикии такрорӣ табдил дода, навсозии ояндаро вайрон мекунад). Он архивро ба сервери нав бароред (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), ишора ба Nginx/Apache `/etc/letsencrypt/live/domain/fullchain.pem`, ва сертификати мавҷудаи шумо фавран дар суроғаи нави IP кор мекунад.


Дастурҳои алоқаманд


Сарчашмаҳо ва роҳнамоии расмӣ

  • Гурӯҳи кории муҳандисии интернет (IETF): * RFC 8555 (Муҳити идоракунии худкори сертификатҳо / ACME), RFC 8659 (Authorization Authority Certification Authority / CAA) ва RFC 6797 (HTTP Strict Security Transport / HSTS)*.
  • Институти миллии стандартҳо ва технология (NIST) (Иёлоти Муттаҳида): Нашри махсуси 800-52 Ваҳй 2: Дастур оид ба интихоб, конфигуратсия ва истифодаи Амнияти қабати нақлиёт (TLS) татбиқ ва SP 1800-16: Амнияти транзаксияҳои веб: Идоракунии сертификати сервери TLS.
  • Гурӯҳи тадқиқоти амнияти интернет (ISRG / Биёед ҳуҷҷатҳои расмиро рамзгузорӣ кунем): Маълумот оид ба маҳдудиятҳои нарх, Қоидаҳои такрории сертификатҳо ва ҳалли мушкилоти ACME.
  • Агентии амнияти киберамният ва инфрасохтор (CISA) (Иёлоти Муттаҳида): Директиви ҳатмӣ оид ба амалиётӣ 18-01: Беҳтар кардани амнияти почтаи электронӣ ва веб (Роҳнамои татбиқи HTTPS ва HSTS).
  • Маркази миллии амнияти киберӣ (NCSC) (Подшоҳии Муттаҳида): Истифодаи TLS барои ҳифзи маълумоти комил дар транзит ва дастур оид ба мониторинги шаффофияти сертификатсия.