[FileBlogSSL3] SSL証明書自動配布インフラの作り方 | コラム | エンタープライズサーチ/文書管理 FileBlog

SSL証明書を自動更新する仕組みの構築方法について説明します。

弊社のFileBlog（Webサーバ製品）はWindows上で動作するため、主にWindows環境に ACMEクライアントをインストールし、Windows上のWebアプリに証明書をインストールして運用することを中心に説明します。なお、Linux上のACMEクライアント(certbotなど)で証明書を取得したり、Linux上のWebサーバ(apache・nginxなど)に証明書を配布して運用したりといったことも含めた一般論も本文書の説明に含みます。

証明書自動更新の仕組み

証明書自動更新は2段階のプロセスです。

Step	名称	説明
Step1	最新証明書の自動取得	認証局から、最新の証明書を取得します
Step2	証明書の配布	取得したサーバ証明書を、各Webサーバ実行環境に反映します

Step1：証明書の取得

ACMEプロトコルを使って認証局から最新の証明書をダウンロードすることが一般的な方法です。

有償の証明書を使う場合、認証局とサブスクリプション契約を結んでおくことが必要です。また、ドメインの所有権を証明するために、Webサーバをインターネット公開するか、DNSサーバの書き込みAPIを利用できるようにすることも必要です。

あるいは、無償の認証局であるLet's Encryptを利用する方法もあります。（サイトをインターネットに公開することが前提です）

このStepでは、オープンソースのACMEクライアントとして一般的な certbot や WinACME を利用し、各自が契約しているDNSプロバイダおよび認証局から発行されたアクセスキーを使って証明書を取得することになります。

Step2 : 証明書の配布

取得したサーバ証明書ファイルを社内のWebサーバの動作環境に配置し、Webサーバの再起動や証明書の再読み込みを実行することで最新証明書を有効化します。FileBlog Ver.5.6.2.1 (2026/7/17リリース）は、ファイルから証明書を読み込んで起動できます。

注意：FileBlogは直接ACMEに対応しません。

Step1・Step2の関係のとおり、FileBlogはACMEに直接対応しません。FileBlogではpem・pfx形式ファイルに保存されたサーバ証明書ファイルを読み込んで動作するため、ACMEクライアントの設定については管理者が認証局やDNSプロバイダから必要なアクセスキーを取得のうえ、WinACMEやcertbotなどのツールを用いて自動化してください。

証明書取得の概要

証明書を取得するために2つの準備があります。

1つはACMEサーバの接続アカウントで、有償認証局の場合にはサブスクリプション契約に基づいてアクセスキーなどが発行されます。

もう1つは、ドメイン所有権を証明する手段です。インターネット公開サイト（１ホスト）に対する証明書であれば、特定のファイルをWebサーバにアップロードすることで証明するHTTP-01チャレンジが使えます。DNSレコードの書き換えによって証明するDNS-01チャレンジでは、より強くドメイン所有権を証明できるためワイルドカード証明書の発行にも対応できます。

サイト・証明書の性質	証明書の無償／有償	ドメイン所有権の証明方法
インターネット公開サイト（専用のSSLサーバ証明書）	無償：Let's Encrypt のACMEサーバを使う有償：認証局のACMEサーバを使う	HTTP-01チャレンジ
ワイルドカード SSLサーバ証明書	無償：Let's Encrypt のACMEサーバを使う有償：認証局のACMEサーバを使う	DNS-01チャレンジ

必要なツール

ACMEクライアント

認証局のACME(Automated Certificate Management Environment) サーバと通信するために必須なのが、ACMEクライアントです。

Windows環境ではWinACME (wcas.exe) が一般的です。
Linuxでは certbot が一般的です。
FileBlogはWindowsで動くので、Windowsで稼働させることを想定して以下では説明します。（certbotでもコマンド文法は異なりますができることは似ています）

ACMEプロトコルは無償のSSL証明書発行を行うLet's Encryptが開発したプロトコルです。有償の認証局から発行されるSSL証明書の配布のために拡張されており、そこで主流となっているのはACME External Account Binding（EAB）という方法です。認証局がアカウントのキー（Key identifier）とHMAC Keyを発行し、認証局のACMEサーバのURLと、三つの値をACMEクライアントに渡すことで動作します。

ACMEクライアントのプラグイン

DNS-01チャレンジを利用する場合、DNSプロバイダ別のプラグインをインストールします。例えば、Amazon の Route53サービスをDNSサービスとして使っている場合は、WinACMEにplugin.validation.dns.route53.*.zip を加えます。

リソース

WinACMEのインストール

win-acme.v2.2.9.1701.x64.pluggable.zip のようなパッケージ（最新のものがよいがpluggableでないとプラグインが使えません）をC:\Program Files\WinACME に展開します。

鉄飛では、AWS Route 53 を使うため plugin.validation.dns.route53.v2.2.9.1701.zip をダウンロードしました。中にはDLLなどが入っているので、wacs.exeと同じフォルダC:\Program Files\WinACME にコピーします。

DNS-01チャレンジ時のDNS参照先をインターネットDNS（例えばRoute53）にする

WinACMEがDNS-01チャレンジでteppi.netゾーンを更新した後の結果を確認するには、_acme-challenge.teppi.net ゾーンのTXTレコードを読み取ります。

インターネットDNSのみを使っている場合は問題ありませんが、LAN内のActive Directoryドメインコントローラなど、社内用のDNSサーバを個別に立てていて、teppi.netゾーンをホスティングしている場合、問い合わせを社内DNSが横取りしてしまうとRoute53が更新したレコードをすぐに読みだせません。

そこで、_acme-challenge.teppi.net ゾーンの名前解決を上位（Route53）のDNSサーバに委任します。（社内DNSのない場合はこの手順は不要です）

委任先は、nslookup -type=NS teppi.net 8.8.8.8 の結果として得られたNameServerです。

teppi.net       nameserver = ns-1111.awsdns-10.org
teppi.net       nameserver = ns-1929.awsdns-49.co.uk
teppi.net       nameserver = ns-888.awsdns-47.net
teppi.net       nameserver = ns-226.awsdns-28.com

上記を登録しました。

これで、_acme-challenge.teppi.net ゾーンに関するDNSサーバへの問い合わせが、すぐにインターネット上の権威DNSサーバに届くようになります。

必要なアクセス情報

無償の SSL証明書認証局である Lets' Encrypt から証明書を取得する場合は、特にアクセスキーは不要です。

key identifier と HMAC key

有償のSSL証明書を認証局から購入している場合には、認証局の管理ページからKey identifierとHMAC Keyの入手が必要です。

例： CA（DigiCertの例）のサブスクリプションに基づき、ACMEサーバ利用のためのAPIキーとHMACハッシュを発行する方法

DNSサービスのアクセスキー

ワイルドカード証明書を取得したい場合や、イントラネットサイト向けに認証局から証明書を取得したい場合は、DNS-01チャレンジが必要です。

DNS-01チャレンジとは、ACMEサーバの求めに応じてDNSレコードを書き換えるというもので、ACMEクライアントに各種のDNSサービスに応じたプラグインを組み合わせたうえで、DNSサービスのアクセスキーを渡すことでクリアできます。（例えば、Amazon Route53サービスをDNSサービスとして使っている場合など）

例： Amazon Route53 でDNS-01認証を可能にするためのIAMユーザ作成・APIキーの発行の方法