[FileBlogSSL1] SSL証明書の有効期間短縮 - 自動更新への対応について | コラム

まもなく、SSL証明書有効期間が劇的に短縮され、これまでのように毎年一回の手動による更新では運用が不可能になります。
更新の自動化を前提とした運用に移行しなければいけません。

しかし、SSL証明書の更新は単純な作業ではなく、「ドメイン・DNS・ネットワーク・サーバにまたがる作業」です。
責任分界を明確にした体制づくりから念入りに設計しないと、簡単には実現できません。

結論：FileBlogは、証明書の自動更新（ACME）に対応済です

本記事は、主に企業・団体の情報システム部門や、ユーザに近い立場でシステム運用を担うエンジニアの方を対象としています。

弊社は、Webアプリケーションサーバ製品（FileBlog）のメーカーとして、お客様社内でのSSLサーバ証明書の運用をお手伝いする立場です。
「FileBlogは、証明書の自動更新（ACME）に対応していますか？」といった、質問を受けるのですが、
本文書が、そのような質問への回答となります。

また、弊社製品FileBlogに限らず、Webアプリケーション一般を運用される方々にとって、有用なコンテンツとなるように書くことを心がけております。

結論から申し上げますと、FileBlogは証明書の自動更新環境構築に対応済です。FileBlogの最新版Ver. 5.6.2.1を2026/7/17にリリースしており、このバージョン以降では、
Windowsサーバ上の任意のフォルダに置いた証明書ファイルをFileBlogから参照できるようになります。

証明書自動更新環境構築に向けて

しかし、「証明書の自動更新環境構築」は、FileBlogのようなWebアプリケーション製品だけで対応できるものではありません。」
定期的に証明書ファイルを取得して最新化するための環境構築は、お客様自身の費用と責任で行っていただきます。弊社として請け負うものではありません。

従来ならば年に一回の作業であった、証明書を購入する手順、そのためのドメインの所有権証明の手順を、自動化することによって30日に一回程度の高頻度で運用できるようにするには、
証明書プロバイダ・DNSプロバイダ・Webサーバ管理者など、ネットワーク環境のさまざまな側面に対するコントロールが必要です。

さまざま、といっても範囲が広いのですが、何が必要なのか？について、本文書（と関連文書）を読んでいただければ、必要な手順の全体像が具体的にわかるようになります。ぜひご一読ください。

きっかけ：証明書有効期間が短縮されます

認証局/ブラウザ（CA/B）フォーラムによって、今後認証局が発行してブラウザが有効性を認めるSSLサーバ証明書の有効期間が、段階的に短縮されることが決定されました。

適用開始日	最大有効期間	今どこ？
～2026/3/14	最大398日
2026/3/15～	最大200日
2027/3/15～	最大100日	★2026/7月現在
2029/3/15～	最大47日

注

CA/Bフォーラムは、証明書発行者（認証局＝CA）とブラウザベンダー（B）などが集まった業界団体。
有効期間は、最大日数が定められているが、CAの実装次第で多少変化します。
ドメイン所有権の確認（DCV＝Domain Control Validation）の有効期間も短縮され、最終的には実質的に証明書発行の都度、再確認が必要になります。

影響：証明書有効期間が切れてWebサイトがダウンする危険

証明書の有効期間が切れたWebサイトへのアクセスは、セキュリティ上危険なアクセスとみなされ、ブラウザによって警告が表示されたり、場合によってはアクセス自体が禁止されたりする可能性があります。

証明書のこまめな更新を怠れば、Webサイト・Webアプリケーションをインターネットに公開して利用することができなくなってしまうかもしれません。
従来ならば証明書の更新は一年二一回で十分でしたが、近い将来には1か月半に一回の頻度で更新が必要となり、手作業での運用が非現実的になるといえます。

動機：なぜ短縮されるのか？

理由はいくつかあります。

セキュリティ向上

まずは、セキュリティの向上です。証明書の鍵情報が漏洩した場合に、悪意あるサイトによる「なりすまし」などに証明書が悪用されるリスクがあったり、ドメインの所有者が変わった後に、以前の証明書が使われ続けることも、問題です。これらのリスクを最小化するために、証明書の有効期間を短縮して、より短いサイクルで証明書の発行を義務付けることになったものです。

証明書自動更新技術の普及

次に、証明書自動更新技術の普及です。無料のCAである「Let's Encrypt」が主導して、証明書自動取得・自動更新のしくみ（ACME＝Automatic Certificate Management Environment）が普及したことで、CA側でのドメイン所有権チェック（DCV）や、証明書発行の自動化が可能になり、ユーザの作業負荷を増やさずに、自動化によって頻繁な証明書更新が技術的に可能になりました。

業界の利害一致と時代の流れ

おそらく最後に、ブラウザベンダとCA全体の利害が一致して、証明書の頻繁な自動更新へとユーザを誘導することになったと思われます。

有償CAにとっては、ユーザをサブスクリプション契約に誘導できるとともに、証明書発行手続きの自動化で、事務手続きコストが削減できるようになります。
ブラウザベンダとしては、フィッシングなど悪意あるサイトの被害に対して批判の矢面に立たされたくないのでしょう。

私たちの事業環境が外部環境にますます依存を深めていくことは、産業・文明の高度化によって必然的に起こることであるので、致し方ないものと理解しています。
現代人の生活は、電力・水道・通信・物流などのインフラに深く依存しており、いまさら自給自足には戻れません。
デジタルセキュリティもまた、必須のインフラになりつつあるということでしょう。（いずれは政府の管理下で価格統制や無償提供の対象となるかもしれませんね）

必要な対応：

企業・団体などで、情報システムを管理する部門においては、証明書期限切れによるシステムダウンを防止するために、下記の対策が必要になります。

更新・配布の自動化の代わりに、これまで毎年一回であった証明書の入れ替え作業を、引き続で手動で毎月一回行うこととして、そのための人的資源を確保する方法もありますが、一般的には自動化が望ましいため、それを前提としています。

【可視化】まず、HTTPS暗号化通信・SSL証明書が必要となるサーバ・機器を一覧化して把握すること
【更新環境の整備・有効期限の確認】手作業でもいいので有効期限切れ前に更新環境を整える。DNSやCAの管理アカウントを把握し、統一的に整理することが望ましい
【更新の自動化】新規証明書取得の自動化を行います
【配布の自動化】取得した証明書を配布してWebサービスに反映する部分を自動化します
【定常運用開始】自動化スクリプトをテストした後、定期的な自動実行を開始します

証明書取得自動化の方法

証明書の発行元によって、二通りに分かれます。

組織内の自己認証局を使う場合

SSL証明書というと、外部の認証局から必ず購入しなければならないように思われますが、必ずしもそうではありません。

組織内で勝手に認証局を立て、その認証局にサーバ証明書を発行させれば、証明書発行のための費用は掛かりません。証明書発行自体は技術的には全く難しいものではありません。

ただし、外部の公的認証局が発行した証明書と異なり、自己認証局が発行した証明書はそのままではブラウザ（Edge/Chromeなど）に正しい証明書として認められません。

ブラウザに認めてもらうには、あらかじめ自己認証局の証明書（ルート証明書）を、組織内の全部の端末に「信頼されるルート証明書」として配布し、登録しておく必要があります。
Windows Active Directoryドメイン環境ではグループポリシーによってルート証明書の配布が可能ですので、イントラネットのWindows環境に限定しで運用するWebアプリケーションサーバのためのSSL証明書は、自己認証局を立てて運用することが比較的容易に可能です。

FileBlogサーバは、自己認証局機能をすでに実装済ですので、こちらをお使いください。
（ただし、FileBlogサーバ以外にも組織内で複数のWebサーバを運用しているという場合、そこまでの対応はできません。）

実現の方法については、こちらをご覧ください

FileBlogで自己証明局を立てて社内で運用する方法

外部の認証局から購入する場合

インターネットに公開するWebサーバに対して、不特定多数の端末からのアクセスを安全に行わせたい場合には、原則として外部の認証局（CA）が発行するSSL証明書が必要です。

そのためには、

まず、認証局とサブスクリプション契約を結び、必要な時に証明書発行APIを利用可能にする必要があります。
また、認証局に対してドメインの所有権を証明するため、DNS-01チャレンジまたはHTTP-01チャレンジに応えられるようにする必要があります。
DNS-01チャレンジは、認証局の求めに応じてDNSのTXTレコードを生成することで、ドメインの所有権を証明するもの
HTTP-01チャレンジは、要求に応じてテキストファイルを公開Webサーバにアップロードすることで、 Webサーバホストの所有権を証明するものです

詳しい手順は別文書で説明します

証明書更新自動化の（組織体制的）前提条件

弊社ではこれまで20年以上、様々なお客様のネットワーク環境・ファイルサーバ環境の保守にかかわってサポートを行ってまいりました。
FileBlogユーザのお客様が、SSL証明書更新の自動化を実現することも、できる限りお手伝いしたいと思っておりますが、
前提としての知識や体制があまりに未整備では、お手伝いしたくても出来ません。

まず、下記にあげるように、各種の管理対象と、だれが何を担当するのかの明確化をお願いします。

証明書更新を自動化するために必要な、技術的な方法については、本文書では触れず、別途文書にて解説します。

管理対象の区別と分業体制を明確にしてください

SSL証明書の自動更新は、単一の作業ではなく、複数の管理領域にまたがる作業です。実際のトラブルの多くは、証明書そのものではなく、DNSやネットワークなど他の管理領域に起因しすることも多く、関係者間での調整が必要になります。特に分業体制が敷かれている場合には、あらかじめ関係者を整理して、プロジェクトへの協力を取り付けておくことが、全体のスケジュールを滞らせないために重要なポイントです。

管理対象	何を管理？	提供業者	SSL証明書自動更新との関係
ドメイン（example.comなど）の所有権	ドメイン所有権: >Whois情報権威DNSサーバへのポインタ	ドメイン・レジストラ	ドメインが無効では証明書が無意味
DNSレコード	DNSレコード: ホストのIPアドレスメールサーバ情報など	DNSプロバイダ DNSホスティング事業者	ドメイン所有権を証明するための DNS-01チャレンジでTXTレコード更新が必要一部CAはCAAレコードをチェック（設定によっては拒否）
サーバ証明書	証明書と秘密鍵の発行更新運用の実行（ACMEサーバ運用）	認証局（CA）	SSL証明書発行・失効管理の主体
インターネット接続・WAN回線	外部ネットワークとの接続: フレッツ回線・専用線など	通信事業者（NTTやプロバイダ）	DNS-01チャレンジ・HTTP-01チャレンジで外部ネットワークへの通信疎通が必要 HTTP-01チャレンジでは外部ネットワークからのTCP/80,443ポート受入が必要
ネットワーク機器・配線	ルータファイヤウォールスイッチケーブルなど	社内管理または機器ベンダ等に委託	DNS-01チャレンジ・HTTP-01チャレンジで外部ネットワークへの通信疎通が必要 HTTP-01チャレンジでは外部ネットワークからのTCP/80,443ポート受入が必要
社内サーバ各種	OS（Windows/Linux ）アプリ（FileBlog/Apache/Nginx）	利用部門または情報システム部門	HTTP-01チャレンジで検証用ファイル公開証明書のインストールアプリへの反映（再起動など）
Active Directoryドメイン	組織内のアカウントグループポリシー組織内CAなど	情報システム部門委託先ベンダ	ユーザ・グループ権限管理組織内CA証明書の配布