ACME Conductor

発行された証明書の使い方
（ケース別）

ACME Conductor で発行された証明書を，実際のサービスやサーバで使うための解説です． まず「証明書をどこで使うか」を選び，該当するケースの節へ進んでください．

読者は 2 種類を想定しています．

証明書を発行するまでの手順は UPKI 証明書の発行手順（登録担当者向け）にあります．設定や仕組みの詳細は Runner 運用ガイドにあります．

証明書をどこで使いますか？

証明書を使う場所該当するケース
Azure App Service，Application Gateway，Front Door，API Managementケース A
Azure 上の仮想マシン，または Linux サーバ（nginx，Apache など）ケース B
Windows Server（IIS など）ケース C
手動でしか証明書を入れられない機器，ロードバランサ，外部のサービスケース D
他の部署や業者に証明書を渡すケース E

迷ったら，利用者に「そのホスト名のサイトは，どこで動いていますか」と聞きます．どのケースでも，秘密鍵の扱いには秘密鍵の取り扱いを守ります．

基本の知識

どこに保存されるか

発行された証明書と秘密鍵は，Azure の Key Vault に，証明書のオブジェクトとして保存されます．

更新のたびに「新しい版」ができる

証明書が更新されると，同じ名前の下に 新しい版（バージョン） が追加されます．古い版は消えずに読み取れる状態で残ります．したがって，利用側は「名前だけで指定して，常に最新の版を使う」ようにしておけば，更新に自動で追従できます．バージョンを固定して指定すると，更新後も古い証明書を使い続けてしまいます．有効期間は 89 日で，発行から約 59 日で更新されます．

PEM と PFX（pkcs12）の違い

Key Vault に保存される証明書には，2 つの形式があります．

形式中身向いている使い方
PEM証明書，中間証明書，秘密鍵を 1 つのテキストにしたものnginx や Apache など，自分でファイルを読むソフトウェア
PFX（PKCS #12）同じものをまとめたバイナリのファイル（パスワードなし）Azure の組み込みの連携（App Service など），Windows

どちらの形式で保存されるかは，証明書の登録時に選ぶ 保存先（store） の設定で決まります．デプロイ担当者に「この証明書は PEM ですか，PFX ですか」と確認してください．Azure の App Service，Application Gateway，Front Door，API Management のような組み込みの連携は PFX を必要とし，Front Door と API Management はさらに RSA の鍵（rsa2048 以上）を必要とします．これは，Runner 運用ガイドに記載された内容です．形式の切り替えは，Runner 側で保存先の設定を変え，次の実行で証明書が再発行されることで反映されます．登録担当者が単独で切り替えることはできません．

読み取りに必要な権限

秘密鍵は Key Vault の「シークレット」として読み出されます．読み取るには，Key Vault に対する secrets/get の権限（Azure RBAC の組み込みロールでは Key Vault Secrets User）が必要です．この権限を持つ人やサービスは，秘密鍵を読めることになるので，本当に必要なものだけに付与します．付与の可否と手続きはデプロイ担当者・Key Vault の管理者に相談してください．

ケース A: Azure の Web サービス

向いている場面: Azure の Web サービスで，独自ドメインの HTTPS を提供するとき．更新の追従を自動にできるので，最も手間がかかりません．

必要な権限・準備

手順の概要

  1. Azure ポータルで，対象のサービスの TLS/SSL（証明書）の設定を開きます．
  2. 「Key Vault から証明書を追加（インポート）」を選び，Key Vault と証明書の名前を指定します．
  3. 証明書のバージョンは 指定しない（「最新」を選ぶ，または版のない識別子を使う）．Application Gateway では，版のない識別子は https://<kv>.vault.azure.net/secrets/<証明書名> の形です．
  4. ホスト名（カスタムドメイン）に証明書を割り当てます．

更新時の扱い: 版を指定しなければ，新しい版が自動で取り込まれます．反映まで時間がかかることがあります（サービスごとに，数時間から 1 日程度）．正確な間隔は，各サービスの公式ドキュメントで確認してください．

注意

ケース B: Linux サーバ

向いている場面: Azure の仮想マシン，またはオンプレミスの Linux サーバで，自分で証明書ファイルを設定するとき．

必要な権限・準備

手順の概要

  1. サインインします（マネージド ID の場合）． 
    az login --identity
  2. 証明書（秘密鍵つき）を取得します．PEM の場合: 
    az keyvault secret download \
  --vault-name <kv> --name <証明書のオブジェクト名> \
  --file cert.pem --encoding utf-8
    PFX（pkcs12）の場合は --encoding base64 を付けます．できたファイルが PFX です． 
    az keyvault secret download \
  --vault-name <kv> --name <証明書のオブジェクト名> \
  --file cert.pfx --encoding base64
    ファイルに書かずに画面へ出すだけなら az keyvault secret show ... ですが，秘密鍵が画面に出るので，通常は使いません．
  3. PEM を，証明書チェーン（fullchain）と秘密鍵に分けます． 
    # 証明書と中間証明書（先頭が自分の証明書）
sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' cert.pem > fullchain.pem
# 秘密鍵
openssl pkey -in cert.pem -out privkey.pem
    PFX しかない場合は，PEM に変換します（パスワードは空です）． 
    openssl pkcs12 -in cert.pfx -passin pass: -nodes -out cert.pem
    Key Vault が返す PFX は 3DES と SHA-1 の MAC の形式で，OpenSSL 3 系でも -legacy なしで読めます．
  4. ファイルを配置し，権限を絞ります． 
    sudo install -m 644 fullchain.pem /etc/ssl/<ホスト名>/fullchain.pem
sudo install -m 600 privkey.pem   /etc/ssl/<ホスト名>/privkey.pem
rm -f cert.pem cert.pfx privkey.pem fullchain.pem   # 作業用のコピーは消す
    秘密鍵は 600（所有者だけが読める）にし，Web サーバを動かすユーザ以外に読ませないようにします．
  5. nginx（ssl_certificate と ssl_certificate_key）や Apache（SSLCertificateFile と SSLCertificateKeyFile）に，このファイルを設定し，設定を再読み込みします（sudo systemctl reload nginx など）．

更新時の扱い: 証明書は約 59 日ごとに変わります．手動では続かないので，自動化します．上の手順 1 から 5 を 1 本のスクリプトにして，systemd タイマーか cron で毎日 1 回実行します．

#!/bin/sh
# 概略．実際はエラー処理と，変更があったときだけ reload する処理を足す
set -eu
umask 077   # 秘密鍵を含む一時ファイルを他のユーザに読ませない
az login --identity --output none
az keyvault secret download --vault-name <kv> --name <証明書のオブジェクト名> \
  --file /tmp/cert.pem --encoding utf-8
# 分割，配置（600），一時ファイルの削除
# 新しい証明書と前回の証明書が違うときだけ reload

Azure や Azure Arc の仮想マシンでは，スクリプトを自作する代わりに，Key Vault の仮想マシン拡張機能（Linux 版と Windows 版があります）を使う方法もあります．Key Vault の証明書を仮想マシン上のファイルとして自動で更新する機能です．自動化の第一候補ですが，設定の細かい点は Microsoft の公式ドキュメントで確認してください．

注意

ケース C: Windows Server

向いている場面: Windows Server の IIS などで HTTPS を提供するとき．

必要な権限・準備: 証明書を PFX の形で取得できること．PFX（pkcs12）で保存されていれば，そのまま取得できます．PEM で保存されている場合は，取得した PEM を変換します．

openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out cert.pfx

（ケース B の手順 3 で PEM を分けてから行います．パスワードの入力を求められます．そのパスワードは，インポートのときに使います．）

手順の概要

  1. PFX を取得します（ケース B の az keyvault secret download ... --encoding base64 を使えます）．
  2. サーバ管理者が，証明書を「ローカルコンピューター」の「個人」ストア（LocalMachine\My）にインポートします．PowerShell の例: 
    Import-PfxCertificate -FilePath .\cert.pfx `
  -CertStoreLocation Cert:\LocalMachine\My
    （パスワード付きの PFX のときは，-Password も指定します．）
  3. IIS マネージャーで，対象サイトの「バインド」を開き，HTTPS のバインドに，インポートした証明書を選びます．
  4. 作業用に置いた PFX ファイルは，インポート後にすぐ削除します．

更新時の扱い: 約 59 日ごとに，上の作業をやり直す必要があります．手動は忘れやすいので，自動化します．Azure（または Azure Arc）の仮想マシンなら，Key Vault の仮想マシン拡張機能（Windows 版） で，証明書を自動で LocalMachine\My に反映できます．ただし IIS のバインドが新しい証明書に切り替わるかは，設定によります．公式ドキュメントで確認してください．

注意: 秘密鍵つきの PFX は，メールやチャットで送らないでください．

ケース D: 手動でしか入れられない機器

向いている場面: ロードバランサ，VPN 装置，ネットワーク機器，外部のサービスなど，管理画面から証明書ファイルをアップロードする方式の機器．

必要な権限・準備: Key Vault から証明書を取得する権限を持つ人が，ダウンロードします．PEM と PFX のどちらを受け付けるかは，機器のマニュアルで確認し，必要ならケース B・C の方法で変換します．

手順の概要

  1. Key Vault から証明書をダウンロードする（ケース B の az keyvault secret download，または Azure ポータルの Key Vault の画面）．
  2. 機器の管理画面で，証明書（と，必要なら中間証明書と秘密鍵）をアップロードする．
  3. ダウンロードしたファイルを，作業が終わったら削除する．

更新時の扱い: 更新のたびに，手動で同じ作業を繰り返す 必要があります．証明書は約 59 日で更新され，89 日で期限が切れます．次のどちらかをしておきます．

注意: 期限が切れるとサイトが「安全でない」と表示されます．担当者が異動しても続けられるように，作業手順書を残してください．

ケース E: 他部署・業者に渡すとき

向いている場面: 運用を外部の業者や他部署に任せていて，その担当者が証明書をサーバに入れるとき．

必要な権限・準備・手順の概要

更新時の扱い: 相手は更新のたびに，上のケース B〜D のどれかで取得し直します．自動化してもらうのが理想です．更新の日の目安（約 59 日ごと）を伝えておきます．

注意: 権限は，契約の終了や担当者の異動のときに，忘れずに削除します．

秘密鍵の取り扱い

更新されたか確かめる

更新は約 59 日ごとです．新しい証明書が実際に使われているかは，次の方法で確かめます．

サーバに反映されていないときは，該当するケースの「更新時の扱い」（再読み込み，インポートのやり直しなど）を見直します．