SSL証明書の有効期間短縮（47日）への対応 — 中小企業の費用と手順

SSL/TLS証明書の有効期間短縮とは、Webサイトの安全性を示す証明書の「有効期限」が、業界ルールの改定によって段階的に短くなっていく取り組みです。以前は最長398日（約13か月）でしたが、2026年3月15日以降に発行される証明書は最長200日になり、2027年3月に100日、2029年3月には47日まで短縮されます。

結論から言うと、「年1回、担当者が手作業で更新する」運用はもう成り立たなくなります。対策の中心は「自動更新にしておくこと」です。レンタルサーバーの無料SSLやCDNのマネージド証明書を使っている会社は、設定を確認するだけで済むケースがほとんどです。一方、有料証明書を手動更新している会社や、社内機器・独自システムの証明書がある会社は、2027年3月までに棚卸しと切り替えを進めておく必要があります。

この変更は、ブラウザ会社や認証局（証明書を発行する事業者）が参加する国際的な業界団体「CA/Browser Forum」が2025年4月に承認したルール（投票案SC-081）に基づいています。公的に信頼されるSSL/TLS証明書の最長有効期間は、次のように段階的に短くなります。

今日（2026年10月）時点では、すでに200日ルールが適用されている段階です。次の節目は2027年3月15日で、ここから最長100日になります。つまり、年1回の更新が、年に3〜4回の更新へと変わっていきます。なお、ドメイン確認（そのドメインを本当に持ち主が管理しているかの確認）も同様に短い周期で再実施が必要になるため、手作業での対応はさらに負担が増えます。

すでに無料の認証局であるLet's Encryptは90日の有効期間で運用しており、標準の証明書を2027年2月に64日、2028年2月に45日へ段階的に短縮する方針を公表しています。また、2025年には有効期限が近づいた際の通知メールの送付も終了しています。「期限が近づけば教えてくれる」ことを前提にした運用は、今後ますます通用しなくなります。細かな日程や条件は認証局ごとに異なる場合があるため、実際に契約している事業者の案内も合わせて確認してください。

理由は主に2つあります。1つ目は安全性の向上です。証明書の秘密鍵が漏えいしたり、証明書が不正に発行されたりしたとき、有効期間が長いほど悪用できる期間も長くなります。期間を短くすれば、被害が続く時間を小さくできます。2つ目は自動化の定着です。更新が頻繁になれば、人が手でやる運用は割に合わなくなり、自動化が標準になります。業界全体として「証明書は自動で入れ替わるもの」という前提に移行する流れです。

「うちはホームページだけだから関係ない」と思われがちですが、社内には意外とSSL/TLS証明書が使われている場所があります。まず次の一覧で、自社に当てはまるものを探してください。

- 自社サイト（コーポレートサイト）: 最も一般的。レンタルサーバーの機能で自動更新されているケースが多い
- ECサイト・予約システム: 止まると売上や予約に直結する。決済や外部サービス連携にも証明書が関わる
- 社内機器の管理画面: NAS、UTM（セキュリティ機器）、無線LAN、複合機などのWeb管理画面で、独自の証明書を入れている場合がある
- メールサーバー: 自社で運用している場合、メール送受信の暗号化に証明書を使っている
- 独自システム・業務システム: 取引先との連携API、社内Webシステム、VPNなど
- 有料のOV/EV証明書を使っている会社: 手動で申請・更新している場合は影響が最も大きい

特に注意が必要なのは、「誰がいつ入れたのか分からない証明書」です。以前の担当者や外部の業者が設定したまま、社内に更新手順が残っていないケースは珍しくありません。有効期間が短くなると、こうした「忘れられた証明書」が期限切れで突然問題を起こすリスクが高まります。

証明書が期限切れになると、影響は想像以上に広範囲です。見た目の警告だけで終わらず、業務が止まる場合があります。

- ブラウザの警告表示: 「この接続ではプライバシーが保護されません」といった全画面の警告が出て、お客様がサイトを閲覧できなくなる
- サイト・サービスの実質停止: 警告を見たお客様は離脱し、ECや予約の売上機会を失う。検索結果での評価や信頼にも響く
- フォーム送信の失敗: 問い合わせフォームや予約フォームが動かなくなり、気づかないうちに問い合わせを取りこぼす
- API連携の停止: 取引先システムや決済、在庫連携などが通信エラーで止まる。夜間や休日だと発覚が遅れやすい
- 社内業務への影響: 管理画面にアクセスできない、メールの送受信エラーが出る、といった形で表面化する

厄介なのは、期限切れはある日突然、しかも休日や夜間に起きやすいことです。更新が年に数回になるほど、うっかりの機会も増えます。だからこそ「人の注意力」ではなく「仕組み」で防ぐ必要があります。

対応の第一歩は、自社が使っている証明書を洗い出すことです。専門知識がなくても、次の項目を順に確認していけば全体像をつかめます。

- ドメインの一覧を作る: 自社が契約しているドメイン（コーポレートサイト、ECサイト、予約サイト、サブドメインなど）を全部書き出す。契約情報や請求書を見ると漏れにくい
- それぞれの証明書の種類を確認する: 無料（Let's Encryptなど）か有料か、どの会社が発行しているか
- 更新方法を確認する: 自動更新か手動か。手動なら誰が、いつ、どうやって更新しているか
- 有効期限を記録する: ブラウザの鍵マークから証明書情報を開くと確認できる。一覧表にまとめる
- 社内機器・メールサーバーも確認する: NAS、UTM、複合機、メールサーバーなど、Webサイト以外の機器を忘れない
- 契約窓口と費用を確認する: どこで契約し、いくらかかっているか。制作会社や保守会社が代行している場合は、その範囲も確認する
- 担当者と連絡先を決める: 期限や異常を知らせる通知の宛先が、退職者や使われていないメールアドレスになっていないか

この棚卸し表があるだけで、「どこが自動で、どこが手動か」が一目で分かります。手動のものから優先して自動化していくのが、無理のない進め方です。

更新の自動化には、いくつかの方法があります。自社の環境や担当者の状況に合わせて選びましょう。次の表の費用はあくまで目安で、利用するサービスや構成、依頼先によって大きく変わります。

基本方針は、「まず自動化できるものはすべて自動化し、手動のものは最小限に絞る」ことです。特にレンタルサーバーやCDNの自動更新に切り替えられる場合は、有料証明書を手動更新するよりも、費用面でも負担面でも有利になることが多くなります。有料証明書の選び方や種類の違いはSSL証明書の選び方・運用ガイドで詳しく整理しています。

サーバーやドメインの契約まわりをあらためて確認したい場合は、ドメイン・サーバーの費用と契約も参考になります。自動更新に切り替えると、証明書の更新費用が減る分、運用の見直しで全体のコストを抑えられる可能性があります。

NAS、UTM、複合機、古い業務システムなどは、自動更新に対応していないことがあります。その場合は次の3つの方法を検討してください。

- 機器の前段にリバースプロキシやCDNを置く: 外部から見える証明書の部分だけを、自動更新できる仕組みに肩代わりさせる
- 社内限定で使うなら、社内用の仕組みに切り替える: 外部に公開していない管理画面なら、公的な証明書にこだわらず、社内用の認証局や運用ルールで管理する方法もある
- 更新のカレンダーを作って手動で回す: 数が少なければ、更新日をカレンダー登録し、担当者と代理担当者を決めて確実に実施する
- 機器の買い替え時に自動更新対応を条件にする: 今後の購入では、証明書の自動更新に対応しているかを選定基準に加える

どの方法が適切かは、機器の種類や社外に公開しているかどうかで変わります。判断に迷う場合は、機器のメーカーや保守会社に「この機器の証明書は自動更新できるか」と確認するのが近道です。

ホームページやシステムの運用を外部に任せている場合は、次の質問をそのまま投げて、回答を書面で残しておくと安心です。契約内容の見方は保守契約のチェックポイントでも解説しています。

- 当社の証明書は自動更新になっていますか。手動の場合、誰がいつ更新していますか
- 有効期間が200日・100日・47日に短くなっても、同じ体制で対応できますか
- 証明書の更新は保守契約の範囲内ですか。追加費用が発生する場合の金額は
- 更新に失敗したときの通知先はどこですか。当社にも連絡が来ますか
- 証明書の一覧と有効期限を共有してもらえますか（棚卸し表の作成に協力してもらえますか）
- 有料のOV/EV証明書を使っている場合、自動更新に切り替えられるものはありますか
- 担当者が退職・交代しても引き継ぎが途切れない体制になっていますか

保守費用の相場や、どこまでが費用に含まれるのが一般的かについては、ホームページ保守費用の記事が目安になります。「証明書の更新は保守に含まれているはず」と思い込まず、必ず確認してください。

次の節目である2027年3月15日まで、約5か月あります。余裕を持って進められるよう、月ごとの目安を示します。

- ステップ1（2026年10月）: 棚卸し — ドメインと証明書の一覧を作り、更新方法（自動・手動）と有効期限を記録する
- ステップ2（2026年11月）: 現状の把握と優先順位づけ — 手動更新のもの、担当者が不明なもの、止まると影響が大きいもの（EC・予約・API連携）を洗い出し、優先順位をつける
- ステップ3（2026年11月〜12月）: 委託先への確認 — 制作会社・保守会社・サーバー会社に、前節の質問をして回答を得る
- ステップ4（2026年12月〜2027年1月）: 自動更新への切り替え — 手動のものから順に、自動更新の仕組みへ切り替える。切り替え後は、更新が実際に動くかを確認する
- ステップ5（2027年2月）: 通知と引き継ぎの整備 — 更新失敗の通知先を現役の担当者に設定し、代理担当者も決める。手順書を1枚にまとめる
- ステップ6（2027年3月）: 最終確認 — 3月15日の切り替え前に、有効期限が短くなっても問題なく動く状態かを再確認する

年末年始をまたぐため、ステップ4は12月上旬までに着手しておくと安心です。休暇中に期限切れが起きても気づけない、という事態を避けられます。

- 「自動更新のはず」と思い込む: 設定がオフだったり、ドメインを追加したときに対象から漏れていたりすることがある。実際の有効期限を目で確認する
- 通知先が古いまま: 退職者や使われていないメールアドレスに通知が届き、誰も気づかない
- サブドメインの見落とし: 予約システム用、キャンペーン用など、あとから追加したサブドメインの証明書を見落とす
- 社内機器を後回しにする: Webサイトは自動化できても、管理画面や複合機の証明書だけが期限切れになる
- 有料証明書を長期契約で購入する: 有効期間が短くなるため、複数年契約の価値は以前より小さくなる。契約条件を確認してから購入する