証明書の有効期限が短縮される：64日間および45日TLSがTunnelsのカスタムドメインにもたらす影響

2027年2月10日、約3か月後、Let’s Encrypt はデフォルトの証明書有効期間を90日から64日へ変更します。約5週間後、2027年3月15日、公的に信頼された TLS 証明書の業界最大有効日数が200日から100日に減少します。どちらの変更も予期されるものでしたが、トンネルに向けられたカスタムドメインに対してこれが何をもたらすのかを問う開発者はほとんどいません。

app.yourdomain.com をトンネリングサービスを介して実行する場合、証明書はあなたのユーザー（または webhook の送信者）とローカルホストの間に配置されます。時計が切れるたびに誰かが更新を行う必要があり、その時計はこれから速く回ります。 本ガイドは正確なタイムライン、トンネルの背後での更新と DNS 検証の仕組み、プロバイダ管理と BYO（Bring Your Own）の証明書の違い、更新が静かに停止したときに現れる障害モードを解説します。

タイムライン：実際に何が変更され、いつ変更されるのか

2つの別々のスケジュールが動作しており、人はそれらをしばしば混同します。

1. CA/Browser Forum のスケジュール（すべての公開CAに適用）

2025年4月、CA/Browser Forum は Ballot SC-081v3 を通過させました。これにより最大証明書有効期間と、CA が以前のドメイン検証（DCV）を再利用できる期間の両方が段階的に短縮されます。2025年4月11日に提出され、反対票はありませんでした。

適用日	最大証明書有効期間	最大 DCV 再利用
2026年3月14日まで	398日	398日
2026年3月15日（すでに発効）	200日	200日
2027年3月15日	100日	100日
2029年3月15日	47日	10日

2. Let’s Encrypt のスケジュール（トンネルと ACME 設定で最も多く使われる CA）

Let’s Encrypt は法令の要件よりも速く動いています。2028年には 45日へ達し、フォーラムの47日最大値の1年前になります。

日付	ACME プロファイル	有効性	認証再利用
2026年5月13日（ライブ）	tlsserver（オプトイン）	45日	発表には記載なし
2027年2月10日	classic（デフォルト）	64日	30日から短縮され 10日
2028年2月16日	classic（デフォルト）	45日	7時間

Let’s Encrypt の発表のいくつかの詳細：

• ステージングは現在稼働中。 64日証明書は 2026年10月14日以降、Let’s Encrypt のステージング環境で利用可能で、運用前に更新設定を試せます。
• 既存の証明書は取り消されません。 Let’s Encrypt は最後の 90日間の証明書が 2027年5月11日に失効することを想定しています。
• tlsserver（45日）または shortlived（6日）プロファイルのユーザーは、2月の変更の影響を受けません。
• 短い認証再利用期間は静かな部分です。 再利用ウィンドウが縮小するにつれて、発行のたびにほぼ全ての検証を通すことになり、キャッシュされた検証に頼らなくなります。Again、Let’s Encrypt は検証データが7時間を超える場合、CAA 再検証の必要性も取り除くと述べています。

デフォルトのプロファイルを使い、ACME クライアントの設定を一切触っていない場合、2027年2月の変更は自動的に適用されます。更新が本当に自動化されていれば問題ありません。2023年以降誰も見ていない Cron ジョブを「自動化」と呼ぶ場合には問題です。

トンネル用カスタムドメインが特別なケースである理由

通常のサーバーでは秘密鍵を保持し、ACME クライアントを自分で実行します。トンネルでは公開のエッジは提供者のもので、あなたのドメインはそれを指す別名です。責任は3つの側に分かれます：

• 提供者 は TLS を終了させ、通常は証明書を取得・更新します。
• あなた は発行を可能にする DNS レコードを管理します。
• あなたのローカルアプリ は証明書を一切見ません。

短い有効期間はこの仕組みの DNS 側を最も圧迫します。提供者側の更新が完璧でも、あなた側のレコードがずれていると更新が失敗します。

プロバイダ管理証明書：便利だが見えないわけではない

多くのトンネルプラットフォームはマネージド証明書をデフォルトとし、ngrok のドキュメントは具体的な例です。特別な要件がない限り自動証明書を推奨します。これらは Let’s Encrypt のような ACME 準拠 CA から証明書を発行・更新します。ほとんどのドメインには HTTP-01 のチャレンジを使用し、ワイルドカードには DNS-01 に切り替えます。

api.your-domain.com のようなブランディングドメインの場合、CNAME レコードを作成します。発行は行われません。*.app.example.com のようなワイルドカードの場合は、/acme-challenge の二つの CNAME が必要です。

プロビジョィングは非同期です。ngrok は通常、数秒から数分程度、DNS チャレンジの検証が遅い場合にはもう少し長いことがあると述べています。実行中、ngrok は自分のデフォルトのワイルドカード証明書を提供します。その証明書はあなたのホスト名用に発行されていないため、ブラウザや他の TLS クライアントはホスト名の不一致警告を表示します。

このドキュメントは1社のベンダーを説明していますが、パターンは一般的です。短い有効期間の下で何を見ておくべきかを示しています：

1. CNAME はあなたの発行認証情報です。 誰かが DNS を“クリーンアップ”して削除すると、プロビジョニングは進行できません。398日なら1年間気づかないこともあります。64日なら約2か月、45日なら約6週間で判明します。
2. ワイルドカードは別レコードに依存します。 _acme-challenge の CNAME は忘れがちで、証明書の更新が必要になるまで何も壊れません。
3. フォールバック証明書は障害のように見えます。 ホスト名の不一致警告は、多くの API クライアントと webhook 送信者にとって致命的なエラーになります。人がクリックして通過できても、動作上の問題となります。

マネージド証明書はあなたの義務を取り除くものではありません。DNS レコードを正しく保ち、結果を監視するという短いリストに限定されます。

Bring Your Own Certificates：回転コストでコントロール

一部のチームは自分たちの証明書をアップロードします。内部 CA からのもの、EV 証明書、パートナーがピン留めしたものなどです。それは正当であり、有効期間が縮まるにつれてトレードオフが鮮明になります。

ngrok を例に挙げると、カスタム証明書は更新と回転の責任を伴います。 leaf 証明書を最初に含む PEM バンドルと、 intermediates、暗号化されていない秘密鍵をアップロードします。次にその証明書を1つ以上のドメインに添付します。なぜなら、それ自体を作成してもトラフィックは変わらないからです。

ngrok では TLS 証明書はすべてのプランで利用可能ですが、BYO 証明書は従量課金プランが必要です。少なくとも1つのエンドポイントがその証明書を使用してアクティブな clock 時間中は、1 時間あたり flat $0.27 で課金されます。ワイルドカード証明書は一度課金され、マッチするサブドメインごとに課金されません。ベンダーによって価格とプラン規則が異なるため、あなたのベンダーを確認してください。

単一のホスト名の回転計算を今から行います：

最大有効期限	年間最小回転回数
398日	1
200日	2
100日	4
64日	6
47日	8

これは、証明書を期限満了時に厳密に置換した場合の最小値です。更新を早めに行うべきであるため、実際の回数はこれよりも高くなります。

1つのホスト名について回転を計算する manual なプロセスは、年に1回程度は許容できたものですが、現在は6〜8回/年、環境ごとに掛け合わせて継続的なコストとなります。BYO の場合は entire パスを自動化してください：

1. あなたの ACME クライアントが証明書を取得します。
2. デプロイフックが provider の API を介してアップロードします。
3. 2 番目のステップでドメインに証明書を添付します。
4. その後、証明書の有効期限を実際に確認します。

スクリプト化できないステップを回避できない場合、それが失敗するステップです。

フォーラムのスケジュールは 公的に信頼された 証明書に適用されます。自分のクライアントが信頼するプライベート CA の証明書はこのスケジュールの外ですが、外部サービスがあなたのトンネル URL にアクセスした場合には役には立ちません。

更新が静かに失敗したときに壊れるもの

“静かに”が決定的な語です。故障を和らげてきたいくつかの点は、今は弱くなっています：

• リマインダメールはもう届きません。 Let’s Encrypt は 2025年6月4日に期限通知メールを終了しました。代わりにサードパーティのモニタリングを推奨しており、モニタリングページは Red Sift Certificates Lite（最大 250 証明書まで無料）を挙げています。安全網としてそのメールに依存していた場合、それはなくなっています。
• 短いウィンドウは余裕を減らします。 Let’s Encrypt は証明書の有効期間の約2/3で更新することを推奨しています。45日証明書の場合、約30日目で更新することになり、失敗を修正するのに約15日余裕が生まれます。64日証明書の場合は約43日目、約3週間の余裕です。
• 再利用は縮小しています。 認証再利用が10日、Let’s Encrypt のデフォルトプロファイルでは次に7時間へと短縮され、“前回うまくいった”が“今回はうまくいく”を意味しなくなりました。

トンネルのカスタムドメインでの典型的な障害モード：

障害	おそらくの症状
DNS 移行中に CNAME が削除または再ターゲットされる	プロビジョニングや更新が進行できない；提供者のステータスにエラーが表示
ファイアウォール、WAF、またはアクセス ポリシーで HTTP-01 要求がブロックされる	構成変更後の発行エラー
DNS API トークンが期限切れまたは回転される (DNS-01 設定)	ログで自動化が失敗する
CAA レコードが使用中の CA を除外している	発行が拒否される
古い ACME クライアントや放置された cron ジョブ	更新試行が全く行われない
アップロードした BYO 証明書が置換されていない	有効期限切れの証明書が引き続きドメインに添付されている

Let’s Encrypt のドキュメントの2つの詳細がここで関連します。まず、HTTP-01 はポート80でのみ実行可能です。その検証は最大10回のリダイレクトに従いますが、ポート80または443のみです。次に、Let’s Encrypt は発行前にCAA レコードを確認し、その CAA 識別子は letsencrypt.org です。

Webhook プロバイダと API ユーザーは最も寛容ではありません。警告をクリックして進む人もいますが、通常は TLS ハンドシェイクに失敗し、最初の兆候はエラーページよりもイベントの欠如です。

更新タイミング：固定オフセットの使用をやめる

多くのツールは 90 日証明書を前提とする固定ルール（例：「残り30日で更新」や「60日ごとに更新」）で設定されていました。Let’s Encrypt のガイダンスは率直です。60日というハードコードされた間隔は 45日証明書にはもはや不十分です。cron ジョブ、ラッパー スクリプト、ランブックに 83、80、60 のようなハードコードされた数値がないかを調べることを推奨します。80日待つようなものは、64日証明書を完全に見逃します。

より良い回答は ACME Renewal Information (ARI)、RFC 9773として標準化されたものです。CA はクライアントに更新の時期を伝え、クライアントは推奨ウィンドウ内で更新すべきです。Let’s Encrypt は ARI を推奨し、クライアントがそれを欠く場合は、証明書の有効期間の約2/3の時点で更新するのが許容されると述べています。

Certbot は CA が ARI をサポートする場合、バージョン 4.1.0（2025年6月）以降自動的に ARI を確認しています。他のクライアントは異なるため、想定せずに特定のクライアントとバージョンを検証してください。トンネル提供者には、あなたが制御していない ARI ベースのタイミングを採用しているかを尋ねてください。

短い有効期間下の DNS 検証

HTTP-01 vs DNS-01

HTTP-01 は単一ホスト名に対してシンプルです。CA がサイトからトークンを取得します。トンネルでは CNAME が設定され次第、提供者が通常それに対して応答します。DNS-01 はワイルドカードに必要で、HTTP-01 ができない場所で機能しますが、発行ごとに DNS 書き込みアクセスが必要です。Let’s Encrypt は DNS API の資格情報をウェブサーバーに置くと、侵害の影響が拡大することを指摘しています。資格情報を限定的にするか、別のサーバーから検証することを推奨します。

チャレンジを DNS キーを共有する代わりに委任する

Let’s Encrypt は DNS-01 検証の標準的な DNS ルックアップに従い、CNAME または NS レコードを使って _acme-challenge 名を別のゾーンに委任できます。これにより、 automation 用に予約されたゾーンを指すように _acme-challenge.yourdomain.com を設定でき、ゾーンだけに対して認証情報を限定します。 Delegation に従うクライアントのサポートは異なるため、あなたのクライアントを確認し、信頼する前にドライランでテストしてください。

DNS-PERSIST-01：新しい監視オプション

Let’s Encrypt は IETF 草案に基づく新しいチャレンジタイプ、DNS-PERSIST-01 を説明しています。 issuing のたびに新しいトークンを公開する代わりに、 _validation-persist.<domain> に CA とあなたの ACME アカウントを示す standing TXT レコードを公開します。更新時には DNS の変更は不要になり、セットアップ後に DNS 書き込みアクセスを閉じることができます。

スコープと有効期限はオプショナルなパラメータで制御されます。policy=wildcard は認証をワイルドカード証明書と一致するサブドメインへ拡張します。persistUntil は有効期限のタイムスタンプを設定します。 expiry がない場合、認証は無期限に続くため、監視リマインダーを設定してください。レコードが保持されるため、ACME アカウントのキーを保護することが最重要課題となります。CA/Browser Forum は 2025年10月に SC-088v3 の下位検証方法を承認しました。

Let’s Encrypt は 2026年Q2 の本番展開を目標にしており、まずステージングから開始します。実運用で稼働しているかの確認は見つかりませんでした。2026年7月時点のコミュニティの議論では、IETF 草案はまだ厳格化中で、公開CAの本番実装はまだないと説明されています。計画として捉え、依存しない方が良いです。トンネル提供者がこれをサポートしているかどうかも重要です、あなた自身の ACME クライアントだけでなく、 managed ドメインでは提供者が ACME アカウントを保持します。

トンネル上のカスタムドメインの実用チェックリスト

2027年2月10日以前

1. すべてのカスタムホスト名を把握し、誰が更新するかを記録する（提供者、あなたの ACME クライアント、または担当者）。
2. DNS レコードを検証する（CNAME のターゲット、ワイルドカードの場合は _acme-challenge）を提供者の最新の指示と照合する。
3. CAA レコードを確認して、実際に発行する CA を許可していることを確認する。
4. 更新をエンドツーエンドでテストする。 Let’s Encrypt のステージングを用いて ACME クライアントを実行し、64日間の証明書を2026年10月14日以降発行していることを確認する。マネージドドメインの場合は、提供者のステータス欄またはダッシュボードが健全な証明書を示していることを確認する。
5. 古いクライアントを更新する。 あなたのクライアントが ACME プロファイルと ARI をサポートしていること、ハードコードされた更新オフセットを削除することを確認する。

継続して

1. 実運用の証明書を監視する。 各ホスト名に接続して、証明書の残り有効期間が設定閾値以下になったときに通知する外部チェックを実行する。エッジが何を提供しているかは、コードの終了コード 0 のみでは判断できません。
2. DNS のドリフトを警告する。 CNAME が期待するターゲットに解決し続けているかを定期チェックすることが、最も一般的なマネージド証明書の障害を捕捉します。
3. 所有者を文書化する。 ドメインを設定した人が退職した場合、更新プロセスがその人とともに去らないようにする。
4. 障害をリハーサルする。 手動回復手順（レコードを再作成、再発行をトリガー、再アップロード）を、深夜2時に必要になる前に把握しておく。

Provider-Managed か BYO? 簡易意思決定ガイド

状況	より良い選択
標準的な公開サイト、Webhooks、カスタムドメイン上の API	Provider-managed
小規模チーム、専任運用なし	Provider-managed
特定の CA または証明書タイプの契約上の要件	BYO、自動アップロード付き
パートナーによってピン留めされた証明書	BYO、回転用運用手順付き
多数のト tunnels にまたがるワイルドカード	DNS-01 の委任で管理、または自動化付き BYO

ほとんどの開発者にとって、マネージド経路が適切であり、短い有効期間はそのケースを強化します。更新を継続的に行うプロバイダは、あなたが自分でスクリプトするはずの作業を代替しています。

Pro カスタムドメインが適用される場所

カスタムドメインは、トンネルが捨てられた URL ではなく、インフラストラクチャの一部になるポイントです：Webhook、デモ、ステージング、クライアントのプレビューの安定したホスト名。証明書の取り扱いがあなたの購入内容の一部になります。任意のトンネル提供者の Pro カスタムドメインプランを評価する際には、次を尋ねてください。

• 証明書は自動的に発行・更新されますか？更新が失敗した場合、ホスト名はどうなりますか？
• どのチャレンジタイプと DNS レコードが必要ですか？ダッシュボードや API で証明書のステータスと有効期限を確認できますか？
• ワイルドカードをサポートしていますか？ _acme-challenge レコードの取り扱いはどうなりますか？
• 自分の証明書を持ち込めますか？ API で回転をスクリプト化できますか？費用はどのくらいですか？
• Let’s Encrypt のリマインダーメールが廃止された現在、提供者は有効期限近づきをどう知らせますか？

これらの問いに明確に答えられるプランは、64日および45日への変更を非イベントにします。

よくある質問

64日への変更は CA/Browser Forum のルールですか？ いいえ。64日間のデフォルトは Let’s Encrypt の暫定的なステップです。フォーラムの現在の最大は 200日で、2027年3月15日に100日に低下します。

トンネル提供者が証明書を管理する場合、何かすべきですか？ 主に DNS レコードを維持し、ホスト名が実際に提供している証明書を監視します。

Let’s Encrypt の証明書は47日になりますか？ いいえ。Let’s Encrypt は 2028年2月16日から 45日を予定しており、フォーラムの最終的な最大値である47日には及びません。

既存の90日証明書はどうなりますか？ 期限が切れるまで有効で、変更の一環として撤回はされません。Let’s Encrypt は最後の90日証明書が 2027年5月11日に有効期限切れになると想定しています。2027年2月10日以降に発行または更新されたものは 64日間です。

自己署名証明書または私的 CA の証明書にもこの変更は適用されますか？ いいえ。スケジュールは公開に信頼された TLS 証明書に適用されます。私的 PKI は対象外ですが、外部サービスがあなたのトンネル URL を呼び出す際には信頼されません。

要点

• 主要な日付は以下です：2027年2月10日（Let’s Encrypt が 64 日へ移行）、2027年3月15日（100日業界最大）、2028年2月16日（Let’s Encrypt が 45 日へ移行）、2029年3月15日（47日最大、DCV 再利用 10日）。
• ト tunnels では、リニューアルエンジンの問題は少なく、DNS のドリフトや期限切れの資格情報、誰も回転させていない BYO 証明書がリスクとなることが多いです。
• Let’s Encrypt のリマインダーメールは 2025年6月で終了しています。外部からの証明書の監視を強化してください。
• 固定オフセットは ARI への移行や、証明書のライフタイムの約2/3での更新へと置き換えてください。
• マネージド証明書を優先し、特別な理由がない限り BYO を選択する場合は、すべてのステップを自動化してください。

出典

• CA/Browser Forum Ballot SC-081v3 スケジュール: SSLInsights、Odown、DNSimple
• Let’s Encrypt / ISRG: Decreasing Certificate Lifetimes to 45 Days
• Let’s Encrypt: 64-Day Certificate Lifetimes Coming Feb 2027
• Let’s Encrypt: DNS-PERSIST-01
• Let’s Encrypt community: DNS-PERSIST-01 deployment status および win-acme 議論
• Let’s Encrypt: Expiration Notification Service Has Ended
• Let’s Encrypt: Monitoring Service Options
• Let’s Encrypt: Challenge Types
• Let’s Encrypt: CAA
• ngrok: TLS certificates documentation
• Certbot 4.1.0 release (ARI support)
• IETF: ACME Renewal Information, RFC 9773