コンテンツにスキップ

win-acme設定ガイド

1. はじめに（win-acmeとは？）

win-acme は、Windows Server環境、特に IIS (Internet Information Services) を利用している環境に特化したACMEクライアントです。 対話型のメニュー（GUI/CUI）に従って選択していくだけで、証明書の取得からIISのサイトへの割り当て（バインディング）、さらには自動更新タスクの登録までを一括して行ってくれる非常に便利なツールです。

事前に準備するもの

作業を開始する前に、以下を準備・確認してください。

  • EAB Credential（MAC Key・Key ID）：所属機関の登録担当者に依頼して発行を受けてください
  • 証明書を取得するドメイン名（例: www.example.ac.jp）
  • Windows Server の管理者権限（「管理者として実行」が必要です）
  • IISが稼働しており、証明書を適用するサイトが設定済みであること
  • TCP 80番ポートへの外部からのアクセスが許可されていること（ファイアウォール設定の確認）

2. インストール（ダウンロード）

win-acme はインストーラー不要で利用できます。

  1. 公式のGitHubリリースページ から、最新の win-acme.v2.x.x.x64.trimmed.zip をダウンロードします。（一般的な Windows Server は x64 環境のためこちらが適切です。x86（32bit）環境の場合は x86.trimmed.zip を選択してください）

Assetsが折りたたまれている場合

GitHubのリリースページで目的のzipファイルが見つからない場合、Assetsリストの末尾にある 「Show all 36 assets」（数値はバージョンにより異なります）などのリンクをクリックして、折りたたまれているアセット一覧を展開してください。

  1. 任意のフォルダ（例: C:\win-acme\）を作成し、zipファイルの中身を展開します。

3. UPKI環境へのアカウント登録（EABの紐付け）

UPKI環境を利用するためには、「EAB（外部アカウントバインディング）」により、正当な権限があることを証明する必要があります。

実際にACMEクライアントを操作する方（利用管理者）は、設定を行う前に、所属機関の登録担当者に依頼して「EAB Credential（MAC Key および Key ID）」を発行してもらい、受け取っておく必要があります。

EAB Credentialの使い切りと、サーバー移転時の対処について

UPKI環境で発行された EAB Credential は一度のアカウント登録にのみ使用できます。登録完了後は再使用できません。 サーバーを移転・再構築する場合は、win-acme の設定ディレクトリ（%ProgramData%\win-acme\）ごとコピーするか、登録担当者に新しい EAB Credential の発行を依頼してください。

win-acme では、起動時のコマンドライン引数でこの情報を指定します。

必ず「管理者として実行」してください

証明書のシステムへのインストールやIISの変更を行うため、管理者権限が必須です。通常の PowerShell で実行すると権限エラーで失敗します。PowerShell のアイコンを右クリックして「管理者として実行」を選んでから作業を行ってください。

Credentialの取り扱いに注意

--eab-key に指定した値はPowerShellのコマンド履歴に残ります。 作業完了後は Clear-History コマンドで履歴を削除することを推奨します。

PowerShell を管理者として実行し、展開したフォルダへ移動してから以下のコマンドを実行します。（例: C:\win-acme\ に展開した場合）

cd C:\win-acme
.\wacs.exe --baseuri "https://secomtrust-acme.com/acme/" --eab-key-identifier "【取得したKey ID】" --eab-key "【取得したMAC Key】"

コマンドを実行すると、EABの紐付け（アカウント登録）が自動的に行われ、続けて対話型メニューが起動します。アカウント登録だけが目的のこの段階では、メニューが表示されたら Q を入力して一度終了して構いません（証明書の発行は次のセクションで行います）。

EABで発行できるFQDNは事前登録したものに限られます（重要）

UPKIでは、EAB Credential ごとに、申請時に事前検証・登録したFQDNのみが発行できます。具体的には、主体者DNのCN（1つ）が固定され、これに加えて CNの値を含め最大8つのFQDN を dNSName（SAN）として1枚の証明書に指定できます。事前登録していないドメインで発行しようとすると、次のエラーになります。

rejectedIdentifier: 事前検証済みのCNと指定されたドメインが一致しません。

さらに win-acme は一度登録したACMEアカウントを保存して再利用します。そのため、すでに別のEAB（別ドメイン用）でアカウントを登録した状態で新しいEABをコマンドに指定しても、指定したEABは無視され、古いアカウントが使われ続けます。別のEAB／ドメインに切り替える場合は、保存済みアカウントを削除してから再登録してください。

  1. %ProgramData%\win-acme\<エンドポイントのフォルダ>\（例: secomtrust-acme.comacme）を開く
  2. Registration_v2 と Signer_v2 の2ファイルをリネーム（退避）または削除する
  3. 正しいEABで上記の wacs.exe --baseuri ... --eab-key-identifier ... --eab-key ... を実行して再登録する

※ EAB Credential は使い切りです。すでに消費済みの場合は、対象ドメイン用の新しいEABの発行を登録担当者に依頼してください。

【必須】RSA鍵長を 2048 に変更してください

発行できる鍵タイプは、EAB発行時に指定した証明書プロファイルに依存します。UPKI環境では RSA プロファイルが主流ですが、UPKIのCAは RSA 3072 を受け付けません。一方 win-acme はデフォルトで RSA 3072bit の鍵を生成するため、そのままでは証明書発行（finalize）の段階で次のエラーになります（ドメイン所有確認は成功するため、途中まで進んでから失敗します）。

CSRの設定値が不正です。[鍵長が許可された長さではありません。]

これを防ぐため、証明書を発行する前に settings.json で鍵長を 2048 に変更してください。

  1. 一度 wacs.exe を実行して settings.json を自動生成させます（初回起動時に settings_default.json から作成されます）
  2. settings.json を実行ファイルと同じフォルダ（例: C:\win-acme\settings.json）で開きます
  3. Csr セクションの "KeyBits": 3072 を "KeyBits": 2048 に変更して保存します
  4. 以降の発行・更新で 2048bit の鍵が使われます

ECDSAプロファイルの場合

申請時に ECDSA プロファイルを指定した場合は、鍵長ではなく鍵種別を変更します。settings.json の Csr.DefaultCsr を "ec" に変更してください（曲線 Csr.Ec.CurveName は既定 secp384r1 ＝ UPKIのP-384と一致するため変更不要です）。

4. 証明書の発行とIISバインディング

IIS環境では検証方法に注意（SelfHosting は失敗します）

対話メニューの N（default settings）や既定の発行では、win-acme は SelfHosting（win-acme自身が一時的にポート80で応答する方式）で検証を試みます。しかし IIS が既にポート80を使用している環境では、CAからのHTTP-01検証リクエストにIISが応答してしまい、検証ファイルが見つからず 404 エラーになります。

HTTP-01のチャレンジ検証に失敗。HTTPステータス: 404, URL: http://.../.well-known/acme-challenge/...

IIS環境では、検証ファイルをサイトの公開フォルダに配置してIIS自身に配信させる「filesystem」方式を使ってください。

対話メニューで多数の質問に答えるよりも、必要な指定をまとめたコマンドを1行実行する方法が確実で簡単です。PowerShell を管理者として実行し、展開したフォルダで以下を実行します。

.\wacs.exe --baseuri "https://secomtrust-acme.com/acme/" --source iis --host www.example.ac.jp --validation filesystem --webroot "C:\inetpub\wwwroot" --installation iis
引数 役割
--source iis --host <ドメイン> IISのbindingから対象ドメインを自動選択（サイト選択メニュー不要）
--validation filesystem --webroot <パス> SelfHostingではなくファイル配置方式で検証（IISが配信し、404を回避）
--installation iis 取得後にIISサイトへ証明書を自動バインド

--webroot には対象IISサイトの物理パスを指定します

標準では C:\inetpub\wwwroot です。異なる場合は、IISマネージャーで対象サイトを選び「基本設定」→「物理パス」で確認した値に置き換えてください。

このコマンド1つで、検証 → 証明書取得 → Windows証明書ストアへの登録 → IISのhttpsバインド → 自動更新タスクの登録までが、対話なしで完了します。

成功すると、処理の最後に以下のようなメッセージが表示されます。

Adding new https binding *:443:www.example.ac.jp
Certificate [IIS] ... created

.well-known/acme-challenge/ が配信できることを確認

filesystem検証では http://<ドメイン>/.well-known/acme-challenge/<トークン> にCAがアクセスします。このパスにHTTPSへの強制リダイレクトやアクセス制限が掛かっていると 404/失敗の原因になります。 （win-acme は拡張子なしの検証ファイルをIISが配信できるよう、一時的な web.config を自動配置します）

取得後の動作確認：

  • IIS マネージャーで対象サイトを開き、「バインド」を確認して HTTPS（ポート 443）のバインドが追加されていることを確認してください。
  • ブラウザで https://www.example.ac.jp/ にアクセスし、証明書エラーが表示されないことを確認してください。

5. 自動更新について

win-acme を使って証明書を取得すると、Windowsの 「タスクスケジューラ」 に証明書更新用のタスクが自動的に登録されます。

これにより、有効期限が近づくとバックグラウンドで自動的に更新プログラムが実行され、IISにバインドされている証明書も自動的に新しいものに差し替わります。

「完全放置」にはせず、最低限の監視を行ってください

自動更新は便利ですが、タスクの無効化、ネットワーク・ファイアウォール構成の変更、ポート80の閉塞、IIS設定の変更などにより、気づかないうちに更新が失敗していることがあります。更新失敗に気づかず証明書が失効すると、サイトが停止してしまいます。 最低限、証明書の有効期限を外形監視する（例: 「残り14日を切ったらアラート」を外部監視サービスやクラウドの監視機能で設定する）ことを強く推奨します。詳しくは 運用・管理のベストプラクティス を参照してください。

更新時の鍵について（--reuse-privatekey は使わないでください）

UPKI環境のCAは、同一の公開鍵での再発行を許可していません（更新のたびに新しい鍵ペアが必要です）。 win-acme はデフォルトで更新ごとに新しい秘密鍵を生成するため、特別な設定をしなくてもそのまま自動更新できます。 ただし、鍵を固定するオプション --reuse-privatekey を指定すると、更新時に「公開鍵が同一」エラーで失敗します。このオプションは指定しないでください。

手動でタスクスケジューラの設定を確認・変更したい場合は、Windows の管理ツールから「タスクスケジューラ」を開き、win-acme renew で始まる名前のタスクを確認してください。