UPKI 証明書の発行手順
（登録担当者向け）

この文書の対象と，終わったときの状態

• 対象: UPKI 登録担当者として，サーバ証明書の申請を取りまとめている方．
• 終わったときの状態: 申請した名前（ホスト名）の証明書が，Azure の Key Vault（証明書の保管場所）に入っています．その後は，期限が近づくと ACME Conductor が自動で更新するので，担当者が毎回申請し直す必要はありません．
• 発行された証明書を実際のサーバでどう使うかは，発行された証明書の使い方（ケース別）を読んでください．
• 所要時間の目安: 作業そのものは，慣れれば 1 時間程度です．ただし UPKI の審査に数日かかることがあるので，全体では数日から 1 週間程度を見込んでください．

ACME Conductor の画面には，画面上部のバーに 日本語 / English の切り替えがあります．このページでは日本語表示の名前で説明します．

全体の流れ（1 画面で）

手順 3 の審査を待っている間に，手順 4 を進めておけます．手順 5 以降は，EAB を受け取り，DNS の設定を確認できてから行います．

はじめに知っておくこと

• 証明書と秘密鍵: 証明書は「このサーバは本物です」という身分証明書のようなもので，秘密鍵はその持ち主だけが持つ鍵です．この 2 つは必ず組で使い，秘密鍵は他人に見せてはいけません．
• UPKI ACME と EAB: ACME は，証明書を自動で発行してもらうための決まりです．UPKI ACME では，最初に「この申請の担当はこの人」と結び付けるための合言葉を使い，これを EAB（Key ID と HMAC Key の 2 つの文字列）と呼びます．EAB は審査の後で UPKI から発行され，パスワードと同じくらい大切なものです．
• ACME Conductor が代わりにやること: 証明書の発行，期限が近づいたときの更新（証明書の有効期間は 89 日で，発行から約 59 日で自動更新に入ります），保管場所への保存です．担当者が更新のたびに操作する必要はありません．
• DNS の CNAME 委任（なぜ必要か）: 証明書を発行してもらうには，そのホスト名が自分たちのものだと証明する必要があります．そのために DNS に一時的な確認用の記録を置きます．ACME Conductor が組織の本番の DNS を直接書き換えないように，確認用の記録は専用の場所（チャレンジ用ゾーン）に置くことにします．そこで，本番の DNS には「確認用の記録は専用の場所を見てください」という案内（CNAME という種類の記録）を 1 回だけ書いておきます．これを 委任 と呼びます．
• Key Vault（証明書の保管場所）: Azure にある，証明書や鍵を安全にしまっておく金庫のようなサービスです．発行された証明書と秘密鍵はここに保存されます．ACME Conductor 自体は秘密鍵を持ちません．

事前に用意するもの

• ☐ ACME Conductor の URL（以下 <Conductor の URL>）と，サインインできるアカウント．URL とアカウントは，デプロイ（構築・運用）を担当する方に確認します．
• ☐ UPKI 証明書発行支援システムの登録担当者画面にログインできること．
• ☐ 利用者から聞く情報．少なくとも次の 3 つです．
  • ホスト名（例: www.example.ac.jp）．メインの 1 つと，追加の名前（最大 7 個）．
  • 用途（Web サイト，メールなど）．
  • どこで使うか（Azure のサービスか，サーバか，機器か）．発行された証明書の使い方の「証明書をどこで使いますか？」を見て，該当するケースを聞いておくと，後で慌てません．
• ☐ DNS を変更できる人．自分でできない場合は，依頼先の担当者（手順 4 の依頼文の例を使います）．
• ☐ 発行できるドメインの範囲と，名前の数の上限．デプロイ担当者に，「許可するドメイン（例: example.ac.jp）」と「1 枚の証明書に入れられる名前の数」を聞いておきます．範囲の外の名前は発行できません（手順 1）．
• ☐ チャレンジ用ゾーンの名前（以下 <チャレンジ用ゾーン>）．これもデプロイ担当者に確認します．

手順

手順 1. ホスト名を決め，前提を確かめる

目的: 申請する名前の一覧を確定します．後から変えると UPKI 側で手続きがやり直しになるので，最初に慎重に決めます．

操作

1. 利用者と相談して，メインのホスト名（UPKI の「利用管理者 FQDN」，証明書の CN になる名前）を 1 つ決めます．
2. 追加のホスト名（UPKI では dNSName）を決めます．メインを含めて最大 8 個です．
3. * を使う名前（ワイルドカード）は使いません．
4. すべての名前が，デプロイ担当者から聞いた「許可するドメイン」の下にあるか確認します．外れているときは，デプロイ担当者に設定の変更を頼みます（GUI からは変えられません）．

確認: 名前の一覧をメモに書き出し，数が上限以内で，すべて許可するドメインの下にあることを確かめます．

手順 2. TSV を作る

目的: UPKI に出す申請用のファイル（TSV）を作ります．

操作

1. UPKI TSV 作成ツールを開きます．
2. 「ACME 利用情報作成申請」の TSV を作ります．利用管理者 FQDN に手順 1 のメインのホスト名を，dNSName に残りの名前を入れます．
3. 証明書プロファイルを選びます．選んだプロファイル（RSA かどうか，鍵の長さ）をメモしておきます． 手順 5 で使います．

確認: 作成した TSV の名前の一覧が，手順 1 のメモと同じです．

手順 3. TSV を提出し，EAB を受け取る

目的: 審査を通して EAB（Key ID と HMAC Key）を受け取ります．

操作

1. UPKI 証明書発行支援システムの登録担当者画面にログインし，TSV をアップロードします．
2. 審査を待ちます．数日かかることがあります．この間に手順 4 を進めます．
3. 審査が済むと EAB（Key ID と HMAC Key）が発行されます．手元の安全な場所に，手順 7 まで一時的に控えてください．

確認: Key ID と HMAC Key の 2 つの文字列が手元にあります．

手順 4. DNS に CNAME を設定してもらう

目的: 各ホスト名の「確認用の記録は専用の場所を見てください」という案内を，本番の DNS に書いてもらいます．

操作

1. 名前ごとに 1 つずつ，次の CNAME の記録が必要です．<ホスト名> に手順 1 の名前を，<チャレンジ用ゾーン> にデプロイ担当者から聞いた名前を入れます．

   _acme-challenge.<ホスト名>.  IN CNAME  <ホスト名>.<チャレンジ用ゾーン>.

   例: www.example.ac.jp の場合

   _acme-challenge.www.example.ac.jp.  IN CNAME  www.<チャレンジ用ゾーン>.

   右側の名前は，他の名前と重ならなければ何でも構いません．チャレンジ用ゾーンの中に，事前に何かを作る必要はありません．
2. DNS を自分で変更できないときは，DNS の管理者に次の依頼文を送ります．

   件名: DNS への CNAME レコード追加のお願い（証明書の自動発行のため）

   お疲れさまです．UPKI の証明書を自動発行する仕組みを使うため，次の CNAME レコードを追加してください．他のレコードの変更は不要です．

   • 種類: CNAME
   • 名前: _acme-challenge.<ホスト名 1>
   • 値: <ホスト名 1>.<チャレンジ用ゾーン>

   （名前ごとに 1 行ずつ）

   • <ホスト名 2> についても同様に，……

   追加の希望日: ○月○日まで（審査結果が出る前に済んでいると助かります）
   追加後は，お知らせください．

3. 設定が済んだら，すべての名前について 確かめます（次の「確認」）．

確認

• コマンドが使える場合（Mac のターミナルや Linux）:

  dig +short CNAME _acme-challenge.<ホスト名>

  <ホスト名>.<チャレンジ用ゾーン>. のように，チャレンジ用ゾーンの中の名前が表示されれば成功です．何も表示されなければ，まだ設定されていません．
• コマンドが使えない場合: DNS を調べる Web サービス（「DNS lookup」などで検索できます）に _acme-challenge.<ホスト名> を入れ，種類に CNAME を選んで調べます．結果がチャレンジ用ゾーンの名前ならば成功です．DNS の設定が世の中に広がるのに，数分から数時間かかることがあります．

手順 5. 発行ポリシーを用意する

目的: 「どのドメインまで，どんな鍵で，期限の何日前に更新するか」というルールを決めます．すでに UPKI 用のポリシーがあり，条件が合うときは，この手順は飛ばして手順 6 に進みます．

操作

1. ブラウザで <Conductor の URL> を開き，サインインします．
2. メニューの「発行ポリシー」を開き，既存のポリシーを確認します．一覧には名前が表示されます．次の条件が合っていればそれを使います．合わなければ，新しいポリシーを作ります．
   • 許可するドメイン: 手順 1 の名前がすべてその下にある．
   • 鍵の種類: 手順 2 のプロファイルに合っている．RSA なら rsa2048．
   • ホスト名の最大数: 手順 1 の名前の数以上（UPKI は最大 8）．
   • 期限の何日前に更新するか: 通常は 30（約 59 日で更新に入ります）．
   • ワイルドカードは許可しない．
   • 接続先（binding）: UPKI のもの（upki などの名前．デプロイ担当者に確認）．
   • 名前: 後で選びやすい名前を付ける（例: 「UPKI 本番」）．他のポリシーと同じ名前は付けられません．
3. 新しく作るときは，「発行ポリシーを追加」を押し，上の値（名前を含む）を入れて「有効」にチェックを入れ，「発行ポリシーを追加」ボタンで保存します．

確認: ポリシーの一覧に，付けた名前で表示されます．

手順 6. 証明書（target）を無効の状態で追加する

目的: ACME Conductor に「この名前の証明書を管理してください」と登録します．まだ EAB を登録していないので，無効の状態で作ります．

操作

1. メニューの「証明書」を開き，「証明書を追加」を押します．
2. 次のように入力します．
   • 主たるホスト名（FQDN）: 手順 1 のメインのホスト名．作成後は変更できません．
   • 追加のホスト名（SAN）: 残りの名前を 1 行に 1 つ．
   • 発行ポリシー: 手順 5 で付けた名前（例: 「UPKI 本番」）のポリシーを選ぶ．
   • 実行の接続先，DNS の接続先，保存先（store）: 他の証明書と同じ値でよいのが普通です．分からなければデプロイ担当者に聞いてください．保存先（Key Vault）の種類が，証明書の形式（PEM か PFX）を決めます．詳しくは使い方の文書を見てください．
   • 有効: チェックを外します．
3. 画面下の「証明書を追加」ボタンを押します．

確認: 証明書の一覧に，無効の状態で表示されます．

手順 7. EAB を登録し，発行できたか確かめる

目的: EAB を登録して，証明書を実際に発行します．

操作

1. 手順 6 で作った証明書の詳細ページを開き，「ACME アカウント」の節を探します．
2. 手順 3 の Key ID と HMAC Key を入力し，「EAB を登録（世代 1）」を押します．入力した内容はブラウザの中で暗号化されて送られ，登録後は画面に表示されません．
3. ページ上部の「有効にする」を押します．有効にした時点で自動的に発行が始まります．ページ上部の「次にやること」の案内にも，その時点ですべきことが表示されます．
4. 「実行履歴」を開いて，実行（run）の状態を見ます．「実行中」から「成功」になれば完了です．数分かかることがあります．

確認

• 実行が「成功」になっている．
• 「ACME アカウント」の節に世代 1 が「使用中」と表示されている．
• 詳しい確認は次の発行できたか確かめるを見てください．

発行できたか確かめる

1. 「証明書」の一覧で，該当の証明書の「証明書の有効期限」の列に日付が入っています．有効期間は 89 日なので，今日から約 89 日後になっているはずです．一覧が長いときは，表の上の絞り込み欄にホスト名の一部を入力すると，該当の行だけが残ります（空白で区切ると，すべての語を含む行に絞れます）．
2. 証明書の詳細ページの「証明書」の行に，保存先のオブジェクト名（<ホスト名を - でつないだもの>-<16 桁の英数字> の形）が表示されます．これが Key Vault の中での証明書の名前です．使い方の文書で必要になるので，利用者やサーバ管理者に伝える名前として控えておきます．
3. 管理者の許可があれば，Azure ポータルの Key Vault で「証明書」を開き，その名前があることを確かめられます．

証明書を実際に使うところ（Web サイトなど）へ反映する手順は，発行された証明書の使い方（ケース別）にあります．

うまくいかないとき

画面の実行履歴に出る失敗の表示と，その意味です．どれも，画面には英語のエラーコードがそのまま表示されます．

AcmeFailure の理由の詳細（UPKI からの応答）は，今のところ画面には出ません．実行にかかった時間と，直前にやった操作から見当をつけます．詳しい切り分けは運用ガイドの「失敗の読み方」にあります．

その後の運用

• 自動更新: 発行から約 59 日で，ACME Conductor が自動的に更新します．担当者が通常やることはありません．更新のたびに Key Vault に新しい版が追加されます．
• 担当者が見ること: 月に 1 回ほど，証明書の一覧の期限の列を見て，期限が近い（たとえば 30 日を切った）のに更新されていないものがないか確認します．実行が失敗し続けている証明書があれば，上の表で原因を調べます．更新が失敗し続けても，証明書が切れるまで 30 日の余裕があります．
• サーバ側の作業: 証明書が更新されても，使う側が新しい証明書を読み込まないと古いままです．自動で追従するかどうかは使い方によって違います．発行された証明書の使い方を見てください．
• 不要になった証明書（テスト用など）: 使わなくなった証明書は，詳細ページで先に「無効にする」を押し，そのあと「退役させる」で片付けられます（FQDN を入力して確認します）．退役させると，一覧から消えて（「退役済みも表示」にチェックを入れると見えます），実行履歴と操作記録は残り，ホスト名は別の証明書として登録し直せます．ただし 元には戻せません．また Key Vault の証明書は削除されず，更新もされないので，期限が来ると切れます．Key Vault から消したいときは，Key Vault の管理者に頼みます．
• 担当者の異動: EAB を使うのは最初の登録だけなので，異動のときに EAB の引継ぎは要りません．Conductor にサインインできる人を変えたいときは，デプロイ担当者に頼みます．

名前を変えるとき

ホスト名を足す・減らす，またはメインのホスト名を変えるときは，UPKI 側の手続きと Conductor 側の操作の順序が決まっています．手順は運用ガイドの「名前を変える」にあります．そのとおりに進めてください（特にメインのホスト名は，証明書の追加からやり直しになります）．

用語集