SSL証明書の有効期限｜上限はすでに200日、2029年に47日へ

2026年9月11日 17:24

ブラウザのアドレス欄に出る、あの鍵のマーク。
あれが出ていれば安全、という程度の理解で日々を過ごしている方が多いと思います。

あのマークの裏側には、有効期限のある証明書が1枚あります。
期限が切れると、サイトは警告画面に変わり、利用者は先に進めなくなります。

自社のサイトの証明書が、いつ切れるのか。
誰が更新しているのか。
すぐに答えられるでしょうか。

この記事で扱うのは、その期限そのものが短くなっている、という話です。
少し前まで1年ちょっとだった上限は、2026年3月15日からすでに200日になっています。
そして2029年には47日まで下がることが、すでに決まっています。

年に1回の更新では、もう足りません。

この記事は、CA/Browser Forum の Baseline Requirements、総務省の用語集と電気通信事故検証会議の議事要旨、IPAと情報通信研究機構の「TLS暗号設定ガイドライン」、Let's Encrypt と IETF の公開資料をもとに、2026年9月11日時点の内容にしています。

鍵マークの裏には、期限のある証明書が1枚ある

まず、言葉を揃えます

この記事では「サーバ証明書」と書きます。
世間では「SSL証明書」と呼ばれることのほうが多いのですが、公的な文書では「サーバ証明書」、業界の基準文書では「TLSサーバ証明書」と書かれます。
どれも同じものを指しています。

総務省の「国民のためのサイバーセキュリティサイト」は、これをこう説明しています。

SSL(TLS)を用いて、利用者がアクセスしているサーバが「本物」であることを保証する電子的な証明書のこと。

同じ用語集は、この証明書が認証局と呼ばれる第三者機関によって発行されること、そのサーバと暗号化通信を行うためにも使われることを書いています。

つまり役割は2つあります。
相手が本物であることを示すことと、通信の中身を隠すことです。
鍵マークは、その2つが成立しているという表示です。

証明書には、必ず終わりの日がある

証明書には、いつからいつまで有効かが書き込まれています。
業界の基準文書は、その期間をこう定義しています。

Validity Period: From RFC 5280: "The period of time from notBefore through notAfter, inclusive."

notBefore から notAfter までの期間、その両端を含む。

運転免許証と同じで、発行された日と、切れる日が最初から決まっています。
そして切れた瞬間、ブラウザは、この接続は安全ではないという趣旨の警告画面を出します。

利用者から見れば、サイトが壊れたのと同じです。
問い合わせフォームも、注文画面も、そこで止まります。

上限は、すでに200日になっている

決めているのは、政府ではない

この上限を決めているのは、CA/Browser Forum という団体です。
認証局と、ブラウザを作っている会社が集まって、公開の認証局が発行するTLSサーバ証明書の基準を決めています。

その基準文書が Baseline Requirements です。
2026年9月11日時点の現行版は Version 2.3.0 で、2026年9月7日付です。

法律ではありません。
ただ、守らないとブラウザ側が証明書を信用しなくなるため、実務上は守らざるを得ません。
制度ではなく、ブラウザ側の判断が効いている領域だということです。

4つの段階が、条文に書かれている

Baseline Requirements の 6.3.2 に、次の4段階が定められています。

Subscriber Certificates issued before 2026-03-15 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.

Subscriber Certificates issued on or after 2026-03-15 and before 2027-03-15 SHOULD NOT have a Validity Period greater than 199 days and MUST NOT have a Validity Period greater than 200 days.

Subscriber Certificates issued on or after 2027-03-15 and before 2029-03-15 SHOULD NOT have a Validity Period greater than 99 days and MUST NOT have a Validity Period greater than 100 days.

Subscriber Certificates issued on or after 2029-03-15 SHOULD NOT have a Validity Period greater than 46 days and MUST NOT have a Validity Period greater than 47 days.

日付でまとめると、こうなります。

2026年3月15日より前に発行：上限398日
2026年3月15日以降：上限200日
2027年3月15日以降：上限100日
2029年3月15日以降：上限47日

同じ節には、この4段階を1枚にした早見表も付いています。
今日は2026年9月ですから、200日の段階はすでに始まっています。

切り替わるのは「発行日」である

読み違えやすい点を1つ補足します。

条文は「issued on or after」、つまり発行された日を基準に書かれています。
すでに手元にある証明書が、ある日を境に短くなるわけではありません。

2026年3月14日に398日で発行された証明書は、そのまま最後まで有効です。
短くなるのは、次に発行するときからです。

だから「まだ切れていないから関係ない」ではありません。
次の更新のときに何日の証明書が返ってくるかを確認する、という順序になります。

15年で、5回短くなっている

今回が初めての短縮ではありません。
IPAと情報通信研究機構の「TLS暗号設定ガイドライン」は、ここまでの経緯を1つの注にまとめています。

2011 年 11 月以降に発行するサーバ証明書の有効期限は 60 ヶ月以内とされていたが、その後、2015 年 4 月以降の発行では 39 ヶ月以内、2018 年 3 月以降の発行では 825 日（約 27 ヶ月）以内、2020 年 9 月以降の発行では 398 日（約 13 ヶ月）以内と、徐々に有効期限が短くなってきている。

ここに今回の3段階が続きます。
5年、3年3か月、2年3か月、1年1か月、そして200日、100日、47日。

15年で5回、同じ方向に動いています。
一度きりの変更ではなく、そういう流れの中にある、と受け取ったほうが正確です。

なぜ短くするのか

認証局の側の説明

理由については、認証局の側の説明を借ります。
無償の認証局である Let's Encrypt は、短い有効期間の利点を2つ挙げています。

1つは、誤発行や鍵の漏えいが起きたときの被害が、短い期間で終わること。
もう1つが、自動化を促すことです。

Once certificate management is automated, shorter lifetimes aren't any less convenient than longer ones.

証明書の管理がいったん自動化されれば、期間が短いことは、長い場合と比べて何ら不便ではない。

裏を返せば、自動化していない組織にとっては、短縮はそのまま作業回数の増加になります。
同じページは、自社の証明書の上限を2028年2月までに45日へ下げるとも書いています。
認証局の側は、すでにその前提で動いています。

議案そのものが、前提を書いている

この短縮を決めたのは、2025年4月11日に可決された議案です。
正式な名称は「Introduce Schedule of Reducing Validity and Data Reuse Periods」といいます。

その議案の説明文に、実務で効いてくる一文があります。

The TBRs maintain a requirement for CAs to revoke certificates they have issued within 24 hours under certain circumstances. It can reasonably be inferred from this that certificates issued in compliance with the TBRs are understood to be managed in such as a way as to allow for certificate replacement within any given 24 hour period.

基準文書には、一定の状況下で認証局が24時間以内に証明書を失効させる要件が以前からある。ここから合理的に推し量れるのは、この基準に沿って発行された証明書は、24時間以内に差し替えられる形で管理されていると理解されている、ということである。

続けて、実際の運用がその想定を満たしてきたとは限らない、とも書かれています。
言い換えると、短縮は新しい要求ではなく、もともとあった前提を可視化したものだ、という立て付けです。

賛否は、どうだったのか

この議案の投票結果も公開されています。

認証局の側は30票で、25が賛成、反対は0、棄権が5。
ブラウザの側は4票で、Apple・Google・Microsoft・Mozilla の4社すべてが賛成しています。

棄権した5社には、日本レジストリサービスとセコムトラストシステムズが含まれています。
反対ではなく棄権ですが、この短縮が全会一致ではなかったことは、記録として残っています。

2018年の通信障害が示したこと

何が起きたか

証明書の期限切れがどれくらいの事故になるのか、公表資料が残っている例を1つ挙げます。

2018年12月6日、全国で携帯電話がつながらなくなりました。
ソフトバンクは同日のおわびで、こう説明しています。

2018年12月6日（木）午後1時39分ごろ、全国のお客さまをカバーする、東京センターおよび大阪センターに配置してある、エリクソン社製パケット交換機全台数で、同社ソフトウエアに異常が発生しました。

同じおわびには、こうも書かれています。

なお、同ソフトウエアは9カ月前から運用しており、同ソフトウエアによる異常は、エリクソン社製の通信設備を使用する海外（11カ国）の通信事業者においても、ほぼ同じ時刻に同様に発生していると、エリクソン社から報告を受けています。

総務省の電気通信事故検証会議に出された資料には、規模が数字で残っています。
継続時間は4時間25分、影響利用者数は約3,060万回線、問い合わせ件数は約21,146件。

原因の中身は、同じ会議の議事要旨に出てきます。

証明書の有効期限の日時の意味は何かとの質問があり、証明書内部で一律に期限設定がされていたため、全世界一斉に同じ時刻で事象が発生し、日本時間で言うと１３時３０分であったと回答があった。

機器の中の証明書が、世界中で同時刻に期限を迎えたということです。

ただし、これは公開の認証局の証明書ではない

ここで注意が要ります。
この証明書は、Webサイトの鍵マークのものとは別物です。

同じ議事要旨に、こう書かれています。

今回のケースでは第三者機関としての認証局が発行している証明書ではないため、そもそも有効期限を短くする必要はなく、長目の有効期限で証明書を発行しておけば問題はなかった

機器のソフトウェアに組み込まれた証明書であって、ここまで見てきた200日や47日の話とは、別のルールで動いています。
この断りを外すと、事実として間違いになります。

それでも、この事故を引く理由があります。

本当の問題は、そこに証明書があると知らなかったこと

同じ議事要旨には、次の一文があります。

証明書が埋め込みになっている状態を、事前には把握していなかったが、今後は同様のことがないようベンダーに対応を申し入れていて、１月末には全ての証明書が閲覧できるようになるということでよいか

把握していなかった。
これが、期限切れ事故の本体だと思います。
期限を忘れたのではなく、期限のあるものがそこにあることを知らなかった、という形です。

そして、この会議の構成員の発言には、もう1つ残しておきたい一文があります。

証明書は有効期限をつけるものだが、何日までに設定するのが正しいかは特にない。必要なのは、期限に応じて証明書の更新を管理することである。

2019年1月の発言です。
この記事の結論は、7年以上前にすでに書かれていた、ということになります。

再発防止策の1つ目が、総点検だった

この事故の再発防止策として最初に挙げられているのは、新しい技術の導入ではありません。

機器ベンダーにて有効期限の確認ができない証明書の有無、ならびに商用設備における証明書の有効期限の総点検実施

数えることです。
そして「有効期限の確認ができない証明書の有無」という書き方に、この問題の性質が出ています。
期限が見えない証明書がある、という状態そのものが、点検の対象になっています。

まず数える、それから自動化する

証明書は、Webサーバーだけにない

最初にやることは、更新の自動化ではありません。
自社に証明書が何枚あるのかを数えることです。

そして証明書は、公開しているWebサイトだけにあるのではありません。

公開しているWebサイトのサーバー
その前に置いているロードバランサやCDN
社内から使う業務システムの画面
メールサーバー
VPN装置やファイアウォールの管理画面
複合機やネットワーク機器の設定画面

このうち、期限が切れて外から見えるのは1つ目だけです。
残りは、切れても社内の誰かが困るだけなので、放置されがちです。
そして放置されたまま、ある日つながらなくなります。

台帳に何を書いておくか

数えたら、書き出します。
特別な道具は要りません。
表計算ソフトの1枚で足ります。

書いておくとよいのは、次の項目です。

どの機器・どのサービスに入っているか
対象のドメイン名
どこの認証局が発行したものか
有効期限
更新の方法（自動か手動か）
更新するのは誰か（自社か、委託先か）
失敗したとき、誰に連絡が来るか

最後の2つが、いちばん抜けます。
「たぶん制作会社がやってくれている」で止まっている項目が1つでもあれば、そこが次に切れる場所です。

国内のガイドラインも、同じことを求めています。
IPAと情報通信研究機構の「TLS暗号設定ガイドライン」は、7.2.3で次のように書いています。

サーバ管理者は、サーバ証明書の更新漏れによって自社のサービスに障害を発生させることがないように、サーバ証明書の有効期間を管理し、更新作業のために必要なリードタイムを考慮した上で、適切な管理方法（例えば、更新作業開始時期の明文化など）を定めることが求められる。

注意力ではなく、明文化された管理方法を求めている点が要点です。

手作業が増えると、何が起きるか

同じ節は、短い有効期間と手作業の組み合わせについても書いています。

更新作業を人力に頼っている場合においては、単純なミスによる更新忘れ、組織改編・担当者異動時の引き継ぎ不備による更新漏れ等のリスクが大きく上昇することとなる。そのため、短い有効期間のサーバ証明書を利用する場合においては自動的に証明書を更新できる体制の整備を行った上で実施することが現実的となる。

47日になれば、いま年1回で回している手作業は、年8回近くになります。
このガイドラインの言い方を借りれば、それは「現実的」ではない側に入ります。

自動化には、標準がある

台帳ができたら、自動化できるものを自動化します。
証明書の発行と更新を自動化するための仕組みは、標準として決まっています。

ACME といい、IETF の RFC 8555 として2019年3月に標準化されています。
その要旨には、こう書かれています。

This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance.

認証局と申請者が、確認と証明書発行の過程を自動化するために使えるプロトコルを、この文書は記述する。

つまり、ドメインの所有確認から証明書の受け取りまでを、人手を介さずに回す仕組みです。
「TLS暗号設定ガイドライン」にも、これを扱ったコラムが置かれています。
国内の公的なガイドラインでも、自動化は前提として扱われているということです。

同じコラムは、留意点も3つ挙げています。

実装に瑕疵や脆弱性があれば、証明書の発行・更新が適切に処理されずに停止する可能性がある
暗号スイートの設定変更などは対象外であり、サーバ管理者が別途対応する必要がある
仕様変更やアップデートが発生した場合に、適宜対処が必要となることもある

入れたら終わり、ではありません。

更新は、期限の3分の2の時点でかける

自動化する場合でも、期限ぎりぎりに更新をかけるのは危険です。
Let's Encrypt は、自社の証明書について次のように案内しています。

Our default certificates are valid for 90 days.

We recommend renewing 90 day certificates every 60 days and six day certificates every three days.

既定の証明書は90日有効で、90日の証明書は60日ごとに更新することを推奨する。

期限の3分の2の時点で更新をかけておけば、1回失敗しても、気づいて直すための時間が30日残ります。
この考え方は、有効期間が何日であっても同じです。
残り3分の1を、事故に備えた余白として空けておく、ということです。

担当者が休んでも切れない体制にする

期限切れの通知メールは、もう来ないかもしれない

前提が1つ変わっています。
Let's Encrypt は、期限切れが近いことを知らせるメールの配信を終了しました。

We will be ending this service on June 4, 2025.

2025年6月4日でこのサービスを終了する。

理由も公表されています。

Providing expiration notification emails means that we have to retain millions of email addresses connected to issuance records. As an organization that values privacy, removing this requirement is important to us.

期限切れ通知メールを提供するということは、発行記録に紐づく何百万件ものメールアドレスを保持し続けることを意味する。プライバシーを重視する組織として、この必要をなくすことは重要である。

自動更新が普及したこと、費用がかかること、仕組みが複雑になることも理由として挙げられています。
通知を受け取り続けたい利用者には、第三者の監視サービスを使うよう案内しています。

ここで、先ほどの国内ガイドラインとの食い違いに触れておきます。
「TLS暗号設定ガイドライン」第3.1.1版は、通常は有効期限の3か月ほど前から発行会社のリマインドメールが届くとしたうえで、特段の制約がなければ1年程度の有効期間の証明書を選び、更新を年次の定型業務にすることが望ましい、と書いています。

このガイドラインは2025年4月公開で、2026年3月15日の切り替えより前のものです。
公開のサーバ証明書で1年程度のものを選ぶことは、いまはできません。
記述が古くなっている箇所がある、という前提で読む必要があります。

「更新できた」を確認する口は、用意されている

自動更新の道具には、成否を外に知らせるための仕組みが最初から入っています。
広く使われている ACME クライアントである Certbot の公式ドキュメントには、次のように書かれています。

certbot renew exit status will only be 1 if a renewal attempt failed. This means certbot renew exit status will be 0 if no certificate needs to be updated.

更新の試行が失敗したときだけ、終了ステータスが1になる。更新すべき証明書がなければ0になる、ということでもある。

ここは読み違えやすい点です。
0は「成功した」ではなく、「失敗しなかった」です。
更新が実際に行われたかどうかは、この値からは分かりません。

そのために、別の口が用意されています。

Starting with Certbot 2.7.0, certbot provides the environment variables RENEWED_DOMAINS and FAILED_DOMAINS to all post renewal hooks.

更新されたドメインと、失敗したドメインが、それぞれ渡されます。
成功したときだけ動かしたい処理には、さらに別の指定があります。

If you want your hook to run only after a successful renewal, use --deploy-hook

道具の側は、通知の口を用意しています。
使っていない組織が多い、というだけの話です。
ここを社内のチャットや監視システムにつなぐだけで、気づかないまま切れる、の大半は防げます。

先ほどのガイドラインのコラムも、同じことを一行で書いています。

ACME の導入はサーバ証明書の更新忘れの防止といった面での効果もあるが、計画通りに更新が行われていることはログなどにより確認するべきである。

外から見る目を、1つ持つ

自動更新の成否だけを見ていると、抜ける事故があります。

証明書は新しくなったが、サーバーへの反映が終わっていない。
複数台あるうちの1台だけ古いままだった。
ロードバランサ側の証明書を更新し忘れた。

どれも、更新処理そのものは成功しています。
これを見つけるには、外から実際に接続して、いまどの証明書が出ているかを確かめるしかありません。

自社のドメインに対して、期限を定期的に確認する仕組みを1つ持っておく。
市販の監視サービスでも、社内の簡単なスクリプトでもかまいません。
大事なのは、更新する側とは別の目で見ることです。

委託先に、確認しておくこと

自社で管理していない証明書がある場合は、次を文書で確認しておくと後が楽です。

どの証明書を、誰が更新するのか
更新は自動か、手作業か
失敗したとき、誰に、どの手段で連絡が来るのか
その連絡先は、いま在籍している人か
契約が終了したあと、その証明書はどうなるのか

最後の項目は見落とされがちです。
保守契約が切れた翌年に証明書が切れる、という順番は珍しくありません。

2026年9月時点の最新状況

いくつか補足します。

Baseline Requirements は、2026年9月11日時点で Version 2.3.0、2026年9月7日付です。
下書きの時点では Version 2.2.9 でしたが、1か月のうちに版が上がっています。
6.3.2 の4段階そのものは変わっていません。

短くなっているのは、有効期間だけではありません。
ドメイン名やIPアドレスの確認結果を再利用できる期間も、2026年3月15日以降は200日、2027年3月15日以降は100日に下がります。
組織情報の確認結果の再利用は398日です。
証明書を出すたびに確認をやり直す頻度も、あわせて上がるということです。

同じ基準文書には、2026年9月15日から、証明書とCRLでのSHA-1の使用を完全に終わらせる項目も入っています。
この記事の公開時点で、4日後です。

国内のガイドラインの側は、「TLS暗号設定ガイドライン」が第3.1.1版、2025年4月25日公開のままです。
本文にも書きましたが、有効期間について1年程度を勧めている箇所は、2026年3月15日の切り替えより前の記述です。
更新されるまでは、この点だけ読み替える必要があります。

まとめ

サーバ証明書は、そのサーバが本物であることを保証する電子的な証明書で、認証局が発行する。SSL証明書とも呼ばれるが同じもの
有効期間は notBefore から notAfter までで、切れるとブラウザは警告画面を出す
上限を決めているのは CA/Browser Forum の Baseline Requirements。法律ではないが、守らないとブラウザが信用しない
上限は、2026年3月15日以降の発行分で200日、2027年3月15日以降で100日、2029年3月15日以降で47日
切り替わるのは発行日を基準としてであり、手元の証明書が途中で短くなるわけではない
短縮は今回が初めてではない。2011年の60か月から数えて、これで5回目の方向転換になる
短縮を決めた議案は、基準に沿った証明書は24時間以内に差し替えられる形で管理されているはずだ、という前提を書いている
2018年の通信障害で本当に問題だったのは、期限を忘れたことではなく、期限のあるものがそこにあると知らなかったこと。再発防止策の1つ目は総点検だった
最初にやることは自動化ではなく、証明書が何枚あるのかを数えること。Webサーバー以外にもある
自動化には ACME という標準がある。ただし入れたら終わりではなく、計画通りに動いているかをログで確認する必要がある
更新は期限ぎりぎりではなく、3分の2の時点でかけておく
認証局からの期限切れ通知メールは、Let's Encrypt では2025年6月4日に終了した。教えてもらえる前提は置けない
自動更新の道具には成否を知らせる口が最初から用意されている。あとは、それをどこにつなぐか
国内のガイドラインは2025年4月公開で、1年程度の証明書を勧める記述が残っている。この点は読み替える

最後に1つだけ付け加えます。

この問題は、忘れないように気をつける、では解決しません。
期限が短くなる方向に業界全体が動いているので、人の記憶で持たせる前提そのものが成り立たなくなります。

2019年の会議で出た「必要なのは、期限に応じて証明書の更新を管理することである」という一文は、当時よりいまのほうが重く効きます。

皆さんの会社では、証明書の更新が失敗したとき、その知らせはどこに届くようになっているでしょうか。

参考・引用元

CA/Browser Forum

CA/Browser Forum「Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates」Version 2.3.0（2026年9月7日付、6.3.2） https://cabforum.org/working-groups/server/baseline-requirements/requirements/
CA/Browser Forum「Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods」（2025年4月11日） https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

総務省・ソフトバンク

総務省「用語集(さ行)｜国民のためのサイバーセキュリティサイト」 https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/glossary/ja_03/
総務省「電気通信事故検証会議（第６回）議事要旨」（平成31年1月17日開催） https://www.soumu.go.jp/main_content/000605829.pdf
ソフトバンク「2018年12月6日に発生した携帯電話サービスの通信障害に関するおわび」（2018年12月6日） https://www.softbank.jp/corp/news/press/sbkk/2018/20181206_02/

IPA・情報通信研究機構

IPA・国立研究開発法人情報通信研究機構「TLS暗号設定ガイドライン」第3.1.1版（2025年4月25日公開、全111ページ、7.2.3およびコラム②） https://www.ipa.go.jp/security/crypto/guideline/gmcbt80000005ufv-att/ipa-cryptrec-gl-3001-3.1.1.pdf

IETF・Let's Encrypt・Certbot

IETF「RFC 8555 Automatic Certificate Management Environment (ACME)」（2019年3月、Standards Track） https://www.rfc-editor.org/rfc/rfc8555
Let's Encrypt「Certificate Lifetime Rationale and Plans」（2026年7月22日更新） https://letsencrypt.org/docs/cert-lifetimes/
Let's Encrypt「Frequently Asked Questions」（2025年4月28日更新） https://letsencrypt.org/docs/faq/
Let's Encrypt「Ending Support for Expiration Notification Emails」（2025年1月22日） https://letsencrypt.org/2025/01/22/ending-expiration-emails
Certbot「User Guide」（EFF、Certbot 5.8.0 のドキュメント） https://eff-certbot.readthedocs.io/en/stable/using.html

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。
規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40