公開Webサイト向けのSSL/TLSサーバー証明書は、CA/Browser Forumの業界要件により、最大有効期間が2026年3月15日から200日、2027年3月15日から100日、2029年3月15日から47日へ段階的に短縮されます。 2026年10月26日時点で200日への変更はすでに施行されており、2027年・2029年のさらなる短縮が予定されています。
変更されるのは単に「証明書の期限日」だけではありません。ドメイン名・IPアドレスの管理権限を確認した結果を、次の証明書発行に再利用できる期間も、同じ2029年3月15日から最大10日へ短縮されます。今後は証明書を更新する機会とドメイン認証を行う機会が増えるため、手作業中心の管理では更新漏れ・反映漏れを防ぐ運用が難しくなります。
本記事では、この制度がいつ・何を・どこまで変更するのかを一次資料に基づいて整理し、レンタルサーバー・自社サーバー・複数サイトの管理者に必要な準備を説明します。一般的な有効期限の調べ方はSSL証明書の有効期限を確認する方法、更新の設定手順はACMEによる自動更新の解説に分け、本記事は制度変更と運用上の影響に焦点を当てます。
SSL証明書の有効期間は2026年からどう変わる？
最初に、公開TLSサーバー証明書についてCA/Browser Forumが定める上限を示します。2026年の変更はすでに施行されており、今後は2027年・2029年に上限がさらに縮みます。「最大」と「認証局が実際に発行する日数」は一致するとは限りません。
2026年3月15日から最大200日へ短縮
2026年3月15日より前に発行する公開TLSサーバー証明書の最大有効期間は398日でした。2026年3月15日以降、2027年3月15日より前に発行する証明書は最大200日となり、CA/Browser Forumの基準では199日以下を推奨しています。この「200日」はすべての証明書が200日になるという意味ではなく、発行できる上限です。
認証局によっては、境界を超えないよう自社の商品を199日などに設定します。例えばDigiCertは業界要件に合わせて199日という発行期間を案内しています。業界要件の200日と、個別商品で案内される199日を混同しないようにしましょう。
2027年3月15日から最大100日へ短縮
2027年3月15日以降、2029年3月15日より前に発行する公開TLSサーバー証明書の最大有効期間は100日となります。CA/Browser Forumは99日以下を推奨しています。2026年時点の最大200日と比べ、同じ証明書を使い続けられる時間がさらに短くなります。
この時期になると、年1回だけ証明書を確認する運用では、1つの証明書が何度も更新されることになります。更新が行われた記録と公開サイトの接続状況を、継続的に把握できる仕組みが必要です。
2029年3月15日から最大47日へ短縮
2029年3月15日以降に発行する公開TLSサーバー証明書の最大有効期間は47日、推奨は46日以下となります。従来の最大398日と比較すると、有効期間の上限は約8分の1に短縮されます。
47日目まで更新を待つ設計では、更新が失敗したときに対応する時間がなくなります。実際の運用では期限に余裕を持って更新し、認証や配信先への反映を確認する必要があります。2029年の47日化は「毎月必ず47日間の証明書を発行する」という制度ではありません。
年表で比較：最大398日から47日へ
業界要件の変更を、証明書の発行日を基準に比較すると次のとおりです。表の「推奨」はCA/Browser ForumのSHOULD、「最大」はMUST NOTを超えてはいけない上限であり、事業者ごとの商品設定とは異なります。
| 証明書の発行日 | 最大有効期間 | 推奨上限 | 施行状況（2026年10月時点） |
|---|---|---|---|
| 2026年3月14日以前 | 398日 | 397日 | 以前の基準 |
| 2026年3月15日以降 | 200日 | 199日 | 施行済み |
| 2027年3月15日以降 | 100日 | 99日 | 今後の予定 |
| 2029年3月15日以降 | 47日 | 46日 | 今後の予定 |
この日程はCA/Browser ForumのBaseline Requirements §6.3.2に明記されています。2028年には同基準で新たな有効期間の上限が始まるわけではありません。2028年の重要な変更としては、後述するLet’s Encrypt独自の45日化が予定されています。
なぜSSL証明書の有効期間が短縮されるのか
証明書の有効期間を短くする目的は、期限切れの回数を増やすことではありません。長期間有効な証明書が持つセキュリティ上のリスクを小さくし、証明書とドメイン管理情報の確認頻度を高めることが背景にあります。
秘密鍵の漏えいや誤発行の影響期間を短くする
秘密鍵が漏えいしたり、誤った内容の証明書が発行されたりすると、その証明書が長期間有効であるほど、問題を見落としたまま運用する期間が長くなる可能性があります。短い有効期間は、そのような証明書が有効であり続ける期間に上限を設けます。
ただし、短期証明書になれば秘密鍵の漏えいが自動的に防がれるわけではありません。秘密鍵のアクセス権限や保存方法、必要に応じた失効・再発行、サーバーの設定などの対策は引き続き必要です。
ドメインの所有・管理状況を新しい情報で確かめる
ドメインの管理者やDNSの設定は、数か月の間にも変わり得ます。古いドメイン認証の結果を長期間再利用できる仕組みでは、その後に発生した変更を十分に反映できない可能性があります。
CA/Browser Forumは証明書の有効期間とともに、ドメイン名・IPアドレスの検証結果を再利用できる期間も短縮します。証明書の発行時に、より新しい管理権限の確認を求める設計です。
手動運用ではなく自動化を前提とする方向
短期化によって、証明書の取得、ドメイン認証、適用、公開環境の確認が以前より頻繁に必要になります。発行のたびに人が管理画面を操作する方式では、更新機会の増加に合わせて工数や見落としのリスクも増えます。
ACMEなどによる自動化は、この変更を現実的に運用するための方法です。ただし「自動更新を設定した」という事実だけでは、公開サーバーに正しい証明書が反映されたかまでは確認できません。
有効期間とドメイン認証の再利用期間は別の制度
2029年に向けた変更で特に注意したいのは、証明書が使える日数と、証明書を発行するためのドメイン認証結果を再利用できる日数が異なることです。この二つを同じ「SSLの期限」として管理すると、発行時に必要な作業を見落とす可能性があります。
証明書の有効期間はブラウザとサーバーの接続に関わる
証明書の有効期間は、証明書に記録された開始日時（notBefore）から終了日時（notAfter）までです。期限が切れると、ブラウザは証明書の有効性を確認できず、HTTPS接続に警告が出る可能性があります。
2029年に最大47日というのは、この公開TLSサーバー証明書自体の有効期間の上限を示します。特定の日にすべての既存証明書が一斉に期限切れになるという意味ではありません。
ドメイン認証の再利用期間は発行手続きに関わる
認証局は証明書を発行する際、申請者が対象ドメインやIPアドレスを管理する権限を持つことを確認します。その確認結果を、次回以降の証明書発行でどのくらいの期間再利用できるかについても業界要件があります。
ドメイン名・IPアドレスの検証結果の最大再利用期間は2026年3月15日から200日、2027年3月15日から100日、2029年3月15日から10日となります。2029年は「証明書の最大47日」と「ドメイン認証結果の再利用は最大10日」を分けて管理する必要があります。
2029年の変更を比較表で整理
同じ日程に見える変更でも対象が異なるため、二つの上限を並べて見ると理解しやすくなります。実際の認証局はこれらより短い期間を採用することがあります。
| 適用開始日 | 証明書の最大有効期間 | ドメイン・IP検証結果の最大再利用期間 |
|---|---|---|
| 2026年3月15日 | 200日 | 200日 |
| 2027年3月15日 | 100日 | 100日 |
| 2029年3月15日 | 47日 | 10日 |
認証結果の再利用期間が10日だからといって、すべての証明書を10日ごとに交換しなければならないという意味ではありません。新たな証明書の発行時に使える検証結果の鮮度に関する制限です。ACMEなどでは、必要な認証を自動で実施する仕組みを整えることが重要になります。
OV・EVの組織認証の再利用期間も同一ではない
OVやEVなどでは、ドメインの管理権限とは別に、組織の身元情報についての確認が必要になる場合があります。CA/Browser Forumの要件では、ドメイン名・IPアドレス以外の主体情報に関する検証データの再利用期間は、2026年3月15日から最大398日となっています。
したがって、2029年にドメイン認証の再利用期間が最大10日となっても、組織認証の全情報を一律に10日ごとに確認し直すという意味ではありません。実際の申請時は利用する認証局と証明書種別の条件を確認してください。
Let’s Encryptは2027年64日、2028年45日へ
CA/Browser Forumが定めるのは公開TLS証明書の業界共通の上限です。一方、Let’s Encryptは、自社で発行する証明書の標準有効期間をさらに短くする日程を公表しています。これらは同じ数字ではないため、別の予定として理解してください。
2027年2月10日から標準64日を予定
Let’s Encryptは2026年10月7日の公式発表で、2027年2月10日以降に発行・更新する通常の証明書について、標準有効期間を64日とする予定を示しました。45日や6日の短期プロファイルを選択している場合は、その条件が別途適用されます。
2026年10月14日には、ステージング環境のclassicプロファイルで64日証明書の発行が開始されたと案内されています。これは試験環境での変更であり、2026年10月の本番環境の標準証明書がすべて64日に切り替わったという意味ではありません。
2028年2月16日から標準45日を予定
Let’s Encryptの2025年12月2日の公式発表では、classicプロファイルの標準有効期間を2028年2月16日から45日に短縮する予定です。これは2029年にCA/Browser Forumが最大47日とする前に、同認証局が独自の移行日程を設定している例です。
なお、2026年5月13日からは、希望する利用者向けの tlsserver ACMEプロファイルで45日証明書を発行する選択肢も用意されています。すべてのLet’s Encrypt利用者が2026年から45日になったという意味ではありません。
CA/Browser Forumの年表と混同しない
同じ2027年でも、Let’s Encryptの標準64日化（2月10日予定）と、業界全体の最大100日化（3月15日）は別の変更です。また2028年はLet’s Encryptの45日化の予定がありますが、業界共通の最大100日の規則が2028年途中に自動で47日に切り替わるわけではありません。
| 日付 | 対象 | 内容 |
|---|---|---|
| 2026年3月15日 | CA/Browser Forum | 最大200日へ（施行済み） |
| 2027年2月10日 | Let’s Encrypt | 通常証明書は標準64日へ変更予定 |
| 2027年3月15日 | CA/Browser Forum | 最大100日へ変更予定 |
| 2028年2月16日 | Let’s Encrypt | 通常証明書は標準45日へ変更予定 |
| 2029年3月15日 | CA/Browser Forum | 最大47日、ドメイン認証再利用は最大10日へ |
発行済みの証明書が突然失効するわけではない
Let’s Encryptは64日化の発表で、変更によって有効な証明書を一斉に失効させることはないと案内しています。CA/Browser Forumの有効期間制限も、表に示した適用開始日以降の新規発行を対象とする基準です。
ただし、手元の証明書にどの有効期間が適用されるかは、発行時期と証明書に記載された日時で判断します。実際の証明書を調べる操作は有効期限の確認手順にまとめています。
証明書の短期化で更新回数はどのくらい増えるのか
上限が短くなると、同じサイトを継続運用する間に証明書を交換する機会は増えます。ただし、更新の頻度は証明書の実際の有効期間や事前更新するタイミングで変わるため、年あたりの回数を業界全体で一つに決めることはできません。
最大有効期間だけで比較した単純な計算例
以下は、365日を各制度の最大有効期間で割った参考値です。期限ぎりぎりで更新することを推奨する数字ではなく、制度変更による期間の短さを比較するための計算例です。実際には有効期限より前に更新するため、更新実行の間隔はさらに短くなります。
| 最大有効期間 | 365日÷有効期間（参考） | 考え方 |
|---|---|---|
| 398日 | 約0.92回分 | 以前の上限。1年を超える期間 |
| 200日 | 約1.83回分 | 2026年以降の上限 |
| 100日 | 約3.65回分 | 2027年以降の上限 |
| 47日 | 約7.77回分 | 2029年以降の上限 |
更新の予定を立てる際に、年間「ちょうど8回」と固定することは適切ではありません。証明書が短期になれば更新に必要な余裕も設けるため、通常はさらに高頻度になります。実際の更新条件は認証局・ACMEクライアント・ホスティング事業者の仕様に従ってください。
複数サイトを手動で管理するほど作業が増える
複数のドメインやサブドメインを管理している場合、更新する証明書と適用先を一覧にしていないと、交換作業のたびに対象の確認が必要になります。管理する対象数が増えれば、更新、検証、担当者への連絡、証明書の保存先の確認などの作業も重くなります。
複数のホストで一つのSAN証明書やワイルドカード証明書を利用している場合、証明書の発行件数とホスト数は一致しません。それでも、配信先が複数なら公開側に正しく反映されたかを確認する必要があります。
更新作業に加えて「確認作業」の頻度も上がる
更新に成功したと報告されても、実際の公開サイトで古い証明書が提供されている場合があります。ロードバランサーやCDN、複数サーバーの一部にだけ新しい証明書が反映される構成では、更新後の確認が重要です。
したがって、単に発行を自動化するだけでなく、サーバーへの適用やHTTPSの最終確認までを自動・定常化できるかが、運用負担を減らすポイントになります。
レンタルサーバー・自社サーバーで影響はどう違う？
同じSSL証明書の短期化でも、運営者が直接対応する作業範囲は、利用するサービスの管理方式によって変わります。証明書を誰が発行・更新しているか、どこでHTTPS接続が終端するかを整理してください。
レンタルサーバーの自動SSLを利用する場合
共有レンタルサーバーやマネージドホスティングでは、事業者が証明書の発行・更新・適用まで管理していることがあります。この場合、利用者が新たにCertbotを導入する必要がない場合もあります。
ただし「無料SSLが設定されている」だけで、短期化後も必ずすべてのホスト名が自動更新されると保証されるわけではありません。契約先の公式マニュアルで対応方針を確認し、更新対象の漏れや公開サイトの期限を確認する運用が必要です。
VPS・専用サーバーで自己管理する場合
VPSや専用サーバーでCertbotなどを利用している場合、定期実行スケジュール、ドメイン認証、証明書の保存先、Webサーバーへの反映、ログなどを管理者が確認する必要があります。過去に「年に1回の手動更新」で運用していた場合は、短期化後の運用に合わなくなります。
自動化を導入済みでも、スケジューラーの停止やDNS・Webサーバー設定変更によって更新に失敗する場合があります。更新テストの具体的な方法はACME自動更新の記事で説明しています。
CDNやロードバランサー利用時の確認ポイント
CDN・ロードバランサーでは、利用者とCDNの間、CDNとオリジンサーバーの間など、証明書を利用する接続区間が複数になる場合があります。各区間でどの管理サービスが証明書を更新するかを把握する必要があります。
CDNが自動的に更新した証明書と、サーバー管理者が別に更新するオリジン証明書が混在する場合は、双方の有効期間と管理責任を区別します。ひとつの管理画面の「更新済み」表示だけで全経路の復旧を確定しないようにします。
制作会社・保守会社との契約で決めておくこと
Web制作会社へ保守を委託している場合、証明書の自動更新が契約範囲に含まれるか、更新失敗時に誰が確認し、誰が顧客へ連絡するか明確にしておきましょう。
契約先が管理するサーバーと、自社が管理するドメイン・DNSが別なら、認証用TXTレコードやAPI権限などで連携が必要になる場合があります。短期化によってこうした作業の頻度が増えることを踏まえ、担当範囲と連絡先を確認します。
2027年・2029年へ向けて自動更新で見直すこと
証明書の交換頻度が増えるほど、更新のタイミングを固定した古いスクリプトや、人の手を前提とした手順書に問題が生じやすくなります。単に「Certbotが入っている」だけでなく、短期証明書でも処理が完了するかを確認しましょう。
「残り30日で更新」など固定の数値を点検する
Let’s Encryptは2027年の64日化の発表で、期限から固定の日数を引く方式を見直し、証明書の有効期間の約3分の2を経過した段階で更新する考え方を示しています。例えば古いスクリプトに「残り60日になったら更新する」といった条件が固定されていれば、短期証明書では更新のタイミングが適切でなくなる可能性があります。
ただし、この「約3分の2」はすべての証明書・すべてのクライアントに強制される業界要件ではありません。実際の更新条件は利用中のACMEクライアントと認証局の仕様を確認してください。
ACME Renewal Info（ARI）への対応を確認する
ACME Renewal Info（ARI）は、認証局が証明書を更新するのに適したタイミングをACMEクライアントへ伝えるための仕組みです。Let’s Encryptは短期証明書への移行にあたり、ARIに対応したクライアントを推奨しています。
利用中のソフトウェアがARIを扱えるかは製品・バージョンごとに異なります。ARIへ対応していれば必ず更新・配信・公開確認が成功するという意味ではないため、スケジュールと結果の確認は必要です。
ドメイン認証の自動化を含めて確認する
2029年にドメイン認証結果の再利用期間が最大10日になると、長期間同じ認証結果に頼る方式では、次回発行の際に新しいドメイン認証が必要になる場面が増えます。HTTP-01やDNS-01などのドメイン認証を、毎回人が操作せずに進められるか確認します。
DNS-01を利用する場合はAPIによるTXTレコード更新の仕組みや権限管理、HTTP-01なら必要な公開URLの到達性が重要です。具体的な設定方法はACMEの導入記事に譲り、ここでは短期化に備えるという目的に絞ります。
更新失敗・定期実行停止を把握できるようにする
証明書の発行が自動でも、実行されなかったり、認証に失敗したり、更新した証明書が反映されなかったりする可能性があります。失敗ログ、定期実行の最終成功時刻、公開サイトの証明書の有効期間を、別々に確認できるようにします。
失敗時の詳細な原因別対応はLet’s Encryptの更新失敗と対処方法にまとめています。
SSL証明書の短期化に対応する監視と連絡体制
短期化により、証明書が古いまま残る時間の余裕は小さくなります。更新したつもりでも公開側が切り替わっていない場合を検知できるよう、期限の把握、確認時刻、担当者への連絡を整える必要があります。
管理画面の更新成功と公開サイトの正常を区別する
更新サービスの管理画面で「成功」と表示されても、公開サイトが利用者へ提示する証明書に反映されていない場合があります。証明書の実際の有効期限、対象ホスト名、HTTPS接続の結果を、公開側から確認できる状態が望まれます。
Webサーバーが稼働していても、証明書の期限切れでブラウザに警告が表示される場合があります。HTTPの死活監視とSSL証明書の期限監視は同じではありません。
通知のタイミングは証明書の期間に合わせる
最大200日、100日、47日という上限に対応する中で、従来と同じ「30日前に通知」という一つの条件がすべてに適切とは限りません。短い証明書で常に期限接近警告が出続ける設計や、更新予定を過ぎても放置する設計は避けます。
監視サービスごとに通知条件や監視頻度は異なります。期限接近の段階的な確認や担当者の連絡順はSSL期限監視の設計例で説明しています。そこで示す日数は一般的な運用例であり、すべてのサービスの既定設定ではありません。
担当者不在でも確認できる運用にする
更新時期に運用担当者が休暇や出張で不在の場合でも、失敗を発見できなければ期限切れへ進む可能性があります。サイトの管理者、証明書の更新担当者、代行者、外部の委託先を記録し、確認方法を引き継げるようにします。
通知を見た人が誰か、対応が完了したか、公開URLの証明書まで確認したかを区別する運用も重要です。通知が送信済みという事実だけで解決済みとは判断できません。
2026年から2029年の準備ロードマップ
制度変更に備える作業は、2029年になってから始めるのではなく、現在の管理対象と更新方式を把握することから着手できます。ここでは2026年10月26日時点で確認できる制度を前提に、実務へ落とし込んだ準備の順序を示します。
2026年：現在の契約と管理対象を棚卸しする
2026年3月から最大200日への変更は施行済みです。まず公開しているWebサイトのホスト名と利用している認証局、更新方法、証明書の管理者、CDNやロードバランサーの有無を整理します。レンタルサーバーを利用している場合は、自動SSLの短期証明書への対応方針を公式マニュアルで確認します。
自社管理サーバーの場合は、定期実行が正常に動くか、更新後にWebサーバーへ反映する仕組みがあるか、公開URLで証明書を確認できるかを調べます。年1回の手作業を前提とした手順は、今の時点で見直す必要があります。
2027年：最大100日とLet’s Encryptの64日化へ対応
2027年は、2月にLet’s Encryptの標準64日化、3月に業界の最大100日化が予定されています。自動更新のテスト、定期実行の確認、ドメイン認証の再試験、更新後の公開証明書の確認をひととおり実施しておくことが重要です。
実際に利用している証明書の有効期間が変わる時期は、認証局や発行日の条件によって異なります。公式発表の変更日だけでなく、利用している商品の案内も確認してください。
2028年：45日級の証明書で運用を検証する
Let’s Encryptのclassicプロファイルは、2028年2月16日に標準45日へ変更する予定です。このような短い証明書では、更新機会が増えるため、失敗時にすぐ気付けるか、次回の実行までの時間が適切かを確認します。
一方、すべての認証局の証明書が2028年に45日になるわけではありません。自社が利用する発行元の実際の有効期間を基準に運用を決めましょう。
2029年：47日上限と認証再利用10日に対応
2029年3月15日以降は、公開TLS証明書の最大有効期間が47日、ドメイン名・IPアドレスの検証結果の再利用期間が最大10日になります。更新の自動化だけでなく、認証の自動化、証明書の配布と反映、公開側の確認が途切れないことを重視します。
利用者がログイン・申込み・決済などを行う重要サイトでは、期限切れにより業務へ影響が出るため、管理責任と障害時の連絡経路を明確にしておきます。具体的な障害後の復旧手順は期限切れの対処方法で別に扱っています。
短期化へ備えるSSL証明書管理チェックリスト
制度変更を理解しても、実際の管理対象が把握できていなければ運用へ反映できません。以下の項目を、証明書の発行元とサーバー・DNSの管理者ごとに確認してください。
- 公開サイトのドメイン名・サブドメインを一覧にしているか。
- 使用している認証局と証明書の有効期間を把握しているか。
- 2026・2027・2029年の最大有効期間の違いを理解しているか。
- 証明書の期限とドメイン認証結果の再利用期間を区別しているか。
- 自動更新を担当するサービス・ソフトウェアが分かるか。
- HTTP-01・DNS-01など必要なドメイン認証を継続できるか。
- 定期実行の最終成功時刻やログを確認できるか。
- Webサーバー・CDN・ロードバランサーの反映先を把握しているか。
- 公開URLで実際に提示されている証明書を確認できるか。
- 短期証明書に不向きな固定の更新・通知条件が残っていないか。
- 担当者不在時の連絡先と代行者が決まっているか。
- 期限切れが発生した際の連絡・復旧方法を整理しているか。
最初の優先事項は「更新主体」と「公開先」の一致
どの会社・システムが証明書を更新し、どのサーバー・CDNがその証明書を公開しているかを確認します。この二つが分かれている場合は、発行成功後に配布・適用を確かめる手順が必要です。
不明な場合は、証明書を発行した事業者の契約書や管理画面、DNSとサーバーの管理構成を確認し、必要に応じて保守事業者へ正式に問い合わせましょう。
記録する情報は「期限・確認日時・担当」の三つから
すべての管理項目を一度に整備できない場合でも、少なくとも証明書の対象ホスト名、現在の有効期限、最後に確認した日時、更新担当者を記録すると、優先的に見直す対象を把握しやすくなります。
ただし手作業の管理表があるだけでは、期限接近を自動検知できるわけではありません。管理件数と重要度に応じて、継続的な確認方法を用意してください。
エンリンクでできることと、できないこと
SSL証明書の短期化に向けた管理では、公開サイトがどの有効期限の証明書を提示しているかを確認することが重要です。エンリンクの現行公開機能の範囲を、証明書の発行・更新作業と区別して整理します。
複数サイトのSSL証明書の期限と残り日数を確認
エンリンクの機能一覧には、HTTPS接続時に確認したSSL証明書の有効期限と残り日数を管理画面に表示する機能が記載されています。複数サイトの更新時期を一覧で確認したい場合に役立ちます。
この機能は証明書の状態を確認するためのものであり、認証局への発行申請やWebサーバーへの証明書配布を自動的に代行するという意味ではありません。
期限接近の通知は管理画面内で確認する
公開機能一覧では、SSL証明書の期限接近を管理画面内の通知で確認でき、既読・未読や履歴を管理できると案内されています。ただし、何日前に通知するかを任意に細かく設定できるか、SSL期限についてメールを必ず送るかは、この公開情報だけでは確認できません。
したがって本記事で説明した更新・連絡の設計例を、エンリンクの標準設定として案内するものではありません。現行機能の詳細は公式機能ページをご確認ください。
無料プランから管理対象を整理できる
2026年10月26日に確認した料金ページでは、無料プランは最大5サイトで定期監視は1日2回とされています。定期監視の頻度は検知時間の保証を意味するものではありません。
自社のサイトのSSL証明書の期限をまとめて把握したい方は、無料アカウント登録から利用できます。証明書の自動更新やドメイン認証の代行とは別の機能である点をご確認ください。
SSL証明書の有効期間短縮についてよくある質問
業界ルールと認証局の個別の運用予定を混同しやすいため、特によくある疑問を整理します。日程や日数は2026年10月26日時点で確認できた公式資料に基づきます。
Q．2026年からすべてのSSL証明書が200日になりますか？
いいえ。2026年3月15日以降に新規発行される公開TLSサーバー証明書の最大有効期間が200日です。各認証局はそれより短い有効期間を採用できます。また、適用開始日前に発行された有効な証明書がその日付で自動的に失効するという意味ではありません。
Q．2027年から最大100日になるのは確定した制度ですか？
CA/Browser ForumのBaseline Requirementsでは、2027年3月15日以降の公開TLSサーバー証明書について最大100日と定められています。2026年10月時点では将来の施行日です。認証局がこれより早く短い有効期間を提供する場合はあります。
Q．2029年に47日となったら10日ごとに証明書を更新しますか？
いいえ。47日は証明書そのものの最大有効期間、10日はドメイン名・IPアドレスの検証結果を次回発行へ再利用できる最大期間です。新しい発行の際の認証要件と、すでに発行した証明書の有効期間は別に考えます。
Q．Let’s Encryptは2027年に最大100日の証明書を発行しますか？
Let’s Encryptは、2027年2月10日から通常の証明書を標準64日に変更する予定を公表しています。2027年3月15日に始まる最大100日は業界共通の上限です。64日で発行することは最大100日の上限に収まります。
Q．無料SSL証明書だけが短縮されるのですか？
いいえ。CA/Browser Forumの基準は、対象となる公開TLSサーバー証明書に適用されるもので、無料・有料という料金区分だけで決まりません。認証局と証明書の種類、実際の発行条件を確認してください。
Q．短期化でWebサイトのSSL暗号化が弱くなるのですか？
証明書の有効期間とTLS通信に利用する暗号化方式は別の要素です。有効期間が短くなったことだけで暗号化が弱くなるという意味ではありません。サーバーのTLS設定、証明書の信頼性、秘密鍵の管理などは従来どおり重要です。
Q．手動更新のままでも2029年まで利用できますか？
制度上「すべてのサイトでCertbotを利用しなければならない」という決まりはありません。ただし証明書の有効期間が短くなれば更新の機会が増え、管理工数や更新漏れのリスクが高くなるため、自動化や管理サービスの利用を検討する必要があります。
Q．今ある証明書の期限を確かめる方法は？
ブラウザの証明書ビューアーやOpenSSLなどで、現在の証明書の有効期間を確認できます。具体的な操作手順は証明書の有効期限確認の記事をご参照ください。本記事は制度と運用への影響を解説しています。
まとめ：2029年の47日化に備えて更新と検証を一体で管理する
公開TLSサーバー証明書の有効期間は、CA/Browser Forumの要件により、2026年3月15日から最大200日、2027年3月15日から最大100日、2029年3月15日から最大47日へ短縮されます。さらに2029年には、ドメイン名・IPアドレスの検証結果を再利用できる期間も最大10日となります。証明書の有効期間とドメイン認証の再利用期間を混同しないことが重要です。
短期化で増えるのは証明書の交換機会だけではなく、ドメイン認証、更新結果の確認、公開サーバーへの反映の確認などの管理作業です。レンタルサーバー利用者は事業者の自動SSL対応を確認し、自社管理サーバーではACMEの定期実行と反映を検証するなど、現在の管理方式に応じて準備を進めましょう。
エンリンクは、公開機能一覧でSSL証明書の有効期限と残り日数、期限接近の管理画面内通知を案内しています。複数サイトを管理する方は料金プランを確認のうえ、無料登録から確認を始められます。ただし証明書の発行・更新を代行する機能ではありません。
参考資料・確認日
本記事の制度変更・数値・日程は、次の公式資料を確認しています（確認日：2026年10月26日）。未来の日程は各発行元の追加発表で変更される場合があります。CA/Browser Forumの最大有効期間と、認証局の商品ごとの発行期間を区別して記載しています。
- CA/Browser Forum：TLS Baseline Requirements — §6.3.2の最大有効期間、§4.2.1の認証データ再利用期間。
- CA/Browser Forum：Ballot SC081v3 — 段階的な短縮の背景と採択内容。
- Let’s Encrypt（2026年10月7日）：64-Day Certificate Lifetimes Coming Feb 2027 — 2027年2月の標準64日化、ARI対応。
- Let’s Encrypt（2025年12月2日）：Decreasing Certificate Lifetimes to 45 Days — 2027年64日・2028年45日の日程。
- DigiCert：Moving to 199-day validity for public TLS certificates — 実際の商品上限が業界要件より短い例。
- DigiCert：Domain validation reuse changes in 2026 — DCV再利用期間の個別の運用変更例。
