用語の一言定義
- 中間CA: 組織内で証明書を発行する中間の認証局。ルートCAとクライアントの間を仲介します。
- CSR: Certificate Signing Request（証明書署名要求）。公開鍵と識別情報を含む署名依頼データです。
- PKCS12: 秘密鍵と証明書を一つのファイルにまとめるフォーマット。
この記事の目的と対象読者
- 目的: WiKIDサーバを初期稼働させ、内部で使用する証明書チェーンを安全に作成・導入すること。
- 対象: サーバ管理者、セキュリティ担当者、インフラエンジニア。
目次
- 初期インストール画面の概要
- 証明書チェーンの設定概要
- ステップ1: 中間CAの生成
- ステップ2: CSRの送付
- ステップ3: 証明書のインストール
- ステップ4: localhost証明書の生成
- ステップ5: wAuthサーバの再起動
- ロール別チェックリスト
- SOP（簡易手順まとめ）
- トラブルシューティングと原因別対処
- セキュリティ強化のヒント
- 受け入れ基準
- 1行用語集
- 要点まとめ
初期インストール画面の概要
WiKID認証サーバの初期設定は比較的短時間で完了します。主要な流れは:
- 中間CAの作成
- CAのインストール
- localhost用証明書の作成
- プロトコルモジュールの有効化
- ドメイン、ネットワーククライアント、ユーザの追加
Figure 3 - 初期管理ページのスクリーンショット
重要: 証明書は秘密鍵と対になって初めて有効です。秘密鍵は必ず安全に保管してください。
証明書チェーンの設定概要
WiKIDシステムは内部で証明書認証を複数の重要な目的で使用します:
- 各認証サーバは中間証明書局（中間CA）でもある
- 各認証サーバは、ネットワーククライアントの識別と認可に証明書を使用する
これらの機能を有効にするため、サーバが本稼働する前に証明書を生成し、署名された証明書をインストールする必要があります。これらはサーバの管理インターフェースから操作します。管理画面の「Creating an Intermediate CA」タブに移動してください。
ステップ1: 中間CAの生成
中間CAを作る最初の作業は、公開鍵/秘密鍵ペアを生成し、サーバ識別用のCSR（Certificate Signing Request）を作成することです。WiKIDは出荷時にWiKIDコーポレートCA証明書を同梱していますが、あなたの環境用の中間CA鍵は独自に生成します。
Figure 4 - 中間証明書局作成画面
フォームはCSR生成に必要な情報を集めます。すべてのフィールドが必須です。
フィールド説明
- Intermediate CA Administrator Email: 署名済み証明書送付先の連絡先メール。稼働中の有効なメールアドレスを指定してください。
- Servers Fully Qualified Domain Name: サーバのDNS上の正式登録名。SSLクライアントはここで指定された名前と接続時のホスト名が一致することを期待します。
- Organization Unit: 部署名（識別用）。
- Organization Name: 会社名。WiKID側の発行処理を速めるため、販売/評価ユニットの記録と一致させてください。
- Locality: 市区町村名。
- State: 州または都道府県名（略さない）。
- Country Code: 国の2文字コード（例: US）。
- Passphrase: 生成される秘密鍵をPKCS12で保護するためのパスフレーズ。サーバ起動時にこの値が必要になります。どこにも保存されないため、忘れないように強力で覚えやすいパスフレーズを選んでください。
「Generate」を選択すると鍵とCSRが作成され、CSRはbase64 DERエンコード形式で表示されます。テキストボックス内の全テキストを選択してクリップボードにコピーします。
Figure 5 - CSR画面
重要: パスフレーズは復元できません。紛失した場合は手順を最初からやり直してください。
ステップ2: CSRの送付
CSRをWiKID Systems CAに送付して署名を依頼します。管理画面内のリンク（例: https://www/wikidsystems.com/wikid/newcertreq.jsp）をクリックして、CSR提出ページに進みます。
Figure 6 - CSR提出画面
CSRテキスト（—-で囲まれたBEGIN/ENDを含む）を貼り付けて送信します。処理中の追跡用にリクエスト番号が発行され、WiKID CA管理者に通知が行きます。通常、処理は1営業日未満で完了しますが、環境によって変わることがあります。
Figure 7 - CSR受付画面
署名が完了すると、指定した管理者メールアドレスに署名済み証明書が送付されます。送付される証明書は次のようなPEMブロックになります。
Figure 8 – 証明書ブロック
注記: 証明書は秘密鍵と対で有効になります。メールクライアント（OutlookやGmail）はテキストをUTF-8変換することがあります。必ずプレーンテキストで切り取り・貼り付けしてください。
ステップ3: 証明書のインストール
署名済み証明書を受け取ったら管理画面の「Install Intermediate CA」タブに戻り、Installオプションを選んで証明書を導入します。
Figure 9 – 証明書インストール画面
メールで受け取った証明書テキストをテキストエリアに貼り付け、ステップ1で設定したパスフレーズを入力してインストールします。エラーが出た場合は:
- パスフレーズが正しいか再確認
- 貼り付けがプレーンテキストになっているか確認
- パスフレーズを忘れた場合はステップ1からやり直し
ステップ4: localhost証明書の生成
認証サーバと直接通信するシステム（ローカルのプロトコルモジュールやサービス）は、サーバが発行した有効な証明書を必要とします。ローカルサービス用の証明書はFQDNに「localhost」を指定して作成してください。名前は必ず「localhost」である必要があります。
Figure 10 – 証明書生成画面
フォーム項目の意味
- Client’s Fully Qualified Domain Name: クライアント接続時にサーバが解決する名前。ローカルサービスでは「localhost」と指定。
- Organization Name: クライアントを運用する組織名。
- Locality: 市区町村名。
- State: 州または都道府県名。
- Country Code: 国の2文字コード。
- Client PKCS12 Passphrase: 生成されるクライアント証明書を保護するパスフレーズ。
- Passphrase again: 確認入力。
- Server Keystore Passphrase: ステップ1で作成した中間CAのキーストア用パスフレーズ。
「Generate」を選ぶとPKCS12形式の配布位置が表示され、ローカル用なら自動的に適切な場所にインストールされます。
Figure 11 – PKCS配布画面
ステップ5: wAuthサーバの再起動
rootで認証サーバにログインし、次を実行してサービスを再起動します。
wikidctl restart再起動時にwAuthパスフレーズの入力を求められます。これはステップ1で設定した中間証明書のパスフレーズです。正しいパスフレーズを入力すると、サーバは新しい証明書をクライアント認証に使用します。
パスフレーズ入力を毎回避けたい場合は、次のファイルを作成して自動化できます（リスクを理解した上で使用してください）。ファイル: /etc/WiKID/security 内容1行:
WAUTH_PASSPHRASE=yourpassprase注意: このファイルにパスフレーズを保存すると、ローカルシステムにアクセスできる者がパスフレーズを入手できるリスクがあり、セキュリティ方針によっては禁止される場合があります。
ロール別チェックリスト
管理者（初期設定担当）:
- 中間CAのCSRを生成したか
- 有効な管理者メールを設定したか
- 中間CAのパスフレーズを安全にバックアップしたか
- 証明書をインストールしたか
運用担当（継続管理）:
- localhost証明書が生成され、所定の場所にインストールされているか
- サービス再起動後、認証フローが正常に動作するか確認したか
- 証明書の有効期限管理と更新計画を作成したか
監査/セキュリティ担当:
- 秘密鍵の権限と保管場所を検査したか（厳格なファイルパーミッション）
- WAUTH_PASSPHRASEの自動化ファイルの存在をレビューしたか
- 鍵・証明書のローテーション手順を確認したか
SOP（簡易手順まとめ）
- 管理画面で中間CAを生成し、CSRを取得する。
- CSRをWiKID CAに送付して署名を依頼する。
- 署名済み証明書を受け取ったら管理画面からインストールする。
- localhost専用のクライアント証明書を生成する。
wikidctl restartを実行してサービスを再起動し、新しい証明書を適用する。
チェックポイント: 各ステップでプレーンテキスト貼り付け、正しいパスフレーズ入力、メールで受け取った証明書の整合性を確認する。
トラブルシューティングと原因別対処
症状: 証明書インストール時にエラーが出る。
- 対処: パスフレーズが間違っている可能性があります。パスフレーズを思い出せない場合は、ステップ1から鍵とCSRを再生成してください。
症状: クライアントがサーバ接続時にホスト名不一致で拒否される。
- 対処: サーバのFQDNと証明書のCN（またはサブジェクト代替名）が一致しているか確認してください。localhost用に作成した証明書はローカルプロセス専用です。
症状: 署名済み証明書がメールで届かない。
- 対処: CSR送付時に入力した管理者メールアドレスを確認し、迷惑メールを含めて受信を確認してください。処理時間は通常1営業日程度ですが、遅延がある場合はWiKIDサポートに問い合わせてください。
症状: サービス再起動時に秘密鍵パスフレーズを入力しても新証明書に切り替わらない。
- 対処: インストールした中間CA証明書とキーストアが正しい場所にあるか確認してください。ログファイルに詳細なエラーが出力されている可能性が高いです。権限不足のためにキーストアが読めない場合もあります。
ログ確認のポイント:
- /var/log/wikid またはシステムジャーナルでエラーを検索
- 権限エラー（Permission denied）やファイル未検出（No such file）を重点的にチェック
セキュリティ強化のヒント
- 秘密鍵のファイルパーミッションを最小に設定（例: 600）し、所有者をサービス専用ユーザにする。
- PKCS12パスフレーズは複雑にし、共有アカウントでの共有は避ける。
- WAUTH_PASSPHRASEをファイルで保存する場合は、ファイル自体のアクセス制限を監査ログで監視する。
- 証明書の有効期限を把握して自動更新スケジュールを組む。更新を忘れるとサービス停止につながる。
- 鍵ローテーション計画を文書化し、定期的にリハーサルを行う。
リスクと緩和策:
- リスク: 端末やメール経路でのテキスト変換により証明書が破損する。
- 緩和: PEMブロック全体をプレーンテキストでコピー＆ペーストし、改行や追加空白を確認する。
- リスク: パスフレーズの紛失。
- 緩和: 重要鍵は安全なパスワード管理ソリューション（企業向けのシークレットストア）で保管する。
受け入れ基準
- 中間CAが生成され、CSRがWiKID CAに提出され、署名済み証明書を受領してインストール済みであること。
- localhost用クライアント証明書が生成され、ローカルプロトコルモジュールがそれを使用して接続できること。
- サービスを再起動し、ログに致命的エラーが出ないこと。
- 管理者が中間CAのパスフレーズを安全にバックアップしていること（秘密管理方針に従う）。
受け入れテスト例:
- 管理者はサーバに対してLDAP、wAuth、他のモジュールを使い、認証フローが通ることを確認する。
- ログに証明書チェーンの不整合や鍵読み込み失敗が記録されていないことを確認する。
1行用語集
- CSR: 証明書署名要求。公開鍵と識別情報をまとめた署名申請データ。
- PKCS12: 秘密鍵と証明書をまとめたファイル形式。
- 中間CA: 組織内で証明書を発行する認証局。
追加の考慮事項と代替手順
オンプレミス環境で内部CAを使用する場合は、ルートCAの信頼チェーンと配布方法を事前に設計してください。複数のサイトやDR（ディザスタリカバリ）を持つ場合は、各サイトに中間CAを配置するか集中管理にするかを検討してください。
小規模なテスト環境では自己署名証明書で進めることも可能ですが、本番では必ず組織内CAまたは信頼できる公開CAで署名された証明書を使用してください。
まとめ
- WiKIDの初期設定は中間CAの生成、CSRの送付、署名済み証明書の導入、localhost証明書の発行、サービス再起動の順に行います。
- パスフレーズ管理とプレーンテキストでの貼り付けが成功の鍵です。
- ロール別チェックリストや受け入れ基準を活用して、作業ミスとセキュリティリスクを最小化してください。
重要: 証明書と秘密鍵は常に対で扱い、秘密鍵の管理に細心の注意を払ってください。
要点まとめ:
- 中間CAと証明書はサーバの認証・暗号化に不可欠です。
- CSRを正しく生成してWiKID CAに送付します。
- 受領した署名済み証明書はプレーンテキストでインストールします。
- 生成した秘密鍵のバックアップと厳格なアクセス制御を実施します。
