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 ಪ್ರಿಲೋಡ್ ಪಟ್ಟಿ, Chrome ಮತ್ತು Safari "ಸುಧಾರಿತ -> ಸೈಟ್‌ಗೆ ಮುಂದುವರಿಯಿರಿ (ಅಸುರಕ್ಷಿತ)" ಬೈಪಾಸ್ ಬಟನ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ಪ್ರಪಂಚದಾದ್ಯಂತ ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೆ 100 ಪ್ರತಿಶತ ಹಾರ್ಡ್-ಫೇಲ್ ಬ್ಲ್ಯಾಕೌಟ್ ಆಗುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಸ್ವಯಂಚಾಲಿತ ನವೀಕರಣ ಕ್ರೋನ್‌ಜಾಬ್ (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 ನವೀಕರಣ ವಿಫಲವಾದಲ್ಲಿ ಪದೇ ಪದೇ ಲೂಪ್‌ನಲ್ಲಿ**: ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಕಟ್ಟುನಿಟ್ಟಾದ ದರ ಮಿತಿಯನ್ನು ** 5 ನಕಲಿ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು 7 ದಿನಗಳಿಗೆ** ಮತ್ತು ** 5 ವಿಫಲವಾದ ಮೌಲ್ಯೀಕರಣಗಳನ್ನು ಪ್ರತಿ ಖಾತೆಗೆ, ಪ್ರತಿ ಹೋಸ್ಟ್ ಹೆಸರಿಗೆ, ಪ್ರತಿ ಗಂಟೆಗೆ** ಜಾರಿಗೊಳಿಸುತ್ತದೆ. ಓಡುತ್ತಿದೆ --force-renewal ಆಧಾರವನ್ನು ಸರಿಪಡಿಸದೆ ಪ್ಯಾನಿಕ್ನಲ್ಲಿ ಐದು ಬಾರಿ nginx ಮರುಲೋಡ್ ಅಥವಾ DNS/ಫೈರ್‌ವಾಲ್ ದೋಷವು ನಿಮ್ಮ ಡೊಮೇನ್ ಅನ್ನು 7 ದಿನಗಳವರೆಗೆ ಎನ್‌ಕ್ರಿಪ್ಟ್ ನೀಡುವಿಕೆಯಿಂದ ಲಾಕ್ ಮಾಡುತ್ತದೆ.
  5. ** ನೀವು ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ದರ ಮಿತಿಯನ್ನು ಹೊಡೆದರೆ (429 Too Many Requests), ನಿಮ್ಮ ACME ಕ್ಲೈಂಟ್ ಅನ್ನು ಎರಡನೇ ಉಚಿತ ಸಾರ್ವಜನಿಕ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರಕ್ಕೆ ಬದಲಿಸಿ (ZeroSSL, Buypass Go SSL, ಅಥವಾ Google Trust Services) ಅಥವಾ ಥ್ರೋಅವೇ ಸಬ್‌ಡೊಮೈನ್ SAN ಅನ್ನು ತಕ್ಷಣವೇ ಸೇರಿಸಿ**:
  6. ಪ್ರತಿ ACME ಕ್ಲೈಂಟ್ (certbot, acme.sh, caddy, cert-manager30 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಬೇರೆ CA ಯಿಂದ ಉಚಿತ ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಮಾಣಪತ್ರವನ್ನು ವಿನಂತಿಸಬಹುದು (--server https://acme.zerossl.com/v2/DV90 ಅಥವಾ https://api.buypass.com/acme/directory), ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್‌ನ ದರ ಮಿತಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೈಪಾಸ್ ಮಾಡುವುದು.
  7. ಪರ್ಯಾಯವಾಗಿ, ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್‌ನ "7 ದಿನಗಳಿಗೆ 5 ನಕಲಿ ಪ್ರಮಾಣಪತ್ರಗಳು" ಮಿತಿಯು ** ನಿಖರವಾದ ಅದೇ ವಿಷಯ ಪರ್ಯಾಯ ಹೆಸರುಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತದೆ (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. ನಿಮ್ಮ ಸೈಟ್ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್, AWS ಕ್ಲೌಡ್‌ಫ್ರಂಟ್ ಅಥವಾ ಫಾಸ್ಟ್‌ಲಿ ಹಿಂದೆ ಕುಳಿತಿದ್ದರೆ, ಅವಧಿ ಮೀರಿದ ಪ್ರಮಾಣಪತ್ರವು CDN ಎಡ್ಜ್‌ನಲ್ಲಿದೆಯೇ ಅಥವಾ ನಿಮ್ಮ ಮೂಲ ಸರ್ವರ್‌ನಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ (Error 526 Invalid SSL Certificate):
  13. ಕ್ಲೌಡ್‌ಫ್ಲೇರ್‌ನಲ್ಲಿ, ನಿಮ್ಮ ಮೂಲ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರದ ಅವಧಿ ಮುಗಿದಿದ್ದರೆ ಮತ್ತು ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಅನ್ನು ಹೊಂದಿಸಿದ್ದರೆ Full (Strict), ಬಳಕೆದಾರರು ದೋಷ 526 ಅನ್ನು ನೋಡುತ್ತಾರೆ. ನೀವು ಮೂಲ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸರಿಪಡಿಸುವಾಗ, ಕ್ಲೌಡ್‌ಫ್ಲೇರ್ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ 15-ವರ್ಷದ Cloudflare ಮೂಲ CA ಪ್ರಮಾಣಪತ್ರವನ್ನು ರಚಿಸುವ ಮೂಲಕ (ಅಥವಾ ತಾತ್ಕಾಲಿಕವಾಗಿ SSL/TLS ಮೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ನೀವು 5 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಲೈವ್ ಸೈಟ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಬಹುದು 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 Chromium/Firefox/Safari ಸ್ಟ್ಯಾಟಿಕ್ HSTS ಪೂರ್ವಲೋಡ್ ಪಟ್ಟಿಗೆ ಸಂಕಲಿಸಲಾಗಿದೆ, ಸಹ max-age=0 ಮಾನ್ಯವಾದ ಸಂಪರ್ಕದ ಮೂಲಕ ಮೊದಲ ಬಾರಿಗೆ ಭೇಟಿ ನೀಡುವವರಿಗೆ ಪ್ರಿಲೋಡ್ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ** HSTS-ಲಾಕ್ ಮಾಡಿದ ಡೊಮೇನ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಮರುಸ್ಥಾಪಿಸುವ ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ ಮಾನ್ಯವಾದ, ಸಾರ್ವಜನಿಕವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹವಾದ X.509 ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪೋರ್ಟ್ 443 ನಲ್ಲಿ ಸ್ಥಾಪಿಸುವುದು.**

ನಿರ್ಧಾರ ವೃಕ್ಷ: ಅವಧಿ ಮೀರಿದ ಉತ್ಪಾದನಾ SSL/TLS ಪ್ರಮಾಣಪತ್ರವನ್ನು ನಿರ್ಣಯಿಸುವುದು ಮತ್ತು ಸರಿಪಡಿಸುವುದು

ನಿಖರವಾದ ವೈಫಲ್ಯದ ಪದರವನ್ನು ಗುರುತಿಸಲು ಈ ನಿರ್ಧಾರ ವೃಕ್ಷವನ್ನು ಅನುಸರಿಸಿ (CDN ಎಡ್ಜ್ ವಿರುದ್ಧ ಮೂಲ ಡೀಮನ್ ಮೆಮೊರಿ ವಿರುದ್ಧ ACME ಚಾಲೆಂಜ್ ವಿರುದ್ಧ CA ದರ ಮಿತಿ) ಮತ್ತು ನಿಮಿಷಗಳಲ್ಲಿ HTTPS ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿ:

flowchart TD
    Start["ಬಳಕೆದಾರರು / API ಗಳು NET ವರದಿ ಮಾಡುತ್ತಿವೆ::ERR_CERT_DATE_INVALID ಅಥವಾ Cloudflare ದೋಷ 526"] --> CheckLive["ರನ್: openssl s_client -servername domain -connect domain:443 | openssl x509 -noout -dates -ವಿತರಕರು"]

    CheckLive --> WhereExpired{"ಯಾವ ಪ್ರಮಾಣಪತ್ರವು ವಾಸ್ತವವಾಗಿ ಅವಧಿ ಮೀರಿದೆ?"}

    WhereExpired -->|"Disk fullchain.pem ಮಾನ್ಯವಾಗಿದೆ, ಆದರೆ ಲೈವ್ ಪೋರ್ಟ್ 443 ಅವಧಿ ಮೀರಿದೆ"| StaleDaemon["ಸ್ಟಾಲ್ ಡೀಮನ್ ಮೆಮೊರಿ ಅಥವಾ ಸ್ಪ್ಲಿಟ್ ಸರ್ಟ್ ಸ್ಟೋರ್: nginx / apache2 / haproxy / postfix ಅನ್ನು ಮರುಲೋಡ್ ಮಾಡಿ, ಅಥವಾ ಸಂಯೋಜಿತ HAProxy PEM ಬಂಡಲ್ ಅನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಿ"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) ಅವಧಿ ಮುಗಿದಿದೆ"| CDNFix["CDN CA ಗಾಗಿ DNS CAA ದಾಖಲೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ (letsencrypt.org / pki.goog / digicert.com / amazon.com) ಮತ್ತು ಯುನಿವರ್ಸಲ್ SSL ಅನ್ನು ಟಾಗಲ್ ಮಾಡಿ ಅಥವಾ ACM ಅನ್ನು ಮರು-ಮೌಲ್ಯಗೊಳಿಸಿ"]
    WhereExpired -->|"ಡಿಸ್ಕ್‌ನಲ್ಲಿನ ಮೂಲ ಸರ್ವರ್ fullchain.pem ಅವಧಿ ಮೀರಿದೆ"| DryRun["ರನ್: sudo certbot renew --dry-run (ಅಥವಾ acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"ACME ನವೀಕರಣ ಏಕೆ ವಿಫಲವಾಗಿದೆ?"}

    WhyFailed -->|"429 ಹಲವಾರು ವಿನಂತಿಗಳು (ದರ ಮಿತಿ ಮೀರಿದೆ)"| RateLimit["ತಕ್ಷಣವೇ ಬೈಪಾಸ್ ಮಾಡಿ: ZeroSSL / ಬೈಪಾಸ್ / Google ಟ್ರಸ್ಟ್ ಸೇವೆಗಳಿಂದ ಸಂಚಿಕೆ ಅಥವಾ 1 ಹೆಚ್ಚುವರಿ ಸಬ್‌ಡೊಮೈನ್ SAN ಸೇರಿಸಿ (-d fix1.example.com)"]
    WhyFailed -->|"CAA ರೆಕಾರ್ಡ್ ನೀಡಿಕೆ ಅಥವಾ ಸರ್ವ್‌ಫೇಲ್ (DNSSEC) ಅನ್ನು ತಡೆಯುತ್ತದೆ"| CAADNS["ರನ್: ಡಿಗ್ CAA example.com -> 0 ಸಂಚಿಕೆ ಸೇರಿಸಿ 'letsencrypt.org' (ಮತ್ತು 'sectigo.com') ಅಥವಾ ರಿಜಿಸ್ಟ್ರಾರ್‌ನಲ್ಲಿ ಮುರಿದ DNSSEC DS ರೆಕಾರ್ಡ್ ಅನ್ನು ಸರಿಪಡಿಸಿ"]
    WhyFailed -->|"ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸಲಾಗಿದೆ / ಸಮಯ ಮೀರಿದೆ / 404 ರಂದು /.well-known/acme-challenge/"| HttpBlock["ಪೋರ್ಟ್ 80 ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ ಅಥವಾ ಮರುನಿರ್ದೇಶನ ಲೂಪ್: ಫೈರ್‌ವಾಲ್‌ನಲ್ಲಿ TCP ಪೋರ್ಟ್ 80 ಅನ್ನು ತೆರೆಯಿರಿ, Auth/Rwrite ನಿಂದ /.well-known/ ಹೊರತುಪಡಿಸಿ, ಅಥವಾ DNS-01 ಚಾಲೆಂಜ್ ಬಳಸಿ"]
    WhyFailed -->|"ಕುಬರ್ನೆಟ್ಸ್ ಸರ್ಟ್-ಮ್ಯಾನೇಜರ್ ಆರ್ಡರ್ ಬಾಕಿ ಉಳಿದಿದೆ"| K8sFix["ರನ್: kubectl ವಿವರಿಸುವ ಸವಾಲನ್ನು -> ಪ್ರವೇಶ ವರ್ಗ ಟಿಪ್ಪಣಿ, HTTP01 ಪರಿಹಾರಕ ಪಾಡ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿ, ಅಥವಾ ವೆಬ್‌ಹೂಕ್ TLS ಪರಿಶೀಲಿಸಿ"]

    StaleDaemon --> VerifyAll["ಚೈನ್ ಮತ್ತು OCSP ಸ್ಟ್ಯಾಪ್ಲಿಂಗ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ: openssl s_client -connect ಡೊಮೇನ್:443 -ಸ್ಥಿತಿ"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

ಹಂತ 1: HSTS ಏಕೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು (Strict-Transport-Security) ಒಟ್ಟು ಹಾರ್ಡ್-ಫೇಲ್ ಬ್ಲ್ಯಾಕೌಟ್ ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ

ವೆಬ್‌ಸೈಟ್ ಎಚ್‌ಎಸ್‌ಟಿಎಸ್ ಅನ್ನು ಇಲ್ಲ ಬಳಸಿದಾಗ, ಅವಧಿ ಮೀರಿದ ಪ್ರಮಾಣಪತ್ರವು ತೆರಪಿನ ಎಚ್ಚರಿಕೆಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ (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, ಹೆಬ್ಬಾವು requests/urllib3, Node.js undici, ಹೋಗು crypto/tls, ಜಾವಾ SSLContext) ಕಟ್ಟುನಿಟ್ಟಾದ RFC 5280 ಅನ್ನು ನಿರ್ವಹಿಸಿ notAfter ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಮೌಲ್ಯೀಕರಣ ಮತ್ತು ಬಳಕೆದಾರರ ಪರಿಕಲ್ಪನೆಯನ್ನು ಹೊಂದಿಲ್ಲ "ಕ್ಲಿಕ್-ಥ್ರೂ." TLS ಸ್ಥಗಿತದ ಸಮಯದಲ್ಲಿ, ಸ್ಟ್ರೈಪ್ ಮತ್ತು 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 ಅನ್ನು ಮರುಲೋಡ್ ಮಾಡಿ.
** ಡಾಕರ್ ಕಂಟೈನರ್ (nginx / traefik / postfix)** ಹೋಸ್ಟ್ OS ಅನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ /etc/letsencrypt/archive/example.com/fullchain4.pem ಮತ್ತು ಸಿಮ್‌ಲಿಂಕ್ ಅನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ, ಆದರೆ ಡಾಕರ್ ಕಂಟೇನರ್ ಒಂದೇ ಫೈಲ್ ಐನೋಡ್ ಅನ್ನು ಬೈಂಡ್-ಮೌಂಟ್ ಮಾಡಿತು (ಅದನ್ನು ಅನ್‌ಲಿಂಕ್ ಮಾಡಲಾಗಿದೆ/ಬದಲಿಸಲಾಗಿದೆ) ಅಥವಾ ನೇಮ್‌ಸ್ಪೇಸ್‌ನೊಳಗಿನ ಧಾರಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಎಂದಿಗೂ ಸ್ವೀಕರಿಸಲಿಲ್ಲ 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/ಬ್ರೌಸರ್ ಫೋರಮ್‌ನಿಂದ ಕಾನೂನುಬದ್ಧವಾಗಿ ಅಗತ್ಯವಿದೆ 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 ಅಥವಾ ಅದರ ಯಾವುದೇ ಉಪಡೊಮೇನ್**. - ಇದಲ್ಲದೆ, ನೀವು ** ವೈಲ್ಡ್‌ಕಾರ್ಡ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ವಿನಂತಿಸುತ್ತಿದ್ದರೆ (*.example.com)** ಮತ್ತು ನಿಮ್ಮ ಡೊಮೇನ್ ನಿರ್ದಿಷ್ಟವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ 0 issuewild "ca.example" ಟ್ಯಾಗ್, CA ಪರಿಶೀಲಿಸುತ್ತದೆ issuewild ಬದಲಿಗೆ ಆಸ್ತಿ issue.

ರೋಗನಿರ್ಣಯ ಮತ್ತು ತ್ವರಿತ ಪರಿಹಾರ CAA ಬ್ಲಾಕ್‌ಗಳು:

  1. ಪರಿಶೀಲಿಸಿ CAA ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು ಅಪೆಕ್ಸ್ ಡೊಮೇನ್ ಎರಡರಲ್ಲೂ ದಾಖಲೆಗಳು: 
    dig +short CAA sub.example.com
dig +short CAA example.com
  2. ಎಂಬುದನ್ನು ಸಹ ಪರಿಶೀಲಿಸಿ sub.example.com a ಆಗಿದೆ CNAME ಮತ್ತೊಂದು ಡೊಮೇನ್‌ಗೆ ಸೂಚಿಸುವುದು (ಪ್ರತಿ RFC 8659, CAಗಳು ಸಹ ಪರಿಶೀಲಿಸುತ್ತವೆ CAA CNAME ಗುರಿಗಳ ಮೇಲಿನ ದಾಖಲೆಗಳು).
  3. ನಿಮ್ಮ DNS ಪೂರೈಕೆದಾರರ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ನಲ್ಲಿ (Cloudflare, Route 53, Cloud DNS, Namecheap), ಅಸ್ತಿತ್ವದಲ್ಲಿರುವುದನ್ನು ಅಳಿಸಬೇಡಿ CAA ನಿಮ್ಮ CDN ಅಥವಾ AWS ACM ಬಳಸಿದ ದಾಖಲೆಗಳು; ಬದಲಿಗೆ, ** ಸೇರಿಸಿ** ಹೆಚ್ಚುವರಿ CAA ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮತ್ತು ನಿಮ್ಮ ಬ್ಯಾಕಪ್ ಸಿಎಗಳನ್ನು ಅಧಿಕೃತಗೊಳಿಸುವ ದಾಖಲೆಗಳು: 
    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 ಟ್ರಸ್ಟ್ ಸೇವೆಗಳು ಬಳಸುತ್ತದೆ pki.goog.)
  4. ನಿಮ್ಮ ಅಧಿಕೃತ ನೇಮ್‌ಸರ್ವರ್‌ಗಳನ್ನು ನವೀಕರಿಸಲು 60 ಸೆಕೆಂಡುಗಳು ನಿರೀಕ್ಷಿಸಿ (dig @ns1.yourdns.com CAA example.com) ಮತ್ತು ತಕ್ಷಣವೇ ಮರು ರನ್ ಮಾಡಿ sudo certbot renew. ಮರುಪ್ರಯತ್ನದಲ್ಲಿ ಸಾರ್ವಜನಿಕ ಸಂಗ್ರಹಗಳನ್ನು ಬೈಪಾಸ್ ಮಾಡುವ ಮೂಲಕ CAಗಳು ಲೈವ್ ರಿಕರ್ಸಿವ್ ಲುಕಪ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವುದರಿಂದ, ವಿತರಣೆಯು ತಕ್ಷಣವೇ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ.

2. ಫಿಕ್ಸಿಂಗ್ DNS problem: SERVFAIL looking up CAA (DNSSEC ಹೊಂದಿಕೆಯಾಗುತ್ತಿಲ್ಲ)

ನಾವು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡೋಣ, Google ಟ್ರಸ್ಟ್ ಸೇವೆಗಳು ಮತ್ತು ZeroSSL ಎಲ್ಲಾ DNS ಲುಕಪ್‌ಗಳಲ್ಲಿ DNSSEC ಮೌಲ್ಯೀಕರಣವನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಜಾರಿಗೊಳಿಸೋಣ (A, AAAA, TXT, ಮತ್ತು CAA) ಡೊಮೇನ್‌ಗೆ ಇಲ್ಲ CAA ದಾಖಲೆ, CA ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕವಾಗಿ ಮಾನ್ಯತೆಯನ್ನು ಪಡೆಯಬೇಕು NOERROR (ಖಾಲಿ ಉತ್ತರ) ಅಥವಾ NXDOMAIN (NSEC / NSEC3 ಅಸ್ತಿತ್ವದ ದೃಢೀಕೃತ ನಿರಾಕರಣೆ) ಪ್ರತಿಕ್ರಿಯೆ. - ನಿಮ್ಮ ಡೊಮೇನ್ ರಿಜಿಸ್ಟ್ರಾರ್ ಹಳೆಯದನ್ನು ಹೊಂದಿದ್ದರೆ DS ನೀವು DNS ಪೂರೈಕೆದಾರರನ್ನು ಸ್ಥಳಾಂತರಿಸಿದ ನಂತರ (ನಿಯೋಗ ಸಹಿ ಮಾಡುವವರು) ರೆಕಾರ್ಡ್ ಮಾಡಿ (ಉದಾಹರಣೆಗೆ, ಮೊದಲು DNSSEC ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸದೆಯೇ GoDaddy ಯಿಂದ Cloudflare ಅಥವಾ ರೂಟ್ 53 ಗೆ ಚಲಿಸುವುದು), 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 ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸುವವರೆಗೆ ಪದೇ ಪದೇ: - 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, ಬೈಪಾಸ್ ಅಥವಾ Google ಟ್ರಸ್ಟ್ ಸೇವೆಗಳಿಗೆ ಬದಲಾಯಿಸಿ

ACME ಪ್ರೋಟೋಕಾಲ್ (RFC 8555) ಒಂದು ಮುಕ್ತ ಮಾನದಂಡವಾಗಿದೆ. ಪ್ರತಿ ಪ್ರಮುಖ ಬ್ರೌಸರ್ ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ನಂಬುತ್ತದೆ ZeroSSL (Sectigo ರೂಟ್), Buypass Go SSL (ನಾರ್ವೇಜಿಯನ್ CA), ಮತ್ತು Google ಟ್ರಸ್ಟ್ ಸೇವೆಗಳು (pki.goog) ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ (ISRG Root X1) ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಜೊತೆಗೆ ದರ ಮಿತಿಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ.

  • ಆಯ್ಕೆ 1: ಈ ಮೂಲಕ ತಕ್ಷಣವೇ ವಿತರಿಸಿ Certbot Buypass Go SSL ಅನ್ನು ಬಳಸುವುದು (ಯಾವುದೇ ಖಾತೆ/ಇಎಬಿ ಕೀ ಅಗತ್ಯವಿಲ್ಲ, 180-ದಿನಗಳ ಮಾನ್ಯತೆ): (ಗಮನಿಸಿ: ವೈಲ್ಡ್‌ಕಾರ್ಡ್ ಅಲ್ಲದಿದ್ದರೂ ಬೈಪಾಸ್ 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 ಕ್ಲೌಡ್ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ (ಅಥವಾ ಮೂಲಕ 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

ಪರಿಹಾರ ಬಿ: ಒಂದು ಹೆಚ್ಚುವರಿ SAN ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ "5 ನಕಲಿ ಪ್ರಮಾಣಪತ್ರಗಳು" ಮಿತಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಿ

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 ಮೌಲ್ಯೀಕರಣ ಸರ್ವರ್‌ಗಳು TCP ಪೋರ್ಟ್ 80 ನಲ್ಲಿ ನಿಮ್ಮ HTTP ಸವಾಲು ಟೋಕನ್ ಅನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಏಕೆ HTTP-01 60 ದಿನಗಳ ಹಿಂದೆ ಕೆಲಸ ಮಾಡಿದ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಒಡೆಯುತ್ತದೆ

  1. ** ಕ್ಲೌಡ್ ಸೆಕ್ಯುರಿಟಿ ಗ್ರೂಪ್ / UFW / iptables ಮುಚ್ಚಿದ ಪೋರ್ಟ್ 80**: ಪೋರ್ಟ್ ಅನ್ನು ಮಾತ್ರ ಅನುಮತಿಸಲು ಯಾರೋ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ಗಟ್ಟಿಗೊಳಿಸಿದ್ದಾರೆ 443 (HTTPS), RFC 8555 ಅನ್ನು ಮರೆತುಬಿಡುತ್ತದೆ HTTP-01 ಮಾನ್ಯತೆ ** ಯಾವಾಗಲೂ ಸರಳ HTTP ಪೋರ್ಟ್ 80** ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ (ಆದರೂ ಇದು ಅನುಸರಿಸುತ್ತದೆ 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 ಅನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ISP/ಫೈರ್‌ವಾಲ್‌ನಿಂದ ನಿರ್ಬಂಧಿಸಿದರೆ ಅಥವಾ ನಿಮ್ಮ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಮಾರ್ಗವನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ .well-known ಬಹು ಬ್ಯಾಕೆಂಡ್ ನೋಡ್‌ಗಳಿಗೆ, 2 ನಿಮಿಷಗಳಲ್ಲಿ DNS ಮೂಲಕ ಮೌಲ್ಯೀಕರಿಸಿ: 

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 ಜೊತೆಗೆ a 60 ಎರಡನೇ TTL. 2. ** Enter ಅನ್ನು ಒತ್ತುವ ಮೊದಲು ಎರಡನೇ ಟರ್ಮಿನಲ್ ವಿಂಡೋದಲ್ಲಿ ನಿರೀಕ್ಷಿಸಿ ಮತ್ತು ಪರಿಶೀಲಿಸಿ**: 
dig +short TXT _acme-challenge.example.com @8.8.8.8
3. ಒಮ್ಮೆ dig ನಿಮ್ಮ ನಿಖರವಾದ ಟೋಕನ್ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, Certbot ನಲ್ಲಿ Enter ಒತ್ತಿರಿ. ನಿಮ್ಮ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಖಾಸಗಿ ಕೀಲಿಯನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ /etc/letsencrypt/live/example.com/ ತಕ್ಷಣವೇ. (ನಿಲುಗಡೆಯನ್ನು ಪರಿಹರಿಸಿದ ನಂತರ, ಸ್ವಯಂಚಾಲಿತ DNS ಪ್ಲಗಿನ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ python3-certbot-dns-cloudflare ಅಥವಾ python3-certbot-dns-route53 ಆದ್ದರಿಂದ ಭವಿಷ್ಯದ ನವೀಕರಣಗಳಿಗೆ ಕೈಪಿಡಿ ಅಗತ್ಯವಿಲ್ಲ TXT ಪ್ರವೇಶ.)

ಹಂತ 6: ನಂತರದ ಚೇತರಿಕೆ ಪರಿಶೀಲನೆ (ಮಧ್ಯಂತರ ಸರಣಿ, OCSP ಸ್ಟ್ಯಾಪ್ಲಿಂಗ್, ಮತ್ತು CDN ಪರ್ಜ್)

ತುರ್ತು ಪ್ರಮಾಣಪತ್ರ ಬದಲಿ ಸ್ಥಾಪಿಸಿದ ನಂತರ ಸಾಮಾನ್ಯ ತಪ್ಪು cert.pem (ಎಲೆಯ ಪ್ರಮಾಣಪತ್ರ ಮಾತ್ರ) ಬದಲಿಗೆ fullchain.pem (ಎಲೆ ಪ್ರಮಾಣಪತ್ರ + ಮಧ್ಯಂತರ CA ಪ್ರಮಾಣಪತ್ರ). ಡೆಸ್ಕ್‌ಟಾಪ್ ಬ್ರೌಸರ್‌ಗಳು (Chrome, FirefoxAIA ಮೂಲಕ ಕಾಣೆಯಾದ ಮಧ್ಯಂತರ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮರೆಮಾಚುವುದು (Authority Information Access) ಚೇಸಿಂಗ್ ಅಥವಾ ಕ್ಯಾಶ್ ಮಾಡಲಾದ ಮಧ್ಯವರ್ತಿಗಳು, ಆದರೆ curl, ಪೈಥಾನ್, ಓಪನ್‌ಎಸ್‌ಎಸ್‌ಎಲ್, ಆಂಡ್ರಾಯ್ಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಸ್ಟ್ರೈಪ್/ಟ್ವಿಲಿಯೊ ವೆಬ್‌ಹೂಕ್‌ಗಳು ತಕ್ಷಣವೇ ವಿಫಲಗೊಳ್ಳುತ್ತವೆ 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.
  • ** Nginx / Apache ನಲ್ಲಿ ಹಳೆಯ OCSP ಸ್ಟ್ಯಾಪ್ಲಿಂಗ್ ಸಂಗ್ರಹವನ್ನು ತೆರವುಗೊಳಿಸಿ**: ಒಂದು ವೇಳೆ 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) (US): 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 ಎಲ್ಲಾ EU ಸದಸ್ಯ ರಾಷ್ಟ್ರಗಳಾದ್ಯಂತ.
  • 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 ನಲ್ಲಿ "ಸುಧಾರಿತ -> ಸೈಟ್‌ಗೆ ಮುಂದುವರಿಯಿರಿ (ಅಸುರಕ್ಷಿತ)" ಅನ್ನು ಏಕೆ ಕ್ಲಿಕ್ ಮಾಡಬಾರದು?

ನಿಮ್ಮ ಡೊಮೇನ್ ಕಳುಹಿಸಿದಾಗ ಕಟ್ಟುನಿಟ್ಟಾದ-ಸಾರಿಗೆ-ಭದ್ರತೆ (HSTS) HTTP ಹೆಡರ್ - ಅಥವಾ ಉನ್ನತ ಮಟ್ಟದ ಡೊಮೇನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ .dev, ಅಪ್ಲಿಕೇಶನ್, .ಪುಟ, ಅಥವಾ .ಬ್ಯಾಂಕ್ ಅದನ್ನು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಲಾಗಿದೆ HSTS ಪ್ರಿಲೋಡ್ ಪಟ್ಟಿ - RFC 6797 ಯಾವುದೇ ಅವಧಿ ಮೀರಿದ, ಸ್ವಯಂ-ಸಹಿ ಅಥವಾ ಹೊಂದಿಕೆಯಾಗದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮರುಪಡೆಯಲಾಗದ ಮಾರಕ ದೋಷವೆಂದು ಪರಿಗಣಿಸಲು ಬ್ರೌಸರ್ ಅಗತ್ಯವಿದೆ. ಸಕ್ರಿಯ ಮ್ಯಾನ್-ಇನ್-ದಿ-ಮಿಡಲ್ (MitM) ದಾಳಿಕೋರರು ವಂಚನೆಯ ಪ್ರಮಾಣಪತ್ರದ ಮೂಲಕ ಕ್ಲಿಕ್ ಮಾಡುವಂತೆ ಬಳಕೆದಾರರನ್ನು ಮೋಸಗೊಳಿಸುವುದನ್ನು ತಡೆಯಲು ಬ್ರೌಸರ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ "ಹೇಗಾದರೂ ಮುಂದುವರೆಯಿರಿ" ಬೈಪಾಸ್ ಬಟನ್ ಅನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಡೆಸ್ಕ್‌ಟಾಪ್ ಕ್ರೋಮ್‌ನಲ್ಲಿ ಡೆವಲಪರ್ ಗುಪ್ತ ಕೀಬೋರ್ಡ್ ಅನುಕ್ರಮವನ್ನು ಟೈಪ್ ಮಾಡಬಹುದು ಇದು ಅಸುರಕ್ಷಿತ ಪರೀಕ್ಷೆಗಾಗಿ ಸ್ಥಳೀಯವಾಗಿ ಬೈಪಾಸ್ ಮಾಡಲು ದೋಷ ಪರದೆಯ ಮೇಲೆ ನೇರವಾಗಿ, ನಿಜವಾದ ಬಳಕೆದಾರರಿಗೆ ಸಾಧ್ಯವಿಲ್ಲ; ನೀವು ಪೋರ್ಟ್ 443 ನಲ್ಲಿ ಮಾನ್ಯ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸ್ಥಾಪಿಸಬೇಕು.

ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡೋಣ ಮುಕ್ತಾಯ ಎಚ್ಚರಿಕೆ ಇಮೇಲ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ ಮತ್ತು ನನ್ನ ಪ್ರಮಾಣಪತ್ರವು ಸೂಚನೆಯಿಲ್ಲದೆ ಅವಧಿ ಮೀರಿದೆ - ಅದು ಏಕೆ ಸಂಭವಿಸಿತು?

ಡೇಟಾ ಧಾರಣ ಓವರ್‌ಹೆಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ACME ಸೆಟಪ್‌ಗಳು ನವೀಕರಣದ ಆರೋಗ್ಯವನ್ನು ನೇರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಕಾರಣ 2025 ರ ಮಧ್ಯದಲ್ಲಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಅಧಿಕೃತವಾಗಿ ಅದರ ಮುಕ್ತಾಯ ಅಧಿಸೂಚನೆ ಇಮೇಲ್ ಸೇವೆಯನ್ನು ನಿವೃತ್ತಿಗೊಳಿಸಿದೆ. ಭವಿಷ್ಯದ ಆಶ್ಚರ್ಯಗಳನ್ನು ತಡೆಗಟ್ಟಲು, ನೀವು ಬಾಹ್ಯ ಅಪ್‌ಟೈಮ್ ಮಾನಿಟರ್ (ಉದಾಹರಣೆಗೆ ಪ್ರೊಮೆಥಿಯಸ್‌ನಂತಹ) ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ನಿಜವಾದ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮುಕ್ತಾಯ ಸಮಯಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬೇಕು ಬ್ಲಾಕ್‌ಬಾಕ್ಸ್_ರಫ್ತುದಾರ, ಅಪ್‌ಟೈಮ್ ಕುಮಾ, ಬೆಟರ್ ಸ್ಟಾಕ್ ಅಥವಾ ಡೇಟಾಡಾಗ್ ಸಿಂಥೆಟಿಕ್ ಟಿಎಲ್‌ಎಸ್ ಚೆಕ್‌ಗಳು) 21 ದಿನಗಳು, 14 ದಿನಗಳು ಮತ್ತು 7 ದಿನಗಳ ಮೊದಲು ಎಚ್ಚರಿಕೆ ನೀಡುವುದು ನಂತರ ಅಲ್ಲ.

ನನ್ನ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ Chrome ಮತ್ತು Firefox ನಲ್ಲಿ ನನ್ನ ಸೈಟ್ ಏಕೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ Android ಫೋನ್‌ಗಳಲ್ಲಿ ವಿಫಲವಾಗಿದೆ, curl, ಮತ್ತು ನಾನು ಪ್ರಮಾಣಪತ್ರವನ್ನು ನವೀಕರಿಸಿದ ನಂತರ ಸ್ಟ್ರೈಪ್ ವೆಬ್‌ಹೂಕ್ಸ್?

ನಿಮ್ಮ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೀರಿ (ssl_certificate Nginx ನಲ್ಲಿ ಅಥವಾ SSLC ಪ್ರಮಾಣಪತ್ರ ಫೈಲ್ ಅಪಾಚೆಯಲ್ಲಿ) ಸೂಚಿಸಲು cert.pem (ಎಲೆಯ ಪ್ರಮಾಣಪತ್ರ ಮಾತ್ರ) ಬದಲಿಗೆ fullchain.pem (ಲೀಫ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮಧ್ಯಂತರ CA ಪ್ರಮಾಣಪತ್ರದೊಂದಿಗೆ ಜೋಡಿಸಲಾಗಿದೆ). Chrome ಮತ್ತು Firefox ನಂತಹ ಡೆಸ್ಕ್‌ಟಾಪ್ ಬ್ರೌಸರ್‌ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಾಣೆಯಾದ ಮಧ್ಯಂತರ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತವೆ ಪ್ರಾಧಿಕಾರ ಮಾಹಿತಿ ಪ್ರವೇಶ (AIA) ನಿಮ್ಮ ಲೀಫ್ ಪ್ರಮಾಣಪತ್ರದ ಒಳಗಿನ URL, ನಿಮ್ಮ ಸರ್ವರ್ ತಪ್ಪು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಸುರುಳಿಯಾಗಿ, OpenSSL, Android ನ ಸಿಸ್ಟಮ್ ಟ್ರಸ್ಟ್ ವೆರಿಫೈಯರ್, ಪೈಥಾನ್ ಮತ್ತು ವೆಬ್‌ಹೂಕ್ ಸರ್ವರ್‌ಗಳು AIA ಚೇಸಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ ಮತ್ತು ಇದರೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ತಕ್ಷಣವೇ ತಿರಸ್ಕರಿಸುತ್ತವೆ ಸ್ಥಳೀಯ ವಿತರಕರ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ. ನಿಮ್ಮ ಸಂರಚನೆಯನ್ನು ಸೂಚಿಸಿ fullchain.pem ಮತ್ತು ನಿಮ್ಮ ಸರ್ವರ್ ಅನ್ನು ಮರುಲೋಡ್ ಮಾಡಿ.

ನನ್ನ ಡೊಮೇನ್‌ಗಾಗಿ ಹ್ಯಾಕರ್ ಅಥವಾ ರಾಕ್ಷಸ ನಿರ್ವಾಹಕರು ಅನಧಿಕೃತ SSL ಪ್ರಮಾಣಪತ್ರವನ್ನು ನೀಡಿದ್ದರೆ ನಾನು ಹೇಗೆ ಪರಿಶೀಲಿಸುವುದು?

ಪ್ರತಿ ಸಾರ್ವಜನಿಕವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರವು ಪ್ರತಿ ನೀಡಲಾದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಸಾರ್ವಜನಿಕರಿಗೆ ಲಾಗ್ ಮಾಡುವ ಅಗತ್ಯವಿದೆ ಪ್ರಮಾಣಪತ್ರ ಪಾರದರ್ಶಕತೆ (CT) ಲಾಗ್‌ಗಳು (RFC 6962) ಬ್ರೌಸರ್‌ಗಳು ಅದನ್ನು ನಂಬುವ ಮೊದಲು. ತೆರೆಯಿರಿ https://crt.sh/?q=%25.yourdomain.com ಅಥವಾ ಕ್ಲೌಡ್‌ಫ್ಲೇರ್‌ನ ಪ್ರಮಾಣಪತ್ರ ಪಾರದರ್ಶಕತೆ ಮಾನಿಟರ್ ನಿಮ್ಮ ಡೊಮೇನ್ ಮತ್ತು ಅದರ ಸಬ್‌ಡೊಮೇನ್‌ಗಳಿಗಾಗಿ ನೀಡಲಾದ ಪ್ರತಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ವೀಕ್ಷಿಸಲು. ನೀವು ಅಧಿಕೃತಗೊಳಿಸದ ಅಪರಿಚಿತ CA ಯಿಂದ ನೀಡಲಾದ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನೀವು ನೋಡಿದರೆ, ಅನಧಿಕೃತ ಮಾರ್ಪಾಡುಗಳಿಗಾಗಿ ತಕ್ಷಣವೇ ನಿಮ್ಮ DNS ರಿಜಿಸ್ಟ್ರಾರ್ ಮತ್ತು ಅಧಿಕೃತ DNS ವಲಯವನ್ನು ಪರೀಕ್ಷಿಸಿ, ವಿತರಿಸುವ CA ನೊಂದಿಗೆ ರಾಕ್ಷಸ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳಿ ಮತ್ತು ನಿಮ್ಮ DNS ಅನ್ನು ಲಾಕ್ ಮಾಡಿ ಸಿಎಎ ದಾಖಲೆಗಳು (`0 issue "letsencrypt.org"`)

ನನ್ನ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಆಗಿದ್ದರೆ ಏನು cert-manager ನಮ್ಮ ಪ್ರವೇಶ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನವೀಕರಿಸಲು ವಿಫಲವಾಗಿದೆ ಮತ್ತು ಆದೇಶವು ಅಂಟಿಕೊಂಡಿದೆ Pending?

ಓಡು kubectl ಪಡೆಯಿರಿ ಆದೇಶ, ಸವಾಲು -A ತದನಂತರ kubectl ಸವಾಲನ್ನು ವಿವರಿಸುತ್ತದೆ -n . 90 ಪ್ರತಿಶತ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರ-ವ್ಯವಸ್ಥಾಪಕ ಸ್ಥಗಿತಗಳು, ದಿ cm-acme-http-solver-* ತಾತ್ಕಾಲಿಕ ಪಾಡ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ಆದರೆ (1) ಇನ್‌ಗ್ರೆಸ್ ಸಂಪನ್ಮೂಲವು ಹಳತಾದ ಪ್ರವೇಶ ವರ್ಗದ ಟಿಪ್ಪಣಿಯನ್ನು ಹೊಂದಿದೆ ಆದ್ದರಿಂದ ನಿಮ್ಮ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಪರಿಹಾರಕ ಮಾರ್ಗವನ್ನು ಎಂದಿಗೂ ಜೋಡಿಸಲಾಗಿಲ್ಲ, (2) ಕುಬರ್ನೆಟ್ಸ್ ನೆಟ್‌ವರ್ಕ್ ನೀತಿ ಪೋರ್ಟ್ 8089 ನಲ್ಲಿ ಸಾಲ್ವರ್ ಪಾಡ್‌ಗೆ ಪ್ರವೇಶ ದಟ್ಟಣೆಯನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ ಅಥವಾ (3) ಹೇರ್-ಪಿನ್ NAT / ಸ್ಪ್ಲಿಟ್-ಹಾರಿಜಾನ್ DNS ಸಮಸ್ಯೆ ತಡೆಯುತ್ತದೆ ಪ್ರಮಾಣಪತ್ರ-ವ್ಯವಸ್ಥಾಪಕನಿಮ್ಮ ಸಾರ್ವಜನಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಐಪಿಯನ್ನು ತಲುಪುವುದರಿಂದ ಆಂತರಿಕ ಸ್ವಯಂ-ಪರಿಶೀಲನೆ (ಪಾಸಿಂಗ್ ಮೂಲಕ ಸರಿಪಡಿಸಬಹುದು --dns01-Recursive-nameservers=8.8.8.8:53,1.1.1.1:53 ಗೆ ಪ್ರಮಾಣಪತ್ರ-ವ್ಯವಸ್ಥಾಪಕ ನಿಯೋಜನೆ ಆರ್ಗ್ಸ್).

ನಾನು ನನ್ನ ನಕಲು ಮಾಡಬಹುದೇ /etc/letsencrypt/ ಮರು-ನೀಡುವ ಬದಲು ತುರ್ತು ವಲಸೆಯ ಸಮಯದಲ್ಲಿ ಹೊಸ ಸರ್ವರ್‌ಗೆ ಫೋಲ್ಡರ್ ಮಾಡುವುದೇ?

ಹೌದು. ನಿಮ್ಮ ಪ್ರಾಥಮಿಕ ಸರ್ವರ್ ಮರಣಹೊಂದಿದರೆ ಮತ್ತು ನೀವು ಹೊಸ ಸರ್ವರ್‌ಗೆ ವಲಸೆ ಹೋಗುತ್ತಿದ್ದರೆ, ಲೆಟ್ಸ್ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮೂಲಕ ದರವನ್ನು ಸೀಮಿತಗೊಳಿಸಿದರೆ, ನಕಲಿಸುವಾಗ ಸಿಮ್‌ಲಿಂಕ್‌ಗಳನ್ನು ಸಂರಕ್ಷಿಸಿ /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 (DNS ಪ್ರಮಾಣೀಕರಣ ಪ್ರಾಧಿಕಾರದ ಅಧಿಕಾರ / CAA), ಮತ್ತು RFC 6797 (HTTP ಕಟ್ಟುನಿಟ್ಟಾದ ಸಾರಿಗೆ ಭದ್ರತೆ / HSTS).
  • ರಾಷ್ಟ್ರೀಯ ಗುಣಮಟ್ಟ ಮತ್ತು ತಂತ್ರಜ್ಞಾನ ಸಂಸ್ಥೆ (NIST) (ಯುನೈಟೆಡ್ ಸ್ಟೇಟ್ಸ್): ವಿಶೇಷ ಪ್ರಕಟಣೆ 800-52 ರೆವ್. 2: ಆಯ್ಕೆ, ಕಾನ್ಫಿಗರೇಶನ್ ಮತ್ತು ಸಾರಿಗೆ ಲೇಯರ್ ಸೆಕ್ಯುರಿಟಿ (TLS) ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ಸ್ ಮತ್ತು SP 1800-16 ಬಳಕೆಗಾಗಿ ಮಾರ್ಗಸೂಚಿಗಳು: ವೆಬ್ ವಹಿವಾಟುಗಳನ್ನು ಭದ್ರಪಡಿಸುವುದು: TLS ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ ನಿರ್ವಹಣೆ.
  • ಇಂಟರ್ನೆಟ್ ಭದ್ರತಾ ಸಂಶೋಧನಾ ಗುಂಪು (ISRG / ಅಧಿಕೃತ ದಾಖಲೆಗಳನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡೋಣ): ದರ ಮಿತಿಗಳ ಉಲ್ಲೇಖ, ನಕಲಿ ಪ್ರಮಾಣಪತ್ರ ನಿಯಮಗಳು ಮತ್ತು ACME ಚಾಲೆಂಜ್ ಟ್ರಬಲ್‌ಶೂಟಿಂಗ್.
  • ಸೈಬರ್‌ ಸೆಕ್ಯುರಿಟಿ ಮತ್ತು ಇನ್‌ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಸೆಕ್ಯುರಿಟಿ ಏಜೆನ್ಸಿ (CISA) (ಯುನೈಟೆಡ್ ಸ್ಟೇಟ್ಸ್): ಬೈಂಡಿಂಗ್ ಆಪರೇಷನಲ್ ಡೈರೆಕ್ಟಿವ್ 18-01: ಇಮೇಲ್ ಮತ್ತು ವೆಬ್ ಭದ್ರತೆಯನ್ನು ಹೆಚ್ಚಿಸಿ (HTTPS ಮತ್ತು HSTS ಇಂಪ್ಲಿಮೆಂಟೇಶನ್ ಗೈಡೆನ್ಸ್).
  • ರಾಷ್ಟ್ರೀಯ ಸೈಬರ್ ಭದ್ರತಾ ಕೇಂದ್ರ (NCSC) (ಯುನೈಟೆಡ್ ಕಿಂಗ್‌ಡಮ್): ಟ್ರಾನ್ಸಿಟ್‌ನಲ್ಲಿ ಪರಿಪೂರ್ಣವಾಗಿ ಡೇಟಾವನ್ನು ರಕ್ಷಿಸಲು TLS ಅನ್ನು ಬಳಸುವುದು ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಪಾರದರ್ಶಕತೆ ಮಾನಿಟರಿಂಗ್ ಮಾರ್ಗದರ್ಶನ.