「証明書の期限、Let’s Encryptからメールが来るから大丈夫です」
「更新は年に1回だし、手順書どおりにやれば問題ありません」
どちらも、もう通用しない考え方です。Let’s Encryptの期限切れの通知メールは2025年に終了しましたし、第6回で見たとおり、証明書の有効期間は2029年に47日まで短くなります。年に1回だった作業が、ほぼ毎月になるのです。
第7回までで、証明書とTLSの仕組みを見てきました。第8回では運用の話に移り、期限切れを防ぐための棚卸し、ACMEによる自動更新、期限の監視を扱います。
期限切れ事故の実例
証明書の期限切れは、原因が単純なのに影響が大きい障害の代表です。
- 2018年12月6日：ソフトバンクとワイモバイルの4G携帯電話サービスなどが、全国で約4時間半使えなくなった。原因はエリクソン社製の交換機のソフトウェアで、組み込まれたデジタル証明書の有効期限が誤って処理されたこと。同じ時刻に海外11か国の通信事業者でも障害が起き、有効期限は出荷時にソフトウェアへ埋め込まれていて、通信事業者側からは確認できなかったと説明されている
- 2020年2月3日：Microsoft Teamsが数時間使えなくなった。Microsoftは認証用の証明書の期限切れが原因と公表した
教訓は3つです。
- 証明書は、自分で買ったものだけでなく、製品の中にも埋め込まれている
- 期限は分かっていても、記憶や手作業に頼ると漏れる
- 切れた瞬間に全台が同時に止まり、冗長構成でも救えない
期限は台数に関係なく1つ。切れた瞬間に全部が止まります。
手作業の更新が破綻する理由
| 最長有効期間 | 適用開始 | 1枚の年間の更新回数（目安） | 100枚なら年間の作業 |
|---|---|---|---|
| 398日 | 2020年9月 | 約1回 | 約100回 |
| 200日 | 2026年3月15日 | 約2〜3回 | 約200〜300回 |
| 100日 | 2027年3月15日 | 約4〜6回 | 約400〜600回 |
| 47日 | 2029年3月15日 | 約8〜12回 | 約800〜1,200回 |
（回数の幅は、期限ぎりぎりで更新する場合と、余裕を持って残り1/3で更新する場合）
47日の証明書は、ほぼ毎月の作業になります。手作業ではCSRの作成、ドメイン認証（2029年からは再利用10日）、配置、再読み込みの確認を毎月繰り返すことになり、休暇や異動で必ず漏れます。
対策の中心は、自動化できるものはACMEで自動化し、手作業の枚数を減らすことです。
証明書の棚卸し（CT・スキャン・台帳）
自動化も監視も、どこに何枚の証明書があるかが分からなければ始まりません。棚卸しには3つの方法を組み合わせます。
- CTログ（第5回）：公開CAの証明書はすべて記録されるため、crt.shなどで自社ドメインを検索すると、社内の誰かが取った証明書まで一覧できる。ただし、社内CAや自己署名の証明書は載らない
- ネットワークのスキャン：社内のアドレス範囲の443番、LDAPS（636番）、メールの465・587番などに接続し、返ってくる証明書を集める。アプライアンスや管理画面の証明書も見つかる
- 台帳：証明書ごとに、名前（SAN）、発行元、有効期限、秘密鍵の場所、配置先、更新方法（自動か手動か）、担当者を記録する
スキャンとCTの結果を台帳と突き合わせると、「台帳に無い証明書（野良証明書）」と「台帳にあるのに見つからない証明書」が分かります。CTは社内CAを、スキャンは届かない場所を見落とすので、組み合わせが大切です。
ACME（RFC 8555）の流れ
ACME（Automatic Certificate Management Environment、RFC 8555）は、証明書の申請から発行までをHTTPSのAPIで自動化する標準の手順です。
- アカウント：鍵ペアを作ってCAに登録する。以降の要求はすべてこの鍵で署名する
- 注文（newOrder）：載せたい名前を伝える
- 認証：CAが名前ごとにチャレンジ（第6回）を返し、クライアントはトークンをWebサーバーやDNSに置いて確認を頼む
- CSRの送信（finalize）：すべての名前の認証が済んだら、機器の上で作ったCSRを送る
- 発行：証明書をダウンロードして配置し、サービスを再読み込みする
- 更新：期限が近づくか、CAから時期を知らされたら（ARI）、②から繰り返す
人が関わるのは最初の設定だけ。以降は②〜⑤を自動で回します。更新のたびに、鍵も新しく作るのが普通です。
チャレンジの選び方
| 状況 | 向くチャレンジ | 注意点 |
|---|---|---|
| 公開 Web サーバーで、ポート80が外から届く | HTTP-01 | LB 配下では、どのサーバーに来てもトークンを返せるようにする |
| ワイルドカード証明書が要る | DNS-01 | HTTP-01・TLS-ALPN-01 では取れない |
| 社内サーバーで外から届かない（名前は公開ドメイン） | DNS-01 | DNS を更新する API の認証情報をサーバーに置くことになる |
| DNS の権限を広く渡したくない | DNS-01＋CNAME 委任 | _acme-challenge を認証専用のゾーンへ CNAME し、そのゾーンだけ更新させる |
| ポート443しか開けられない | TLS-ALPN-01 | 対応するクライアントが限られる |
| 機器が多く、DNS を毎回変えたくない | DNS-PERSIST-01 | 固定の TXT で済む。Let’s Encrypt はステージングのみ（2026年9月） |
DNS-01の最大のリスクは、DNSを書き換えられる認証情報をサーバーに置くことです。ゾーン全体の権限が漏れると、Webサイトの乗っ取りにつながります。権限をレコード単位に絞る、CNAMEで認証専用のゾーンに委任する、などで被害を限定しましょう。CAAのaccounturi・validationmethods（RFC 8657、第5回）で、使えるアカウントと方法を絞ることもできます。
Let’s Encryptの現在（2026年9月）
| 項目 | 内容 |
|---|---|
| プロファイル | classic（既定）：90日・認証の再利用30日／tlsserver：45日（2026年5月から）／shortlived：160時間（約6日） |
| 既定の有効期間の短縮予定 | 2027年2月10日から classic を64日（再利用10日）、2028年2月16日から45日（再利用7時間） |
| 短期証明書・IP アドレスの証明書 | 2026年1月に一般提供。IP アドレスの証明書は shortlived のみ |
| 失効の確認 | OCSP は2025年8月6日に終了。CRL のみ（第5回） |
| 期限切れの通知メール | 2025年6月4日に終了。監視は自分で行う |
| クライアント認証（clientAuth） | 2026年2月11日に classic から削除。tlsclient も7月8日に終了 |
| 更新の時期 | ARI（RFC 9773）に従うことを推奨 |
| DNS-PERSIST-01 | ステージングで提供。本番は未提供 |
冒頭の「メールが来るから大丈夫」は、ここで崩れます。通知メールをやめた理由として、自動化の普及、数百万のメールアドレスを持ち続けることのプライバシー上の問題、費用が挙げられています。「メールが来るから大丈夫」だった運用には、すでに通知が来ていません。プロファイルはACMEクライアントで選べます（certbotは--preferred-profile）。
ACMEクライアント
| クライアント | 動作環境 | 特徴 | 向く場面 |
|---|---|---|---|
| certbot | Linux 等（Python） | EFF 製。Apache・nginx の設定を書き換えるプラグイン。ARI 対応（4.1 以降） | Linux の Web サーバー |
| acme.sh | Linux・Unix（シェルスクリプト） | 依存が少ない。DNS の API に多数対応。既定の CA は ZeroSSL | 小さな環境、DNS-01、機器への配布 |
| win-acme | Windows | IIS のバインドを自動で更新。証明書ストアや PFX に保存 | IIS・Windows サーバー |
| Posh-ACME | Windows・Linux（PowerShell） | PowerShell のモジュール。DNS のプラグインが豊富 | PowerShell で組み込みたい場面 |
| Caddy・Traefik 等 | Web サーバー・リバースプロキシーに内蔵 | 設定に名前を書くだけで取得・更新まで自動 | 新規構築、コンテナ環境 |
| cert-manager | Kubernetes | Ingress・Secret と連携して自動更新 | Kubernetes |
acme.shでLet’s Encryptを使うなら、--set-default-ca --server letsencryptで既定のCAを変えます。
どのクライアントでも、次の3点は必ず設定しましょう。
- 更新後にサービスを再読み込みするフック
- 失敗したときの通知
- 秘密鍵ファイルの権限
クラウドの証明書サービス（ACM等、第9回）は、ACMEを使わずに自動更新されます。
ARI（ACME Renewal Information）
ACMEクライアントは、これまで「期限の30日前」のように自分で決めた時期に更新していました。しかし、CAが大量の証明書を失効させる事故が起きると、利用者は期限に関係なく急いで更新しなければなりません。
その合図を自動で伝えるのが、ARI（ACME Renewal Information、RFC 9773、2025年6月）です。
- クライアントは証明書ごとにCAの
renewalInfoに問い合わせ、CAは更新すべき時間帯（suggestedWindow）を返す - 普段は有効期間の後半が示され、失効の予定があれば前倒しされる
- クライアントは時間帯の中の時刻をランダムに選ぶため、更新がCAに集中することも避けられる
Chrome Root ProgramはACMEに対応するCAにARIを求めており、certbot（4.1以降）、acme.sh、Posh-ACMEなどが対応しています。いつ更新するかを決めるのは、クライアントではなくCA、という考え方です。
社内でのACME
ACMEは公開CAだけのものではありません。社内CAでACMEを使えば、社内の証明書も同じ仕組みで自動更新できます。
- 代表例はオープンソースのstep-ca（Smallstep）。社内にACMEサーバーを立て、社内の名前をHTTP-01・DNS-01で認証できる
- 商用の公開CA（DigiCert、Sectigo、GlobalSign等）もACMEに対応しており、EAB（External Account Binding）の鍵でクライアントを契約に結び付ける
- 一方、AD CSはACMEに対応していない。ドメインに参加したWindowsは自動登録（第9回）で更新できるが、Linuxや機器は手作業になりがち
AD CSだけでは、Linuxと機器が自動化から漏れます。その場合は、ACMEに対応した社内CAを別に用意する、AD CSの前に中継するソフトを置く、機器にはSCEP（AD CSではNDES）を使う、などを検討します。どの場合も、社内CAのルート証明書の配布が前提です。
期限の監視
自動化しても、監視は必要です。自動更新が静かに失敗していることがあるからです。
$ echo | openssl s_client -connect www.example.jp:443 -servername www.example.jp 2>/dev/null \
| openssl x509 -noout -enddate -checkend $((14*86400))
notAfter=Oct 27 22:17:21 2026 GMT
Certificate will not expire # 14日以内に切れるなら "Certificate will expire"、終了コード1PS> Get-ChildItem Cert:\LocalMachine\My |
Where-Object NotAfter -lt (Get-Date).AddDays(14) |
Select-Object Subject, NotAfter, Thumbprint
Subject NotAfter Thumbprint
------- -------- ----------
CN=app01.corp.example.jp 2026/10/05 8:59:59 3F2A9C…（省略）- 閾値は有効期間に合わせる。自動更新は残り1/3（47日なら約16日）で行い、監視は「更新されるはずの時期を過ぎても古いまま」を警告する。例：残り14日で警告、7日で緊急
- 外から実際に接続して確かめる。ファイルが新しくなっても、サービスが再読み込みしていなければ古い証明書が返る。中間証明書の期限も見る
- ツールの例：Zabbix（Webサイトの証明書のテンプレート）、Prometheusのblackbox_exporter（
probe_ssl_earliest_cert_expiry）、外部の監視サービス
鍵の更新とローテーション
証明書を更新するときは、秘密鍵も作り直すかを決めておきます。
- 原則は、更新のたびに鍵も新しくする。同じ鍵を何年も使い続けると、その間に一度でも漏れていれば、新しい証明書も危険なままになる。ACMEクライアントの多くは既定で毎回新しい鍵を作る
- ただし、アプリや機器が公開鍵を固定して確かめている（ピン留め）場合や、DANE（TLSAレコード、連載「DNS入門」第6回）で公開鍵のハッシュをDNSに載せている場合は、新しい鍵を先に登録してから切り替える手順が必要
- 鍵が漏れた疑いがあるときは、鍵を作り直して再発行し、古い証明書を失効させる（第5回）
更新は、鍵の種類を見直す機会でもあります。RSAからECDSAへの切り替えや、将来の耐量子計算機暗号の証明書への移行を考えると、鍵の種類を簡単に変えられる「暗号の俊敏性（クリプトアジリティ）」は、自動化の大きな利点です。鍵が同じなら、証明書を新しくしても漏えいは続きます。
自動化できない機器の扱い
すべての証明書をACMEで自動化できるわけではありません。ロードバランサーなどのアプライアンス、サーバーの管理コントローラー、古い業務システム、社外のサービスに預けた証明書などは、ACMEクライアントを入れられないことがあります。
次の順で考えます。
- 製品の機能を調べる：ACMEクライアントの内蔵や、APIでの証明書の入れ替えに対応する製品が増えている
- 外で取って配る：別のサーバーのACMEクライアントがDNS-01で取った証明書を、APIやSSHで機器に配る
- 前段で終端する：前に置いたロードバランサーやリバースプロキシーでTLSを終端し、そこを自動化する（第9回）
- 社内CAに切り替える：公開する必要がない管理画面などは、社内CAの証明書にすれば47日の制約を受けない
どれもできない機器は、台帳で「手動更新」として管理し、監視と手順書、交換の計画を用意します。最後まで残った機器だけを、人が台帳で見張る、という形を目指しましょう。
考えてみよう
- 自分の担当範囲の証明書を、台帳を見ずに何枚挙げられますか。crt.shで自社ドメインを検索すると、知らない証明書は出てきませんか。
- 今使っている証明書のうち、ACMEで自動化できるもの、外で取って配れば自動化できるもの、どうしても手作業のものは、それぞれ何枚ありますか。
- 期限切れや更新の失敗に、利用者より先に気づける仕組みはありますか。失敗したとき、誰にどう通知されますか。
ヒント：この記事の「棚卸し」「チャレンジの選び方」と「ACMEクライアント」「期限の監視」「自動化できない機器の扱い」の判断の順番が手がかりです。第11回の問2で、この題材を設計します。
まとめ
- 期限切れは全台が同時に止まる。製品に埋め込まれた証明書にも注意
- 47日時代は年に8〜12回の更新。手作業は必ず漏れる
- 自動化の前に棚卸し。CT・スキャン・台帳を突き合わせる
- ACMEで申請から更新まで自動化。チャレンジはHTTP-01かDNS-01、DNS-01は権限を絞る
- Let’s Encryptの通知メールはもう来ない。ARIで更新時期をCAに合わせる
- 監視は外から実際に接続して確かめる。自動化できない機器は台帳で見張る
次回は、社内PKI（AD CS）とクラウドの証明書サービス、ロードバランサーでのTLS終端、vSphereの証明書を扱います。
連載「証明書入門」全11回
- なぜ証明書が必要か
- 暗号の基礎
- openssl・PowerShellで試す
- X.509証明書の中身
- PKIと信頼の仕組み
- 証明書の種類と発行
- TLSの仕組み
- ライフサイクルと自動化（この記事）
- 社内PKIとクラウド
- 証明書トラブルシュート
- 証明書の設計演習
コメント