どちらも、もう通用しない考え方です。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. 証明書は、自分で買ったものだけでなく、製品の中にも埋め込まれている
2. 期限は分かっていても、記憶や手作業に頼ると漏れる
3. 切れた瞬間に全台が同時に止まり、冗長構成でも救えない

期限は台数に関係なく1つ。切れた瞬間に全部が止まります。

手作業の更新が破綻する理由

（回数の幅は、期限ぎりぎりで更新する場合と、余裕を持って残り1/3で更新する場合）

47日の証明書は、ほぼ毎月の作業になります。手作業ではCSRの作成、ドメイン認証（2029年からは再利用10日）、配置、再読み込みの確認を毎月繰り返すことになり、休暇や異動で必ず漏れます。

対策の中心は、自動化できるものはACMEで自動化し、手作業の枚数を減らすことです。

証明書の棚卸し（CT・スキャン・台帳）

自動化も監視も、どこに何枚の証明書があるかが分からなければ始まりません。棚卸しには3つの方法を組み合わせます。

1. CTログ（第5回）：公開CAの証明書はすべて記録されるため、crt.shなどで自社ドメインを検索すると、社内の誰かが取った証明書まで一覧できる。ただし、社内CAや自己署名の証明書は載らない
2. ネットワークのスキャン：社内のアドレス範囲の443番、LDAPS（636番）、メールの465・587番などに接続し、返ってくる証明書を集める。アプライアンスや管理画面の証明書も見つかる
3. 台帳：証明書ごとに、名前（SAN）、発行元、有効期限、秘密鍵の場所、配置先、更新方法（自動か手動か）、担当者を記録する

スキャンとCTの結果を台帳と突き合わせると、「台帳に無い証明書（野良証明書）」と「台帳にあるのに見つからない証明書」が分かります。CTは社内CAを、スキャンは届かない場所を見落とすので、組み合わせが大切です。

ACME（RFC 8555）の流れ

ACME（Automatic Certificate Management Environment、RFC 8555）は、証明書の申請から発行までをHTTPSのAPIで自動化する標準の手順です。

1. アカウント：鍵ペアを作ってCAに登録する。以降の要求はすべてこの鍵で署名する
2. 注文（newOrder）：載せたい名前を伝える
3. 認証：CAが名前ごとにチャレンジ（第6回）を返し、クライアントはトークンをWebサーバーやDNSに置いて確認を頼む
4. CSRの送信（finalize）：すべての名前の認証が済んだら、機器の上で作ったCSRを送る
5. 発行：証明書をダウンロードして配置し、サービスを再読み込みする
6. 更新：期限が近づくか、CAから時期を知らされたら（ARI）、②から繰り返す

人が関わるのは最初の設定だけ。以降は②〜⑤を自動で回します。更新のたびに、鍵も新しく作るのが普通です。

チャレンジの選び方

DNS-01の最大のリスクは、DNSを書き換えられる認証情報をサーバーに置くことです。ゾーン全体の権限が漏れると、Webサイトの乗っ取りにつながります。権限をレコード単位に絞る、CNAMEで認証専用のゾーンに委任する、などで被害を限定しましょう。CAAのaccounturi・validationmethods（RFC 8657、第5回）で、使えるアカウントと方法を絞ることもできます。

Let’s Encryptの現在（2026年9月）

冒頭の「メールが来るから大丈夫」は、ここで崩れます。通知メールをやめた理由として、自動化の普及、数百万のメールアドレスを持ち続けることのプライバシー上の問題、費用が挙げられています。「メールが来るから大丈夫」だった運用には、すでに通知が来ていません。プロファイルはACMEクライアントで選べます（certbotは--preferred-profile）。

ACMEクライアント

acme.shでLet’s Encryptを使うなら、--set-default-ca --server letsencryptで既定のCAを変えます。

どのクライアントでも、次の3点は必ず設定しましょう。

1. 更新後にサービスを再読み込みするフック
2. 失敗したときの通知
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"、終了コード1

PS> 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クライアントを入れられないことがあります。

次の順で考えます。

1. 製品の機能を調べる：ACMEクライアントの内蔵や、APIでの証明書の入れ替えに対応する製品が増えている
2. 外で取って配る：別のサーバーのACMEクライアントがDNS-01で取った証明書を、APIやSSHで機器に配る
3. 前段で終端する：前に置いたロードバランサーやリバースプロキシーでTLSを終端し、そこを自動化する（第9回）
4. 社内CAに切り替える：公開する必要がない管理画面などは、社内CAの証明書にすれば47日の制約を受けない

どれもできない機器は、台帳で「手動更新」として管理し、監視と手順書、交換の計画を用意します。最後まで残った機器だけを、人が台帳で見張る、という形を目指しましょう。

考えてみよう

1. 自分の担当範囲の証明書を、台帳を見ずに何枚挙げられますか。crt.shで自社ドメインを検索すると、知らない証明書は出てきませんか。
2. 今使っている証明書のうち、ACMEで自動化できるもの、外で取って配れば自動化できるもの、どうしても手作業のものは、それぞれ何枚ありますか。
3. 期限切れや更新の失敗に、利用者より先に気づける仕組みはありますか。失敗したとき、誰にどう通知されますか。

ヒント：この記事の「棚卸し」「チャレンジの選び方」と「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回

1. なぜ証明書が必要か
2. 暗号の基礎
3. openssl・PowerShellで試す
4. X.509証明書の中身
5. PKIと信頼の仕組み
6. 証明書の種類と発行
7. TLSの仕組み
8. ライフサイクルと自動化（この記事）
9. 社内PKIとクラウド
10. 証明書トラブルシュート
11. 証明書の設計演習