.png)
SSL証明書の「47日問題」とは？中小企業が今確認したい更新方法
- 3 分前
- 読了時間: 6分
Webサイトを開いたとき、アドレスバーに表示される「https」
この通信を暗号化し、接続先が正しいことを確認するために使われているのが、SSL/TLS証明書です。
最近、この証明書をめぐって「47日問題」という言葉を見かけるようになりました。
47日ごとに自分で更新作業をしなければならないのか
新しい証明書やサービスを購入する必要があるのか
制作会社やレンタルサーバーに任せている場合も対応が必要なのか
専門用語が多く、自社に関係する話なのか判断できない方もいるでしょう。
結論からいえば、レンタルサーバーなどで証明書が自動更新されているなら、今すぐ慌てて設定を変える必要はありません。
ただし、「委託先に任せているから、自社は何も把握しなくてよい」とも限りません。
大切なのは、証明書の詳しい仕組みを覚えることではなく、誰が、どの方法で更新し、失敗したときに誰が気づくのかを確認することです。
「47日問題」は、証明書の有効期間が短くなる話
ここでいうSSL/TLS証明書は、インターネット上のWebサイトやシステムなどで使われる、一般に信頼された公開証明書です。
CA/Browser Forumが定める基準により、公開TLS証明書の最長有効期間は段階的に短縮されます。
証明書の発行日 | 最長有効期間 |
2026年3月15日より前 | 398日 |
2026年3月15日～2027年3月14日 | 200日 |
2027年3月15日～2029年3月14日 | 100日 |
2029年3月15日以降 | 47日 |
つまり、2026年から突然47日になったわけではありません。
現在は200日への短縮が始まっており、2027年に100日、2029年に47日へ移行する予定です。
有効期間が短くなると、もし証明書や秘密鍵に問題が起きた場合の影響を、長期間残しにくくなります。その一方で、更新回数は増えるため、期限のたびに人が作業する運用は現実的ではなくなります。
そこで重要になるのが、証明書の取得からサーバーへの反映までを含めた更新の自動化です。
「47日ごとに手作業する」という意味ではない
47日という数字だけを見ると、「毎月のように更新作業が発生する」と感じるかもしれません。
しかし、管理型のレンタルサーバーやクラウドサービスでは、事業者側が証明書を自動更新している場合があります。
自社のWebサイトがこの仕組みを利用しており、更新後の反映や異常時の通知まで管理されているなら、利用企業が毎回手作業をする必要はありません。
一方、次のような環境では確認が必要です。
証明書を購入し、担当者が毎年手作業で更新している
Webサイトや業務システムを独自のサーバーで運用している
制作会社とサーバー会社のどちらが証明書を管理しているか分からない
Webサイト以外にも、サブドメイン、API、VPNなどで証明書を使っている
更新通知が、退職者や以前の委託先のメールアドレスへ届いている
証明書の更新に失敗すると、ブラウザーに警告が表示され、利用者がWebサイトへアクセスできなくなったり、外部サービスとの通信が失敗したりする可能性があります。
問題になるのは、有効期間が短くなることそのものよりも、手作業や担当者の記憶に依存した更新を続けることです。
制作会社やサーバー会社に任せていても、確認は必要
証明書の設定作業を、自社で行う必要はありません。
専門的な管理は制作会社やサーバー会社へ任せてもよいでしょう。
ただし、「任せている」という認識だけでは、次の点が曖昧なままになることがあります。
契約している保守業務に証明書の更新が含まれているか
レンタルサーバーの自動更新が有効になっているか
ドメイン認証やDNS変更が必要な場合、誰が対応するか
自動更新に失敗した場合、誰に通知されるか
サーバー移転やサイト構成の変更後も自動更新が続くか
「自動更新に設定されています」という回答だけでなく、更新失敗を検知し、復旧するところまで担当が決まっているかを確認することが重要です。
委託先へそのまま送れる5つの質問
専門用語を詳しく理解していなくても、次の質問を制作会社、保守会社またはサーバー会社へ送れば、現状を整理できます。
----------------
当社のWebサイトで使用しているSSL/TLS証明書について、次の点をご確認ください。
1．証明書は自動更新されていますか。手作業が必要な箇所はありますか。
2．証明書の有効期間短縮後も、現在の仕組みで自動更新を継続できますか。
3．自動更新に失敗した場合、誰に、どのような方法で通知されますか。
4．更新に失敗した場合の対応窓口と、当社側で必要な作業を教えてください。
5．当社が利用するドメイン、サブドメイン、APIなどに、別途管理が必要な証明書はありますか。
----------------
回答は口頭で済ませず、メールや管理台帳などに残しておくと、担当者や委託先が変わったときにも確認できます。
自社で準備しておきたいこと
証明書の技術的な設定を行わなくても、自社側で次の情報は整理しておきましょう。
1．利用中のドメインとサービス
会社のWebサイトだけでなく、予約サイト、採用サイト、会員ページ、業務システム、VPNなども確認します。
独自ドメインを使っているサービスがあれば、管理者と契約先を一覧にします。
2．管理会社と契約範囲
制作会社、保守会社、レンタルサーバー会社のうち、誰が証明書を管理しているかを確認します。
「Webサイト保守」という契約名だけで判断せず、証明書の更新が含まれているかを確認してください。
3．通知先と緊急連絡先
期限や更新失敗の通知が、現在も確認されているメールアドレスへ届くかを確認します。
担当者個人のアドレスだけでなく、複数人で確認できる管理用アドレスを使う方法もあります。
4．変更時の確認ルール
サーバー移転、DNS変更、ドメイン追加、委託先変更などを行うと、自動更新が動かなくなる場合があります。
システム構成を変えた際は、証明書の更新方法も確認項目に加えます。
新しい製品の購入より、まず現状確認を
「47日問題への対応」と聞くと、新しい証明書や管理サービスを導入しなければならないように感じるかもしれません。
しかし、すでに利用しているレンタルサーバーやクラウドサービスが自動更新へ対応していれば、追加費用や大規模な変更が発生しないこともあります。
反対に、証明書を手作業で更新しているシステムが複数ある場合は、自動化や監視方法の見直しが必要です。
まずは製品を探すのではなく、現在の証明書、管理者、更新方法、通知先を確認することから始めましょう。
まとめ｜専門家になるより、確認できる状態をつくる
SSL/TLS証明書の最長有効期間は、2026年の200日、2027年の100日を経て、2029年には47日へ短縮されます。
ただし、利用企業が47日ごとに手作業をするという意味ではありません。
自動更新が適切に動き、失敗時の通知と対応先が決まっていれば、過度に心配する必要はありません。
確認したいのは、次の4点です。
証明書は自動更新されるか
有効期間の短縮後も現在の仕組みで対応できるか
失敗したときに誰が気づくか
誰が復旧対応を行うか
自社で、証明書の設定ができるようになる必要はありません。
委託先へ必要な質問をし、その回答を社内に残すことが、最初の一歩です。
💬 ご相談はこちら
ITワークラボでは、IT担当者がいない中小企業向けに、Webサイトやクラウドサービスを含むIT環境の管理状況、契約先、担当範囲の整理をサポートしています。
「証明書を誰が管理しているか分からない」
「制作会社とサーバー会社のどちらへ確認すればよいか判断できない」
といった段階でも、お気軽にご相談ください。
現時点で具体的な対策が決まっていなくても問題ありません。
初回相談は無料です。
参考情報
📖 あわせて読みたい
関連ページ
IT・セキュリティ体制構築の支援内容は、「サービスページ」でご案内しています。
実際のご相談事例は、「導入事例」でもご紹介しています。
ITワークラボの考え方は、「ITワークラボについて」をご覧ください。
コメント