TLS証明書の短命化はどこまで進んだか

手動更新を終える時点は枚数では決まりません。1枚の期限切れで本番が止まり、発行・検証・配布に人が必要で、新証明書の実適用を独立確認できないなら、既に手動更新を基本経路から除くべきです。

2026年3月15日以降に発行された公開信頼TLSサーバー証明書の最大有効期間は200日です。現行CA/Browser Forum Baseline Requirementsには2027年3月15日から100日、2029年3月15日から47日への短縮予定があります。[7] 後の2段階は未施行で、必要に応じて日程を変更する余地もあります。将来予定を既に有効な運用事実と扱ってはいけません。

短命化で必要なのは、更新ボタンを頻繁に押すことではありません。使用場所を把握し、発行とDomain Validationを自動化し、秘密鍵を適切な境界に保管し、全TLS終端へ配布して実際の提供を確認します。失敗時には安全な旧状態への復帰か、新証明書による復旧が必要です。この全体がCertificate Lifecycle Managementです。

最新BRはv2.2.9で、2026年8月6日に効力が生じました。[6] 表の200・100・47日は最大値です。1日は86,400秒で、わずかな超過も翌日扱いになるため、標準発行期間はそれぞれ199・99・46日以下が推奨される構造です。[1] DigiCertとSectigoは2026年3月の施行前または同時に、現行最大期間を199日へ変更しました。

表がすべての私設証明書に直接適用されるわけではありません。BRはインターネットからアクセス可能なサーバーを認証する公開信頼TLS証明書を対象とし、内部専用Root CAのPrivate PKIは直接適用の範囲外です。内部でも短命化や自動化を選べますが、組織が別途定める方針です。

発行時点
TLS最大有効期間
Domain・IP検証の最大再利用期間
2026年8月27日の状態
2026年3月15日より前398日398日過去の段階
2026年3月15日以上、2027年3月15日未満200日200日施行中
2027年3月15日以上、2029年3月15日未満100日100日現行BRの予定段階
2029年3月15日以降47日10日現行BRの予定段階
公開信頼TLSの最大有効期間と検証再利用期間：BR v2.2.9、2026年8月6日発効。8月27日時点

方針は既に実装段階に入ったか

これは遠い将来の議論ではありません。Chromiumの現在の検証Codeには、発行日を基準に2026年200日、2027年100日、2029年47日の制限が反映されています。Mozilla Root Store Policyも、収録CAに現行BRへの準拠を求めています。

Chrome Root Programは2027年3月15日から、信頼体系に含む各TLS Profileに自動発行・更新手段を要求します。ACME対応ならRFC 8555の主要操作に加え、RFC 9773のACME Renewal Informationも必要です。[2] これはCA側の能力の要件であり、サイト運営者に特定Clientを要求する意味ではありません。

CAごとの実発行期間は既に違います。DigiCertとSectigoは最大199日ですが、Let’s Encryptの既定Profileは90日です。一年の商品や契約でも、その間に199日以下の個別証明書を再発行する構造があります。購入期間とnotBefore–notAfterの有効期間は同じ値ではありません。

サービスの仕組み

コンテンツに合わせて配信経路を設計 — ファイルの更新方法に応じてキャッシュを分け、エッジ配信の結果とオリジン負荷を監視します。

手動更新の終了基準は証明書の枚数か

10枚なら自動化し1枚なら手動でよいという基準は安全ではありません。1枚でも決済API、管理画面、公開サイト、顧客連携Endpointを止めるなら高リスクです。表は手動更新を基本経路から除く兆候です。

人の介入自体が問題ではありません。人は方針、Domain承認、例外、セキュリティ事故、緊急復旧を担当します。除くべきなのは、日常の発行・更新が特定担当者の予定表、メール、記憶、手作業順序に依存する状態です。

手動更新を一時例外にできるのは、次をすべて満たす場合です。本番停止リスクが低い、Endpointと配布先が一つで明確、主担当と代替担当がいる、実サービスを確認する独立した期限警報がある、再試行と検証時間が十分、交換・失効・緊急再発行を実施した経験がある、例外終了日と自動化責任者を記録していることです。一つでも欠ければ長期モデルではなく未解決の運用負債です。

現在の状態
起こり得る問題
基本判断
本番トラフィックを処理する証明書担当者不在や作業漏れがサービス停止に直結定期発行・更新を自動化
CDN・LB・Ingress・複数Serverなど配布先が複数一部だけ旧証明書を提供する部分配布配布と対象別確認を自動化
DNS・Security・Infrastructureなど複数チームを経由承認・作業待ちが残存期間を消費Workflowと責任境界を自動化
DNS TXTを人が直接入力休暇・夜間・変更凍結中に更新停止DNS APIまたは専用検証構造
取得したファイルを人がコピー鍵流出、誤Chain、対象漏れSecret配布経路と原子的切り替え
Portalやローカルファイルの期限だけを見るLB・CDNが旧証明書を提供しても発見できない外部から実提供を確認
失敗計画が旧証明書の再配布しかない期限切れ・失効・流出ならRollback不能Rollbackと緊急発行を分離
手動更新を基本経路から除くべき兆候

ACMEの導入でLifecycle自動化は完了するか

ACMEは証明書管理を自動化する公開標準です。RFC 8555はAccount作成、Order、Domain Control証明、CSR提出、発行済み証明書の取得、失効要求を定義します。[2] 一般的なDV証明書は人の個別介入なくオンラインで要求・検証・発行できます。しかし接続だけでLifecycleは完成しません。

全体はInventoryから始まり、発行方針とOwner、ACME Order、HTTP-01/DNS-01 Challenge、Key・CSR生成、発行、証明書とChainの事前検証へ進みます。全終端へ配布して実サービスを検証し、更新・期限監視、Rotation、Rollback、Revocation、Emergency Issuance、Retirement、Auditまで続きます。

ACMEは発行取引を標準化しますが、保有証明書、責任者、配布先、部分失敗、旧証明書の再利用可否までは自動判断しません。目標はClientの設置ではなく、更新対象になれば発行・検証・配布・実サービス確認が自動で進み、失敗がOwnerに届いて安全な再試行や復旧へつながる状態です。

HTTP-01とDNS-01をどう選ぶか

新しさではなく、Domain Controlをどこで安全かつ反復可能に証明できるかで選びます。違いは表のとおりです。

HTTP-01は指定Challenge経路でAccount Keyに結び付く値を提供します。[2] Port 80、Redirect、IPv4・IPv6、複数Frontendの一貫性が影響します。Let’s EncryptもWildcard非対応で、複数Web ServerではすべてにChallengeファイルが必要と説明しています。[5]

DNS-01はWildcardと非公開Web Endpointに使えますが、DNS権限が高リスクSecretになります。Zone全体を変更できるCredentialをWeb Serverに置くと侵害範囲が広がります。可能なら_acme-challenge専用ZoneをCNAMEやNSで委任し、該当RecordだけのCredentialか別の検証Serverを使います。DNS伝播時間も更新窓に含めます。

人がPortalでTXT Recordを追加するDNS-01は、ProtocolがACMEでも運用は手動です。本番の定期更新ではDNS API、専用委任領域、別Validation Serviceのいずれかで反復作業を除きます。

区分
HTTP-01
DNS-01
検証方法/.well-known/acme-challenge/でToken応答_acme-challengeのTXT Record
必要権限対象Web EndpointのHTTP経路制御該当DNS Recordの変更権限
Network条件CAがPort 80へ到達可能Authoritative DNSへTXTが伝播
Wildcard非対応対応
複数Frontend全対象で同じ応答、または中央検証経路が必要Web Frontendと分離して検証可能
非公開Web Endpoint通常は不適切DNSを公開検証できれば利用可能
主なリスクPort 80遮断、誤Redirect、一部応答欠落広いDNS Credential、伝播遅延、古いRecordの残存
適合環境単純な公開Server、中央Ingress、自動HTTP Route制御Wildcard、多数Frontend、非公開Origin、発行とRuntimeの分離
HTTP-01とDNS-01：RFC 8555の検証方法・権限・条件・リスク・適合環境

秘密鍵と自動化Credentialはなぜ別のSecretか

記載の4種類を分けます。ACME ClientはAccount Keyで要求に署名し、発行段階では別のCSRを提出します。[2] Let’s EncryptもAccount KeyをCertificate Keyとして再使用できないと明記しています。[5]

秘密鍵の生成場所は終端構造と要件で変わります。終端で生成して外部Exportしない、中央Secret ManagementやHSM・KMS境界で生成して承認先だけに渡す、CDNや管理型Load Balancerに管理させる方式があります。

どの方式でも、鍵の場所と読み取り・交換権限をInventoryに残します。HSMは全環境の正解ではありませんが、Ticket・メッセージ・共有フォルダ・通常CI Logによる鍵の受け渡しを標準経路にしてはいけません。

ACME Account Key・Credential
Order、Authorization管理、実装によっては失効要求を可能にするSecretです。CA・Account・Domain範囲を制限し、自動化システムで保護します。
Certificate Private Key
Endpointの身元を証明しTLSを終端する鍵です。実終端か承認された中央Key管理境界に保管します。
DNS API Credential
ACME TXTを含むDNS変更を可能にします。_acme-challenge専用の最小権限にし、可能なら専用Zoneを使います。
Deployment Credential
LB・CDN・Secret Store・Applianceなどへ証明書と鍵を配布する資格情報です。対象と操作を制限し、監査記録を保ちます。

Certificate Inventoryに何を記録するか

Inventoryは期限一覧ではなく、証明書、サービス、Key、検証権限、配布先、復旧経路を結ぶ運用台帳です。[4] 18の記録項目を示しています。

CA Portalで検索できるものだけでは漏れます。CDNやCloud Load Balancerの自動発行証明書、古いApplianceや未使用Legacy Hostnameの証明書も、実トラフィックや信頼関係に残るなら管理対象です。

Certificate ID
変更されない内部識別子です。
Service・Environment
どのServiceのProduction・Staging・Development用かを示します。
Names
FQDN、SAN一覧、Wildcardの有無です。
TLS Termination Point
CDN・LB・Ingress・Reverse Proxy・Web Server・Applianceのどこで終端するかです。
Exposure
公開Internet、Partner専用、内部Private PKIの区分です。
CA・Account・Profile
発行CA、ACME Account、Profile、商品・契約との関係です。
Current Certificate
Serial、Fingerprint、notBefore、notAfter、Issuer、Chainです。
Key Boundary
生成・保管場所、Export可否、Key Versionです。
Challenge
HTTP-01/DNS-01、Validation Endpoint、DNS Zone、Credential Referenceです。
Owner
最終責任者と代替担当者です。
Distribution Targets
証明書とKeyを適用する全Endpoint・Region・Clusterです。
Renewal Policy
ARIの有無、Renewal Start、Escalation、Last Safe Deploymentです。
Monitoring
実提供証明書の確認場所とAlert Ownerです。
Rollback
旧正常証明書・Chainの保管場所と使用終了条件です。
Revocation
失効権限、受付経路、事故時の承認者です。
Emergency Issuance
緊急Account・Credential・配布経路・実行責任者です。
Lifecycle State
Planned、Active、Renewing、Failed、Revoked、Retiredの現在状態です。
Evidence
最後の成功発行・配布・外部検証時刻と作業記録です。

Lifecycle Runbookは何を約束するか

このRunbookは特定CAの操作説明ではなく、公開TLSの反復可能な運用契約です。Scope登録から定期Auditまで17段階ごとに標準作業、完了Evidence、失敗時の行動を定めます。失敗行動のない段階は、結局その場の判断に戻ります。

段階
標準作業
完了Evidence
失敗時の行動
1. Scope登録新Domain・Endpoint・Serviceの配布前にCertificate IDを作り、公開TLSとPrivate PKIを分ける。Inventory、Service・Environment・Names・Exposure未登録証明書を発行・配布Gateに通さない。
2. Owner指定Service・Automation・DNSのOwnerと代替担当を定め、最終責任者は1名に明確化する。Owner・Backup Owner、On-call・Escalation経路不在や退職・異動による空白を更新例外ではなく運用リスクとして警報する。
3. Issuance Policy許可CA・Account・Profile・SAN・Wildcard・Key Algorithm・再使用方針を定める。承認済みPolicy IDと変更記録方針外の発行は配布せず原因を確認する。
4. Challenge設計HTTP-01/DNS-01を選び、Network・DNS伝播・Wildcard・複数Frontend条件を確認する。Challenge Test、Route・DNS権限不安定なHTTP RouteやDNS APIを手動迂回せず、専用検証経路を復旧する。
5. Credential境界Account Key、Certificate Private Key、DNS Token、Deployment Credentialを分離する。Secret Reference、Scope、アクセス方針、Rotation記録露出疑いのCredentialを失効・交換し、影響した発行範囲を調べる。
6. Key・CSR生成承認場所でKeyを作り、正しいSAN・AlgorithmのCSRを生成する。Key Version、CSR Digest、要求Domain生成・検証失敗なら発行停止。一時Keyファイルを共有経路に移さない。
7. Issuance実行ACMEや承認APIでOrder・Authorization・Finalizeを実行。無限RetryせずBackoffと期限を適用する。Order ID、Authorization結果、発行SerialRate Limit・CAA・DNS・権限エラーを分けてOwnerへ渡す。安全配布時刻までに解決しなければIncidentへ移す。
8. 発行Artifact検証SAN、有効期間、Issuer、Chain、Keyとの一致、Algorithm、Policyを検査する。Pre-deployment Validation PASS誤発行を配布しない。必要なら再発行し、誤証明書の失効を判断する。
9. DistributionVersioned ArtifactやSecret Versionで全CDN・LB・Ingress・Server・Regionへ配布する。対象別AcknowledgementとVersion一部失敗を全成功と記録しない。拡大を止め、失敗対象とTrafficを分離する。
10. Activation・Live Verification限定先で有効化し、SNI付き実TLS接続でSerial・Fingerprint・Chain・Expiryを確認。IPv4・IPv6・主要Regionを分ける。外部Probeと期待Fingerprintの一致誤提供ならTraffic拡大を停止。旧証明書が安全なら戻し、危険ならForward Recovery。
11. Renewal Window対応時はARI推奨窓を使い、非対応ならLead Timeから開始・Escalation・Last Safe Deploymentを計算する。次回窓とJob Schedule初回失敗から期限警報を待たず、Retry Budgetと残り安全時間を合わせて警報する。
12. Rotation完了全対象の新証明書を確認し、旧証明書・Keyの使用終了時刻を記録する。Fleet全体の意図したSerial、旧Version無効旧Serialを提供するEndpointが残れば部分配布Incidentとして扱う。
13. Rollback・Forward Recovery旧証明書が有効・未失効・未流出で現Domain・Chainに適合するときだけ限定Rollbackする。条件確認と外部再検証旧Key流出や失効時は戻さず、新Key・証明書で前進復旧する。
14. Revocation鍵流出、無断発行、誤名称・情報、信頼不能な証明書を承認経路で失効要求する。要求、CA結果、Inventory更新revokeCertや緊急経路が失敗すればSecurity Incidentへ上げ、CA支援と代替信頼経路を使う。
15. Emergency Issuance通常と別の緊急権限・Account・連絡網で新Keyと証明書を発行し、限定配布と外部検証を行う。緊急記録、新Serial、影響Endpoint緊急経路も動かなければTraffic隔離、確認済み代替Endpoint、事前検証した発行経路を使う。
16. RetirementDomain・Service廃止時に証明書、Key、DNS委任、ACME Authorization、配布Secretを除く。廃止Evidence、Inventory RetiredDNSやLegacy Endpointが残れば完了扱いにしない。
17. 定期AuditInventoryをDNS・Endpoint・Certificate Transparency・Cloud資産と照合し、未登録とOwner空白を探す。照合結果、例外一覧と期限Unknown証明書はService・Owner・発行経路が分かるまでSecurity Review対象にする。
Certificate Lifecycle Runbook：公開TLSの反復可能な運用契約17段階
サービスの仕組み

監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。

更新を期限N日前に固定してよいか

有効期間と運用Lead Timeは証明書ごとに異なります。199日、90日、45日の証明書へ同じ30日前ルールを当てると、遅すぎたり不必要に早まったりします。

RFC 9773のARIではCAが証明書別の推奨更新窓をClientに提供できます。[3] 負荷分散だけでなく、大量失効や早期交換時に通常より早い更新を案内します。CAとClientが対応するなら、固定Cron日付よりARIを優先します。

使えなければ、notAfterから最大検証遅延、承認・変更待ち、全対象配布時間、再試行予算、変更凍結・休日、Incidentバッファを引き、最後の安全配布時刻を計算します。通常更新を始めるRenewal Start、再試行失敗が続けば人へ即時連絡するEscalation Deadline、通常手順で更新できる最後のLast Safe Deploymentを設けます。notAfterは更新期限ではなく、サービス失敗が始まる時刻です。

Let’s EncryptはARIを優先し、使えない場合は自社証明書の補助基準として寿命の一定割合が残る時点での更新を勧めています。[5] 全CA共通の30日ルールではありません。大量証明書は同時更新せず、発行時刻とJobを分散し、失敗が全Fleetへ同時に広がらないようBatchを分けます。

発行成功と配布成功はなぜ別の状態か

ACME Orderがvalidでも、新証明書が実サービスに適用されたとは限りません。Lifecycleには4つの独立した成功信号が必要です。

期限監視はローカルファイルやPortalだけでは不十分です。実際のユーザー経路へSNIを含めて接続し、notAfter、Serial、Fingerprint、Chainを検査します。IPv4だけ新しい、ソウルだけ新しい、CDN Edgeは新しいがOriginは期限切れ、一部IngressだけSecret Reload失敗、Listener一つだけ誤Certificate ID、中間Chainが誤っている、といった部分失敗を分けます。

期限30日前の単一警報に加え、Job未開始、Authorization・CAA・DNS失敗、発行後の配布未開始、一部Endpointだけ更新、実SerialとInventory目標の不一致、Rotation終了後の旧証明書提供、EscalationまたはLast Safe Deployment到達も警報します。

Issuance Success
CAが正しい証明書を発行した状態です。
Artifact Validation Success
SAN、Chain、有効期間、Private Keyが期待値と一致した状態です。
Distribution Success
全CDN・LB・Ingress・Serverが新Versionを受信した状態です。
Live Serving Success
外部Clientから見て、実Endpointが新Serialと正しいChainを提供する状態です。

Rollbackできない証明書もあるか

新証明書の配布失敗で、無条件に旧証明書を有効化してはいけません。旧証明書が未期限切れ、未失効、鍵流出の疑いなし、現Domain・構成に適合、Clientが信頼するChain、復帰後も十分な時間があることが条件です。

新SANやChainが誤り、旧証明書が条件を満たすなら短時間の復帰は可能です。旧Keyが流出または証明書が失効済みなら、Rollbackは事故を再有効化します。必要なのは新Key・新証明書によるForward Recoveryです。配布Rollbackでも流出・失効Secretを対象外にします。

Versioned Artifactで管理しても、旧Versionには使用終了条件が必要です。無期限に残した旧秘密鍵は復旧手段ではなく、新しい攻撃資産になります。

失効と緊急発行に別Runbookが必要なのはなぜか

交換と失効は別作業です。ACMEはrevokeCertを定義し、Account KeyまたはCertificate Keyで失効要求できます。[2] 実事故では、何をいつ失効させるか、先にTrafficを隔離するか、どの経路で新発行するかを組織が決めます。

失効を検討する例は、鍵流出または疑い、無承認発行、誤Domain・SAN・組織情報、Domain所有権や運用権の喪失、信頼できないシステムへのコピー、CAやSecurity Teamからの要求です。

緊急発行は8段階です。第1に宣言して通常変更を凍結し、期限リスク、鍵流出、無断発行を分けます。第2にInventoryでKey・Account・DNS Token・SAN・配布経路を共有する影響範囲を探します。第3に露出Credentialを交換し、Certificate KeyだけでなくAccount Key、DNS Token、Deployment Credentialも調べます。第4に損傷Keyを再使用せず新規発行します。別CAはChain、CAA、Client互換性、配布経路を事前検証した場合だけ使います。

第5に限定Endpointへ配布し、Serial、SAN、Chain、Handshake、健康信号を確認します。第6に可用性と攻撃リスクを合わせて旧証明書を失効します。悪用進行中なら隔離と失効を優先し、単なる配布誤りなら安全なReplacementを先に用意します。第7に長期接続、Cache、古いLB、IPv6、Legacy Hostnameも含め全配布先を再確認します。第8に原因、露出時間、失効結果、新Serial、再発防止作業と責任者を記録します。

代替CAは全組織の正解ではありません。Account、CAA、Chain、契約、方針、監査範囲も増えます。障害・規制・Client互換性の要件があり、実際の切り替えを試験した場合に復旧選択肢として意味があります。

管理型証明書もInventoryに残すべきか

CDN、PaaS、管理型LBが自動発行・更新すれば、利用者自身のACME Clientは不要です。ただし組織のLifecycle責任は消えません。

最低限、対象Hostname、TLS終端、発行・更新失敗の通知者、検証に必要なDNSと権限、移行・Account終了時の扱い、実提供の確認者、Vendor障害やAccountロック時の緊急経路を把握します。

供給者は発行とKey保管の一部を持ち、組織はInventory、Owner、設定Drift、実サービス検証、供給者変更時の復旧経路を持ちます。

自動化完了を確かめる5つの質問

全稼働証明書と終端がInventoryにあるか、Owner・Key位置・Challenge Credential境界が決まっているか、発行・検証・配布・再試行が反復手作業なく進むか、ツールと独立して実提供を確認するか、旧証明書が危険な場合の失効・緊急発行を試験したか。この5つに答えて初めて手動更新を終えたと言えます。

短命化は特定CAを選ぶ合図ではありません。年1回の購入品ではなく、配布とセキュリティ運用に含まれる反復可能なCredential Lifecycleとして扱う合図です。通常の発行・更新を自動化し、人は方針・例外・事故に集中します。47日段階まで待つ理由はありません。200日段階は既に始まっています。