--- title: "SSL sertifikası süre sonu uyarıları: Artık kimse size e-posta atmıyor" description: "Let's Encrypt artık süre sonu e-postası göndermiyor ve sertifikalar 200 gün sürüyor. Test edilmiş bir openssl betiği, doğru eşikler ve size ulaşan uyarılar." date: 2026-09-18 author: Nooc authorAvatarLink: /images/avatars/nooc.webp authorLink: https://nooc.me tags: - SSL sertifikası süre sonu - TLS izleme - certbot - sunucu çöktü bildirimleri - çağrı bildirimleri --- # SSL sertifikası süre sonu uyarıları: Artık kimse size e-posta atmıyor Herkesin sertifika altyapısının altında iki şey değişti ve çoğu ekip ikisine de uyum sağlamadı. **Birincisi, güvenlik ağı kaldırıldı.** Let's Encrypt süre sonu bildirim servisini **4 Haziran 2025**'te kapattı — otomasyon bozulduğunda binlerce siteyi sessizce kurtaran o e-postaları. Gerekçe sağlamdı (abonelerin çoğu yenilemeyi otomatikleştirdi, milyonlarca e-posta adresi saklamak bir gizlilik yükü ve servis "yılda on binlerce dolara" mal oluyordu) ve duyuru, bunun yerine üçüncü taraf izleme bulmanızı söyleyerek bitiyor ([Let's Encrypt](https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended)). Pek çok kişi bunu okudu, katıldı ve ikinci yarısını hiç yapmadı. **İkincisi, hata payı çöktü.** **15 Mart 2026**'dan bu yana açık bir TLS sertifikası en fazla 200 gün geçerli olabiliyor; bu süre [CA/Browser Forum SC-081v3 oylaması](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) uyarınca 15 Mart 2027'de 100 güne, 15 Mart 2029'da 47 güne düşüyor. Let's Encrypt tavandan daha hızlı ilerliyor: 6 günlük sertifikalar 15 Ocak 2026'da genel kullanıma açıldı ve plan, varsayılan profili Şubat 2027'de 64 güne, Şubat 2028'de 45 güne getiriyor ([Let's Encrypt](https://letsencrypt.org/2025/12/02/from-90-to-45)). Her iki değişiklik de aynı yöne itiyor. Yenileme daha sık gerçekleşiyor, dolayısıyla bozulmak için daha çok fırsatı oluyor ve bozulduğunda kimse size posta göndermiyor. Bu rehber, o boşluğu kapatan kontroldür: test edilmiş bir kabuk betiği, kısa ömürlü sertifikalara uygun eşikler ve son durumda telefonunuzu [Echobell](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-ssl-certificate-expiry-alerts-tr&mt=8) ile çaldırmanın bir yolu. ## Sertifika kaynaklı bir kesinti gerçekte ne kadar kötü? **Geçen yıl kuruluşların üçte birinden fazlasının başına gelecek kadar kötü.** DigiCert'in 2026 Global Certificate Management Outlook raporunda — Propeller Insights'ın Mayıs 2026'da ABD, Birleşik Krallık ve Avustralya'da 1.001 BT ve siber güvenlik karar vericisiyle yaptığı anket — kuruluşların **üçte birinden fazlası** son bir yılda süresi dolmuş bir sertifika yüzünden hizmet kesintisi bildirdi. Neredeyse **dörtte üçü** sertifikayla ilgili en az beş saat kesinti yaşadı, **beşte biri** 25 saat veya daha fazlasına ulaştı ve neredeyse **dörtte biri** en ciddi sertifika olayının **250.000 doların** üzerinde maliyeti olduğunu söyledi ([DigiCert](https://www.globenewswire.com/news-release/2026/09/09/3358724/0/en/digicert-research-finds-certificate-failures-are-a-six-figure-infrastructure-risk.html)). Bu sayılardaki ilginç kısım süre. Beş saat, bir sertifikayı yenilemenin aldığı süre değil — yenileme saniyeler sürer. Beş saat, birinin durumu *fark etmesinin* aldığı süredir. ## Otomatik yenileme neden yetmiyor? **Çünkü yenileme otomasyonu sessizce başarısız olur ve çalışmayı bırakmış bir cron hiçbir çıktı üretmez.** Aşağıdakilerin her biri gerçek ve yaygındır, hiçbiri ses çıkarmaz: - **Zamanlayıcı artık çalışmıyor.** Bir dağıtım yükseltmesi, yeniden inşa edilmiş bir konteyner ya da üç ay önce kimsenin hatırlamadığı bir `systemctl disable`. Tetiklenmeyen bir `certbot.timer`, başarıyla tetiklenen bir `certbot.timer` ile birebir aynı görünür. - **Yenileme başarılı oldu ama servis hiç yeniden yüklenmedi.** Yeni sertifika diskte; nginx, HAProxy ya da Postfix hâlâ bellekte eskisini tutuyor. "Tamamen otomatik" bir kurulumun yine de süresinin dolmasının en yaygın yolu budur. - **Challenge yolu bozuldu.** Biri `/.well-known/acme-challenge/` önüne bir yönlendirme, bir WAF kuralı veya bir `Deny` ekledi ve HTTP-01 başarısız oluyor. Ya da DNS-01 için kullanılan DNS sağlayıcısı API belirtecinin süresi doldu. - **Yenileme tek bir düğümde gerçekleşti.** İki yük dengeleyici, bir cron. İkincisi artık yapamayana kadar eski sertifikayı sunmaya devam eder. - **Sertifika zaten bir web sunucusunda değil.** Dahili mTLS istemcileri, bir Kafka broker'ı, bir LDAP sunucusu, bir VPN konsantratörü, cihaz yönetimi için bir push sertifikası. Açık internetten hiçbir şey onu görmez ve hiçbir ACME istemcisi onu yönetmez. - **Yenileme yanlış aralığa sabitlenmiş.** Let's Encrypt bu konuda açık: Varsayılan profil 64 ve ardından 45 güne düştüğünde "60 günlük sabit bir aralıkla yenileme artık yeterli olmayacak" ([Let's Encrypt](https://letsencrypt.org/2025/12/02/from-90-to-45)). Sonuncusu vurguyu hak ediyor, çünkü takvimin herkesi içine ittiği arıza tam da bu. Yenileme ritminiz 2022'de birinin yazdığı bir sayıysa, sertifika ömrü artık o sayıya doğru geliyor. ## Bir sertifikanın süre sonunu komut satırından nasıl kontrol ederim? **Tek bir `openssl` boru hattı, bağımlılık yok.** Çalışan bir sunucu için: ```bash openssl s_client -connect example.com:443 -servername example.com /dev/null \ | openssl x509 -noout -subject -issuer -startdate -enddate ``` Diskteki bir dosya için: ```bash openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -enddate ``` Paylaşımlı bir IP'de `-servername` isteğe bağlı değildir — SNI olmadan sunucunun varsayılan saydığı sertifikayı alırsınız ve bu, endişelendiğiniz sertifika olmayabilir. Evet/hayır cevabı için tarih ayrıştırmayı tamamen atlayın. `openssl x509 -checkend `, sertifika o pencereyi atlatırsa **0**, pencerenin içinde süresi dolarsa (zaten dolmuşsa da) **1** ile çıkar: ```bash openssl x509 -in fullchain.pem -noout -checkend $((14 * 86400)) \ || echo "14 gün içinde süresi doluyor" ``` Bu çıkış kodu sözleşmesi izlemenin tüm ilkel yapısıdır. Aşağıdaki her şey onun etrafındaki tesisattan ibarettir. ### "Yenilendi ama yeniden yüklenmedi" durumunu yakalamak **Diskte olanla gerçekten sunulanı karşılaştırın.** Bu, neredeyse hiç kimsenin çalıştırmadığı kontroldür ve yenileme otomasyonunun göremediği arızayı tam olarak yakalar: ```bash served=$(openssl s_client -connect 127.0.0.1:443 -servername example.com /dev/null \ | openssl x509 -noout -fingerprint -sha256) ondisk=$(openssl x509 -in /etc/letsencrypt/live/example.com/fullchain.pem -noout -fingerprint -sha256) [ "$served" = "$ondisk" ] || echo "servis eski sertifikayı sunuyor — yeniden yükleme gerekiyor" ``` Her iki komut da aynı `sha256 Fingerprint=AB:CD:...` biçimini yazdırır, bu yüzden düz bir metin karşılaştırması yeter. Yenileme zamanlayıcınızın penceresinden birkaç dakika sonra çalıştırın. ## Bir sertifika uyarısı hangi eşikleri kullanmalı? **Sabit gün sayıları değil, sertifika ömrünün kesirleri.** "30 günde uyar" kuralı 90 günlük sertifikalar için makuldü. 47 günlük bir sertifikaya uygulandığında tamamen sağlıklı bir sertifikada tetiklenir; 6 günlük bir sertifikaya uygulandığında sürekli tetiklenir. Bunun yerine merdiveni yenileme noktasına sabitleyin. Let's Encrypt, "mevcut sertifikanın ömrünün yaklaşık üçte ikisinde" yenilemeyi öneriyor — yani **ömrün üçte biri kaldığında** yenilemenin *çoktan yapılmış olması gerekir*. O noktadan sonraki her şey, yapılmadığının kanıtıdır: | Kalan ömür | Ne anlama gelir | Bildirim türü | | --- | --- | --- | | 1/3 | Yenileme penceresi açıldı | Hiçbir şey — bu normal | | 1/6 | Pencere bir kez kaçırıldı | Normal push | | 1/12 | Yenileme gecikmiyor, başarısız oluyor | Zamana duyarlı | | < 1/24, süresi dolmuş veya erişilemez | Kesintiye saatler kaldı | Çağrı | Somut sayılarla, 47 günlük bir sertifika için kabaca şöyle: 7,8 güne kadar sessizlik, 3,9 günde push, 2 günde zamana duyarlı, 1 günün altında çağrı. 90 günlük bir sertifika için: 15 gün, 7,5 gün, 3,75 gün. 6 günlük bir sertifika için saatlerden söz ediyoruz ve orada insana göre bir merdiven artık doğru araç olmaktan çıkar — [ACME Renewal Information](https://letsencrypt.org/2025/09/16/ari-rfc)'a (ARI, RFC 9773 olarak yayımlandı) dayanın; sertifika otoritesi istemcinize ne zaman yenileyeceğini söylesin, siz de yalnızca tekrarlayan istemci hatalarında uyarı verin. Kesri hesaplamak dört satır ve bu, aynı betiği düzenleyicisi ne olursa olsun sahip olduğunuz her sertifika için doğru kılıyor: ```bash 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() { # stdin'den bir PEM okur, kalan ömrün yüzdesini yazdırır 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) )) } ``` İlk `date` biçimi GNU, ikincisi BSD/macOS; `||` hangisi varsa onu seçer. ## Bunu beni gerçekten bulan bir uyarıya nasıl dönüştürürüm? Echobell bir webhook'u veya e-postayı normal bir push'a, zamana duyarlı bir uyarıya ya da Odak ve Rahatsız Etmeyin modlarını delip geçen gerçek bir çalan çağrıya dönüştürür (bkz. [iOS Odak modunu aşmak](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)). Sertifikalarda bu önemlidir, çünkü yukarıdaki tablonun son basamağı tam da pazar sabahı 03.00'te denk geleceğiniz basamaktır. ### Adım 1 — Bir değil, iki kanal oluşturun Uygulamada bir kanal oluşturun, bildirim türünü **Zamana duyarlı** yapın ve adını "Süresi dolan sertifikalar" koyun. İkincisini **Çağrı** türüyle oluşturun ve "Sertifika dolmak üzere" adını verin. Her kanalın ayrıntılarından webhook URL'sini kopyalayın; `https://hook.echobell.one/t/` biçimindedir. Bunları sır gibi saklayın — Çağrı URL'sini elinde tutan herkes telefonunuzu çaldırabilir ([webhook rehberi](/docs/webhook)). Şablonları, bildirime kilit ekranından hiçbir şeyi açmadan aksiyon alınabilecek biçimde yazın: ``` Başlık: TLS {{state}}: {{host}} Gövde: {{daysLeft}} gün kaldı, {{notAfter}} tarihinde doluyor — düzenleyen {{issuer}} ``` Gönderdiğiniz her JSON anahtarı bir değişkene dönüşür ([şablonlar](/docs/template)). ### Adım 2 — Kontrolü çalıştırın Bu, yukarıdaki bölümlerden derlenmiş ve baştan sona test edilmiş betiktir. `/usr/local/bin/cert-watch` olarak kaydedin: ```bash #!/usr/bin/env bash # cert-watch — bir TLS sertifikası süre sonuna yaklaştığında Echobell'e POST gönderir. set -uo pipefail HOOK="${ECHOBELL_CERT_HOOK:?ECHOBELL_CERT_HOOK değişkenine kanalınızın webhook URL'sini verin}" 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 | 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 ``` Üç durum bildirir — `expiring`, `expired` ve `unreachable` — ve her şey yolundayken susar. Hedefler `host` veya `host:port` biçiminde yazılır, böylece web dışı sertifikalar da kapsanır: ```bash ECHOBELL_CERT_HOOK="https://hook.echobell.one/t/" \ cert-watch example.com api.example.com mail.example.com:993 ldap.internal:636 ``` `unreachable` bilinçli olarak sessiz bir atlama değil, bir uyarıdır. "Bakamadım"ı "her şey yolunda" sayan bir kontrol, sertifikaların en baştan süresinin dolmasının nedenidir. ### Adım 3 — Zamanlayın ve zamanlamanın kendisi başarısız olduğunda uyarın 45 gün ve üzeri sertifikalar için günde bir kez yeter; 6 günlük sertifika kullanıyorsanız günde iki kez. Bir systemd zamanlayıcısı: ```ini # /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 ``` ```ini # /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` önemlidir: O olmadan, planlanan saatte kapalı olan bir makine o çalıştırmayı tamamen atlar. Sonra döngüyü kontrolün kendisi üzerinde kapatın. Sıfırdan farklı kodla biten bir `Type=oneshot` birimi `OnFailure=` tetikler, yani tek bir drop-in bozuk bir yenilemenin kendini duyurmasını sağlar: ```ini # /etc/systemd/system/certbot.service.d/echobell.conf [Unit] OnFailure=echobell-alert@%n.service ``` ```ini # /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 ``` `/usr/local/bin/echobell-notify` üç satırdır: ```bash #!/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`, herhangi bir yenileme başarısız olduğunda sıfırdan farklı kodla çıkar; tam da istediğiniz sinyal ve tam da şu anda hiçbir yere gitmeyen sinyal. Dikkat: certbot'un `--deploy-hook` seçeneği yalnızca *başarı* durumunda çalışır, bu yüzden bunun için kullanılamaz — hata yolu birimden gelmelidir. ### Adım 4 — Merdiveni koşullarla ayırın Her iki kanal da aynı yükü alır; hangisinin gerçekten tetikleneceğine [koşullar](/docs/conditions) karar verir. Zamana duyarlı kanalda: ``` state == "expiring" && daysLeft > 3 ``` Çağrı kanalında: ``` state == "expired" || state == "unreachable" || state == "renewal-failed" || daysLeft <= 3 ``` `<=` operatörünün her iki tarafı `Number()` ile dönüştürdüğünü unutmayın; metin olarak gönderilen bir `daysLeft` yine de sayısal olarak karşılaştırılır. Koşullarda "içerir" operatörü yoktur; betiğin desen eşlemesi gerektiren serbest metin yerine açık bir `state` alanı göndermesinin sebebi budur. ### Adım 5 — Güvenmeden önce test edin Betiği, sertifikasının bozuk olduğu bilinen bir sunucuya yöneltin ve uyarının geldiğini görün: ```bash ECHOBELL_CERT_HOOK="https://hook.echobell.one/t/" cert-watch expired.badssl.com ``` Bunu, uyarıyı gerçekten alacak telefonda Rahatsız Etmeyin açıkken yapın ve uygulamada **Başarısız çağrıyı yeniden dene** seçeneğini açın ki Odak tarafından bastırılan bir çağrı yeniden denensin. Hiç tetiklemediğiniz bir yükseltme yolu bir varsayımdır. ## İzleme sistemim sertifikaları zaten kontrol ediyorsa? **O zaman mevcut webhook'unu bir kanala bağlayın ve betiği atlayın.** İzleme sistemlerinin çoğu süre sonu tarihini zaten bilir; genelde eksik olan, uyuyan bir insanı aşabilen bir yoldur. - **Uptime Kuma**'da yerleşik bir sertifika süre sonu bildirimi var — onu bir kanala yönlendirin ([Uptime Kuma rehberi](/docs/developer/uptime-kuma), [çağrı kurulumu](/blog/uptime-kuma-phone-call-alerts)). - Blackbox exporter'lı **Prometheus + Alertmanager** size `probe_ssl_earliest_cert_expiry` verir; bunun üzerinde bir kural yazıp bir kanala yönlendirin ([Prometheus rehberi](/docs/developer/prometheus), [Alertmanager ile çağrılar](/blog/alertmanager-phone-call-alerts)). - **Grafana** uyarı kuralları doğrudan bir kanala POST eder ([Grafana rehberi](/docs/developer/grafana)). - **Upptime** ve **UptimeRobot** açık uç noktaları kapsar ([Upptime](/docs/developer/upptime), [UptimeRobot](/docs/developer/uptimerobot)). - **Yalnızca e-posta gönderen her şey** — bir sertifika otoritesinin kendi portalı, bir bulut sağlayıcısının ACM bildirimleri, dahili bir PKI — bunun yerine bir yönlendirme kuralıyla çözülür. Her kanalın kendi adresi vardır ve `from`, `to`, `subject`, `text` ile `html` değişken olarak kullanılabilir ([e-posta tetikleyicileri](/docs/email-trigger)). Bunların hiçbirinin yerini tutmadığı tek şey, kontrolün sertifikayı sunan makinenin *dışından* çalışmasıdır. İzlemeniz aynı sunucuda yaşıyorsa, sunucuyu düşüren bir arıza uyarıyı da beraberinde götürür. ## Echobell'in yapmadıkları Burada kesin konuşmak önemli, çünkü sertifika yönetimi bundan çok daha fazlasını yapan ürünlerle dolu bir kategori. **Echobell şunları yapar:** bir webhook'u veya e-postayı normal push'a, zamana duyarlı uyarıya ya da çalan çağrıya dönüştürür; koşullarla süzer; şablonlarla biçimlendirir; tek bir tetiklemeyi paylaşılan bir kanalın tüm abonelerine iletir, herkes kendi aciliyetini seçer. **Echobell şunları yapmaz:** - **Sertifikalarınızı keşfetmez veya envanterlemez.** Ağınızı taramaz, sertifika şeffaflığı günlüklerini gezmez ve kimsenin düzenlediğini hatırlamadığı sertifikadan söz etmez. Yukarıdaki betik yalnızca listelediğiniz sunucuları kontrol eder. Sertifika yayılması gerçek bir sorundur ve bu, onun çözümü değildir. - **Hiçbir şeyi yenilemez.** ACME istemcisi yoktur, anahtarlarınıza erişmez. Yenilemenin bozulduğunu söyler; düzeltmek yine sizde. - **Kendi takvimiyle sertifika kontrol etmez.** Barındırılan bir sonda yoktur. Bakma işini sizin çalıştırdığınız bir şey — bir zamanlayıcı, bir CI işi, mevcut izlemeniz — üstlenmelidir. - **Nöbet rotasyonu, yükseltme politikası veya onay sağlamaz.** "Beş dakikada kimse açmazsa sıradakini ara" yoktur. Buna ihtiyacınız varsa bir olay platformuna ihtiyacınız var — [Opsgenie alternatifleri karşılaştırmasına](/blog/opsgenie-end-of-life-alternatives) bakın. - **Teslimatı garanti etmez.** Bir çağrı push altyapısına, ağa ve şarjı olan bir telefona bağlıdır. Arıza ile fark etme arasındaki mesafeyi kısaltır; mutlak biçimde yaslanılacak bir kontrol değildir. ## SSS ### Let's Encrypt gerçekten süre sonu e-postalarını kesti mi? Evet. Süre sonu bildirim servisi 4 Haziran 2025'te sona erdi ve Let's Encrypt, düzenleme kayıtlarıyla birlikte sakladığı e-posta adreslerini sildi. Duyuru üçüncü taraf izlemeyi öneriyor ve bir seçenek olarak 250 sertifikaya kadar ücretsiz olan Red Sift Certificates Lite'ı gösteriyor. Bir yıldan uzun süredir Let's Encrypt'ten süre sonu uyarısı almadıysanız sebebi budur — hiçbir şeyin süre sonuna yaklaşmamış olması değil. ### 2026'da TLS sertifikaları ne kadar geçerli? 15 Mart 2026'dan bu yana, kamuya güvenilir TLS sertifikaları için en fazla 200 gün. Tavan SC-081v3 uyarınca 15 Mart 2027'de 100 güne, 15 Mart 2029'da 47 güne iniyor. Tek tek sertifika otoriteleri güvenlik için tavanın altında düzenler — örneğin DigiCert, tam da "izin verilen azami geçerliliği aşmamak için" 199 günlük sertifikalar düzenliyor. Let's Encrypt kendi takviminde daha ileri ve daha hızlı gidiyor; 6 günlük sertifikalar Ocak 2026'dan beri genel kullanımda. ### ARI kullanıyorsam yine de süre sonu uyarısı vermeli miyim? Evet, ama farklı olaylar üzerine. ARI (RFC 9773) ACME istemcinize *ne zaman* yenileyeceğini söyler ve sabit aralık arızasını tamamen ortadan kaldırır; ancak yenilemenin başarılı olacağını, servisin yeniden yükleneceğini veya istemcinin hâlâ çalıştığını garanti etmez. Artık yönetmeniz gerekmeyen bir geri sayım yerine, tekrarlayan yenileme hatalarına ve sunulan sertifikanın diskteki sertifikadan ayrışmasına uyarı kurun. ### Web sunucusunda olmayan sertifikalar ne olacak? Süresi en çok dolanlar tam da onlardır, çünkü hiçbir ACME istemcisi onları izlemez ve bir şey bozulana kadar hiçbir tarayıcı şikâyet etmez. Betik `host:port` alır; 993'te IMAP, 636'da LDAPS, 9093'te bir Kafka broker'ı ya da 8443'te dahili bir API aynı şekilde çalışır. Hiçbir zaman bir sokete dokunmayan sertifikalar — kod imzalama, push bildirim sertifikaları, bir cihaz filosundaki istemci sertifikaları — için tarihi bulundukları yerden çekip aynı kanala göndermek gerekir. ### Günlük bir kontrol gürültüye dönüşmez mi? Bir şey yokken susuyorsa dönüşmez; betiğin eşiğin üzerinde hiçbir şey göndermemesinin sebebi tam olarak budur. Gürültülü tasarım, her gün "sertifika tamam" diye rapor verendir: iki hafta sonra kimse okumaz ve gelmeyi bıraktığı gün kimse fark etmez. Bir kalp atışı istiyorsanız onu ayrı bir Normal kanala koyun, asla çalan kanala değil. Bu argümanın genel hâli için [uyarı yorgunluğunu gidermek](/blog/fix-alert-fatigue-developer-guide) yazısına bakın. ### Tüm ekip sertifika uyarısını alabilir mi? Evet. Kanalı paylaşın; her abone tetiklemeyi alır ve kendi bildirim türünü seçer. İşe yarayan bir dağılım: nöbetteki kişi Çağrı kanalına, diğerleri Zamana duyarlı kanala abone olur; böylece 03.00'teki bir süre sonu altı kişiyi değil bir kişiyi uyandırır. ### macOS'ta çalışır mı? Çalışır, tek bir kaydıyla: BSD `date` komutu `-d` kabul etmez, bu yüzden `days_left` ve `to_epoch` önce GNU biçimini dener, sonra `date -u -j -f` biçimine düşer. macOS'taki `openssl` varsayılan olarak LibreSSL'dir ve `-checkend` ile `-fingerprint` seçeneklerini birebir aynı şekilde destekler. OpenSSL'i Homebrew'dan kurarsanız da değişen bir şey olmaz. ### Bildirimde sertifika ayrıntıları göndermek güvenli mi? Buradaki alanlar — sunucu adı, süre sonu tarihi, düzenleyen — herkese açıktır; aynı `openssl` komutuyla herkes bunları sunucunuzdan okuyabilir. Yükü özel anahtarlarla, dahili yollarla ya da açık olmayan bir sunucudaki sertifikaya dair sunucu adı dışındaki hiçbir şeyle genişletmeyin. Echobell bildirim içeriğini ve geçmişini yalnızca cihazınızda saklar, sunucuda sadece hesapları, kanalları ve abonelikleri tutar ([gizlilik modeli](/docs/features)) — iyi bir varsayılan, ama gereğinden fazlasını göndermek için bir gerekçe değil. --- ## İlgili yazılar - [API kesintileri için çağrı bildirimleri](/blog/phone-call-alerts-api-downtime) - [Uptime Kuma ile çağrı bildirimleri](/blog/uptime-kuma-phone-call-alerts) - [Başarısız cron işleri için bildirimler](/blog/cron-job-failure-alerts) - [Uyarı yorgunluğunu gidermek: geliştirici rehberi](/blog/fix-alert-fatigue-developer-guide) - [Kritik uyarılar iOS Odak modunu nasıl aşar](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts) - [Webhook entegrasyon rehberi](/docs/webhook) - [Koşullar rehberi](/docs/conditions)