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

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

弊社のWebサーバ製品FileBlogは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に対応しません。
ファイルに保存されたサーバ証明書ファイルを読み込んで動作しますので、ACMEクライアントの設定についてはお客様が
認証局やDNSプロバイダから必要なアクセスキーを取得の上、WinACMEやcertbotなどのツールを用いて自動化してください。

証明書取得の概要

証明書を取得するためには、準備として二つが必要です。

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

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

サイト・証明書の性質	証明書の無償／有償	ドメイン所有権の証明方法
インターネット公開サイト（専用のSSLサーバ証明書）	無償：Let's Encrypt のACMEサーバを使う<br/> 有償：認証局のACMEサーバを使う	HTTP-01チャレンジ
ワイルドカード SSLサーバ証明書を使う	無償：Let's Encrypt のACMEサーバを使う<br/> 有償：認証局の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参照先を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サーバへの問い合わせが、すぐにAmazon Route53の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サービスとして使っている場合など）