Skip to content

Sertipikat SSL / TLS Produksi Kadaluwarsa: Ngalereskeun HSTS Hard-Fail Outages sareng Hayu Urang Encrypt CAA / Rate-Limit Blocks

Nomer darurat béda-béda dumasar nagara. Kaca ieu nganggo 911, nomer pikeun Amérika Serikat sareng Kanada. Seueur nagara sanés nganggo 112, 999, atanapi nomer sanés. Panggihan nomer pikeun nagara anjeun.

Nalika produksi SSL/TLS (HTTPS) sertipikat kadaluwarsa - sanajan sadetik kaliwat notAfter UTC timestamp - unggal browser modern (Chrome, Safari, Firefox, Edge), aplikasi mobile (iOS App Transport Security, Android Network Security Config), panarima webhook (Stripe, Shopify, Twilio, GitHub), sarta klien API hulu geuwat severs konektipitas kalawan NET::ERR_CERT_DATE_INVALID atawa SSL_ERROR_RX_RECORD_TOO_LONG. Parah deui, upami domain anjeun ngirimkeun Strict-Transport-Security (HSTS) lulugu atawa disusun kana browser ** HSTS Preload Daptar **, Chrome jeung Safari nyabut "Advanced -> Lumangsungna ka situs (teu aman)" tombol bypass lengkep, hasilna 100 persen hard-gagal blackout pikeun unggal pamaké sakuliah dunya. Seringna, cronjob pembaharuan otomatis (Certbot, acme.sh, Caddy, cert-manager, atawa AWS ACM) geus cicingeun gagal salila 30 poé kusabab DNS restrictive CAA rékaman, a DNSSEC rusak DS catetan, a firewall blocking port 80 (HTTP-01 tantangan), atanapi pangladén wéb (nginx / haproxy) anu nga-renew file dina disk (fullchain.pem) tapi henteu pernah ngamuat deui prosés pagawé dina mémori na. Lamun gangguan anjeun disababkeun ku pendaptaran domain kadaluwarsa atawa nameservers dibajak tinimbang sertipikat X.509 sorangan, pindah langsung ka ngaran domain pangbajak, kadaluwarsa DNS, sarta Panyandakan Alih ku ramatloka; lamun server anjeun sagemblengna unreachable atanapi kaluar tina spasi disk kitu certbot teu bisa nulis ka /etc/letsencrypt, tingali server disk 100% pinuh jeung nol-spasi recovery atawa web hosting krisis, migrasi, sarta restorasi cadangan. Upami pareum TLS ieu nganonaktipkeun telemétri rumah sakit, API kiriman darurat, atanapi infrastruktur kaamanan umum, nelepon nomer darurat lokal anjeun (911 di Amérika Serikat sareng Kanada, 112 sakuliah Uni Éropa, 999 di Britania Raya) atanapi konsultasi diréktori internasional kami ngeunaan nomer darurat.

Laksanakeun ieu ayeuna

  1. Cék dina 10 detik naha sertipikat dina disk saleresna parantos diropéa, sareng pangladén wéb atanapi pangimbang beban anjeun ngan saukur gagal ngamuat deui kana RAM:
  2. Bandingkeun stop kontak TLS hirup ngalawan .pem file dina disk ayeuna: 
    # 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. ** Upami file dina disk nunjukkeun masa depan anu sah notAfter titimangsa bari port live 443 nembongkeun tanggal kadaluwarsa**: Klién ACME anjeun (certbot / acme.sh) suksés minggu ka tukang, tapi nginx, apache2, haproxy, atawa postfix teu kungsi dimuat deui, atawa (haproxy / vault) merlukeun fullchain.pem + privkey.pem dihijikeun kana hiji kebat. Lumpat sudo nginx -t && sudo systemctl reload nginx (atawa sudo systemctl reload apache2 haproxy) sareng pareum anjeun bakal réngsé dina 2 detik.
  4. **ULAH ngajalankeun certbot renew --force-renewal sababaraha kali dina loop lamun pembaharuan gagal **: Hayu Encrypt enforces wates laju ketat ** 5 duplikat sertipikat per 7 poé ** jeung ** 5 validations gagal per akun, per hostname, per jam **. Lumpat --force-renewal lima kali dina panik tanpa ngalereskeun kaayaan nginx reload atanapi DNS/firewall bug bakal ngonci domain anjeun kaluar tina penerbitan Let's Encrypt dugi ka 7 dinten.
  5. ** Upami anjeun pencét Batas Laju Énkripsi Hayu (429 Too Many Requests), pindahkeun klien ACME anjeun ka Otoritas Sertipikat umum gratis kadua (ZeroSSL, Buypass Go SSL, atawa Google Trust Services) atanapi tambahkeun subdomain SAN langsung**:
  6. Unggal klien ACME (certbot, acme.sh, caddy, cert-manager) tiasa menta sertipikat dipercaya gratis ti CA anu béda dina 30 detik (--server https://acme.zerossl.com/v2/DV90 atawa https://api.buypass.com/acme/directory), sagemblengna bypassing wates laju Hayu Encrypt urang.
  7. Alternatipna, wates Let's Encrypt "5 duplikat sertipikat per 7 dinten" ngan manglaku ka set sami persis tina Ngaran Alternatif Subject (SANs). Nambahkeun hiji subdomain tambahan valid (-d example.com -d www.example.com -d tlsfix1.example.com) ngajadikeun eta sertipikat non-duplikat jeung bypasses wates laju bijil Duplikat langsung.
  8. ** Pariksa lamun DNS a CAA rékaman atawa pegat DNSSEC ngahalangan Otoritas Sertipikat anjeun tina ngaluarkeun (CAA record for example.com prevents issuance)**:
  9. Tanya Otorisasi Otoritas Sertifikasi domain anjeun (CAA) catetan: dig +short CAA example.com. Upami DNS anjeun gaduh 0 issue "sectigo.com" atawa 0 issue "amazon.com" (atawa dina domain indungna), Hayu urang Encrypt (letsencrypt.org) jeung ZeroSSL (sectigo.com) dilarang ku RFC 8659 ti ngaluarkeun dugi ka nambahkeun 0 issue "letsencrypt.org" ka zona DNS anjeun.
  10. ** Lamun port 80 (HTTP-01 tantangan) diblokir ku firewall, CDN, atawa ISP, atawa lamun pangladén wéb anjeun nolak ngamimitian kusabab sertipikat leungit, paké --standalone atawa --dns (DNS-01) validasi**:
  11. Eureun nginx/apache sakeudeung jeung lumpat sudo certbot certonly --standalone -d example.com, atawa pamakéan --manual --preferred-challenges dns pikeun validasi ku nempelkeun a _acme-challenge.example.com TXT catetan kana konsol DNS Anjeun tanpa noel port 80.
  12. ** Upami situs anjeun aya di tukangeun Cloudflare, AWS CloudFront, atanapi Fastly, pariksa naha sertipikat anu kadaluwarsa aya dina CDN Edge atanapi dina Server Asal anjeun (Error 526 Invalid SSL Certificate)**:
  13. Dina Cloudflare, upami sertipikat server asal anjeun kadaluwarsa sareng Cloudflare disetel ka Full (Strict), pamaké tingali ** Kasalahan 526 **. Nalika anjeun ngalereskeun sertipikat asal, anjeun tiasa mulangkeun lalu lintas situs langsung dina 5 detik ku cara ngahasilkeun 15 taun Cloudflare Origin CA sertipikat dina dasbor Cloudflare (atanapi samentawis gentos mode SSL/TLS tina Full (Strict) ka Full salila 10 menit nu diperlukeun pikeun ngaganti asal .pem file).

Danger

** Entong nyobian "ngalereskeun" konci HSTS Preload ku netepkeun Strict-Transport-Security: max-age=0 bari sertipikat SSL/TLS anjeun masih kadaluwarsa**: RFC 6797 sacara eksplisit ngalarang panyungsi pikeun ngolah atanapi ngahormatan naon waé. Strict-Transport-Security lulugu (kaasup max-age=0) ngaliwatan sambungan TLS anu teu dipercaya, ditandatanganan sorangan, atawa kadaluwarsa, atawa leuwih polos HTTP. Saterusna, lamun domain anjeun boga includeSubDomains; preload disusun kana daptar preload HSTS statik Chromium/Firefox/Safari, komo max-age=0 leuwih sambungan valid moal miceun bandéra preload pikeun datang munggaran-waktos. Hiji-hijina jalan pikeun mulangkeun aksés ka domain anu dikonci HSTS nyaéta masang sertipikat X.509 anu valid, dipercaya ku masarakat dina port 443.

Tangkal kaputusan: diagnosa sareng ngalereskeun sertipikat SSL / TLS produksi kadaluwarsa

Turutan tangkal kaputusan ieu pikeun nunjuk lapisan gagalna pasti (CDN Edge vs. Asal Daemon Memory vs. ACME Challenge vs. CA Rate Limit) sareng malikkeun lalu lintas HTTPS dina sababaraha menit:

flowchart TD
    Start["Pamaké / API Ngalaporkeun NET::ERR_CERT_DATE_INVALID atanapi Cloudflare Kasalahan 526"] --> CheckLive["Ngajalankeun: openssl s_client -servername domain -connect domain: 443 | openssl x509 -noout -dates -issuer"]

    CheckLive --> WhereExpired{"Sertipikat Mana Anu Sabenerna Kadaluwarsa?"}

    WhereExpired -->|"Disk fullchain.pem Dupi VALID, Tapi Live Port 443 geus kadaluwarsa"| StaleDaemon["Mémori Daemon Stale atanapi Split Cert Store: Reload nginx / apache2 / haproxy / postfix, atanapi Rebuild Gabungan HAProxy PEM Bundle"]
    WhereExpired -->|"CDN Edge Cert (Cloudflare / CloudFront / Fastly) Kadaluwarsa"| CDNFix["Pariksa DNS CAA Records pikeun CDN CA (letsencrypt.org / pki.goog / digicert.com / amazon.com) sareng Toggle Universal SSL atanapi Re-Validate ACM"]
    WhereExpired -->|"Origin Server fullchain.pem on Disk Is EXPIRED"| DryRun["Jalankeun: sudo certbot renew --dry-run (atanapi acme.sh --renew -d domain --debug)"]

    DryRun --> WhyFailed{"Naha Pembaruan ACME Gagal?"}

    WhyFailed -->|"429 Loba Teuing Paménta (Wates Ongkoh Ngalangkungan)"| RateLimit["Langsung Bypass: Ngaluarkeun tina ZeroSSL / Buypass / Google Trust Services ATAWA Tambah 1 Tambahan Subdomain SAN (-d fix1.example.com)"]
    WhyFailed -->|"CAA Record Nyegah Issuance atanapi SERVFAIL (DNSSEC)"| CAADNS["Jalankeun: ngali CAA example.com -> Tambah 0 masalah 'letsencrypt.org' (sareng 'sectigo.com') atanapi Fix Rusak DNSSEC DS Record di Registrar"]
    WhyFailed -->|"Sambungan Ditolak / Waktos / 404 on /.well-known/acme-challenge/"| HttpBlock["Port 80 Diblokir atanapi Redirect Loop: Buka TCP Port 80 di Firewall, Ngaluarkeun /.well-known/ tina Auth/Rewrite, atawa Paké DNS-01 Challenge"]
    WhyFailed -->|"Kubernetes sertipikat-manajer Orde Macet di Pending"| K8sFix["Jalankeun: kubectl ngajelaskeun tantangan -> Pariksa annotasi kelas Ingress, kawijakan jaringan pod solver HTTP01, atanapi Webhook TLS"]

    StaleDaemon --> VerifyAll["Pariksa Chain & OCSP Stapling: openssl s_client -connect domain: 443 -status"]
    CDNFix --> VerifyAll
    RateLimit --> VerifyAll
    CAADNS --> VerifyAll
    HttpBlock --> VerifyAll
    K8sFix --> VerifyAll

Fase 1: Ngartos naha HSTS (Strict-Transport-Security) ngabalukarkeun total hard-fail blackout

Lamun situs web henteu ngagunakeun HSTS, sertipikat kadaluwarsa mintonkeun peringatan interstisial (Your connection is not private) kalawan hiji ** "Advanced -> Lumangsungkeun ka example.com (teu aman)"** link nu ngidinan pamaké nekat klik ngaliwatan.

Nanging, ampir sadaya aplikasi wéb produksi modern, bank, platform SaaS, sareng .dev / .app / .page / .bank domain tingkat luhur ngalaksanakeun HTTP Kaamanan Angkutan Ketat (HSTS, RFC 6797): 1. ** Dinamis HSTS (max-age=31536000): Sakur panyungsi anu nganjang ka situs anjeun dina 365 dinten katukang nyéépkeun kawijakan éta Strict-Transport-Security: max-age=31536000; includeSubDomains. Dugi waktos éta béakna, browser ngalarang pangguna ngaklik kasalahan sertipikat naon waé (ERR_CERT_DATE_INVALID, ERR_CERT_COMMON_NAME_INVALID, atawa ERR_CERT_AUTHORITY_INVALID). 2. ** Pramuat HSTS statik (preload daptar atawa .dev / .app gTLD): Upami domain anjeun dikintunkeun ka hstspreload.org - atanapi upami domain anjeun nganggo TLD Registry-Preloaded sapertos .dev, .app, .page, .new, .chrome, atawa .bank - unggal salinan Chrome, Edge, Firefox, Safari, sareng Android WebView di Bumi gaduh domain anjeun hardcoded kana binér salaku HSTS-enforced sateuacan pangguna kantos nganjang ka situs anjeun pertama kalina. 3. ** Naha includeSubDomains ngarecah alat internal sareng server pementasan**: Upami domain root anjeun (example.com) ngirimkeun Strict-Transport-Security: max-age=31536000; includeSubDomains, unggal subdomain (vpn.example.com, internal-jira.example.com, printer.example.com) ogé dikonci kana modeu hard-fail HSTS. 4. ** Naha integrasi API sareng Webhook (Stripe, Twilio, Slack, iOS ATS) gagal geuwat**: Klién TLS server-to-server (libcurl, Python requests/urllib3, Node.js undici, indit crypto/tls, Jawa SSLContext) ngalaksanakeun RFC 5280 anu ketat notAfter validasi sacara standar sareng teu gaduh konsép pangguna "klik-liwat." Dina mangsa pareum TLS, Stripe sareng Shopify webhooks bakal gagal pangiriman sareng ngalebetkeun antrian percobaan deui mundur eksponensial.

Fase 2: Diagnostik 60 detik - Naha sertipikat saleresna parantos diénggalan dina disk?

Dina kasarna 35 persén produksi Let's Encrypt outages, sertipikat ieu sabenerna renewed on disk sababaraha minggu ka tukang ku certbot.timer atawa acme.sh, Tapi daemon ngajalankeun masih ngalayanan sertipikat kadaluwarsa heubeul ti RAM.

Lengkah 1: Bandingkeun stop kontak jaringan langsung sareng file on-disk

Jalankeun duanana paréntah dina server anjeun: 

# 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

Lengkah 2: Fix 4 umum "Diperbarui dina Disk, Kadaluwarsa dina RAM" sarap

Palayanan / Proxy Naha Éta Ngaladénan Sertifikasi Kadaluwarsa Lawas Saatos Pembaruan Paréntah Pasti pikeun Ngalereskeun Langsung & Permanén
Nginx / Apache certbot dipaké --webroot atawa --standalone (atawa dns-* plugin) tinimbang --nginx, jadi euweuh hook ulang pos-pembaharuan kungsi sinyal prosés master. Lumpat sudo nginx -t && sudo systemctl reload nginx. Tambahkeun hook nyebarkeun permanén di /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh:
systemctl reload nginx (sudo chmod +x naskah).
HAProxy HAProxy merlukeun fullchain.pem AND privkey.pem dihijikeun kana ** tunggal digabungkeun .pem berkas**(combined.pem). Certbot diropéa fullchain.pem jeung privkey.pem, tapi combined.pem masih salinan heubeul 90 poé. Bangun deui bungkusan sareng muat ulang HAProxy:
sudo sh -c 'cat /etc/letsencrypt/live/example.com/fullchain.pem /etc/letsencrypt/live/example.com/privkey.pem > /etc/haproxy/certs/example.com.pem'
sudo chmod 600 /etc/haproxy/certs/example.com.pem && sudo systemctl reload haproxy
** Symlink rusak dina /etc/letsencrypt/live/** Aya anu nyalin sacara manual /etc/letsencrypt/archive/example.com/fullchain3.pem kana /etc/nginx/ssl/ tinimbang nunjuk nginx.conf ka nu /etc/letsencrypt/live/example.com/fullchain.pem symlink, atawa Certbot dijieun duplikat nasab ngaranna /etc/letsencrypt/live/example.com-0001/. Lumpat sudo certbot certificates ningali lamun example.com-0001 dijieun. Punten ssl_certificate di /etc/nginx/ ka nu aktip /etc/letsencrypt/live/<lineage>/fullchain.pem symlink sareng muatkeun deui Nginx.
** Wadah Docker (nginx / traefik / postfix)** OS host renewed /etc/letsencrypt/archive/example.com/fullchain4.pem sareng ngamutahirkeun symlink, tapi wadah Docker ngabeungkeut-dipasang inode file tunggal (anu teu dihubungkeun / diganti) atanapi prosés wadahna di jero rohangan ngaran anu henteu kantos nampi. SIGHUP. Ngabeungkeut-Gunung sakabéh /etc/letsencrypt diréktori (pernah hiji .pem file sabab symlink target robah dina pembaharuan) jeung ngajalankeun docker kill -s HUP <nginx_container>.

Fase 3: Ngalereskeun DNS CAA blok catetan jeung DNSSEC gagalna validasi

Lamun lumpat sudo certbot renew --dry-run sareng tingali: - 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. Kumaha DNS CAA (RFC 8659) blok pembaharuan sertipikat

Unggal Otoritas Sertipikat publik sacara sah diwajibkeun ku CA/Browser Forum Baseline Requirements pikeun naroskeun DNS CAA catetan sateuacan ngaluarkeun sertipikat naon waé. CA walks ** nepi ka tangkal DNS ** ti sub.app.example.com -> app.example.com -> example.com: - Lamun example.com boga ** enol CAA rékaman , sagala CA diwenangkeun ngaluarkeun. - Lamun example.com boga ** malah hiji CAA rékaman (contona, 0 issue "amazon.com" ditambahkeun otomatis lamun batur dijieun distribusi AWS CloudFront, atawa 0 issue "digicert.com"), **unggal Otoritas Sertipikat anu sanés di Bumi dilarang pisan ngaluarkeun sertipikat pikeun example.com atawa salah sahiji subdomains na **. - Salajengna, upami anjeun menta sertipikat Wildcard (*.example.com) jeung domain anjeun nangtukeun hiji husus 0 issuewild "ca.example" tag, CA cek nu issuewild harta tinimbang issue.

Diagnostik sarta fix instan pikeun CAA blok:

  1. Cék CAA rékaman boh dina hostname sareng domain puncak: 
    dig +short CAA sub.example.com
dig +short CAA example.com
  2. Pariksa ogé naha sub.example.com nyaeta a CNAME nunjuk ka domain sejen (Per RFC 8659, CAs ogé pariksa CAA rékaman dina target CNAME).
  3. Dina dasbor panyadia DNS anjeun (Cloudflare, Rute 53, Cloud DNS, Namecheap), ** ulah ngahapus anu aya CAA rékaman ** dipaké ku CDN Anjeun atawa AWS ACM; tibatan, ** append ** tambahan CAA rékaman otorisasi Hayu Encrypt sareng CA cadangan anjeun: 
    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"
    (Catetan: ZeroSSL nganggo sectigo.com salaku identifier CAA dasarna, sareng Google Trust Services nganggo pki.goog.)
  4. Antosan 60 detik kanggo nameservers otoritatif anjeun pikeun ngapdet (dig @ns1.yourdns.com CAA example.com) jeung geura ngajalankeun deui sudo certbot renew. Kusabab CA ngalaksanakeun pamariksaan rekursif langsung ngalangkungan cache umum nalika dicobian deui, penerbitan langsung suksés.

2. Ngalereskeun DNS problem: SERVFAIL looking up CAA (DNSSEC teu cocog)

Hayu Encrypt, Google Trust Services, sareng ZeroSSL mastikeun ngalaksanakeun validasi DNSEC dina sadaya panéangan DNS (A, AAAA, TXT, jeung CAA). Malah lamun domain ngabogaan ** euweuh CAA catetan **, CA kudu nampa hiji cryptographically valid NOERROR (jawaban kosong) atawa NXDOMAIN (NSEC / NSEC3 dioténtikasi panolakan ayana) respon. - Lamun registrar domain anjeun nahan bulukan DS (Penandatangan Delegasi) catetan saatos anjeun migrasi panyadia DNS (contona, pindah ti GoDaddy ka Cloudflare atanapi Rute 53 tanpa nganonaktipkeun DNSSEC heula), rékursif rékursif anu ngalaksanakeun DNSSEC balik SERVFAIL. - Verifikasi dina 5 detik: Jalankeun delv @8.8.8.8 example.com CAA atawa test di dnsviz.net. Lamun dig @8.8.8.8 example.com mulih status: SERVFAIL bari dig +cd @8.8.8.8 example.com (+cd = Mariksa Ditumpurkeun, teu malire DNSSEC) mulih alamat IP anjeun, ** ranté DNSSEC anjeun pegat **. Asup ka registrar domain anjeun geuwat sarta boh miceun bulukan DS ngarekam atawa nyalin arus DS parameter tina host DNS aktif anjeun.

Fase 4: Ngaliwatan Wates Laju Énkripsi Hayu (429 Too Many Requests) nalika pareum aktif

Dina mangsa kajadian kacau, insinyur mindeng balikan deui peti atawa ngajalankeun certbot sababaraha kali nepi ka Hayu Encrypt nampik sadaya pamundut kalayan: - 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

Waktos antosan ti 1 jam (pikeun otorisasina gagal) dugi ka 7 dinten (168 jam) (pikeun wates sertipikat duplikat 5). Ulah ngadagoan 1 jam atawa 7 poé bari situs produksi Anjeun keur down. Anjeun gaduh dua workarounds lengkep sah, saharita:

Workaround A (Pangalusna): Pindahkeun Otoritas Sertipikat ACME ka ZeroSSL, Buypass, atanapi Google Trust Services dina 30 detik

Protokol ACME (RFC 8555) mangrupikeun standar terbuka. Unggal browser utama sareng sistem operasi percanten ZeroSSL (Sectigo root), Buypass Go SSL (Norwegia CA), sareng Google Trust Services (pki.goog) idéntik jeung Hayu urang Énkripsi (ISRG Root X1). Henteu aya anu ngabagi wates laju sareng Let's Encrypt.

  • ** Pilihan 1: Ngaluarkeun langsung via Certbot ngagunakeun Buypass Go SSL (Teu aya akun / konci EAB anu diperyogikeun, validitas 180 dinten)**: (Catetan: Buypass ngadukung sertipikat multi-domain dugi ka 5 SAN, sanaos henteu wildcard *.example.com sertipikat) 
    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
  • ** Pilihan 2: Ngaluarkeun langsung via acme.sh (anu ingkar ka ZeroSSL atanapi ngalihkeun CA sareng --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
  • Pilihan 3: Ngaluarkeun via Google Trust Services (pki.goog) ACME Umum: Dina Google Cloud Console (atanapi via gcloud publicca external-account-keys create), ngahasilkeun Binding Akun Luar gratis (EAB) konci dina 10 detik tur ngajalankeun: 
    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

Workaround B: Leupaskeun wates Hayu Encrypt "5 Duplikat Sertipikat" ku nambahkeun hiji hostname SAN tambahan

Hayu urang Encrypt wates duplikat 168 jam (too many certificates (5) already issued for this exact set of domains) ngalacak set alfabét pasti tina ngaran host SAN dina sertipikat, sedengkeun wates Domain Kadaptar sakabéh nyaéta 50 sertipikat per minggu. 1. Jieun DNS bahya A catetan nunjuk ka server anu sarua: tls-recovery-01.example.com -> <your_server_ip>. 2. Nyuhunkeun sertipikat sareng domain asli anjeun ** ditambah ** nami host énggal: 

sudo certbot certonly --nginx --cert-name example.com \
  -d example.com -d www.example.com -d tls-recovery-01.example.com
(Ngaliwat --cert-name example.com apdet anjeun aya /etc/letsencrypt/live/example.com/ diréktori di tempat jadi Anjeun malah teu kudu ngédit nginx.conf.) Sabab {example.com, tls-recovery-01.example.com, www.example.com} mangrupakeun set brand-anyar domain, Hayu urang Encrypt ngaluarkeun sertipikat langsung.

Fase 5: Ngalereskeun rusak HTTP-01 tantangan (Port 80) atawa ngagunakeun DNS-01 validasi darurat

Iraha certbot renew gagal jeung Timeout during connect (likely firewall problem) atawa Invalid response from http://example.com/.well-known/acme-challenge/...: 404 (atawa 403), server validasi CA teu tiasa ngahontal token tantangan HTTP anjeun dina port TCP 80.

Naha HTTP-01 dumadakan ngarecah dina server nu digawé 60 days ago

  1. **Grup Kaamanan Cloud / UFW / iptables ditutup Port 80 **: Batur hardened firewall pikeun ngidinan wungkul port 443 (HTTPS), poho yén RFC 8555 HTTP-01 validasi ** salawasna dimimitian dina port HTTP polos 80 ** (sanajan bakal nuturkeun a 301 alihan ka https:// dina palabuhan 443).
  2. ** IPv6 pegat (AAAA) Rékam**: Domain anjeun gaduh duanana IPv4 (A) catetan jeung IPv6 (AAAA) rékaman. Hayu urang Encrypt ** sok resep IPv6 (AAAA) heula**. Lamun alamat IPv6 anjeun misrouted, diblokir ku ip6tables, atanapi henteu kabeungkeut dina Nginx (listen [::]:80;), validasi kali kaluar sanajan IPv4 jalan hade.
  3. Nginx / Router Aplikasi (React / Next.js / Django / Rails) ngahalangan /.well-known/acme-challenge/: Anjeun server Blok dina port 80 proxy sadaya lalu lintas (location / { proxy_pass http://localhost:3000; }) kana aplikasi backend tinimbang ngalayanan .well-known ti disk.

Dua perbaikan instan pikeun rusak HTTP-01 validasi

Fix 1: Tambihkeun prioritas tinggi khusus /.well-known/acme-challenge/ blok di Nginx (Port 80)

Pastikeun port 80 anjeun diblokir /etc/nginx/sites-enabled/ porsi tokens ACME langsung ti /var/www/letsencrypt ** sateuacan ** sagala return 301 https://... atawa proxy_pass diréktif: 

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;
    }
}
Teras jieun folder sareng ngaluarkeun: 
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

Fix 2: Bypass Port 80 sareng server wéb lengkep sareng manual DNS-01 (TXT) tantangan

Upami port 80 dipeungpeuk ku ISP/firewall hulu atanapi penyeimbang beban anjeun teu tiasa dijalankeun .well-known ka sababaraha titik backend, sangkan méré konfirmasi via DNS dina 2 menit: 

sudo certbot certonly --manual --preferred-challenges dns -d example.com -d "*.example.com"
Certbot bakal ngareureuhkeun sareng ningalikeun: Please deploy a DNS TXT record under the name: _acme-challenge.example.com with the following value: XyZ123... 1. Buka konsol DNS anjeun sareng jieun TXT rékaman _acme-challenge kalawan a 60 TTL kadua. 2. **Antosan sareng pariksa dina jandela terminal kadua sateuacan pencét Lebetkeun *: 
dig +short TXT _acme-challenge.example.com @8.8.8.8
3. sakali dig prints string token pasti anjeun, pencét ** Lebetkeun ** di Certbot. Sertipikat anjeun sareng konci pribadi bakal diserat /etc/letsencrypt/live/example.com/ geuwat. * (Saatos outage direngsekeun, pasang plugin DNS otomatis sapertos python3-certbot-dns-cloudflare atawa python3-certbot-dns-route53 jadi renewals hareup teu merlukeun manual TXT asupna.)

Fase 6: Verifikasi saatos pamulihan (Ranté Panengah, Stapling OCSP, sareng Purge CDN)

Kasalahan umum saatos ngagantian sertipikat darurat dipasang cert.pem (nu sertipikat daun nyalira) tinimbang fullchain.pem (sertipikat daun + sertipikat CA panengah). browser desktop (Chrome, Firefox) sering masker sertipikat panengah leungit via AIA (Authority Information Access) ngudag atawa sindangan perantara, bari curl, Python, OpenSSL, aplikasi Android, sareng Stripe/Twilio webhooks langsung gagal unable to verify the first certificate (SSL certificate problem: unable to get local issuer certificate).

  • Parios yén server anjeun ngirimkeun Ranté Perantara lengkep (fullchain.pem): ngajalankeun: 
    echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | grep -E "Verify return code|depth="
    Anjeun kedah ningali sahenteuna dua tingkat (depth=0 domain anjeun sarta depth=1 CA panengah sapertos Let's Encrypt E5/R11 atawa ZeroSSL RSA Domain Secure Site CA) jeung Verify return code: 0 (ok). Lamun ningali Verify return code: 21 (unable to verify the first certificate), ngarobah config server wéb anjeun tina cert.pem ka fullchain.pem.
  • ** Hapus cache OCSP Stapling basi dina Nginx / Apache **: Lamun ssl_stapling on; diaktipkeun, ngamuat pangladén wéb sareng pariksa openssl s_client -servername example.com -connect example.com:443 -status 2>/dev/null | grep -A 15 "OCSP response".
  • ** Konpigurasikeun ngawaskeun kadaluwarsa SSL multi-lapisan (Cék TCP éksternal + Prometheus blackbox_exporter)**: Ulah ngan ukur ngandelkeun panginget email (Hayu Encrypt email panginget kadaluwarsa di 2025). Monitor port live 443 stop kontak éksternal (probe_ssl_earliest_cert_expiry - time() < 86400 * 14) tur nyetel cron cron poean on sudo certbot renew --dry-run.

Nomer darurat régional sareng protokol agénsi

Nalika sertipikat TLS anu kadaluwarsa biasana direngsekeun ku tim rékayasa, gangguan sertipikat anu ngarecah portal kasehatan, webhooks pangiriman darurat, auténtikasi perbankan, atanapi infrastruktur umum pamaréntah tiasa memicu alur kerja kajadian pangaturan:

  • Amérika Serikat jeung Kanada:
  • Kaamanan-Kahirupan / Klinis / Pareum Pangiriman: Telepon 911 upami gagalna sertipikat TLS ngeureunkeun telemétri pasien, e-resep, atanapi komunikasi pangiriman darurat.
  • Badan Kaamanan Siber sareng Infrastruktur (CISA) (AS): Agénsi sipil féderal dina CISA Binding Operational Directive (BOD) 18-01 sarta operator infrastruktur kritis ngalaman penerbitan sertipikat teu sah (kompromi CA atawa BGP/DNS hijacking) kudu ngalaporkeun ka 1-844-Say-CISA (1-844-729-2472) atawa cisa.gov/report.
  • Puseur Kanada pikeun Kaamanan Siber: Kontak 1-833-CYBER-88 (1-833-292-3788).
  • Karajaan Inggris:
  • Layanan Darurat: Telepon 999 upami gangguan TLS mangaruhan sistem klinis NHS kritis atanapi kaamanan hirup.
  • Pusat Kaamanan Siber Nasional (NCSC): Upami anjeun mendakan sertipikat anu teu sah dikaluarkeun pikeun domain anjeun dina Transparansi Sertipikat (crt.sh) log nunjukkeun pangbajak DNS, ngalaporkeun via ncsc.gov.uk.
  • Uni Éropa:
  • Layanan Darurat: Telepon 112 di sadaya nagara anggota EU.
  • Diréktif NIS2 & Sertipikat Auténtikasi Situs Web Kualifikasi eIDAS (QWACs): Éntitas ésénsial sareng penting dina Diréktif NIS2 anu ngalaman gangguan kasadiaan anu berkepanjangan atanapi konci PKI badami kedah ngabéjaan CSIRT nasionalna dina 24 jam.
  • Australia jeung Selandia Anyar:
  • Layanan Darurat: Telepon 000 di Australia atanapi 111 di Selandia Anyar; hubungi ACSC (1300 CYBER1) pikeun kajadian infrastruktur.
  • India jeung Asia-Pasifik:
  • India (CERT-In / Controller of Certifying Otoritas CCA): Telepon 112 pikeun tanggap darurat; ngalaporkeun kompromi PKI atanapi outages infrastruktur signifikan ka incident@cert-in.org.in dina 6 jam.

Patarosan anu sering ditaroskeun

Naha kuring atanapi pangguna kuring henteu tiasa ngaklik "Advanced -> Teraskeun ka situs (teu aman)" dina Chrome atanapi Safari salami pareum ieu?

Nalika domain anjeun ngirimkeun Ketat-Angkutan-Kaamanan (HSTS) lulugu HTTP - atawa ngagunakeun domain tingkat luhur kawas .dev, .app, .kaca, atawa .bank anu hardcoded kana browser HSTS Preload List - RFC 6797 merlukeun browser pikeun ngubaran sagala sertipikat kadaluwarsa, timer ditandatanganan, atawa mismatched salaku kasalahan fatal non-recoverable. Panyungsi ngahaja ngahapus tombol bypass "Teruskeun waé" pikeun nyegah panyerang Man-in-the-Middle (MitM) aktip tina nipu pangguna pikeun ngaklik sertipikat palsu. Sedengkeun pamekar dina desktop Chrome bisa ngetik runtuyan keyboard disumputkeun ieu aman langsung dina layar kasalahan pikeun bypass eta lokal pikeun nguji, pamaké nyata teu bisa; Anjeun kudu masang sertipikat valid dina port 443.

Hayu urang Encrypt dieureunkeun ngirim surelek peringatan kadaluwarsa na cert abdi kadaluwarsa tanpa aya bewara - naha éta kajadian?

Hayu urang Encrypt sacara resmi pensiunan layanan email béwara béakna dina pertengahan 2025 pikeun ngirangan panyimpen data overhead sareng kusabab pangaturan ACME otomatis kedah ngawas kaséhatan pembaharuan langsung. Pikeun nyegah kejutan ka hareup, anjeun kedah ngawas cap waktu béakna TLS sasalaman saleresna dina jaringan nganggo monitor uptime éksternal (sapertos Prometheus. blackbox_exporter, Uptime Kuma, Better Stack, atawa Datadog Synthetic TLS cék) ngageter dina 21 poé, 14 poé, jeung 7 poé saméméh. teu Sanggeus.

Naha situs abdi tiasa dianggo saé dina Chrome sareng Firefox dina laptop abdi, tapi gagal dina telepon Android, curl, sarta Stripe webhooks sanggeus kuring diropéa sertipikat?

Anjeun ngonpigurasi pangladén wéb anjeun (ssl_sertipikat dina Nginx atawa SSLCertificateFile dina Apache) pikeun nunjuk ka cert.pem (nu sertipikat daun nyalira) tinimbang fullchain.pem (sertipikat daun dibuntel sareng sertipikat CA Perantara). Panyungsi desktop sapertos Chrome sareng Firefox sacara otomatis ngaunduh sertipikat perantara anu leungit dina latar tukang nganggo Aksés Inpormasi Otoritas (AIA) URL di jero sertipikat daun anjeun, nyumputkeun salah konfigurasi server anjeun. Tapi, ngagulung, OpenSSL, verifikasi kapercayaan sistem Android, Python, sareng server webhook henteu ngalaksanakeun AIA ngudag sareng langsung nampik sambungan sareng teu tiasa nampi sertipikat penerbit lokal. Arah config anjeun ka fullchain.pem sareng muatkeun deui server anjeun.

Kumaha kuring pariksa naha hacker atanapi admin jahat ngaluarkeun sertipikat SSL anu henteu sah pikeun domain kuring?

Unggal Otoritas Sertipikat anu dipercaya ku masarakat diwajibkeun pikeun asup unggal sertipikat anu dikaluarkeun ka umum Log Sertipikat Transparansi (CT). (RFC 6962) sateuacan panyungsi bakal percanten. Buka https://crt.sh/?q=%25.yourdomain.com atanapi Monitor Transparansi Sertipikat Cloudflare pikeun ningali unggal sertipikat anu kantos dikaluarkeun pikeun domain anjeun sareng subdomainna. Upami anjeun ningali sertipikat anu dikaluarkeun ku CA anu teu biasa anu anjeun henteu otorisasi, langsung pariksa pendaptaran DNS anjeun sareng zona DNS anu otoritatif pikeun modifikasi anu henteu sah, cabut sertipikat jahat sareng CA anu ngaluarkeun, sareng konci DNS anjeun nganggo CAA rékaman (`0 issue "letsencrypt.org"`).

Kumaha lamun Kubernetes klaster urang cert-manager gagal nganyarkeun sertipikat Ingress kami sareng Orde macét Pending?

Lumpat kubectl meunang pesenan, tantangan -A lajeng kubectl ngajelaskeun tantangan -n . Dina 90 persén Kubernetes sertipikat-manajer outages, éta cm-acme-http-solver-* pod samentara jalan, tapi boh (1) sumberdaya Ingress boga annotation kelas ingress luntur jadi jalur solver pernah napel load balancer Anjeun, (2) a Kubernetes Kabijakan Jaringan ngahalangan lalu lintas asup ka pod solver dina port 8089, atanapi (3) masalah DNS-pin rambut NAT / split-horizon DNS nyegah sertipikat-manajerPamariksaan diri internal tina ngahontal IP balancer beban publik anjeun (bisa dilereskeun ku lulus --dns01-recursive-nameservers = 8.8.8.8:53,1.1.1.1:53 ka nu sertipikat-manajer args penyebaran).

Dupi abdi tiasa nyalin abdi /etc/letsencrypt/ folder ka server anyar salila migrasi darurat tinimbang ulang ngaluarkeun?

Sumuhun. Upami server primér anjeun maot sareng anjeun migrasi ka server énggal bari dibatesan ku Let's Encrypt, jaga symlink nalika nyalin /etc/letsencrypt/ ngagunakeun tar -czpf letsencrypt_backup.tar.gz /etc/letsencrypt (henteu pernah nganggo polos scp -r, nu ngarobah symlinks di /etc/letsencrypt/live/ kana duplikat file statik sarta megatkeun pembaharuan hareup). Ékstrak arsip éta kana server énggal (`sudo tar -xzpf letsencrypt_backup.tar.gz -C /`), nunjuk Nginx / Apache kana `/etc/letsencrypt/live/domain/fullchain.pem`, sareng sertipikat anjeun anu tos aya bakal langsung dianggo dina alamat IP énggal.

Panungtun patali

Sumber jeung hidayah resmi

  • Satgas Téknik Internét (IETF): *RFC 8555 (Lingkungan Manajemén Sertipikat Otomatis / ACME), RFC 8659 (Otorisasi Otoritas Sertifikasi DNS / CAA), sareng RFC 6797 (HTTP Kaamanan Angkutan Ketat / HSTS) *.
  • Institut Standar sareng Téknologi Nasional (NIST) (Amérika Serikat): * Publikasi husus 800-52 Wahyu 2: Tungtunan pikeun Pamilihan, Konfigurasi, sarta Mangpaat Palaksanaan Kaamanan Lapisan Angkutan (TLS) & SP 1800-16: Ngamankeun Transaksi Web: Manajemén Sertipikat Server TLS *.
  • Grup Panaliti Kaamanan Internét (ISRG / Hayu urang Encrypt Dokumén Resmi): * Rate Watesan Rujukan, Duplikat Aturan Sertipikat, sarta ACME Challenge Troubleshooting *.
  • Badan Kaamanan Siber sareng Infrastruktur (CISA) (Amérika Serikat): Diréktif Operasional beungkeutan 18-01: Ningkatkeun Email sareng Kaamanan Wéb (HTTPS sareng Pitunjuk Palaksanaan HSTS).
  • Puseur Kaamanan Siber Nasional (NCSC) (Britania Raya): Maké TLS pikeun Nangtayungan Data Sampurna dina Transit sareng Bimbingan Pangimeutan Transparansi Sertipikat.