【PR】この記事にはA8.netのアフィリエイト広告を含みます。
先に結論：XServer VPSで公開中の証明書を外部TLS handshakeから調べると、Let’s Encrypt YE1発行、期限は2026年11月26日、残り85.056958日でOKでした。45日・13日・1日・期限切れの4状態は4/4正しく判定し、隔離CaddyのACME通信失敗も0.388568秒で4系統すべて検出できました。本番証明書を変更せず監視できるため、判定は監視について解決です。
Caddyなら証明書期限を気にしなくてよい？
自動更新は便利ですが、監視不要にはなりません。現在HTTPSが成功していても、次回更新時のDNS、firewall、outbound通信、data volume、時刻の問題は別です。失敗に気づかなければ、browserが期限切れを表示して初めて発覚する可能性があります。
悩みの起点にしたReddit「SSL certs suddenly flag as out of date (Caddy)…」では、数か月正常だった後に期限エラーが発生しました。投稿者の解決欄では、firewallがDNS/53をPi-holeへ強制し、証明書検証を妨げていたと報告されています。
CaddyのAutomatic HTTPSは何をしてくれる？
Caddy公式のAutomatic HTTPSによると、対象siteの証明書を取得・更新し、HTTPからHTTPSへのredirectも自動化します。
一方、公開domainではA/AAAA record、外部からの80/443到達、Caddyのport bind、書き込み可能で永続化されたdata directoryなどが前提です。自動化の成否と、外から実際に提示される証明書の残日数を別々に監視します。
XServer VPSでどんな実験をした？
| 項目 | 実測条件 |
|---|---|
| VPS | XServer VPS、4 vCPU、4GB RAM、150GB |
| OS | Ubuntu 26.04 |
| Caddy | 2.10.2-alpine |
| 本番確認 | TLS handshakeでleaf certificateを読み取り |
| 閾値 | 30日以下WARNING、7日以下CRITICAL、0日以下EXPIRED |
| 失敗case | Let’s Encrypt staging、network none、公開portなし |
| container上限 | 0.25 CPU、128MiB RAM、PID 96 |
本番Caddyの証明書、Caddyfile、DNS、packet filter、data volumeは変更していません。取得失敗は別の一時containerだけで再現しました。
現在のXServer VPS証明書はあと何日？
| 項目 | 実測値 |
|---|---|
| subject | CN=x210-131-222-72.static.xvps.ne.jp |
| issuer | Let’s Encrypt YE1 |
| 有効開始 | 2026-08-28 10:17:08 UTC |
| 有効期限 | 2026-11-26 10:17:07 UTC |
| 残日数 | 85.056958日 |
| hostname一致 | true |
| 判定 | OK、exit code 0 |
外から実際に提示されたleaf certificate 1,346 bytesをOpenSSLで解析し、SHA-256 fingerprintも生データへ保存しました。「Caddyの保存fileがある」ではなく、利用者が受け取る証明書を確認した点が重要です。
30日・7日・期限切れを正しく区別できた？
| 証明書条件 | 期待 | 実測 | exit code |
|---|---|---|---|
| 45日 | OK | OK | 0 |
| 13日 | WARNING | WARNING | 1 |
| 1日 | CRITICAL | CRITICAL | 2 |
| 1日証明書を2日後として評価 | EXPIRED | EXPIRED | 3 |
4/4条件で期待値と一致しました。45日・13日・1日はOpenSSLで実際に生成したcertificateです。期限切れは同じ1日certificateのnotAfterを2日後の評価時刻と比較し、host時計を変更していません。
なぜ30日と7日で二段階にする？
30日でWARNINGにすれば、DNSやfirewallを調べる時間を確保できます。7日以下は更新失敗が続いている可能性が高いため、CRITICALとして通知経路や担当者を変えられます。
日数は唯一の正解ではありません。重要なのは「HTTPSがまだ動く」期間に検知し、0日になるまで同じ警告を放置しないことです。exit codeを分けるとcron、systemd timer、監視agentから扱いやすくなります。
ACME更新失敗を実際に再現できた？
隔離containerで再現できました。exp29-acme-failure.invalidをCaddyへ設定し、ACME CAはLet’s Encrypt staging、networkはnoneにしました。
Caddyはautomatic TLS managementを有効にし、obtaining certificateへ進みました。その後、staging directoryのDNS lookupでconnect: network is unreachableを記録しました。production CAのrate limitを使わず、外部公開portも作っていません。
どのログを監視すればよい？
| 検出軸 | 今回の結果 |
|---|---|
| certificate / ACME | 検出 |
| obtaining / renewing | 検出 |
| network / DNS | 検出 |
| error level / error field | 検出 |
4/4系統を0.388568秒で検出しました。単語一つだけでは、正常な「certificate maintenance started」も拾います。logger、message、error fieldを組み合わせ、同時に残日数が減っているか確認します。
実験中に何が失敗した？
初回は安全策で--cap-drop=ALLを指定しました。ところがCaddyがcertificate取得へ進む前に終了し、container PIDが0になったためcgroup値も取得できませんでした。
内部の80/443へbindするNET_BIND_SERVICEまで外したのが原因です。再実験では公開portを追加せず、--cap-add=NET_BIND_SERVICEだけを戻しました。監視scriptもPID 0を例外にせず「container exited」と記録するよう修正しています。
CPU・RAM・ストレージへの影響は？
- 隔離Caddy peak RAM：12.09MiB
- 隔離Caddy CPU：0.084374秒
- host MemAvailable：約3263.41MiBから3258.91MiB
- root disk差：4,096 byte増
- 成功run総時間：3.665185秒
これはTLS handshake、3 certificate生成、隔離Caddy起動、ログ判定の値です。本番renewalや通常access負荷のbenchmarkではありません。
本番サービスと後片付けは？
公開/health/readyは開始前、隔離ACME失敗中、終了後の全3回でHTTP 200でした。database=ok、artifact_storage=okも維持しています。
本番Caddy、FastAPI、PostgreSQLは前後ともrestart 0、statusも一致しました。一時container、tmpfs、一時certificateを削除し、dangling volumeは前後0件です。
VPS上ではどう監視する？
- 5分から1時間ごとに外部TLS handshakeでnotAfterを取得する。
- 30日以下をWARNING、7日以下をCRITICAL、期限超過をEXPIREDにする。
- Caddy application logからACME、certificate、DNS、network errorを抽出する。
- 残日数とerrorが同時に悪化したら通知priorityを上げる。
- Caddy container restart数、data volume mount、VPS時刻も記録する。
- certificate fingerprintが予期せず変わった場合も履歴へ残す。
初心者が迷いそうなポイントは？
- access logとCaddy application logは別物。
- 現在のHTTPS成功だけでは次回更新成功を保証しない。
- Let’s Encrypt productionで実験を繰り返すとrate limitの恐れがある。
- containerの
/dataが永続化されているか確認する。 - DNSは名前解決だけでなくACME challengeにも関係する。
- logをAIへ渡す前にIP、domain、token、header等をredactする。
XServer VPSでこの悩みはどこまで解決した？
証明書監視については解決です。本番certificateを変更せず残り85.06日を確認し、4段階の期限判定を4/4成功させました。隔離ACME失敗ログも4系統で検出し、本番3containerはrestart 0でした。
実際の本番renewalを故意に止めること、メールやSlackへの通知、複数domain、IPv6、certificate chain全体は未検証です。次の実装では、この判定をsystemd timerまたはVPS上の監視jobへ組み込みます。
よくある質問
Q. Caddyが自動更新するなら監視は不要ですか？
A. 不要ではありません。DNS、firewall、network、storage、時刻の問題で更新に失敗するため、外部からの残日数確認が必要です。
Q. 証明書の残日数はどこを見ますか？
A. TLS handshakeで受け取ったleaf certificateのnotAfterと、UTCの現在時刻を比較します。
Q. 30日以下ならすぐ障害ですか？
A. まだ有効です。早期調査用のWARNINGとして扱い、7日以下でCRITICALへ上げる設計にしました。
Q. ACME失敗実験で本番証明書に影響しましたか？
A. 影響していません。別container、reservedな.invalid domain、staging URL、network none、公開portなしで実施しました。
Q. CaddyログをそのままAIへ送ってよいですか？
A. IP、domain、認証情報、headerが含まれる可能性があります。必要なfieldだけ抽出し、secretをredactしてから扱います。
実験日：2026年9月2日。数値は筆者が契約中のXServer VPS 4GB環境における単発の実測です。certificate、Caddy、DNS、network、契約planにより結果は変わります。
コメント