Notifikasi Kedaluwarsa Sertifikat SSL: Tidak Ada Lagi yang Mengirimimu Email

Let's Encrypt berhenti mengirim email kedaluwarsa dan sertifikat kini 200 hari. Skrip openssl teruji, ambang batas yang tepat, dan notifikasi yang sampai.

Diperbarui

Daftar Isi

Ada dua hal yang berubah di bawah tumpukan sertifikat semua orang, dan sebagian besar tim belum menyesuaikan diri terhadap keduanya.

Pertama, jaring pengamannya dilepas. Let's Encrypt menutup layanan notifikasi kedaluwarsa pada 4 Juni 2025 — email yang diam-diam menyelamatkan ribuan situs setiap kali otomatisasi rusak. Alasannya masuk akal (sebagian besar pelanggan sudah memperpanjang otomatis, menyimpan jutaan alamat email adalah beban privasi, dan layanannya menghabiskan "puluhan ribu dolar per tahun"), dan pengumumannya ditutup dengan saran mencari pemantauan pihak ketiga (Let's Encrypt). Banyak orang membaca itu, setuju, lalu tidak pernah mengerjakan bagian keduanya.

Kedua, margin kesalahannya runtuh. Sejak 15 Maret 2026, sertifikat TLS publik paling lama berlaku 200 hari, turun menjadi 100 hari pada 15 Maret 2027 dan 47 hari pada 15 Maret 2029 berdasarkan ballot SC-081v3 CA/Browser Forum. Let's Encrypt bergerak lebih cepat dari batas itu: sertifikat 6 hari tersedia umum sejak 15 Januari 2026, dan rencananya membawa profil bawaan ke 64 hari pada Februari 2027 serta 45 hari pada Februari 2028 (Let's Encrypt).

Kedua perubahan itu mendorong ke arah yang sama. Perpanjangan terjadi lebih sering, jadi lebih banyak kesempatan untuk rusak — dan ketika rusak, tidak ada yang mengirimimu surat. Panduan ini adalah pemeriksaan yang menutup celah tersebut: skrip shell yang sudah diuji, ambang batas yang masuk akal untuk sertifikat berumur pendek, dan cara membuat kasus terakhir membunyikan teleponmu lewat Echobell.

Seberapa parah sebenarnya gangguan akibat sertifikat?

Cukup parah sehingga lebih dari sepertiga organisasi mengalaminya tahun lalu. Dalam 2026 Global Certificate Management Outlook milik DigiCert — survei Propeller Insights terhadap 1.001 pengambil keputusan TI dan keamanan siber di AS, Inggris, dan Australia, dilakukan Mei 2026 — lebih dari sepertiga organisasi melaporkan gangguan layanan akibat sertifikat kedaluwarsa dalam setahun terakhir. Hampir tiga perempat mengumpulkan setidaknya lima jam downtime terkait sertifikat, satu dari lima mencapai 25 jam atau lebih, dan hampir satu dari empat menyebut insiden sertifikat terparahnya merugikan lebih dari 250.000 dolar (DigiCert).

Bagian menarik dari angka itu adalah durasinya. Lima jam bukan waktu yang dibutuhkan untuk memperpanjang sertifikat — perpanjangan hanya butuh hitungan detik. Lima jam adalah waktu yang dibutuhkan seseorang untuk mengetahuinya.

Kenapa perpanjangan otomatis saja tidak cukup?

Karena otomatisasi perpanjangan gagal tanpa suara, dan cron yang berhenti berjalan sama sekali tidak menghasilkan keluaran. Semua kasus berikut nyata dan umum, dan tidak satu pun bersuara:

  • Timer-nya sudah tidak jalan. Upgrade distribusi, container yang dibangun ulang, atau systemctl disable tiga bulan lalu yang tidak diingat siapa pun. certbot.timer yang tidak menyala terlihat persis seperti yang menyala dengan sukses.
  • Perpanjangan berhasil tetapi layanannya tidak pernah reload. Sertifikat baru sudah ada di disk; nginx, HAProxy, atau Postfix masih memegang yang lama di memori. Ini cara paling umum sebuah setup "otomatis penuh" tetap kedaluwarsa.
  • Jalur challenge rusak. Seseorang menambahkan redirect, aturan WAF, atau Deny di depan /.well-known/acme-challenge/, sehingga HTTP-01 gagal. Atau token API penyedia DNS untuk DNS-01 sudah kedaluwarsa.
  • Perpanjangan hanya terjadi di satu node. Dua load balancer, satu cron. Yang kedua terus menyajikan sertifikat lama sampai tidak bisa lagi.
  • Sertifikatnya bahkan tidak ada di web server. Klien mTLS internal, broker Kafka, server LDAP, konsentrator VPN, sertifikat push manajemen perangkat. Tidak ada yang melihatnya dari internet publik dan tidak ada klien ACME yang mengelolanya.
  • Perpanjangan dipaku ke interval yang salah. Let's Encrypt menyatakannya terang-terangan: "memperpanjang pada interval tetap 60 hari tidak akan lagi memadai" begitu profil bawaan turun ke 64 lalu 45 hari (Let's Encrypt).

Yang terakhir layak ditekankan, karena itulah kegagalan yang sedang didorong kalender ke arah semua orang. Kalau ritme perpanjanganmu adalah angka yang diketik seseorang pada 2022, masa berlaku sertifikat kini justru berjalan mendekati angka itu.

Bagaimana memeriksa masa berlaku sertifikat dari baris perintah?

Satu pipeline openssl, tanpa dependensi. Untuk host yang hidup:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -startdate -enddate

Untuk berkas di disk:

openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -enddate

Opsi -servername tidak opsional pada IP bersama — tanpa SNI kamu mendapat sertifikat yang dianggap server sebagai bawaannya, yang mungkin bukan sertifikat yang kamu khawatirkan.

Untuk jawaban ya/tidak, lewati saja penguraian tanggal. openssl x509 -checkend <detik> keluar dengan 0 jika sertifikat bertahan melewati jendela itu dan 1 jika kedaluwarsa di dalamnya (termasuk jika sudah kedaluwarsa):

openssl x509 -in fullchain.pem -noout -checkend $((14 * 86400)) \
  || echo "kedaluwarsa dalam 14 hari"

Kontrak kode keluar itulah keseluruhan primitif pemantauannya. Semua yang di bawah ini hanya perpipaan di sekitarnya.

Menangkap kasus "sudah diperpanjang tapi belum reload"

Bandingkan yang ada di disk dengan yang benar-benar disajikan. Ini pemeriksaan yang nyaris tidak pernah dijalankan siapa pun, dan justru menangkap kegagalan yang tak bisa dilihat otomatisasi perpanjangan:

served=$(openssl s_client -connect 127.0.0.1:443 -servername example.com </dev/null 2>/dev/null \
         | openssl x509 -noout -fingerprint -sha256)
ondisk=$(openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -fingerprint -sha256)

[ "$served" = "$ondisk" ] || echo "layanan masih menyajikan sertifikat lama — perlu reload"

Kedua perintah mencetak format yang identik, sha256 Fingerprint=AB:CD:..., jadi perbandingan string biasa sudah cukup. Jalankan beberapa menit setelah jendela timer perpanjanganmu.

Ambang batas apa yang sebaiknya dipakai notifikasi sertifikat?

Pecahan dari masa hidup sertifikat, bukan jumlah hari tetap. Aturan "peringatkan pada 30 hari" masuk akal untuk sertifikat 90 hari. Diterapkan pada sertifikat 47 hari, ia berbunyi untuk sertifikat yang sepenuhnya sehat; diterapkan pada sertifikat 6 hari, ia berbunyi terus-menerus.

Sebagai gantinya, tambatkan tangganya pada titik perpanjangan. Let's Encrypt menyarankan memperpanjang "kira-kira setelah dua pertiga masa hidup sertifikat saat ini" — jadi sepertiga sisa masa hidup adalah saat perpanjangan seharusnya sudah terjadi. Semua setelah titik itu adalah bukti bahwa itu tidak terjadi:

Sisa masa hidupArtinyaJenis notifikasi
1/3Jendela perpanjangan terbukaTidak ada — ini normal
1/6Jendela terlewat sekaliPush biasa
1/12Perpanjangan gagal, bukan terlambatTime Sensitive
< 1/24, kedaluwarsa, atau tak terjangkauKamu tinggal beberapa jam dari gangguanPanggilan

Dalam angka konkret, untuk sertifikat 47 hari kira-kira begini: diam sampai 7,8 hari, push di 3,9 hari, time sensitive di 2 hari, panggilan di bawah 1 hari. Untuk sertifikat 90 hari: 15 hari, 7,5 hari, 3,75 hari. Untuk sertifikat 6 hari satuannya jam, dan tangga untuk manusia berhenti menjadi alat yang tepat — andalkan ACME Renewal Information (ARI, diterbitkan sebagai RFC 9773), yang membiarkan CA memberi tahu klienmu kapan harus memperpanjang, lalu beri notifikasi hanya saat klien gagal berulang kali.

Menghitung pecahannya cukup empat baris, dan itu membuat skrip yang sama benar untuk setiap sertifikat yang kamu punya, apa pun penerbitnya:

to_epoch() {
  date -u -d "$1" +%s 2>/dev/null || date -u -j -f '%b %d %T %Y %Z' "$1" +%s 2>/dev/null
}

pct_left() {  # membaca PEM dari stdin, mencetak persentase sisa masa hidup
  local pem nb na
  pem=$(cat)
  nb=$(to_epoch "$(printf '%s' "$pem" | openssl x509 -noout -startdate | cut -d= -f2)")
  na=$(to_epoch "$(printf '%s' "$pem" | openssl x509 -noout -enddate | cut -d= -f2)")
  echo $(( (na - $(date -u +%s)) * 100 / (na - nb) ))
}

Bentuk date pertama adalah GNU, yang kedua BSD/macOS; || memilih mana pun yang kamu punya.

Bagaimana mengubah ini menjadi notifikasi yang benar-benar sampai?

Echobell mengubah webhook atau email menjadi push biasa, notifikasi time sensitive, atau panggilan telepon sungguhan yang menembus Focus Mode dan Do Not Disturb (lihat menembus Focus Mode iOS). Untuk sertifikat itu penting, karena anak tangga terakhir pada tabel di atas justru yang akan kamu injak pukul 03.00 hari Minggu.

Langkah 1 — Buat dua channel, bukan satu

Buat channel di aplikasi, atur jenis notifikasinya ke Time Sensitive, dan beri nama "Sertifikat akan kedaluwarsa". Buat channel kedua dengan jenis Panggilan dan beri nama "Sertifikat hampir kedaluwarsa". Salin URL webhook masing-masing dari detail channel; bentuknya https://hook.echobell.one/t/<channel-token>. Perlakukan sebagai rahasia — siapa pun yang memegang URL Panggilan bisa membunyikan teleponmu (panduan webhook).

Tulis templatenya agar notifikasi bisa langsung ditindaklanjuti dari layar kunci tanpa membuka apa pun:

Judul: TLS {{state}}: {{host}}
Isi: sisa {{daysLeft}} hari, kedaluwarsa {{notAfter}} — diterbitkan oleh {{issuer}}

Setiap kunci JSON yang kamu kirim menjadi variabel (template).

Langkah 2 — Jalankan pemeriksaannya

Ini skrip dari bagian-bagian di atas, dirakit dan diuji dari ujung ke ujung. Simpan sebagai /usr/local/bin/cert-watch:

#!/usr/bin/env bash
# cert-watch — kirim POST ke Echobell saat sertifikat TLS mendekati kedaluwarsa.
set -uo pipefail

HOOK="${ECHOBELL_CERT_HOOK:?setel ECHOBELL_CERT_HOOK ke URL webhook channel-mu}"
WARN_DAYS="${WARN_DAYS:-14}"

post() {
  curl -sS -m 10 -X POST "$HOOK" \
    -H 'content-type: application/json' \
    -d "{\"host\":\"$1\",\"daysLeft\":$2,\"notAfter\":\"$3\",\"state\":\"$4\"}" \
    >/dev/null
}

days_left() {
  local end
  end=$(date -u -d "$1" +%s 2>/dev/null) ||
    end=$(date -u -j -f '%b %d %T %Y %Z' "$1" +%s 2>/dev/null) || return 1
  echo $(( (end - $(date -u +%s)) / 86400 ))
}

check() {
  local host="$1" port="$2" pem state not_after days

  pem=$(openssl s_client -connect "$host:$port" -servername "$host" \
        </dev/null 2>/dev/null | openssl x509 2>/dev/null)

  if [ -z "$pem" ]; then
    post "$host" 0 "" "unreachable"
    return
  fi

  if printf '%s' "$pem" | openssl x509 -noout -checkend 0 >/dev/null 2>&1; then
    printf '%s' "$pem" | openssl x509 -noout -checkend $((WARN_DAYS * 86400)) >/dev/null 2>&1 && return 0
    state="expiring"
  else
    state="expired"
  fi

  not_after=$(printf '%s' "$pem" | openssl x509 -noout -enddate | cut -d= -f2)
  days=$(days_left "$not_after") || days=-999
  post "$host" "$days" "$not_after" "$state"
}

for target in "$@"; do
  case "$target" in
    *:*) check "${target%:*}" "${target##*:}" ;;
    *) check "$target" 443 ;;
  esac
done

Ia melaporkan tiga keadaan — expiring, expired, dan unreachable — dan diam saat semuanya baik-baik saja. Target ditulis sebagai host atau host:port, jadi sertifikat non-web pun ikut tercakup:

ECHOBELL_CERT_HOOK="https://hook.echobell.one/t/<token>" \
  cert-watch example.com api.example.com mail.example.com:993 ldap.internal:636

unreachable sengaja dijadikan notifikasi, bukan dilewati diam-diam. Pemeriksaan yang memperlakukan "saya tidak bisa melihat" sebagai "semuanya baik" justru penyebab sertifikat kedaluwarsa sejak awal.

Langkah 3 — Jadwalkan, dan beri notifikasi saat penjadwalannya sendiri gagal

Sekali sehari cukup untuk sertifikat 45 hari ke atas; dua kali sehari jika kamu memakai sertifikat 6 hari. Timer systemd:

# /etc/systemd/system/cert-watch.service
[Unit]
Description=TLS certificate expiry check

[Service]
Type=oneshot
EnvironmentFile=/etc/echobell.env
ExecStart=/usr/local/bin/cert-watch example.com api.example.com mail.example.com:993
# /etc/systemd/system/cert-watch.timer
[Unit]
Description=Daily TLS certificate expiry check

[Timer]
OnCalendar=daily
RandomizedDelaySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true itu penting: tanpanya, mesin yang mati pada waktu terjadwal akan melewatkan eksekusi itu begitu saja.

Lalu tutup lingkarannya pada pemeriksaan itu sendiri. Unit Type=oneshot yang keluar dengan kode bukan nol memicu OnFailure=, jadi satu drop-in membuat perpanjangan yang rusak mengumumkan dirinya sendiri:

# /etc/systemd/system/certbot.service.d/echobell.conf
[Unit]
OnFailure=echobell-alert@%n.service
# /etc/systemd/system/echobell-alert@.service
[Unit]
Description=Echobell alert for %i

[Service]
Type=oneshot
EnvironmentFile=/etc/echobell.env
ExecStart=/usr/local/bin/echobell-notify %i

Dengan /usr/local/bin/echobell-notify sepanjang tiga baris:

#!/usr/bin/env bash
curl -sS -m 10 -X POST "$ECHOBELL_CERT_HOOK" \
  -H 'content-type: application/json' \
  -d "{\"host\":\"$(hostname -f)\",\"state\":\"renewal-failed\",\"unit\":\"$1\",\"daysLeft\":-1}"

certbot renew keluar dengan kode bukan nol saat ada perpanjangan yang gagal — persis sinyal yang kamu inginkan, dan persis sinyal yang saat ini tidak sampai ke mana-mana. Perlu dicatat, --deploy-hook milik certbot hanya berjalan saat berhasil, jadi tidak bisa dipakai untuk ini; jalur kegagalan harus datang dari unit.

Langkah 4 — Pisahkan tangganya dengan kondisi

Kedua channel menerima payload yang sama; kondisi menentukan mana yang benar-benar berbunyi. Pada channel Time Sensitive:

state == "expiring" && daysLeft > 3

Pada channel Panggilan:

state == "expired" || state == "unreachable" || state == "renewal-failed" || daysLeft <= 3

Perhatikan bahwa <= mengonversi kedua sisi dengan Number(), jadi daysLeft yang dikirim sebagai string tetap dibandingkan secara numerik. Kondisi tidak punya operator "mengandung" — itulah sebabnya skrip mengirim field state yang eksplisit, bukan teks bebas yang harus kamu cocokkan polanya.

Langkah 5 — Uji sebelum mempercayainya

Arahkan skrip ke host dengan sertifikat yang memang diketahui bermasalah dan lihat notifikasinya datang:

ECHOBELL_CERT_HOOK="https://hook.echobell.one/t/<token>" cert-watch expired.badssl.com

Lakukan dengan Do Not Disturb aktif di ponsel yang benar-benar akan menerimanya, dan nyalakan Ulangi Panggilan Gagal di aplikasi agar panggilan yang ditahan Focus Mode dicoba lagi. Jalur eskalasi yang belum pernah kamu picu hanyalah tebakan.

Bagaimana kalau pemantauanku sudah memeriksa sertifikat?

Kalau begitu sambungkan webhook yang sudah ada ke sebuah channel dan lewati skripnya. Sebagian besar sistem pemantauan sudah tahu tanggal kedaluwarsa; yang biasanya kurang adalah jalur yang sanggup melewati manusia yang sedang tidur.

  • Uptime Kuma punya notifikasi kedaluwarsa sertifikat bawaan — arahkan saja ke sebuah channel (panduan Uptime Kuma, setup panggilan).
  • Prometheus + Alertmanager dengan blackbox exporter memberimu probe_ssl_earliest_cert_expiry; buat aturan di metrik itu dan rutekan ke channel (panduan Prometheus, panggilan lewat Alertmanager).
  • Aturan notifikasi Grafana bisa POST langsung ke channel (panduan Grafana).
  • Upptime dan UptimeRobot menutupi endpoint publik (Upptime, UptimeRobot).
  • Apa pun yang hanya mengirim email — portal CA itu sendiri, pemberitahuan ACM dari penyedia cloud, PKI internal — cukup dengan aturan penerusan. Setiap channel punya alamatnya sendiri, dan from, to, subject, text, serta html tersedia sebagai variabel (pemicu email).

Satu hal yang tidak bisa digantikan oleh semua itu adalah pemeriksaan yang berjalan dari luar mesin yang menyajikan sertifikatnya. Kalau pemantauanmu tinggal di host yang sama, kegagalan yang menjatuhkan host itu ikut membawa notifikasinya.

Yang tidak dilakukan Echobell

Ketepatan penting di sini, karena manajemen sertifikat adalah kategori yang penuh produk yang melakukan jauh lebih banyak dari ini.

Echobell melakukan: mengubah webhook atau email menjadi push biasa, notifikasi time sensitive, atau panggilan berdering; menyaring dengan kondisi; memformat dengan template; mengirim satu pemicu ke setiap pelanggan channel bersama, masing-masing memilih tingkat urgensinya sendiri.

Echobell tidak melakukan:

  • Menemukan atau menginventarisasi sertifikatmu. Ia tidak memindai jaringanmu, tidak menyisir log certificate transparency, dan tidak akan memberi tahu soal sertifikat yang tak seorang pun ingat pernah diterbitkan. Skrip di atas hanya memeriksa host yang kamu daftarkan. Persebaran sertifikat adalah masalah nyata, dan ini bukan solusinya.
  • Memperpanjang apa pun. Tidak ada klien ACME dan tidak ada akses ke kuncimu. Ia memberi tahu bahwa perpanjangan rusak; memperbaikinya tetap urusanmu.
  • Memeriksa sertifikat atas jadwalnya sendiri. Tidak ada probe yang dihosting. Sesuatu yang kamu jalankan — timer, job CI, pemantauan yang sudah ada — harus pergi melihat.
  • Menyediakan rotasi on-call, kebijakan eskalasi, atau konfirmasi. Tidak ada "kalau lima menit tidak diangkat, telepon orang berikutnya". Kalau butuh itu, kamu butuh platform insiden — lihat perbandingan alternatif Opsgenie.
  • Menjamin pengiriman. Panggilan bergantung pada infrastruktur push, jaringan, dan ponsel yang terisi daya. Ia memperpendek jarak antara kerusakan dan kesadaran; bukan kendali yang bisa disandari mutlak.

Pertanyaan umum

Apakah Let's Encrypt benar-benar berhenti mengirim email kedaluwarsa?

Ya. Layanan notifikasi kedaluwarsa berakhir pada 4 Juni 2025, dan Let's Encrypt menghapus alamat email yang disimpan bersama catatan penerbitan. Pengumumannya merekomendasikan pemantauan pihak ketiga dan menyebut Red Sift Certificates Lite, gratis hingga 250 sertifikat, sebagai salah satu opsi. Kalau kamu sudah lebih dari setahun tidak menerima peringatan kedaluwarsa dari Let's Encrypt, itulah sebabnya — bukan karena tidak ada yang mendekati kedaluwarsa.

Berapa lama sertifikat TLS berlaku pada 2026?

Maksimal 200 hari untuk sertifikat TLS yang dipercaya publik, sejak 15 Maret 2026. Batas itu turun ke 100 hari pada 15 Maret 2027 dan 47 hari pada 15 Maret 2029 berdasarkan ballot SC-081v3. Masing-masing CA menerbitkan di bawah batas demi keamanan — DigiCert, misalnya, menerbitkan sertifikat 199 hari justru "untuk menghindari melampaui masa berlaku maksimum yang diizinkan". Let's Encrypt melangkah lebih jauh dan lebih cepat dengan jadwalnya sendiri, dengan sertifikat 6 hari tersedia umum sejak Januari 2026.

Kalau saya memakai ARI, apakah tetap perlu notifikasi kedaluwarsa?

Perlu, tetapi untuk peristiwa yang berbeda. ARI (RFC 9773) memberi tahu klien ACME-mu kapan memperpanjang, yang sepenuhnya menghapus mode kegagalan interval tetap — tetapi ia tidak menjamin perpanjangannya berhasil, layanannya reload, atau klienmu masih berjalan. Beri notifikasi untuk kegagalan perpanjangan berulang dan untuk sertifikat yang disajikan berbeda dari yang ada di disk, bukan untuk hitung mundur yang tidak perlu lagi kamu kelola.

Bagaimana dengan sertifikat yang tidak ada di web server?

Justru itu yang paling sering kedaluwarsa, karena tidak ada klien ACME yang mengawasinya dan tidak ada browser yang protes sampai ada yang rusak. Skripnya menerima host:port, jadi IMAP di 993, LDAPS di 636, broker Kafka di 9093, atau API internal di 8443 semuanya bekerja sama saja. Sertifikat yang tidak pernah menyentuh socket — code signing, sertifikat notifikasi push, sertifikat klien pada armada perangkat — memerlukan tanggal yang diambil dari tempat penyimpanannya lalu dikirim ke channel yang sama.

Bukankah pemeriksaan harian akan jadi kebisingan?

Tidak, kalau ia diam saat tidak ada masalah — itulah sebabnya skripnya tidak mengirim apa pun di atas ambang batas. Desain yang berisik justru yang melaporkan "sertifikat OK" setiap hari: dua minggu kemudian tidak ada yang membacanya, dan pada hari ia berhenti datang tidak ada yang menyadarinya. Kalau kamu ingin heartbeat, taruh di channel Normal terpisah dan jangan pernah di channel yang berdering. Lihat mengatasi kelelahan notifikasi untuk versi umum dari argumen ini.

Bisakah satu tim menerima notifikasi sertifikat yang sama?

Bisa. Bagikan channel-nya dan setiap pelanggan menerima pemicu, masing-masing memilih jenis notifikasinya sendiri. Pembagian yang praktis: siapa pun yang sedang on-call berlangganan channel Panggilan, sisanya channel Time Sensitive, sehingga kedaluwarsa pukul 03.00 membangunkan satu orang, bukan enam.

Apakah ini jalan di macOS?

Jalan, dengan satu catatan: date BSD tidak menerima -d, itulah sebabnya days_left dan to_epoch mencoba bentuk GNU lebih dulu lalu jatuh ke date -u -j -f. openssl di macOS secara bawaan adalah LibreSSL dan mendukung -checkend serta -fingerprint dengan cara yang sama. Kalau kamu memasang OpenSSL dari Homebrew, tidak ada yang berubah.

Amankah mengirim detail sertifikat di dalam notifikasi?

Field yang dipakai di sini — nama host, tanggal kedaluwarsa, penerbit — bersifat publik; siapa pun bisa membacanya dari server-mu dengan perintah openssl yang sama. Jangan menambahkan kunci privat, jalur internal, atau apa pun dari sertifikat pada host non-publik di luar nama host-nya. Echobell menyimpan isi dan riwayat notifikasi hanya di perangkatmu, dan hanya menyimpan akun, channel, serta langganan di server (model privasi) — default yang bagus, tapi bukan alasan untuk mengirim lebih dari yang perlu.

Terkait

Artikel terkait

Peringatan Kegagalan Pembayaran Stripe: Sengketa, Penolakan, dan Webhook Mati

Stripe memberi tahu lewat email soal sengketa dan pembayaran gagal. Cara mengubah event webhook Stripe jadi push, notifikasi mendesak, atau panggilan.

Baca selengkapnya

Dapat pemberitahuan saat perintah panjang di terminal selesai

Berhenti menunggui build yang makan empat puluh menit. Satu baris setelah perintah apa pun mengirim hasilnya ke ponsel Anda, termasuk saat Anda sudah pergi.

Baca selengkapnya

Notifikasi pesanan Shopify yang sampai ke ponsel dalam hitungan detik

Kirim webhook Shopify langsung ke ponsel: push senyap untuk tiap pesanan, lebih nyaring untuk keranjang besar, dan panggilan ketika pengembalian dana atau pembatalan membutuhkan Anda.

Baca selengkapnya