Cảnh báo chứng chỉ SSL sắp hết hạn: không còn ai gửi email cho bạn nữa

Let's Encrypt ngừng gửi email báo hết hạn và chứng chỉ chỉ còn 200 ngày. Script openssl đã kiểm chứng, ngưỡng đúng, và cảnh báo thật sự đến được với bạn.

Cập nhật

Mục lục

Có hai thứ đã thay đổi ngay bên dưới hạ tầng chứng chỉ của tất cả mọi người, và phần lớn các đội chưa điều chỉnh theo thứ nào cả.

Thứ nhất, tấm lưới an toàn đã bị gỡ bỏ. Let's Encrypt đóng dịch vụ thông báo hết hạn vào ngày 4 tháng 6 năm 2025 — chính là những email đã lặng lẽ cứu hàng nghìn website mỗi khi tự động hóa hỏng. Lý do thì hợp lý (đa số người dùng đã gia hạn tự động, lưu hàng triệu địa chỉ email là gánh nặng về quyền riêng tư, và dịch vụ tốn "hàng chục nghìn đô la mỗi năm"), và thông báo kết lại bằng lời khuyên hãy tự tìm dịch vụ giám sát bên thứ ba (Let's Encrypt). Nhiều người đọc đến đó, gật đầu, rồi không bao giờ làm nửa sau.

Thứ hai, biên an toàn đã sụp. Từ 15 tháng 3 năm 2026, một chứng chỉ TLS công khai chỉ được phép có hiệu lực tối đa 200 ngày, giảm còn 100 ngày từ 15 tháng 3 năm 2027 và 47 ngày từ 15 tháng 3 năm 2029, theo phiếu SC-081v3 của CA/Browser Forum. Let's Encrypt còn đi nhanh hơn mức trần: chứng chỉ 6 ngày đã mở cho tất cả từ 15 tháng 1 năm 2026, và lộ trình đưa hồ sơ mặc định xuống 64 ngày vào tháng 2 năm 2027 và 45 ngày vào tháng 2 năm 2028 (Let's Encrypt).

Cả hai thay đổi đều đẩy về cùng một hướng. Gia hạn diễn ra thường xuyên hơn, tức là có nhiều cơ hội hỏng hơn, và khi hỏng thì chẳng ai gửi thư cho bạn. Bài này chính là phép kiểm tra lấp vào khoảng trống đó: một script shell đã chạy thử, các ngưỡng hợp lý cho chứng chỉ ngắn hạn, và cách để trường hợp cuối cùng làm điện thoại bạn đổ chuông bằng Echobell.

Sự cố vì chứng chỉ thực sự nghiêm trọng đến đâu?

Đủ nghiêm trọng để hơn một phần ba tổ chức gặp phải trong năm qua. Trong báo cáo 2026 Global Certificate Management Outlook của DigiCert — khảo sát do Propeller Insights thực hiện tháng 5 năm 2026 với 1.001 lãnh đạo CNTT và an ninh mạng tại Mỹ, Anh và Úc — hơn một phần ba tổ chức cho biết đã gián đoạn dịch vụ vì chứng chỉ hết hạn trong năm qua. Gần ba phần tư cộng dồn ít nhất năm giờ downtime liên quan đến chứng chỉ, một phần năm lên tới 25 giờ trở lên, và gần một phần tư nói sự cố chứng chỉ nghiêm trọng nhất khiến họ mất hơn 250.000 đô la (DigiCert).

Điều đáng chú ý trong các con số đó là thời lượng. Năm giờ không phải thời gian gia hạn một chứng chỉ — gia hạn chỉ mất vài giây. Năm giờ là thời gian ai đó cần để phát hiện ra.

Vì sao gia hạn tự động vẫn chưa đủ?

Vì tự động hóa gia hạn hỏng trong im lặng, và một cron đã ngừng chạy thì không sinh ra bất kỳ output nào. Mỗi tình huống dưới đây đều có thật và phổ biến, và không cái nào gây tiếng động:

  • Timer không còn chạy nữa. Một lần nâng cấp bản phân phối, một container được dựng lại, hay một lệnh systemctl disable ba tháng trước mà không ai còn nhớ. certbot.timer không kích hoạt trông y hệt certbot.timer kích hoạt thành công.
  • Gia hạn thành công nhưng dịch vụ chưa bao giờ reload. Chứng chỉ mới đã nằm trên đĩa; nginx, HAProxy hay Postfix vẫn giữ cái cũ trong bộ nhớ. Đây là cách phổ biến nhất khiến một thiết lập "hoàn toàn tự động" vẫn hết hạn.
  • Đường challenge bị hỏng. Ai đó thêm một redirect, một luật WAF, hay một Deny phía trước /.well-known/acme-challenge/, thế là HTTP-01 thất bại. Hoặc token API của nhà cung cấp DNS dùng cho DNS-01 đã hết hạn.
  • Gia hạn chỉ xảy ra trên một node. Hai load balancer, một cron. Cái thứ hai tiếp tục phục vụ chứng chỉ cũ cho tới khi không thể nữa.
  • Chứng chỉ vốn không nằm trên web server. Client mTLS nội bộ, một broker Kafka, một máy chủ LDAP, một thiết bị VPN, một chứng chỉ push của hệ quản lý thiết bị. Không gì trên internet công cộng nhìn thấy nó và không client ACME nào quản lý nó.
  • Gia hạn bị đóng cứng ở chu kỳ sai. Let's Encrypt nói thẳng: "gia hạn theo chu kỳ cố định 60 ngày sẽ không còn đủ" một khi hồ sơ mặc định xuống 64 rồi 45 ngày (Let's Encrypt).

Điểm cuối đáng nhấn mạnh, vì đó là kiểu hỏng mà tấm lịch đang đẩy tất cả mọi người vào. Nếu nhịp gia hạn của bạn là một con số ai đó gõ vào năm 2022, thì giờ chính thời hạn chứng chỉ đang tiến về phía con số đó.

Làm sao kiểm tra hạn chứng chỉ từ dòng lệnh?

Một đường ống openssl duy nhất, không cần cài gì thêm. Với một host đang chạy:

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

Với một tệp trên đĩa:

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

Trên IP dùng chung, -servername không phải tùy chọn — không có SNI thì bạn nhận chứng chỉ mà máy chủ coi là mặc định, và đó có thể không phải chứng chỉ bạn đang lo.

Nếu chỉ cần câu trả lời có/không, hãy bỏ qua hẳn phần phân tích ngày tháng. openssl x509 -checkend <giây> thoát với mã 0 nếu chứng chỉ sống qua được khoảng đó và 1 nếu hết hạn bên trong khoảng đó (kể cả khi đã hết hạn rồi):

openssl x509 -in fullchain.pem -noout -checkend $((14 * 86400)) \
  || echo "hết hạn trong vòng 14 ngày"

Giao ước về mã thoát đó chính là toàn bộ nguyên thủy giám sát. Mọi thứ bên dưới chỉ là đường ống bao quanh nó.

Bắt trường hợp "đã gia hạn nhưng chưa reload"

So sánh cái trên đĩa với cái thực sự đang được phục vụ. Đây là phép kiểm tra gần như không ai chạy, và nó bắt đúng lỗi mà bản thân tự động hóa gia hạn không thể thấy:

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 "dịch vụ đang phục vụ chứng chỉ cũ — cần reload"

Cả hai lệnh đều in ra cùng định dạng sha256 Fingerprint=AB:CD:..., nên chỉ cần so chuỗi thông thường. Hãy chạy nó vài phút sau khung giờ của timer gia hạn.

Cảnh báo chứng chỉ nên dùng ngưỡng nào?

Theo tỉ lệ vòng đời chứng chỉ, không phải số ngày cố định. Quy tắc "cảnh báo trước 30 ngày" từng hợp lý với chứng chỉ 90 ngày. Áp lên chứng chỉ 47 ngày, nó kêu với một chứng chỉ hoàn toàn khỏe mạnh; áp lên chứng chỉ 6 ngày, nó kêu liên tục.

Thay vào đó, hãy neo bậc thang vào thời điểm gia hạn. Let's Encrypt khuyến nghị gia hạn "vào khoảng hai phần ba vòng đời của chứng chỉ hiện tại" — nghĩa là còn lại một phần ba chính là lúc việc gia hạn lẽ ra đã phải xong. Mọi thứ sau mốc đó đều là bằng chứng rằng nó chưa xảy ra:

Vòng đời còn lạiNghĩa là gìLoại thông báo
1/3Cửa sổ gia hạn đã mởKhông báo — đây là bình thường
1/6Đã bỏ lỡ cửa sổ một lầnPush thường
1/12Gia hạn đang thất bại chứ không phải muộnKhẩn
< 1/24, đã hết hạn, hoặc không kết nối đượcBạn chỉ còn vài giờ trước sự cốCuộc gọi

Quy ra số cụ thể, với chứng chỉ 47 ngày thì đại khái: im lặng cho tới 7,8 ngày, push ở 3,9 ngày, khẩn ở 2 ngày, gọi khi dưới 1 ngày. Với chứng chỉ 90 ngày: 15 ngày, 7,5 ngày, 3,75 ngày. Với chứng chỉ 6 ngày thì đơn vị là giờ, và một bậc thang dành cho con người không còn là công cụ phù hợp — hãy dựa vào ACME Renewal Information (ARI, công bố dưới dạng RFC 9773), để CA tự nói cho client biết khi nào cần gia hạn, và chỉ cảnh báo khi client thất bại nhiều lần.

Tính tỉ lệ chỉ tốn bốn dòng, và nó khiến cùng một script đúng với mọi chứng chỉ bạn có, bất kể ai phát hành:

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() {  # đọc PEM từ stdin, in ra phần trăm vòng đời còn lại
  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) ))
}

Dạng date đầu tiên là GNU, dạng thứ hai là BSD/macOS; dấu || sẽ chọn cái nào bạn có.

Làm sao biến việc này thành cảnh báo thực sự đến được với tôi?

Echobell biến một webhook hoặc một email thành push thường, thông báo khẩn, hoặc một cuộc gọi thật sự đổ chuông xuyên qua chế độ Tập trung và Không làm phiền (xem vượt qua chế độ Tập trung trên iOS). Với chứng chỉ, điều đó quan trọng vì bậc cuối trong bảng trên chính là bậc bạn sẽ chạm vào lúc 3 giờ sáng Chủ nhật.

Bước 1 — Tạo hai kênh, không phải một

Tạo một kênh trong ứng dụng, đặt loại thông báo là Khẩn và gọi nó là "Chứng chỉ sắp hết hạn". Tạo kênh thứ hai với loại Cuộc gọi và gọi nó là "Chứng chỉ sắp hết hiệu lực". Sao chép URL webhook từ phần chi tiết của từng kênh; nó có dạng https://hook.echobell.one/t/<channel-token>. Hãy coi chúng như bí mật — ai cầm URL của kênh Cuộc gọi đều có thể làm điện thoại bạn reo (hướng dẫn webhook).

Viết template sao cho từ màn hình khóa đã có thể hành động mà không cần mở khóa:

Tiêu đề: TLS {{state}}: {{host}}
Nội dung: còn {{daysLeft}} ngày, hết hạn {{notAfter}} — cấp bởi {{issuer}}

Mọi khóa JSON bạn gửi đều trở thành biến (template).

Bước 2 — Chạy phép kiểm tra

Đây là script gom từ các mục trên, đã chạy thử từ đầu đến cuối. Lưu thành /usr/local/bin/cert-watch:

#!/usr/bin/env bash
# cert-watch — gửi POST tới Echobell khi chứng chỉ TLS sắp hết hạn.
set -uo pipefail

HOOK="${ECHOBELL_CERT_HOOK:?hãy đặt ECHOBELL_CERT_HOOK là URL webhook của kênh}"
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

Nó báo ba trạng thái — expiring, expired và unreachable — và im lặng khi mọi thứ ổn. Mục tiêu viết dạng host hoặc host:port, nên các chứng chỉ ngoài web cũng được bao phủ:

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

unreachable được cố ý làm thành một cảnh báo chứ không phải bỏ qua lặng lẽ. Một phép kiểm tra coi "tôi không nhìn được" là "mọi thứ vẫn ổn" chính là lý do khiến chứng chỉ hết hạn ngay từ đầu.

Bước 3 — Lên lịch, và cảnh báo khi chính lịch đó hỏng

Mỗi ngày một lần là đủ với chứng chỉ từ 45 ngày trở lên; hai lần mỗi ngày nếu bạn dùng chứng chỉ 6 ngày. Một 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 rất quan trọng: không có nó, một máy đang tắt vào giờ đã định sẽ bỏ qua luôn lần chạy đó.

Rồi khép vòng lên chính phép kiểm tra. Một unit Type=oneshot thoát với mã khác 0 sẽ kích hoạt OnFailure=, nên chỉ một drop-in là đủ để một lần gia hạn hỏng tự lên tiếng:

# /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

Trong đó /usr/local/bin/echobell-notify chỉ có ba dòng:

#!/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 thoát với mã khác 0 khi bất kỳ lần gia hạn nào thất bại — đúng tín hiệu bạn cần, và cũng đúng tín hiệu hiện đang không đi tới đâu cả. Lưu ý: --deploy-hook của certbot chỉ chạy khi thành công, nên không dùng được cho việc này; nhánh thất bại phải đến từ phía unit.

Bước 4 — Tách bậc thang bằng điều kiện

Cả hai kênh nhận cùng một payload; điều kiện quyết định kênh nào thực sự kích hoạt. Ở kênh Khẩn:

state == "expiring" && daysLeft > 3

Ở kênh Cuộc gọi:

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

Lưu ý rằng <= ép cả hai vế qua Number(), nên daysLeft gửi dưới dạng chuỗi vẫn được so sánh theo số. Điều kiện không có toán tử "chứa", và đó chính là lý do script gửi một trường state rõ ràng thay vì một đoạn văn tự do mà bạn phải khớp mẫu.

Bước 5 — Thử trước khi tin

Trỏ script vào một host có chứng chỉ chắc chắn hỏng và xem cảnh báo có tới không:

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

Hãy làm điều này khi bật Không làm phiền trên chính chiếc điện thoại sẽ nhận, và bật Gọi lại khi cuộc gọi thất bại trong ứng dụng để cuộc gọi bị chế độ Tập trung chặn được thử lại. Một đường leo thang chưa bao giờ được kích hoạt chỉ là một phỏng đoán.

Nếu hệ giám sát của tôi đã kiểm tra chứng chỉ rồi thì sao?

Thì hãy nối webhook sẵn có của nó vào một kênh và bỏ qua script. Đa số hệ giám sát đã biết ngày hết hạn; thứ chúng thường thiếu là một đường đi vượt qua được một con người đang ngủ.

  • Uptime Kuma có sẵn thông báo hết hạn chứng chỉ — chỉ cần trỏ nó tới một kênh (hướng dẫn Uptime Kuma, thiết lập cuộc gọi).
  • Prometheus + Alertmanager với blackbox exporter cho bạn probe_ssl_earliest_cert_expiry; đặt cảnh báo trên đó rồi định tuyến tới một kênh (hướng dẫn Prometheus, cuộc gọi qua Alertmanager).
  • Quy tắc cảnh báo của Grafana POST thẳng tới một kênh (hướng dẫn Grafana).
  • Upptime và UptimeRobot bao phủ các endpoint công khai (Upptime, UptimeRobot).
  • Bất cứ thứ gì chỉ gửi email — cổng của chính CA, thông báo ACM của nhà cung cấp đám mây, một PKI nội bộ — thì dùng một quy tắc chuyển tiếp. Mỗi kênh có địa chỉ riêng, và from, to, subject, text, html đều dùng được như biến (kích hoạt bằng email).

Điều duy nhất không lựa chọn nào trong số đó thay thế được là chạy phép kiểm tra từ bên ngoài cỗ máy đang phục vụ chứng chỉ. Nếu hệ giám sát sống trên cùng host, một sự cố hạ gục host cũng mang luôn cảnh báo đi theo.

Những gì Echobell không làm

Chính xác ở phần này là điều quan trọng, vì quản lý chứng chỉ là một lĩnh vực đầy sản phẩm làm được nhiều hơn thế này rất nhiều.

Echobell có: biến webhook hoặc email thành push thường, thông báo khẩn hoặc cuộc gọi đổ chuông; lọc bằng điều kiện; định dạng bằng template; chuyển một lần kích hoạt tới mọi người đăng ký một kênh chung, mỗi người tự chọn mức khẩn cấp.

Echobell không:

  • Phát hiện hay kiểm kê chứng chỉ của bạn. Nó không quét mạng, không dò log certificate transparency, và sẽ không kể cho bạn về chứng chỉ mà không ai nhớ đã phát hành. Script ở trên chỉ kiểm tra những host bạn liệt kê. Chứng chỉ mọc tràn lan là vấn đề có thật, và đây không phải lời giải cho nó.
  • Gia hạn bất cứ thứ gì. Không có client ACME và không chạm vào khóa của bạn. Nó báo rằng gia hạn đã hỏng; sửa vẫn là việc của bạn.
  • Tự kiểm tra chứng chỉ theo lịch của riêng nó. Không có probe được lưu trữ sẵn. Thứ đi nhìn phải là thứ do bạn chạy — một timer, một job CI, hệ giám sát sẵn có.
  • Cung cấp lịch trực, chính sách leo thang hay xác nhận đã nhận. Không có "nếu năm phút không ai nghe thì gọi người kế tiếp". Nếu cần thứ đó, bạn cần một nền tảng quản lý sự cố — xem so sánh các lựa chọn thay thế Opsgenie.
  • Bảo đảm gửi tới nơi. Một cuộc gọi phụ thuộc vào hạ tầng push, mạng, và một chiếc điện thoại còn pin. Nó rút ngắn khoảng cách giữa lúc hỏng và lúc biết; nó không phải biện pháp kiểm soát để dựa vào tuyệt đối.

Câu hỏi thường gặp

Let's Encrypt thật sự đã ngừng gửi email báo hết hạn?

Đúng vậy. Dịch vụ thông báo hết hạn kết thúc ngày 4 tháng 6 năm 2025, và Let's Encrypt đã xóa các địa chỉ email từng lưu kèm hồ sơ cấp phát. Thông báo khuyến nghị dùng giám sát bên thứ ba và nêu Red Sift Certificates Lite, miễn phí tới 250 chứng chỉ, như một lựa chọn. Nếu hơn một năm nay bạn không nhận được cảnh báo hết hạn nào từ Let's Encrypt, lý do là vậy — chứ không phải vì chưa từng có gì sắp hết hạn.

Chứng chỉ TLS có hiệu lực bao lâu trong năm 2026?

Tối đa 200 ngày với chứng chỉ TLS được tin cậy công khai, kể từ 15 tháng 3 năm 2026. Mức trần giảm còn 100 ngày vào 15 tháng 3 năm 2027 và 47 ngày vào 15 tháng 3 năm 2029 theo phiếu SC-081v3. Từng CA phát hành thấp hơn mức trần cho an toàn — DigiCert chẳng hạn phát hành chứng chỉ 199 ngày, đúng là "để tránh vượt quá thời hạn tối đa được phép". Let's Encrypt còn đi xa và nhanh hơn theo lộ trình riêng, với chứng chỉ 6 ngày mở cho tất cả từ tháng 1 năm 2026.

Dùng ARI rồi thì còn cần cảnh báo hết hạn không?

Vẫn cần, nhưng trên những sự kiện khác. ARI (RFC 9773) nói cho client ACME của bạn biết khi nào gia hạn, xóa sạch kiểu hỏng do chu kỳ đóng cứng — nhưng nó không bảo đảm gia hạn thành công, dịch vụ reload, hay client vẫn còn chạy. Hãy cảnh báo khi gia hạn thất bại nhiều lần và khi chứng chỉ đang phục vụ khác với chứng chỉ trên đĩa, chứ không phải trên một đồng hồ đếm ngược mà bạn không còn phải quản nữa.

Còn những chứng chỉ không nằm trên web server?

Đó chính là những chứng chỉ dễ hết hạn nhất, vì không client ACME nào canh chúng và không trình duyệt nào lên tiếng cho tới khi có thứ gì đó hỏng. Script nhận host:port, nên IMAP ở 993, LDAPS ở 636, broker Kafka ở 9093, hay một API nội bộ ở 8443 đều dùng y như nhau. Những chứng chỉ chẳng bao giờ chạm tới socket — ký mã nguồn, chứng chỉ thông báo đẩy, chứng chỉ client trên một dàn thiết bị — thì cần lấy ngày từ nơi chúng đang nằm rồi gửi vào cùng kênh đó.

Kiểm tra hằng ngày có thành tiếng ồn không?

Không, nếu nó im lặng khi mọi thứ ổn — đó chính là lý do script không gửi gì khi còn trên ngưỡng. Thiết kế ồn ào mới là cái báo "chứng chỉ vẫn ổn" mỗi ngày: hai tuần sau không ai đọc nữa, và đúng ngày nó ngừng đến thì không ai nhận ra. Nếu bạn muốn một nhịp tim, hãy đặt nó ở một kênh Thường riêng và tuyệt đối không đặt ở kênh biết đổ chuông. Xem khắc phục mệt mỏi vì cảnh báo cho phiên bản tổng quát của lập luận này.

Cả nhóm có nhận được cảnh báo chứng chỉ không?

Có. Chia sẻ kênh và mọi người đăng ký đều nhận được lần kích hoạt đó, mỗi người tự chọn loại thông báo. Một cách chia hợp lý: người đang trực đăng ký kênh Cuộc gọi, những người còn lại đăng ký kênh Khẩn, để một lần hết hạn lúc 3 giờ sáng đánh thức một người thay vì sáu người.

Nó có chạy trên macOS không?

Có, với một lưu ý: date của BSD không nhận -d, nên days_left và to_epoch thử dạng GNU trước rồi mới lùi về date -u -j -f. openssl trên macOS mặc định là LibreSSL và hỗ trợ -checkend cùng -fingerprint y hệt. Nếu bạn cài OpenSSL qua Homebrew thì cũng không có gì thay đổi.

Gửi thông tin chứng chỉ trong thông báo có an toàn không?

Các trường dùng ở đây — tên host, ngày hết hạn, đơn vị cấp — đều là thông tin công khai; ai cũng có thể đọc chúng từ máy chủ của bạn bằng đúng lệnh openssl đó. Đừng mở rộng payload bằng khóa riêng, đường dẫn nội bộ, hay bất cứ thứ gì từ chứng chỉ trên host không công khai ngoài tên host. Echobell chỉ lưu nội dung và lịch sử thông báo trên thiết bị của bạn, phía máy chủ chỉ giữ tài khoản, kênh và đăng ký (mô hình riêng tư) — một mặc định tốt, nhưng không phải lý do để gửi nhiều hơn mức cần thiết.

Bài liên quan

Bài viết liên quan

Cảnh báo bằng cuộc gọi cho Prometheus Alertmanager: chỉ đánh thức khi thật nguy cấp

Alertmanager không có receiver gọi thoại. Hãy đưa cảnh báo Prometheus thành cuộc gọi chỉ với mức critical: cấu hình webhook, điều kiện, và cái bẫy mang tên Watchdog.

Đọc tiếp

Cảnh báo bằng cuộc gọi cho Uptime Kuma: Làm điện thoại bạn đổ chuông

Uptime Kuma có hơn 90 kênh thông báo nhưng không cái nào làm điện thoại bạn reo. Đây là cách thêm cảnh báo bằng cuộc gọi khi có sự cố, chỉ với một webhook.

Đọc tiếp

Đồng hồ 24 giờ của CRA bắt đầu chạy từ 11/9/2026: Hãy chắc chắn có người nghe máy

Từ 11/9/2026, Đạo luật Cyber Resilience của EU cho nhà sản xuất 24 giờ để gửi cảnh báo sớm — qua trình duyệt, không có API báo cáo. Đây là cách biến sự kiện đó thành một cuộc gọi với Echobell, và những gì cảnh báo ồn hơn vẫn không giải quyết được.

Đọc tiếp