ใบรับรอง SSL/TLS การผลิตหมดอายุ: แก้ไขปัญหาการขัดข้อง HSTS Hard-Fail และมาเข้ารหัสบล็อก CAA/จำกัดอัตรา¶

เมื่อผลิต 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 เปอร์เซ็นต์สำหรับผู้ใช้ทุกคนทั่วโลก บ่อยครั้ง cronjob การต่ออายุอัตโนมัติ (Certbot, acme.sh, Caddy, cert-managerหรือ AWS ACM) ล้มเหลวอย่างเงียบๆ เป็นเวลา 30 วัน เนื่องจาก DNS ที่มีข้อจำกัด 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. หากคุณถึงขีดจำกัดอัตรา Let's Encrypt (429 Too Many Requests) เปลี่ยนไคลเอ็นต์ ACME ของคุณเป็นผู้ออกใบรับรองสาธารณะรายที่สองฟรี (ZeroSSL, Buypass Go SSLหรือ Google Trust Services) หรือเพิ่มโดเมนย่อยแบบใช้ครั้งเดียว SAN ทันที:
6. ลูกค้า 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 โดยสิ้นเชิง
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 Challenge) ถูกบล็อกโดยไฟร์วอลล์, 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 Server ของคุณ (Error 526 Invalid SSL Certificate):
13. บน Cloudflare หากใบรับรองเซิร์ฟเวอร์ต้นทางของคุณหมดอายุและตั้งค่า Cloudflare เป็น Full (Strict)ผู้ใช้เห็น ข้อผิดพลาด 526 ในขณะที่คุณแก้ไขใบรับรองต้นทาง คุณสามารถคืนค่าการเข้าชมเว็บไซต์แบบเรียลไทม์ได้ภายใน 5 วินาทีโดยสร้าง ใบรับรอง Cloudflare Origin CA เป็นเวลา 15 ปีในแดชบอร์ด Cloudflare (หรือสลับโหมด SSL/TLS ชั่วคราวจาก Full (Strict) ถึง Full เป็นเวลา 10 นาทีเพื่อทดแทนต้นกำเนิด .pem ไฟล์)

แผนผังการตัดสินใจ: การวินิจฉัยและแก้ไขใบรับรอง SSL/TLS การผลิตที่หมดอายุ¶

ปฏิบัติตามแผนผังการตัดสินใจนี้เพื่อระบุเลเยอร์ความล้มเหลวที่แน่นอน (CDN Edge เทียบกับ Origin Daemon Memory เทียบกับ ACME Challenge เทียบกับขีดจำกัดอัตรา CA) และกู้คืนการรับส่งข้อมูล HTTPS ในไม่กี่นาที:

flowchart TD
    Start["ผู้ใช้ / API การรายงาน NET :: ERR_CERT_DATE_INVALID หรือข้อผิดพลาด Cloudflare 526"] --> CheckLive["เรียกใช้: openssl s_client - โดเมนเซิร์ฟเวอร์ - เชื่อมต่อโดเมน: 443 | openssl x509 -noout -dates -ผู้ออก"]

    CheckLive --> WhereExpired{"ใบรับรองใดที่หมดอายุจริงแล้ว?"}

    WhereExpired -->|"ดิสก์ fullchain.pem ถูกต้อง แต่ Live Port 443 หมดอายุแล้ว"| StaleDaemon["หน่วยความจำ Stale Daemon หรือ Split Cert Store: โหลด nginx / apache2 / haproxy / postfix ใหม่หรือสร้าง Bundle HAProxy PEM ที่รวมกันใหม่"]
    WhereExpired -->|"ใบรับรอง CDN Edge (Cloudflare / CloudFront / Fastly) หมดอายุแล้ว"| CDNFix["ตรวจสอบระเบียน DNS CAA สำหรับ CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) และสลับ Universal SSL หรือตรวจสอบ ACM อีกครั้ง"]
    WhereExpired -->|"Origin Server fullchain.pem บนดิสก์หมดอายุแล้ว"| DryRun["เรียกใช้: sudo certbot renew --dry-run (หรือ acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"เหตุใดการต่ออายุ ACME จึงล้มเหลว"}

    WhyFailed -->|"429 คำขอมากเกินไป (เกินขีดจำกัดอัตรา)"| RateLimit["บายพาสทันที: ปัญหาจาก ZeroSSL / Buypass / Google Trust Services หรือเพิ่ม SAN โดเมนย่อยเพิ่มเติม 1 รายการ (-d fix1.example.com)"]
    WhyFailed -->|"บันทึก CAA ป้องกันการออกหรือ SERVFAIL (DNSSEC)"| CAADNS["เรียกใช้: ขุด 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 Challenge"]
    WhyFailed -->|"คำสั่งซื้อผู้จัดการใบรับรอง Kubernetes ค้างอยู่ในสถานะรอดำเนินการ"| K8sFix["เรียกใช้: kubectl อธิบายความท้าทาย -> ตรวจสอบคำอธิบายประกอบคลาส Ingress, นโยบายเครือข่ายพ็อดตัวแก้ปัญหา HTTP01 หรือ Webhook TLS"]

    StaleDaemon --> VerifyAll["ตรวจสอบ Chain & OCSP Stapling: 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) พร้อมด้วยลิงก์ "ขั้นสูง -> ดำเนินการต่อไปยัง example.com (ไม่ปลอดภัย)" ที่อนุญาตให้ผู้ใช้ที่สิ้นหวังสามารถคลิกผ่านได้

อย่างไรก็ตาม เว็บแอปพลิเคชันที่ใช้งานจริงที่ทันสมัยเกือบทั้งหมด ธนาคาร แพลตฟอร์ม SaaS และ .dev / .app / .page / .bank โดเมนระดับบนสุดบังคับใช้ HTTP Strict Transport Security (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 บน Earth มีโดเมนของคุณฮาร์ดโค้ดเป็นไบนารีตามที่บังคับใช้ 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, โหนด js undici,ไป crypto/tls,จาวา SSLContext) ดำเนินการ RFC 5280 ที่เข้มงวด notAfter การตรวจสอบความถูกต้องตามค่าเริ่มต้น และไม่มีแนวคิดเรื่อง "การคลิกผ่าน" ของผู้ใช้ ในช่วงที่ TLS หยุดทำงาน Stripe และ Shopify webhooks จะไม่สามารถจัดส่งและเข้าสู่คิวการลองแบ็คออฟแบบเอ็กซ์โพเนนเชียลอีกครั้ง

ระยะที่ 2: การวินิจฉัย 60 วินาที - ใบรับรองได้รับการต่ออายุบนดิสก์แล้วจริงหรือ¶

ในการผลิตประมาณ 35 เปอร์เซ็นต์ Let's Encrypt หยุดทำงาน ใบรับรองได้รับการต่ออายุจริงบนดิสก์เมื่อสัปดาห์ก่อนโดย certbot.timer หรือ acme.shแต่ daemon ที่รันอยู่ยังคงให้บริการใบรับรองเก่าที่หมดอายุจาก 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: แก้ไขกับดัก "ต่ออายุบนดิสก์ หมดอายุใน RAM" ทั่วไป 4 รายการ¶

ขั้นตอนที่ 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 หรือโดเมนย่อยใดๆ - นอกจากนี้ หากคุณขอ ใบรับรอง Wildcard (*.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 คือ CNAME ชี้ไปยังโดเมนอื่น (ต่อ RFC 8659, CAs จะตรวจสอบ 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"
   

   (หมายเหตุ: ZeroSSL ใช้ sectigo.com เป็นตัวระบุ CAA พื้นฐาน และ Google Trust Services ใช้ pki.goog.)
4. รอ 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). แม้ว่าโดเมนจะมี หมายเลข 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 (นอร์เวย์ 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 Trust (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: ข้ามขีดจำกัด Let's Encrypt "5 Duplicate Certificates" โดยการเพิ่มชื่อโฮสต์ 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

ขั้นตอนที่ 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 ถูกบล็อกโดย ISP/ไฟร์วอลล์อัปสตรีม หรือโหลดบาลานเซอร์ของคุณไม่สามารถกำหนดเส้นทางได้ .well-known ไปยังโหนดแบ็กเอนด์หลายโหนด ตรวจสอบผ่าน DNS ภายใน 2 นาที:

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

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

ระยะที่ 6: การตรวจสอบหลังการกู้คืน (Intermediate Chain, OCSP Stapling และ CDN Purge)¶

ข้อผิดพลาดทั่วไปหลังจากติดตั้งใบรับรองฉุกเฉินทดแทน cert.pem (ใบประกาศนียบัตรอย่างเดียว) แทน fullchain.pem (ใบรับรองลีฟ + ใบรับรอง CA ระดับกลาง) เบราว์เซอร์เดสก์ท็อป (Chrome, Firefox) มักจะปกปิดใบรับรองระดับกลางที่ขาดหายไปผ่าน AIA (Authority Information Access) การไล่หรือแคชตัวกลางในขณะที่ curl, Python, OpenSSL, แอพ Android และ Stripe/Twilio webhooks ล้มเหลวทันทีด้วย unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

• ตรวจสอบว่าเซิร์ฟเวอร์ของคุณส่ง Intermediate Chain ที่สมบูรณ์ (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.
• ล้างแคช Stapling OCSP เก่าใน 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): อย่าพึ่งพาการแจ้งเตือนทางอีเมลเพียงอย่างเดียว (Let's Encrypt ยกเลิกอีเมลแจ้งเตือนการหมดอายุในปี 2025) ตรวจสอบซ็อกเก็ตพอร์ตสด 443 ภายนอก (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) และตั้งค่าการตรวจสอบ cron รายวัน sudo certbot renew --dry-run.

หมายเลขฉุกเฉินในภูมิภาคและระเบียบการของหน่วยงาน¶

แม้ว่าใบรับรอง TLS ที่หมดอายุมักจะได้รับการแก้ไขโดยทีมวิศวกร แต่การหยุดทำงานของใบรับรองที่ทำให้พอร์ทัลการดูแลสุขภาพเสียหาย เว็บฮุคการจัดส่งฉุกเฉิน การรับรองความถูกต้องของธนาคาร หรือโครงสร้างพื้นฐานสาธารณะของรัฐบาล อาจกระตุ้นให้เกิดเวิร์กโฟลว์เหตุการณ์ด้านกฎระเบียบ:

• สหรัฐอเมริกาและแคนาดา:
• ความปลอดภัยในชีวิต / ทางคลินิก / การขัดข้องในการจัดส่ง: กดหมายเลข 911 หากความล้มเหลวของใบรับรอง TLS ตัดการสื่อสารทางไกลของผู้ป่วย การสั่งจ่ายยาทางอิเล็กทรอนิกส์ หรือการสื่อสารการแจ้งเหตุฉุกเฉิน
• หน่วยงานรักษาความปลอดภัยทางไซเบอร์และโครงสร้างพื้นฐาน (CISA) (สหรัฐอเมริกา): หน่วยงานพลเรือนของรัฐบาลกลางภายใต้ CISA Binding Operational Directive (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 ในนิวซีแลนด์ ติดต่อ เอซีเอสซี (1300 CYBER1) สำหรับเหตุการณ์ด้านโครงสร้างพื้นฐาน
• อินเดียและเอเชียแปซิฟิก:
• อินเดีย (CERT-In / ผู้ควบคุมหน่วยงานผู้รับรอง CCA): กดหมายเลข 112 สำหรับการตอบสนองฉุกเฉิน รายงานการประนีประนอมของ PKI หรือการขัดข้องของโครงสร้างพื้นฐานที่สำคัญไปยัง incident@cert-in.org.in ภายใน 6 ชั่วโมง

คำถามที่พบบ่อย¶

เหตุใดฉันหรือผู้ใช้จึงไม่สามารถคลิก "ขั้นสูง -> ดำเนินการต่อไปยังไซต์ (ไม่ปลอดภัย)" ใน Chrome หรือ Safari ในระหว่างที่ไฟดับนี้¶

เมื่อโดเมนของคุณส่งไฟล์ การเข้มงวด-การขนส่ง-การรักษาความปลอดภัย (HSTS) ส่วนหัว HTTP - หรือใช้โดเมนระดับบนสุดเช่น .dev, .แอป, .หน้าหรือ .ธนาคาร ที่ถูกฮาร์ดโค้ดลงในรายการโหลดล่วงหน้า HSTS ของเบราว์เซอร์ - RFC 6797 กำหนดให้เบราว์เซอร์ถือว่าใบรับรองที่หมดอายุ ลงนามด้วยตนเอง หรือไม่ตรงกันเป็นข้อผิดพลาดร้ายแรงที่ไม่สามารถกู้คืนได้ เบราว์เซอร์ตั้งใจลบปุ่มบายพาส "ดำเนินการต่อ" เพื่อป้องกันไม่ให้ผู้โจมตี Man-in-the-Middle (MitM) ที่ใช้งานอยู่หลอกให้ผู้ใช้คลิกผ่านใบรับรองที่ปลอมแปลง ในขณะที่นักพัฒนาบนเดสก์ท็อป Chrome สามารถพิมพ์ลำดับแป้นพิมพ์ที่ซ่อนอยู่ได้ สิ่งนี้ไม่ปลอดภัย บนหน้าจอข้อผิดพลาดโดยตรงเพื่อหลีกเลี่ยงการทดสอบภายในเครื่อง ผู้ใช้จริงไม่สามารถทำได้ คุณต้องติดตั้งใบรับรองที่ถูกต้องบนพอร์ต 443

Let's Encrypt หยุดส่งอีเมลคำเตือนการหมดอายุและใบรับรองของฉันหมดอายุโดยไม่ต้องแจ้งให้ทราบ - เหตุใดจึงเกิดขึ้น¶

Let's Encrypt เลิกให้บริการอีเมลแจ้งเตือนการหมดอายุอย่างเป็นทางการในช่วงกลางปี ​​2025 เพื่อลดค่าใช้จ่ายในการเก็บรักษาข้อมูล และเนื่องจากการตั้งค่า ACME อัตโนมัติควรตรวจสอบความสมบูรณ์ของการต่ออายุโดยตรง เพื่อป้องกันเหตุไม่คาดคิดในอนาคต คุณต้องตรวจสอบการประทับเวลาการหมดอายุของ Handshake TLS จริงผ่านเครือข่ายโดยใช้ตัวตรวจสอบสถานะการออนไลน์ภายนอก (เช่น Prometheus blackbox_exporter, การตรวจสอบ Uptime Kuma, Better Stack หรือ Datadog Synthetic TLS) แจ้งเตือนที่ 21 วัน 14 วัน และ 7 วันก่อน ไม่ใช่หลังจาก.

เหตุใดไซต์ของฉันจึงทำงานได้ดีใน Chrome และ Firefox บนแล็ปท็อปของฉัน แต่ล้มเหลวบนโทรศัพท์ Android curlและ Stripe webhooks หลังจากที่ฉันอัปเดตใบรับรองแล้ว¶

คุณกำหนดค่าเว็บเซิร์ฟเวอร์ของคุณ (ssl_certificate ใน Nginx หรือ ไฟล์ใบรับรอง SSL ใน Apache) เพื่อชี้ไปที่ ใบรับรอง.pem (ใบประกาศนียบัตรอย่างเดียว) แทน fullchain.pem (ใบรับรอง leaf ที่มาพร้อมกับใบรับรอง Intermediate CA) เบราว์เซอร์เดสก์ท็อป เช่น Chrome และ Firefox จะดาวน์โหลดใบรับรองระดับกลางที่ขาดหายไปในเบื้องหลังโดยอัตโนมัติโดยใช้ การเข้าถึงข้อมูลผู้มีอำนาจ (AIA) URL ภายใน Leaf Cert ของคุณ ซึ่งซ่อนการกำหนดค่าเซิร์ฟเวอร์ของคุณไม่ถูกต้อง อย่างไรก็ตาม, ขด, OpenSSL, ตัวตรวจสอบความน่าเชื่อถือของระบบ Android, Python และเซิร์ฟเวอร์ webhook จะไม่ทำการไล่ล่า AIA และปฏิเสธการเชื่อมต่อกับทันที ไม่สามารถรับใบรับรองผู้ออกในท้องถิ่นได้. ชี้การกำหนดค่าของคุณไปที่ fullchain.pem และโหลดเซิร์ฟเวอร์ของคุณใหม่

ฉันจะตรวจสอบได้อย่างไรว่าแฮกเกอร์หรือผู้ดูแลระบบโกงออกใบรับรอง SSL ที่ไม่ได้รับอนุญาตสำหรับโดเมนของฉัน¶

ผู้ออกใบรับรองที่เชื่อถือได้ทุกรายจะต้องบันทึกใบรับรองที่ออกให้ทุกรายการสู่สาธารณะ บันทึกความโปร่งใสของใบรับรอง (CT) (RFC 6962) ก่อนที่เบราว์เซอร์จะเชื่อถือ เปิด https://crt.sh/?q=%25.yourdomain.com หรือการตรวจสอบความโปร่งใสของใบรับรองของ Cloudflare เพื่อดูใบรับรองทั้งหมดที่เคยออกสำหรับโดเมนของคุณและโดเมนย่อย หากคุณเห็นใบรับรองที่ออกโดย CA ที่ไม่คุ้นเคยซึ่งคุณไม่ได้อนุญาต ให้ตรวจสอบผู้รับจดทะเบียน DNS และโซน DNS ที่เชื่อถือได้ทันทีเพื่อดูการแก้ไขที่ไม่ได้รับอนุญาต เพิกถอนใบรับรองปลอมด้วย CA ผู้ออก และล็อค DNS ของคุณด้วย ซีเอเอ บันทึก (`0 issue "letsencrypt.org"`).

จะเกิดอะไรขึ้นถ้าคลัสเตอร์ Kubernetes ของฉันเป็น cert-manager ไม่สามารถต่ออายุใบรับรอง Ingress ของเราได้ และคำสั่งซื้อค้างอยู่ Pending?¶

วิ่ง kubectl รับคำสั่งซื้อความท้าทาย -A แล้ว kubectl อธิบายความท้าทาย -n . ใน 90 เปอร์เซ็นต์ของ Kubernetes ผู้จัดการใบรับรอง การหยุดทำงาน cm-acme-http-ตัวแก้ปัญหา-* พ็อดชั่วคราวกำลังทำงานอยู่ แต่ (1) ทรัพยากร Ingress มีคำอธิบายประกอบคลาสทางเข้าที่ล้าสมัย ดังนั้นเส้นทางของตัวแก้ปัญหาจึงไม่แนบกับโหลดบาลานเซอร์ของคุณ (2) Kubernetes นโยบายเครือข่าย กำลังบล็อกการรับส่งข้อมูลขาเข้าไปยังพ็อดตัวแก้ปัญหาบนพอร์ต 8089 หรือ (3) ปัญหา DNS ของ hair-pin NAT / split-horizon ผู้จัดการใบรับรองการตรวจสอบภายในตนเองของการเข้าถึง IP ของโหลดบาลานเซอร์สาธารณะของคุณ (แก้ไขได้โดยการส่งผ่าน --dns01-recursive-nameservers=8.8.8.8:53,1.1.1.1:53 ไปที่ ผู้จัดการใบรับรอง args การปรับใช้)

ฉันสามารถคัดลอกของฉัน /etc/letsencrypt/ ไปยังเซิร์ฟเวอร์ใหม่ในระหว่างการโยกย้ายฉุกเฉินแทนที่จะออกใหม่หรือไม่¶

ใช่. หากเซิร์ฟเวอร์หลักของคุณเสียและคุณกำลังย้ายไปยังเซิร์ฟเวอร์ใหม่ในขณะที่ Let's Encrypt ถูกจำกัดอัตรา ให้รักษาลิงก์สัญลักษณ์ไว้เมื่อทำการคัดลอก /etc/letsencrypt/ ใช้ tar -czpf Letencrypt_backup.tar.gz /etc/letsencrypt (อย่าใช้ธรรมดา เอสซีพี -อาร์ซึ่งเปลี่ยน symlink เข้ามา /etc/letsencrypt/สด/ เป็นไฟล์สแตติกที่ซ้ำกันและทำลายการต่ออายุในอนาคต) แยกไฟล์เก็บถาวรนั้นไปยังเซิร์ฟเวอร์ใหม่ (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`) ชี้ Nginx/Apache ไปที่ `/etc/letsencrypt/live/domain/fullchain.pem`และใบรับรองที่มีอยู่ของคุณจะใช้งานได้ทันทีบนที่อยู่ IP ใหม่

คำแนะนำที่เกี่ยวข้อง¶

• การไฮแจ็กชื่อโดเมน, DNS ที่หมดอายุ และการครอบครองเว็บไซต์
• ดิสก์เซิร์ฟเวอร์เต็ม 100% (ว่าง 0 ไบต์): การกู้คืนฐานข้อมูลและการใช้พื้นที่เป็นศูนย์
• การล็อกผู้ดูแลระบบโดเมนที่กำหนดเองของ Google Workspace หรือ Microsoft 365 และการช่วยเหลือ DNS TXT
• วิกฤตเว็บโฮสติ้ง การโยกย้าย และการกู้คืนข้อมูลสำรอง
• การไฮแจ็ค DNS, การกำหนดค่าเราเตอร์ ISP WAN ใหม่ และการปลอมแปลงพอร์ทัลแบบเชลย
• หมายเลขฉุกเฉินตามประเทศ

แหล่งที่มาและคำแนะนำอย่างเป็นทางการ¶

• คณะทำงานเฉพาะกิจวิศวกรรมอินเทอร์เน็ต (IETF): RFC 8555 (สภาพแวดล้อมการจัดการใบรับรองอัตโนมัติ / ACME), RFC 8659 (การอนุญาตผู้ออกใบรับรอง DNS / CAA) และ RFC 6797 (HTTP Strict Transport Security / HSTS)
• สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (NIST) (สหรัฐอเมริกา): สิ่งพิมพ์พิเศษ 800-52 ฉบับที่ 2: แนวทางสำหรับการเลือก การกำหนดค่า และการใช้การใช้งาน Transport Layer Security (TLS) และ SP 1800-16: การรักษาความปลอดภัยธุรกรรมทางเว็บ: การจัดการใบรับรองเซิร์ฟเวอร์ TLS
• กลุ่มวิจัยความปลอดภัยทางอินเทอร์เน็ต (ISRG / มาเข้ารหัสเอกสารอย่างเป็นทางการกันเถอะ): การอ้างอิงการจำกัดอัตรา กฎใบรับรองที่ซ้ำกัน และการแก้ไขปัญหา ACME Challenge
• หน่วยงานรักษาความปลอดภัยทางไซเบอร์และโครงสร้างพื้นฐาน (CISA) (สหรัฐอเมริกา): Binding Operational Directive 18-01: Enhance Email and Web Security (HTTPS และ HSTS Implementation Guidance)
• ศูนย์รักษาความปลอดภัยไซเบอร์แห่งชาติ (NCSC) (สหราชอาณาจักร): การใช้ TLS เพื่อปกป้องข้อมูลอย่างสมบูรณ์แบบในการส่งผ่านและคำแนะนำในการตรวจสอบความโปร่งใสของใบรับรอง