SSL 인증서 만료 알림: 이제 아무도 메일로 알려주지 않습니다

Let's Encrypt가 만료 안내 메일을 중단했고 인증서 수명은 200일입니다. 실제로 돌려본 openssl 점검, 짧은 수명에 맞는 임계값, 닿는 알림 만들기.

업데이트

목차

모두의 인증서 환경 아래에서 두 가지가 바뀌었고, 대부분의 팀은 둘 다 대응하지 못했습니다.

첫째, 안전망이 사라졌습니다. Let's Encrypt는 2025년 6월 4일 만료 알림 서비스를 종료했습니다. 자동화가 조용히 망가졌을 때 수천 개의 사이트를 살려낸 바로 그 메일입니다. 근거 자체는 타당했습니다(대부분의 사용자는 이미 자동 갱신을 쓰고, 수백만 개의 이메일 주소를 보관하는 것은 프라이버시 부담이며, 서비스 운영비가 "연간 수만 달러"). 그리고 공지는 "대신 서드파티 모니터링을 찾아 쓰라"는 말로 끝납니다(Let's Encrypt). 많은 사람이 여기까지 읽고 동의했지만, 후반부는 끝내 하지 않았습니다.

둘째, 여유가 사라졌습니다. 2026년 3월 15일부터 공개 TLS 인증서의 최대 유효기간은 200일이고, CA/Browser Forum 투표 SC-081v3에 따라 2027년 3월 15일에 100일, 2029년 3월 15일에 47일로 줄어듭니다. Let's Encrypt는 상한보다 빨리 움직이고 있습니다. 6일짜리 인증서는 2026년 1월 15일에 정식 제공되었고, 기본 프로필은 2027년 2월에 64일, 2028년 2월에 45일이 될 예정입니다(Let's Encrypt).

두 변화는 같은 방향으로 작용합니다. 갱신이 잦아지면 망가질 기회도 늘어나고, 망가져도 아무도 메일을 보내주지 않습니다. 이 글은 그 틈을 메우는 점검입니다. 실제로 동작을 확인한 셸 스크립트, 짧은 수명 인증서에 맞는 임계값, 그리고 마지막 단계에서 Echobell로 전화를 울리게 하는 방법을 다룹니다.

인증서 때문에 생기는 장애는 실제로 얼마나 심각한가요?

지난 1년간 3분의 1이 넘는 조직이 실제로 겪을 만큼 심각합니다. DigiCert의 「2026 Global Certificate Management Outlook」(2026년 5월 Propeller Insights가 미국·영국·호주의 IT·보안 의사결정자 1,001명을 대상으로 실시)에서, 지난 1년간 3분의 1 이상의 조직이 만료된 인증서로 인한 서비스 중단을 보고했습니다. 4분의 3에 가까운 조직이 인증서 관련 다운타임을 최소 5시간 겪었고, 5분의 1은 25시간 이상, 4분의 1에 가까운 조직은 가장 심각했던 인증서 사고의 피해가 25만 달러를 넘었다고 답했습니다(DigiCert).

이 숫자에서 흥미로운 대목은 지속 시간입니다. 5시간은 인증서를 갱신하는 데 걸리는 시간이 아닙니다. 갱신은 몇 초면 끝납니다. 5시간은 누군가가 그것을 알아차리는 데 걸린 시간입니다.

자동 갱신만으로는 왜 부족한가요?

갱신 자동화는 조용히 실패하고, 더 이상 돌지 않는 cron은 아무 출력도 내지 않기 때문입니다. 아래는 모두 실제로 흔한 실패이며, 하나도 소리를 내지 않습니다.

  • 타이머가 더 이상 돌지 않습니다. 배포판 업그레이드, 컨테이너 재빌드, 혹은 석 달 전 누군가 실행했지만 아무도 기억 못 하는 systemctl disable. 발동하지 않는 certbot.timer는 정상 발동하는 것과 겉보기가 똑같습니다.
  • 갱신은 성공했지만 서비스가 리로드되지 않았습니다. 새 인증서는 디스크에 있는데 nginx, HAProxy, Postfix는 메모리에 있는 예전 것을 계속 붙들고 있습니다. "완전 자동" 구성이 그래도 만료되는 가장 흔한 경로입니다.
  • 챌린지 경로가 깨졌습니다. 누군가 /.well-known/acme-challenge/ 앞에 리디렉션, WAF 규칙, Deny를 넣어 HTTP-01이 실패합니다. 또는 DNS-01에 쓰던 DNS 제공자 API 토큰이 만료됐습니다.
  • 한 노드에서만 갱신되었습니다. 로드밸런서 두 대에 cron은 하나. 두 번째 장비는 더 이상 제공할 수 없을 때까지 옛 인증서를 계속 내보냅니다.
  • 그 인증서는 애초에 웹 서버에 있지 않습니다. 내부 mTLS 클라이언트, Kafka 브로커, LDAP 서버, VPN 장비, 기기 관리용 푸시 인증서. 공개 인터넷에서는 보이지 않고 ACME 클라이언트도 관리하지 않습니다.
  • 갱신 주기가 잘못된 값으로 하드코딩돼 있습니다. Let's Encrypt는 이 점을 분명히 말합니다. 기본 프로필이 64일, 다시 45일로 내려가면 "60일이라는 고정 주기 갱신은 더 이상 충분하지 않습니다"(Let's Encrypt).

마지막 항목은 강조할 만합니다. 달력이 모두를 밀어 넣고 있는 바로 그 실패이기 때문입니다. 갱신 주기가 2022년에 누군가 입력한 숫자 그대로라면, 이제는 인증서 수명 쪽이 그 숫자를 향해 다가오고 있습니다.

명령줄에서 인증서 만료일을 확인하려면?

의존성 없는 openssl 파이프라인 하나면 됩니다. 운영 중인 호스트라면:

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

디스크의 파일이라면:

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

공유 IP에서는 -servername이 선택 사항이 아닙니다. SNI 없이 요청하면 서버가 기본으로 여기는 인증서를 돌려주는데, 그게 당신이 걱정하는 인증서가 아닐 수 있습니다.

예/아니오만 필요하다면 날짜 파싱은 아예 건너뛰어도 됩니다. openssl x509 -checkend <초>는 그 구간을 인증서가 버티면 0, 그 안에 만료되면(이미 만료된 경우 포함) 1로 종료합니다.

openssl x509 -in fullchain.pem -noout -checkend $((14 * 86400)) \
  || echo "14일 이내 만료"

이 종료 코드 규약이 모니터링의 원시 기능 전부입니다. 아래 내용은 전부 그 주변 배관일 뿐입니다.

"갱신했지만 리로드하지 않은" 경우 잡아내기

디스크에 있는 것과 실제로 제공 중인 것을 비교하세요. 거의 아무도 돌리지 않는 점검이면서, 갱신 자동화 스스로는 볼 수 없는 실패를 잡아냅니다.

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 "서비스가 예전 인증서를 제공 중 — 리로드 필요"

두 명령 모두 sha256 Fingerprint=AB:CD:... 형식으로 동일하게 출력하므로 단순 문자열 비교면 충분합니다. 갱신 타이머의 실행 구간이 지난 뒤 몇 분 후에 돌리세요.

인증서 알림의 임계값은 어떻게 잡아야 하나요?

고정 일수가 아니라 인증서 수명의 비율로 잡습니다. "30일 전 경고"는 90일 인증서에는 합리적이었습니다. 47일 인증서에 적용하면 완전히 멀쩡한 인증서에서 울리고, 6일 인증서에 적용하면 항상 울립니다.

대신 갱신 시점을 기준으로 단계를 잡으세요. Let's Encrypt는 "현재 인증서 수명의 약 3분의 2 지점"에서 갱신할 것을 권장합니다. 즉 수명의 3분의 1이 남은 시점은 갱신이 이미 끝났어야 하는 때입니다. 그 뒤로 벌어지는 모든 일은 갱신이 이뤄지지 않았다는 증거입니다.

남은 수명의미알림 유형
1/3갱신 구간이 열림알리지 않음 — 정상
1/6갱신 구간을 한 번 놓침일반 푸시
1/12갱신이 늦은 게 아니라 실패 중시간 민감
1/24 미만, 만료, 접속 불가장애까지 몇 시간전화

구체적인 숫자로 보면 47일 인증서는 대략 이렇습니다. 7.8일까지는 침묵, 3.9일에 푸시, 2일에 시간 민감, 1일 미만에 전화. 90일 인증서는 15일, 7.5일, 3.75일. 6일 인증서는 시간 단위가 되고, 이쯤 되면 사람용 단계는 더 이상 적절한 도구가 아닙니다. ACME Renewal Information(ARI, RFC 9773으로 발행)에 맡겨 CA가 클라이언트에게 갱신 시점을 알려주게 하고, 클라이언트가 반복해서 실패할 때만 알리세요.

비율 계산은 네 줄이면 되고, 발급자와 상관없이 보유한 모든 인증서에 같은 스크립트가 맞아떨어지게 해줍니다.

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() {  # 표준 입력에서 PEM을 읽어 남은 수명 비율(%)을 출력
  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) ))
}

첫 번째 date 형식은 GNU, 두 번째는 BSD/macOS용입니다. ||가 있는 쪽을 골라 씁니다.

이걸 실제로 나에게 닿는 알림으로 만들려면?

Echobell은 웹훅이나 이메일을 일반 푸시, 시간 민감 알림, 또는 집중 모드와 방해 금지를 뚫고 울리는 실제 전화로 바꿔줍니다(iOS 집중 모드 우회하기 참고). 인증서에서 이게 중요한 이유는, 위 표의 마지막 단계가 하필 일요일 새벽 3시에 밟게 되는 단계이기 때문입니다.

1단계 — 채널을 하나가 아니라 둘 만들기

앱에서 채널을 만들고 알림 유형을 시간 민감으로 설정한 뒤 "인증서 만료 임박"이라고 이름 붙입니다. 두 번째 채널은 전화로 설정하고 "인증서 만료 직전"이라고 이름 붙입니다. 각 채널 상세에서 웹훅 URL을 복사하세요. https://hook.echobell.one/t/<channel-token> 형태입니다. 이 URL은 비밀로 다뤄야 합니다. 전화 채널 URL을 가진 사람은 누구든 당신의 전화를 울릴 수 있습니다(웹훅 가이드).

잠금 화면에서 잠금을 풀지 않고도 판단할 수 있도록 템플릿을 작성하세요.

제목: TLS {{state}}: {{host}}
본문: {{daysLeft}}일 남음, {{notAfter}} 만료 — 발급자 {{issuer}}

보낸 JSON 키는 모두 변수가 됩니다(템플릿).

2단계 — 점검 실행하기

앞선 절들을 하나로 합쳐 처음부터 끝까지 실제로 돌려본 스크립트입니다. /usr/local/bin/cert-watch로 저장하세요.

#!/usr/bin/env bash
# cert-watch — TLS 인증서가 만료에 가까워지면 Echobell로 POST를 보낸다.
set -uo pipefail

HOOK="${ECHOBELL_CERT_HOOK:?ECHOBELL_CERT_HOOK에 채널 웹훅 URL을 설정하세요}"
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

상태는 expiring, expired, unreachable 세 가지를 보고하며, 아무 문제가 없을 때는 침묵합니다. 대상은 host 또는 host:port로 적으므로 웹이 아닌 인증서도 그대로 커버됩니다.

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

unreachable은 의도적으로 조용한 건너뛰기가 아니라 알림으로 만들었습니다. "확인할 수 없었음"을 "정상"으로 취급하는 점검이야말로 애초에 인증서가 만료되는 이유입니다.

3단계 — 일정에 넣고, 일정 자체가 실패할 때도 알리기

45일 이상 인증서라면 하루 한 번으로 충분하고, 6일 인증서를 쓴다면 하루 두 번으로 합니다. 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가 중요합니다. 이 옵션이 없으면 예정 시각에 꺼져 있던 장비는 그 회차를 그냥 건너뜁니다.

그다음 점검 자체의 고리를 닫습니다. Type=oneshot 유닛이 0이 아닌 코드로 끝나면 OnFailure=가 발동하므로, drop-in 하나만 넣으면 망가진 갱신이 스스로 알려옵니다.

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

/usr/local/bin/echobell-notify는 세 줄입니다.

#!/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는 갱신이 하나라도 실패하면 0이 아닌 코드로 종료합니다. 정확히 원하는 신호이자, 지금은 어디에도 전달되지 않는 신호입니다. 참고로 certbot의 --deploy-hook은 성공 시에만 실행되므로 이 용도로는 쓸 수 없습니다. 실패 경로는 유닛 쪽에서 가져와야 합니다.

4단계 — 조건으로 단계 나누기

두 채널은 같은 페이로드를 받고, 어느 쪽이 실제로 발동할지는 조건이 결정합니다. 시간 민감 채널:

state == "expiring" && daysLeft > 3

전화 채널:

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

<=는 양쪽을 Number()로 변환하므로 daysLeft를 문자열로 보내도 숫자로 비교됩니다. 조건에는 "포함" 연산자가 없고, 그래서 스크립트가 패턴 매칭이 필요한 자유 문장 대신 명시적인 state 필드를 보내는 것입니다.

5단계 — 믿기 전에 테스트하기

인증서가 잘못됐다고 알려진 호스트로 스크립트를 향하게 하고 알림이 오는지 확인하세요.

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

실제로 받게 될 휴대폰에서 방해 금지를 켠 상태로 테스트하고, 앱에서 실패한 통화 재시도를 켜서 집중 모드에 막힌 전화가 다시 걸리도록 하세요. 한 번도 발동시켜 본 적 없는 에스컬레이션 경로는 추측일 뿐입니다.

이미 모니터링이 인증서를 확인하고 있다면?

그 모니터링의 기존 웹훅을 채널에 연결하고 스크립트는 건너뛰면 됩니다. 대부분의 모니터링은 이미 만료일을 알고 있습니다. 보통 없는 것은 잠든 사람을 넘어 닿는 경로입니다.

  • Uptime Kuma에는 인증서 만료 알림이 내장돼 있습니다. 채널로 향하게 하면 됩니다(Uptime Kuma 가이드, 전화 알림 설정).
  • Prometheus + Alertmanager에 blackbox exporter를 붙이면 probe_ssl_earliest_cert_expiry를 얻습니다. 여기에 알림 규칙을 걸고 채널로 라우팅하세요(Prometheus 가이드, Alertmanager 전화 알림).
  • Grafana 알림 규칙은 채널로 직접 POST할 수 있습니다(Grafana 가이드).
  • Upptime과 UptimeRobot은 공개 엔드포인트를 커버합니다(Upptime, UptimeRobot).
  • 이메일만 보내는 것들 — CA 자체 포털, 클라우드 사업자의 ACM 안내, 사내 PKI — 은 전달 규칙으로 처리합니다. 채널마다 전용 주소가 있고 from, to, subject, text, html을 변수로 쓸 수 있습니다(이메일 트리거).

이 중 어느 것도 대신하지 못하는 한 가지는, 인증서를 제공하는 장비 바깥에서 점검을 돌리는 것입니다. 모니터링이 같은 호스트에 살고 있다면, 호스트를 쓰러뜨리는 장애는 알림까지 함께 데려갑니다.

Echobell이 하지 않는 일

여기서는 정확한 표현이 중요합니다. 인증서 관리는 이보다 훨씬 많은 일을 하는 제품이 가득한 분야이기 때문입니다.

Echobell이 하는 일: 웹훅이나 이메일을 일반 푸시, 시간 민감 알림, 울리는 전화로 바꿉니다. 조건으로 거릅니다. 템플릿으로 다듬습니다. 공유 채널의 모든 구독자에게 같은 트리거를 전달하고, 각자 긴급도를 고르게 합니다.

Echobell이 하지 않는 일:

  • 인증서 탐색이나 인벤토리. 네트워크를 스캔하지 않고, 인증서 투명성 로그를 뒤지지 않으며, 아무도 발급을 기억하지 못하는 인증서를 알려주지도 않습니다. 위 스크립트는 당신이 나열한 호스트만 봅니다. 인증서 난립은 실제 문제지만, 이것은 그 해법이 아닙니다.
  • 갱신. ACME 클라이언트도 없고 키에 접근하지도 않습니다. 갱신이 망가졌다는 사실만 알려주며, 고치는 일은 여전히 당신 몫입니다.
  • 자체 일정에 따른 점검. 호스팅된 프로브가 없습니다. 보러 가는 역할은 당신이 돌리는 무언가(타이머, CI 작업, 기존 모니터링)가 맡아야 합니다.
  • 온콜 로테이션, 에스컬레이션 정책, 확인 응답 제공. "5분 내에 아무도 받지 않으면 다음 사람에게 전화" 같은 기능은 없습니다. 그게 필요하면 인시던트 플랫폼이 필요합니다 — Opsgenie 대체제 비교를 참고하세요.
  • 전달 보장. 전화는 푸시 인프라, 네트워크, 충전된 휴대폰에 의존합니다. 고장과 인지 사이의 거리를 줄여줄 뿐, 절대적으로 기댈 수 있는 통제 수단은 아닙니다.

자주 묻는 질문

Let's Encrypt가 정말 만료 메일을 중단했나요?

네. 만료 알림 서비스는 2025년 6월 4일에 종료되었고, Let's Encrypt는 발급 기록과 함께 보관하던 이메일 주소도 삭제했습니다. 공지에서는 서드파티 모니터링을 권하며, 250장까지 무료인 Red Sift Certificates Lite를 하나의 선택지로 언급합니다. 1년 넘게 Let's Encrypt의 만료 경고를 받지 못했다면 이유는 이것이지, 만료에 가까웠던 인증서가 없어서가 아닙니다.

2026년 TLS 인증서의 유효기간은 얼마인가요?

2026년 3월 15일부터 공개 신뢰 TLS 인증서는 최대 200일입니다. SC-081v3에 따라 2027년 3월 15일에 100일, 2029년 3월 15일에 47일로 내려갑니다. 각 CA는 안전을 위해 상한보다 짧게 발급합니다. 예를 들어 DigiCert는 "허용된 최대 유효기간을 넘지 않기 위해" 199일로 발급합니다. Let's Encrypt는 자체 일정으로 더 멀리, 더 빨리 가고 있으며 6일 인증서는 2026년 1월부터 정식 제공됩니다.

ARI를 쓰고 있어도 만료 알림이 필요한가요?

필요합니다. 다만 대상 이벤트가 달라집니다. ARI(RFC 9773)는 ACME 클라이언트에게 언제 갱신할지 알려주므로 하드코딩된 주기라는 실패 요인은 완전히 사라집니다. 하지만 갱신이 성공한다거나, 서비스가 리로드된다거나, 클라이언트가 아직 살아 있다는 보장은 하지 않습니다. 더 이상 직접 관리할 필요가 없는 카운트다운이 아니라, 반복되는 갱신 실패와 제공 중인 인증서가 디스크의 것과 어긋나는 상황에 알림을 거세요.

웹 서버에 없는 인증서는 어떻게 하나요?

그런 인증서가 가장 잘 만료됩니다. ACME 클라이언트가 지켜보지 않고, 무언가 망가지기 전까지 브라우저도 항의하지 않기 때문입니다. 스크립트는 host:port를 받으므로 993의 IMAP, 636의 LDAPS, 9093의 Kafka 브로커, 8443의 사내 API 모두 같은 방식으로 다룹니다. 소켓에 전혀 등장하지 않는 인증서 — 코드 서명, 푸시 알림 인증서, 기기 그룹의 클라이언트 인증서 — 는 그것이 보관된 곳에서 날짜를 꺼내 같은 채널로 보내면 됩니다.

매일 점검하면 소음이 되지 않나요?

문제가 없을 때 침묵한다면 그렇지 않습니다. 스크립트가 임계값 위에서는 아무것도 보내지 않는 이유가 바로 이것입니다. 시끄러운 설계는 오히려 매일 "인증서 정상"을 보고하는 쪽입니다. 2주면 아무도 읽지 않고, 그것이 오지 않게 된 날 아무도 알아채지 못합니다. 하트비트가 필요하다면 별도의 일반 채널에 두고, 울리는 채널에는 절대 두지 마세요. 이 논지의 일반형은 알림 피로 해소하기에 있습니다.

팀 전체가 인증서 알림을 받을 수 있나요?

가능합니다. 채널을 공유하면 구독자 모두가 트리거를 받고, 각자 알림 유형을 고릅니다. 실용적인 분담 하나: 당번인 사람은 전화 채널을, 나머지는 시간 민감 채널을 구독합니다. 그러면 새벽 3시의 만료가 여섯 명이 아니라 한 명만 깨웁니다.

macOS에서도 동작하나요?

동작합니다. 한 가지만 주의하세요. BSD의 date는 -d를 받지 않기 때문에 days_left와 to_epoch는 GNU 형식을 먼저 시도한 뒤 date -u -j -f로 넘어갑니다. macOS의 openssl은 기본적으로 LibreSSL이지만 -checkend와 -fingerprint는 동일하게 동작합니다. Homebrew로 OpenSSL을 설치해도 달라지는 것은 없습니다.

알림에 인증서 정보를 담아도 안전한가요?

여기서 쓰는 필드 — 호스트명, 만료일, 발급자 — 는 모두 공개 정보이며, 같은 openssl 명령으로 누구나 당신의 서버에서 읽어갈 수 있습니다. 개인 키, 내부 경로, 비공개 호스트 인증서의 호스트명을 넘어서는 정보 등은 페이로드에 추가하지 마세요. Echobell은 알림 내용과 기록을 기기에만 저장하고 서버에는 계정·채널·구독 관계만 둡니다(프라이버시 모델). 좋은 기본값이지만, 필요 이상으로 보내도 된다는 뜻은 아닙니다.

관련 글

관련 글

Prometheus Alertmanager 전화 알림: 정말 급한 것에만 울리게 하기

Alertmanager에는 음성 리시버가 없습니다. critical 등급일 때만 Prometheus 알림을 전화로 바꾸는 방법: webhook 설정, 조건, 그리고 Watchdog 함정.

더 보기

Uptime Kuma 전화 알림: 장애가 나면 휴대폰이 울리게 만들기

Uptime Kuma는 90가지가 넘는 알림 제공자를 지원하지만 전화를 걸어 주는 것은 없습니다. Webhook 하나로 장애 발생 시 전화 알림을 추가하는 방법을 소개합니다.

더 보기

CRA의 24시간 시계는 2026년 9월 11일에 시작됩니다: 반드시 누군가 받게 하세요

2026년 9월 11일부터 EU 사이버 복원력법은 제조자에게 조기 경보를 제출할 24시간을 줍니다. 제출은 브라우저에서만 가능하고 보고용 API는 없습니다. 이 트리거를 Echobell로 전화까지 연결하는 방법과, 알림을 더 크게 울려도 해결되지 않는 부분을 정리했습니다.

더 보기