SSL証明書の有効期限はいつまで？47日ルールで何が変わるかと更新対策

2026年2月10日セキュリティ

結論：SSL証明書の有効期限は短くなる│2029年3月以降は最大47日

結論から言うと、SSL/TLS証明書は業界ルールの変更で有効期限が段階的に短くなり、2029年3月15日以降は最大47日になります。

今までは「だいたい年1回更新すればOK」という感覚で運用できましたが、これからは更新頻度が上がる前提で、「更新漏れを起こさない仕組み」が重要になります。

SSL有効期限の短縮スケジュール（最大有効期間）

まず押さえるべきは、いつから何日になるかです。スケジュールは以下のとおりです。

適用開始日	最大有効期間
～2026年3月14日	397日（※約13か月）
2026年3月15日～	200日
2027年3月15日～	100日
2029年3月15日～	47日

※「今発行済みの証明書が突然47日に短くなる」という話ではなく、上記の日以降に「発行される証明書」が短い期間になる、ということを理解しておきましょう。

DCV再利用期間も短くなる（2029年以降は10日）

さらに、証明書発行時に必要になるドメイン認証（DCV）情報を「使い回せる期間」も同じ流れで短くなります。段階的に短くなり、最終的に2029年3月15日以降は最大10日になります。

つまり、ドメイン認証を一度実施しても、10日以内に証明書を発行・設置まで完了させないと、再度認証からやり直しになります。手作業での「更新月になったら対応」では間に合わなくなり、更新が常時運用へと変わることを意味します。

有効期限短縮で一番怖いのは、費用よりも「更新漏れによるサイト影響」です。そこで押さえたいのが、更新の手間をどこまで仕組みで減らせるかです。

例えば、有効期間短縮（2026年3月15日〜）に伴い、バリュードメインでは1年契約の場合、有効期間199日の証明書を2枚提供する形式を採用しています。

1枚目の発行時に年間料金をお支払いいただき、2枚目は追加料金なしで自動更新されます。

つまり、契約・支払いは年1回のままで、証明書の更新作業は自動で完了します。さらに、業界最安級の価格設定で、コストを抑えながら短縮化に対応できます。お客様側での対応は原則不要で、更新漏れのリスクをサービス側で吸収する仕組みです。
※自動更新にはバリュードメインのドメイン・サーバーをご利用いただく必要があります。

2029年に最大47日になる最終段階でも、自動更新の仕組みがあれば「月1回以上の更新作業」に追われることはありません。増えていく更新作業を人手に頼らず回せることが、短縮時代のSSL運用では決定的に重要になります。

バリュードメインのSSL証明書を見る

SSL証明書の「有効期限」と「更新期限」— まずここだけ押さえる

SSL証明書まわりで混乱しやすいのが、「有効期限」と「更新期限（更新のタイミング）」が別物だという点です。短縮化が進むほど更新回数が増えるため、まずはこの2つを正しく理解しておくと、更新漏れを防ぎやすくなります。

有効期限（Not After）とは？期限切れで起きること

有効期限（Not After）は、SSL証明書そのものの「使用期限」です。ここを過ぎると、ブラウザは「安全ではない可能性がある」と判断し、警告画面を表示したり、アクセスをブロックする場合があります。

実務的に厄介なのは、期限切れが単なるセキュリティ問題ではなく、次のような事業影響につながることです。

つまり、有効期限は「いつまで安全か」というより、いつまで「普通にアクセスしてもらえるか」に直結する期限だと捉えるのが分かりやすいです。

更新期限と猶予の考え方│いつ更新すべきか？

一方の更新期限は、「有効期限の前に、いつ更新手続きを完了させるべきか」という運用上の期限です。ここで重要なのは、有効期限ギリギリに作業しないことです。

実際には、ドメイン認証（DCV）の実施、証明書の発行・再発行、サーバーへの設置、動作確認といった一連の作業が必要です。

短縮化が進むほど更新頻度が上がるため、手動運用では「担当者の不在」「見落とし」「手順の属人化」といった問題が起きやすくなります。
だからこそ、更新を「年1回のイベント」から「回り続ける仕組み」へ転換することが大切です。

具体的には、更新・再発行を自動化する運用を提供しているサービスを選ぶことで、少なくとも「更新作業そのもの」を起点にした事故を減らせます。

DV/OV/EVで更新手順がどう違うか

SSL証明書には大きく DV／OV／EV の種類があります。違いは「暗号化の強さ」ではなく、誰が使っているサイトか（組織の実在性）をどこまで確認するかです。運用目線では、ここが更新の手間とリードタイムに直結します。

「どれが正解か」はサイトの目的次第ですが、更新頻度が増える将来を考えると、自社に必要な認証レベルと回せる運用が釣り合っているかで選ぶと失敗を防げます。

SSL証明書の有効期限の3つの確認方法

SSL証明書の有効期限は「知らないうちに切れていた」が一番危険です。

まずは今どこで確認できるかを押さえて、できれば人が見なくても気づける仕組みまで用意しておくと安心です。ここでは、初心者でも迷いにくい3つのパターンで紹介します。

ブラウザで確認（鍵マーク→証明書→有効期限）

いちばん手軽なのがブラウザ確認です。管理画面が分からなくても、サイトにアクセスできればその場で期限を確認できます。

※スマホの注意点：スマホブラウザは証明書詳細が見づらい/表示導線が違うことがあります。
「表示が見つからない」ときは、パソコンでの確認か、次に紹介する「監視/コマンド」方式が確実です。

サーバー・監視で確認（監視ツール・アラート設計）

短縮化で更新回数が増えるほど、人力チェックは限界が来ます。そこでおすすめなのが「期限が近づいたら通知する」監視です。ここまでやると、更新漏れの事故率が大きく下がります。

監視で最低限やることは、以下の3つです。

• 通知タイミングを決める
  例：30日前／14日前／7日前
• 通知先を複数にする
  担当者＋責任者（不在・見落とし対策）
• 対象を漏れなく登録
  本番だけでなく、API・管理画面・サブドメインも

この方法は、運用対象のサイトが複数ある場合（制作会社で複数顧客を管理している、部署ごとにサイトを持っている、複数サービスを運用しているなど）に特に向いています。

また、決済・ログイン・問い合わせフォームのように「止められない」ページがあり、期限切れによる影響を絶対に避けたいケースでも有効です。担当者の交代が起きやすく、属人化による見落としリスクがある環境では、仕組みでカバーできるため安心です。

監視で気づける状態を作ったうえで、更新作業自体も自動化されていると運用はさらに安定します。

証明書管理画面（CA/管理ツール）で棚卸し

最後は、最も運用向けの方法です。証明書は更新漏れだけでなく、次のような問題も起きがちです。

• どの証明書がどのサーバーに入っているか不明
• サブドメインや旧環境に証明書が残っている
• 更新担当が変わって履歴が追えない

こうなる前に、CAや管理ツールの画面で証明書を棚卸しし、台帳化（一覧化）しておくのが有効です。

この方法は、証明書の本数が増えて「どれがどこで使われているか」を把握しづらくなってきた場合に特に向いています。

また、社内の複数担当者や制作会社など、複数人・複数会社が関わる運用では、証明書の所在や責任範囲が曖昧になりやすいため、棚卸しと台帳化の効果が大きくなります。さらに、更新作業をできる人が限られていて属人化している状態を脱却し、誰が見ても運用できる形に整えたい場合にも有効です。

なぜ短縮される？47日ルールの背景

「なぜわざわざ有効期限を短くするの？」と感じる方も多いはずです。

結論から言うと、今回の短縮は「面倒にするため」ではなく、SSL証明書の信頼性をより高い状態で保つための業界方針です。

この変更の背景には、「手作業による更新」を前提としない運用への移行があります。短縮化が進むほど人手での管理は非現実的になるため、業界全体が自動化・標準化を前提とした運用設計へ舵を切っているのです。

CA/B Forumで可決、Apple提案が採択

この変更は、ブラウザベンダーと認証局（CA）などで構成される業界団体（CA/B Forum）の流れの中で決まり、2026年・2027年・2029年の3段階で移行します。

また、前述のとおりDCV再利用期間も最大10日まで短くなるため、手動での再認証は失敗やサービス中断につながりやすくなります。

つまり「運用の難易度が上がる」ことを前提に設計する必要があります。

情報の鮮度（証明書情報の信頼性）を上げる狙い

SSL証明書は「このドメインに接続して大丈夫か」を判断するための、いわば「身分証明」です。有効期限が長いほど、もし途中で状況が変わっても（組織変更、鍵の管理状況の変化など）情報が古い状態のまま残りやすくなります

そこで、有効期限を短くして証明書を置き換えるサイクルを早め、情報を新しい状態に保ちやすくするのが狙いです。

つまり短縮の本質は、更新回数が増えること以上に、運用の作り方を変えることにあります。

失効確認（CRL/OCSP）への依存を減らす考え方

SSL証明書には「もし問題が起きたら失効させる」仕組みがあり、代表的なものにCRLやOCSPがあります。

ただ、現場目線では「失効確認だけに頼って安全を担保する」のは運用が難しい面もあります。
そこで、SSL証明書をより短い周期で更新し、古い状態の証明書が長く残り続けるリスクを減らす方向に寄せる考え方が強まっています。

前述のとおり、更新頻度が増えるほど手動運用は破綻しやすいため、「自動化」「監視」「台帳化」の優先度が一気に上がります。

SSL有効期限短縮の影響は？運用現場で起きる困りごと

有効期限の短縮は、「証明書の更新回数が増える」だけの話ではありません。

実務では、更新に付随する作業（認証・反映・確認）が増えるため、人手で回すほど事故が起きやすくなります。

特に2029年以降は最大47日、DCV再利用期間も最長10日になるため、更新の失敗がサービス影響につながりやすい運用になります。

ここでは、現場で起きがちな困りごとを3つに絞って整理します。

更新頻度が増える（397日→1〜2か月ペースへ）

今までの感覚だと、証明書更新は「年に1回の作業」でした。しかし最大47日になると、更新はざっくり言えば1〜2か月ごとに発生します。

更新のたびに発生しやすい作業は、次のようなものです。

この一連の作業が1〜2か月ごとに回ってくると、「前回どうやったっけ？」が増え、手順が曖昧なまま更新して設定ミスや確認漏れが起きやすくなります。

年1回なら「イベント」として気合いで乗り切れますが、1〜2ヶ月に1回のペースでは人手での運用は確実に破綻します。

DCV（ドメイン認証）の再実施が増える＝手作業は破綻しやすい

証明書更新は、単に期限を延ばすだけではなく、多くの場合ドメイン認証（DCV）を伴います。

短縮の最終段階では、DCVの再利用期間が最長10日になるため、作業が遅れたり失敗したりすると、一気にリカバリーが難しくなります。

前述のとおり、更新頻度が上がるほど手動運用は破綻しやすくなります。DCV再利用期間の短縮により「一回のミスの影響」も大きくなるため、自動化・監視・台帳化で事故を防ぐ運用が必須です。

SSL証明書本数が多いほど事故が起きやすい

SSL証明書が1枚なら、多少手作業でも何とか回ります。しかし、次のような環境になると事故率が上がります。

本数が増えるほど「どこに設置されているか」「誰が更新できるか」が曖昧になりやすく、更新漏れや設定ミスが起きやすくなります。

有効期限短縮の影響は、更新回数の増加によって「手順の属人化」「認証の詰まり」「反映ミス」が起きやすくなることです。 特にDCV再利用期間が短くなる最終段階では、手動運用のリスクがさらに高まります。

そのため、自動化・監視・台帳化を前提に運用を組み直すことが、現場での事故を減らす近道になります。

短縮化対策の最優先は自動更新

有効期限短縮が進むと、SSL運用は「年に1回の更新作業」では回りません。

ポイントは、更新を人の作業として頑張るのではなく、仕組みで事故を起こしにくくすることです。

特に2029年3月15日以降は最大47日、DCV再利用も最長10日になるため、手動運用は失敗がサービス中断につながりやすくなります。

結論から言うと、短縮化時代のSSL運用で最優先なのは自動更新です。

2029年以降は最大47日になり、更新は年1回のイベントではなく、ほぼ常時運用に近い形になります。
「担当者不在」「見落とし」「手順ミス」といった手作業のリスクを排除するには、自動化が不可欠です。

自動更新を実現する技術として知っておきたいのがACMEです。
ACMEは「ドメイン認証（DCV）から証明書の発行・更新までを自動化するための規格」で、Let's Encryptなど多くのサービスで採用されています。

自動更新に対応したサービスを選ぶことで、以下が実現できます。

「更新作業そのものを自動で回せるか」が、運用負担を抑えるうえでの決定的な差になります。

SSL証明書の有効期限に関するよくある質問

SSL証明書の有効期限に関するよくある質問には以下があります。

SSL証明書の有効期限が切れたらどうなる？

有効期限が切れると、ブラウザに警告が表示されたり、アクセス自体がブロックされることがあります。

ユーザーが離脱しやすくなるだけでなく、決済・ログイン・問い合わせフォームなど重要な導線が止まる可能性があり、売上や信用に直結します。

復旧には以下の作業が必要で、通常2〜24時間程度かかります。

特に2029年以降はDCV再利用期間も短縮されるため、手動運用での復旧は一層難しくなります。だからこそ、期限切れは起きてから対応ではなく、更新の自動化や監視で起きない運用に寄せるのが安全です。

更新のたびにCSRは必要？

状況によって異なります。

一般に、証明書の更新（再発行）では「同じ鍵・同じCSRで進められるケース」もありますが、運用やポリシー、設置環境（サーバー移行・鍵更新など）によっては新しいCSRを作ることもあります。

実務で大切なのは、「CSRが必要かどうか」よりも、更新手順が毎回ブレないように手順書化（固定化）して、「発行→設置→確認」までを一連で回せる状態にしておくことです。

ワイルドカード/マルチドメインは影響ある？

基本的に、有効期間短縮の影響は同様に受けます。ワイルドカードやマルチドメインは「まとめられて便利」な一方で、更新や設置で失敗すると影響範囲が大きくなりやすいです。

証明書の本数が多い環境では、更新頻度増に耐えるために、申請・配布・反映・検証まで含めて自動化・標準化していく必要性が示されています。

Let’s Encryptで自動更新できるなら、有料SSLのメリットは何？

暗号化そのものだけなら、無料SSLで十分なケースも多いです。

一方で、有料SSLは認証レベル（DV/OV/EV）の違いがあり、取引・監査・社内規程などで「企業認証（OV）以上」が必要な場合に選ばれます。

加えて、短縮化により更新回数が増えるため、有料・無料を問わず「更新作業を自動化できるか」「運用を安定して回せるか」が重要になります。

「要件に合う認証レベル」と「回せる運用」をセットで選ぶと失敗を防げます。

まとめ：期限短縮は「仕様変更」。自動化と監視ができれば怖くない

SSL証明書の有効期限短縮は、Web運用の前提が変わる仕様変更です。最終的に2029年3月15日以降は最大47日、DCV再利用期間も最大10日へ短縮されます。

更新漏れを防ぐには、次の3つを整えるだけです。

1. 有効期限を可視化：ブラウザ確認または管理画面で台帳化
2. 期限アラートを設定：30日前／14日前／7日前に担当者＋責任者へ通知
3. 更新作業を自動化：申請・配布・反映・検証まで標準化

各方法の詳細は「SSL証明書の有効期限の3つの確認方法」で解説しています。

2026年3月15日から短縮が始まり、準備期間は実質1年程度。特に以下の環境では早めの対策が必須です。

バリュードメインなら、短縮化対応がすでに完了しています。
有効期間短縮（2026年3月15日〜）に合わせ、1年契約で有効期間199日の証明書を年2回自動発行する設計です（2回目は追加料金なし）。

業界最安級の価格でありながら、更新作業はサービス側で自動実行。お客様側での対応は原則不要です。2029年の最大47日へ短縮される最終段階でも、低コスト・低負担で運用を継続できます。
※自動更新にはバリュードメインのドメイン・サーバー利用が必要です。

「更新回数が増える時代」に、更新作業そのものから解放される。それが、短縮化に備えた最も確実な対策です。

短縮化対応済みのSSL証明書を今すぐ確認