## この記事でわかること

- 自動更新（ACME プロトコル）がどう動いているか、ざっくりとした全体像
- 自動更新が壊れる代表的なパターン
- 「壊れていることに気付かない」を防ぐ監視の仕込み方
- 商用証明書を使う場合の自動化の限界

SSL の役割や仕組みの基礎から確認したい方は [SSL とは｜Web 担当者向けにわかりやすく解説](/blog/ssl-basics-smb) を先に読むと、本記事が理解しやすくなります。

## なぜ自動更新が必須になったのか

SSL 証明書の有効期間は、業界として段階的に短縮されていきます。CA/Browser Forum（認証局とブラウザベンダーの業界団体）が 2025 年 4 月に可決した Ballot SC-081v3 により、最長有効期間は次のスケジュールで短縮される予定です。

- 2026 年 3 月以降: 最長 398 日 → **200 日**
- 2027 年 3 月以降: 100 日
- 2029 年 3 月以降: 47 日

加えて Let's Encrypt は以前から **90 日**を既定とし、さらに短い有効期間の証明書（short-lived certificate）の提供も進めています。「年に 1 回更新」という運用は、現実として崩壊しつつあります。手動運用は人為ミスの温床なので、自動化はサイト運営者でも避けて通れない論点です。

## ACME プロトコルの動き方（仕組みのざっくり理解）

Let's Encrypt をはじめとする無料証明書のほとんどは、**ACME（Automated Certificate Management Environment、RFC 8555）** という自動発行プロトコルで動いています。動きをざっくり追うと:

1. **アカウント鍵の登録**: クライアント（certbot 等）が認証局にアカウント鍵を登録
2. **発行リクエスト**: 「このドメインに証明書がほしい」と認証局に依頼
3. **所有確認チャレンジ**: 認証局から「ドメインの管理者であることを証明して」と言われる。代表的な方式は 2 つ
   - **HTTP-01**: 指定のファイルを `http://example.co.jp/.well-known/acme-challenge/<token>` に配置できれば管理者と認める
   - **DNS-01**: 指定の TXT レコードを `_acme-challenge.example.co.jp` に追加できれば認める
4. **証明書発行**: チャレンジが通ると、認証局が証明書を発行
5. **証明書のインストール**: クライアントが証明書を Web サーバーに配置し、リロードを実行

このフローを cron や systemd timer で 60〜80 日ごとに走らせる、というのが「自動更新」の中身です。

![ACME プロトコルの 5 ステップ自動更新フロー](/blog/ssl-renewal-automation/acme-flow.svg)

## 自動更新が壊れる代表的なパターン

「設定したら勝手に動き続ける」と思われがちですが、現場では次のような故障モードが頻発します。

![自動更新が壊れる代表的な 5 パターン](/blog/ssl-renewal-automation/failure-modes.svg)

### 1. acme クライアントが落ちている

サーバー再起動後、自動起動の設定が無く certbot が動かなくなっているケース。systemd-timer なら `systemctl status certbot.timer` で稼働確認できます。cron なら `/etc/cron.d/certbot` の存在を確認してください。

### 2. HTTP-01 のチャレンジファイルが配置できない

`.well-known/acme-challenge/` パスが、リライトルールで HTTPS にリダイレクトされたり、メンテナンスページに置き換わったりすると認証が失敗します。別のフレームワーク（WordPress、Next.js 等）に乗せ替えたタイミングで起きやすい故障です。

### 3. DNS-01 の API 権限切れ

DNS-01 を使っている場合、Cloudflare や Route 53 等の API トークンに有効期限がある or スコープを変更されると失敗します。エラーログには `permission denied` が出ます。

### 4. 80 番ポートが塞がれている

セキュリティ強化で 80 番ポートを閉じた瞬間、HTTP-01 が機能しなくなります。本来は HTTPS だけで運用したいケースでも、ACME のために 80 番は開けておくか DNS-01 への切り替えが必要です。

### 5. CAA レコードの不一致

CAA レコードで「Let's Encrypt 以外発行禁止」と設定しているのに、別の認証局を使おうとして失敗するケース。ドメイン側の設定変更時にチェック漏れが発生しがちです。

## 「壊れていることに気付かない」を防ぐ

サイト運営で一番起きるのは「自動更新は動いているはずなのに、いつの間にか止まっていて気付いた時には期限切れ目前」というパターンです。これを防ぐには **更新を実行する側** と **期限を見張る側** の 2 系統を独立して持つのが安全です。

### 仕込み 1: 更新ログを毎週確認

certbot なら `/var/log/letsencrypt/letsencrypt.log` に最終実行時刻が記録されます。週 1 で確認するのは現実的でないため、ログ監視ツール（Datadog、Mackerel、Grafana 等）で「直近 30 日に renew が成功したか」をチェックする監視ジョブを設定するのが王道です。

### 仕込み 2: 外部から期限を監視

CT log を経由して、現に発行されている証明書の `not_after` を外部からチェックします。サーバー内部の自動更新に依存しないため、**仮にサーバー側が壊れていても期限の接近に気付ける**のが利点です。[SSL 証明書 単発チェック](/ssl/check) では crt.sh と CertSpotter を使った外部視点での期限確認ができます。

### 仕込み 3: 期限前アラートを複数チャネルへ

サーバー内部の通知（メール）と、外部監視サービスの通知（チャットツール）の 2 系統を、期限の **30 日前・14 日前・7 日前・1 日前**で段階的に発火させます。担当者の異動や長期休暇でも取りこぼしません。

## 商用証明書（Cybertrust 等）と自動化の限界

国内認証局の商用証明書（Cybertrust、GMO グローバルサイン、セコム等）は、企業実在確認や審査プロセスが介在するため、ACME 完全自動化は基本的にできません。EV 証明書はさらに厳しく、年次の審査が必要です。

選択肢は 2 つに整理できます。

- **A. 商用証明書を継続し、更新を半自動化**: 期限の 60 日前から自動的に通知を発火させ、認証局のマイページからの更新作業だけ手動で行う運用
- **B. 用途を分けて Let's Encrypt に寄せる**: ブランド表示が必須でない管理画面・API・キャンペーン用ドメイン等は Let's Encrypt で自動化、コーポレートサイトのトップだけ商用を維持

EV / OV / DV 各証明書の選び方は [SSL 証明書の種類（DV / OV / EV）の違い](/blog/ssl-certificate-types-dv-ov-ev) で詳しく解説しています。

## 現実解

リソースの限られたサイト運営者では、次の構成が最もトラブルが少ないです。

1. **メインドメイン**: Let's Encrypt + ACME 自動更新
2. **監視**: 外部から期限を見張るサービス（自社で組む or 外部に委託）
3. **棚卸し**: 年 1 回、保有ドメインと証明書の棚卸し
4. **緊急時の連絡経路**: 期限切れ警告が出た時の連絡先（複数人）を事前に決めておく

[SSL 棚卸し・自動更新支援](/ssl)（5 万円〜）では、ここまでの一連を初回セットアップとして対応します。「自動更新を入れたいが何から手を付けていいか分からない」段階のご相談も歓迎します。

## まずは現状を把握しましょう

自社の SSL がどう設定されているか分からない場合は、まず [SSL 証明書 単発チェック](/ssl/check) で 30 秒の現状診断をどうぞ。発行元 CA、有効期限、HSTS の設定、HTTP/2 / 3 対応までまとめて確認できます。

総合的にメール認証・DNS まで含めて点検したい方は [無料のドメイン診断](/diagnose) もご利用ください。具体的なご相談は [お問い合わせフォーム](/contact) からお気軽にどうぞ。