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

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

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

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

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

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

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

Ver. 5.6.2.1（2026/7/17リリース）で対応済み

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

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

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

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

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

なお、本文書はWindows環境でのWinACMEによる環境構築を前提としていますが、Linux/Unix環境でcertbotなどを用いる場合も全体像は大きくは変わらないでしょう。

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

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

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

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

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

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

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

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

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

セキュリティ向上

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

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

次に、証明書の自動更新技術の普及です。無料の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サーバホストの所有権を証明するもの

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

2026年8月31日FileBlog「DEEP」技術コラム

[FileBlogSSL3] SSL証明書自動配布インフラの作り方

2026年8月31日FileBlog「DEEP」技術コラム

[FileBlogSSL4] 証明書発行自動化のための key(s)の入手/DigiCertの場合

2026年8月31日FileBlog「DEEP」技術コラム

[FileBlogSSL5] AWS Route53でDNS-01チャレンジに応答するための準備

2026年8月31日FileBlog「DEEP」技術コラム

[FileBlogSSL6] WinACMEを呼び出すPowerShellスクリプト例

2026年8月31日FileBlog「DEEP」技術コラム

[FileBlogSSL7] SSL証明書更新の自動化/LetsEncryptの場合

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

弊社ではこれまで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証明書の配布