SSL/TLS証明書の有効期間が47日に 2029年までの日程と今やる準備

WebサイトのSSL/TLS証明書(通信を暗号にし、サイトの持ち主を示す電子的な証明書)は、使える期間がどんどん短くなっています。2026年3月15日からは最長200日になり、2029年3月15日には47日になります。年に1回、手作業で入れ替えてきた会社ほど、今のうちに仕組みを変える必要があります。

何が決まったのか CA/Browser Forumの決議SC-081v3

証明書のルールは、CA/Browser Forum(認証局とブラウザー会社でつくる業界団体)が決めています。2025年4月11日、有効期間を段階的に短くする決議SC-081v3が可決されました。提案したのはAppleで、GoogleとMozilla、認証局のSectigoが賛同しています。

投票の結果は次のとおりです。ブラウザー側は全社が賛成し、反対は1票もありませんでした。

棄権した5つの中には、日本のJPRS(日本レジストリサービス)とセコムトラストシステムズが入っています。決議の中身は、認証局が守る基本ルール(Baseline Requirements)に書き込まれました。2026年9月7日付の最新版2.3.0にも同じ日程が載っています。

対象になる証明書・ならない証明書

対象は、ブラウザーが標準で信頼する「公開の」サーバー証明書です。確認の厳しさの順にDV(ドメインの管理だけを確認)、OV(会社の実在も確認)、EV(さらに厳しく確認)と種類がありますが、どれも同じ上限です。

一方、社内で立てた認証局(プライベートCA)が出す証明書は、この決まりの対象外です。メールの暗号化に使うS/MIME証明書や、プログラムに署名するコードサイニング証明書も別のルールで動いています。

有効期間と確認の使い回しはこう短くなる

証明書の上限は「発行した日」で決まります。2026年10月3日の時点は、上限200日の段階にいます。

OV・EVで確認する会社名や所在地の情報は、使い回せる期間が2026年3月15日に825日から398日へ短くなりました。こちらはその後の短縮は決まっていません。

なお基本ルールは、上限ちょうどではなく「1日少なく」することを勧めています。たとえば2029年以降は「46日を超えないほうがよい、47日を超えてはならない」と書かれています。

「ドメイン確認の使い回し」とは何か

認証局は証明書を出す前に、申し込んだ人がそのドメインを本当に管理しているかを確かめます。これをドメイン認証(DCV)といいます。方法は、決められたメールへの返信、DNSへの文字列の登録、Webサーバーへのファイルの設置などです。

これまでは一度確かめれば、1年あまりは結果を使い回せました。2029年3月以降は10日しか使えません。47日ごとの更新のたびに、ほぼ毎回この確認をやり直すことになります。

年に何回更新することになるか

期限ぎりぎりではなく、余裕を持って更新するのが普通です。無料の認証局のLet's Encryptは、有効期間の3分の2ほどが過ぎたら更新するよう勧めています。この考え方で回数を数えると、次のようになります。

なぜ短くするのか

決議の説明では、証明書は「発行した時点の事実を写したもの」だとしています。時間がたつほど、ドメインの持ち主が変わるなど、中身が現実とずれやすくなります。

証明書を途中で無効にする仕組み(失効)もありますが、決議は確実に働かない場面があると指摘しています。期間そのものを短くすれば、失効の仕組みに頼らず守れます。あわせて、更新の自動化が進むことや、暗号の方式を早く切り替えられることも理由に挙げています。

手作業の更新が回らなくなる理由

年1回の更新なら、カレンダーに書いておけば何とかなりました。47日になると、次の理由で手作業では回らなくなります。

• 回数が増える。上の表のとおり、証明書20枚で年240回の入れ替えになる
• ドメイン確認も毎回になる。メールで承認する方式だと、そのたびに人が承認する
• 入れ替える場所が多い。Webサーバー、ロードバランサー、VPN装置などに同じ証明書を入れていることがある
• 担当者が休む・異動する。月に何度もある作業を1人で抱えると、休暇の週に期限が来る
• 通知に頼れない。Let's Encryptは2025年6月4日で期限切れの通知メールをやめた

自動更新の仕組み ACMEを使う

答えは自動化です。標準の方法として、ACME(証明書の申し込みから入れ替えまでを自動で行う通信の約束事)があります。2019年3月にRFC 8555として標準になりました。

サーバーにACMEのソフト(クライアント)を入れておくと、次の流れを人の手なしで繰り返します。

1. 期限が近づいたら、認証局に新しい証明書を申し込む
2. 認証局から出された課題に答えて、ドメインの管理を証明する
3. 新しい証明書を受け取り、Webサーバーなどに入れ替えて再起動する

ドメインの確かめ方は2種類から選ぶ

無料の認証局だけの話ではない

ACMEはLet's Encryptだけの仕組みではありません。たとえばJPRSは、2022年3月2日からDV証明書でACMEに対応した発行サービスを、取り扱い事業者を通じて提供しています。今の販売店や認証局が対応しているかは、窓口に確かめるのが早道です。

Let's Encryptも自らの期間を短くします。標準の証明書は2027年2月10日から64日、2028年2月16日から45日になる予定です(2026年10月3日時点の発表)。

認証局が「そろそろ更新を」と知らせるARI(RFC 9773、2025年6月)という仕組みもできました。対応したクライアントなら、認証局が一斉に失効させる前の早めの更新にも自動で応じられます。

まず証明書の棚卸しをする

自動化の前に、どこに何枚の証明書があるかを知る必要があります。台帳はExcelでも十分です。次の列を用意します。

漏れなく見つける3つの方法

1. ドメインの一覧から探す。ドメインを登録している会社の管理画面で、自社のドメインをすべて書き出す
2. 証明書の公開記録から探す。Google Chromeは、公開のログ(Certificate Transparency)に記録のない公開の証明書を信頼しない。ログの検索サイトにドメイン名を入れると、過去に出た証明書を一覧で調べられる
3. 機器の管理画面を見る。VPN装置、UTM、NAS、複合機などの管理画面に入れている証明書を確かめる

2番目の方法では、制作会社や部署が独自に取った「知らない証明書」が見つかることもあります。見つけたら、誰が更新しているのかを台帳に書き足します。

自動にできないものから優先して手を打つ

担当と通知先を個人から外す

自動にしても、更新が失敗することはあります。DNSの設定変更やサーバーの移転で、ACMEが静かに止まることがあるからです。Let's Encryptも、更新されないときに知らせる監視を用意するよう勧めています。

委託先には、次のような文面で確かめておくと話が早くなります。

今日からできること 2029年3月までの段取り

次の節目は2027年3月15日の100日です。手作業の証明書が年5〜6回の更新になる前に、自動化のめどをつけるのが現実的な目標です。

最後に、今週中にできるチェックリストです。

• 自社が持っているドメインを書き出した
• 証明書の公開記録を検索し、知らない証明書がないか確かめた
• 台帳に期限・場所・更新方法・担当を書いた
• 期限の通知が個人のアドレスに届いていないか確かめた
• レンタルサーバーやクラウドの自動更新の設定を確かめた
• 委託先が管理している証明書の対応を問い合わせた
• 証明書の期限を外から監視する仕組みを用意した