企業や組織でMicrosoft Dynamics CRM 2016をオンプレミス環境で運用していると、ワイルドカード証明書の更新は避けて通れない作業です。しかし、前任者が退職して手順書やノウハウが失われると、どこから手を付ければよいか分からなくなることもあるでしょう。本記事では、Dynamics CRM 2016とADFSをクレームベース認証で連携させている環境において、新しく取得したワイルドカード証明書を安全かつ確実に適用するための手順やポイントを、分かりやすく解説します。
Dynamics CRM 2016環境におけるワイルドカード証明書の重要性
ワイルドカード証明書は、同一ドメイン下の複数サブドメインを一枚の証明書でカバーできる利便性から、多くの企業で採用されています。特にDynamics CRMのオンプレミス環境では、IIS上のHTTPS通信を保護するだけでなく、ADFSとの連携によるシングルサインオンやクレームベース認証でも証明書が必要になるため、証明書管理は運用上の大きな課題となります。
既存証明書の有効期限切れがもたらすリスク
ワイルドカード証明書が期限切れになると、次のような影響が考えられます。
- Dynamics CRMへのHTTPSアクセス時にブラウザでセキュリティ警告が表示される
- ADFSを経由した認証エラーが発生し、CRMにログインできなくなる
- 顧客やユーザーに不審感を与え、ビジネス上の信頼を損ねる
このような事態を回避するためにも、証明書の更新手順を明確化しておきましょう。
自己署名証明書とパブリックCA証明書の違い
ワイルドカード証明書には、大きく分けて以下の二種類が存在します。
- 自己署名証明書（内部CA）: 社内のActive Directory 証明書サービスなどによって発行される証明書。社内ネットワークだけで利用するケースで費用を抑えられるメリットがあるが、外部からのアクセスで「信頼されない証明書」と警告が表示される可能性がある。
- パブリックCA証明書: グローバルサイン、DigiCert、セコムなどの公的な認証局から発行される証明書。外部アクセス時にもブラウザやOSが標準的に信頼するため、警告なく安全に通信を行える。
証明書更新に先立って確認すべきポイント
証明書の更新に着手する前に、以下の点を確認しておきましょう。
現在の証明書情報の把握
まずは現在のDynamics CRM環境とADFSで利用されている証明書の情報を確認します。Windowsサーバー上でIISマネージャーを開き、「サーバー証明書」画面から「発行者」や「発行先(Subject)」「有効期限」「シリアル番号」などをチェックしましょう。
また、ADFS管理コンソールの「サービス」→「証明書」画面でも、サービス通信証明書やトークン署名証明書が何になっているかを必ず確認しておきます。
更新手順やドキュメントの有無
前任者が残したドキュメントやメモが少しでも残っていないか、社内ファイルサーバーやメールアーカイブ、ITポータルサイトなどを探してみるのもおすすめです。特に、過去にどの認証局を使っていたかや、どのような設定を施したかが分かれば、更新作業の手間を大幅に減らせるでしょう。
組織のセキュリティポリシー
証明書の作成や更新を行う際、組織のセキュリティポリシーにより、鍵長(2048bitや4096bitなど)やハッシュアルゴリズム(SHA256など)に関する制約がある場合があります。事前にセキュリティ担当部門や情報システム部門と連携し、適切な設定値を確認しておきましょう。
自己署名（内部CA）でワイルドカード証明書を作成・更新する手順
内部CAを利用する場合、社内のActive Directory 環境下で運用される「Active Directory 証明書サービス」を使用し、IIS上から証明書要求ファイルを作成するのが一般的です。以下の流れで進めます。
1. IISマネージャーで証明書要求の作成
IISマネージャーを立ち上げ、左ペインで対象となるサーバーを選択し、「サーバー証明書」をクリックします。その後、右ペインに表示される「操作」項目の中から「証明書要求の作成」を選択します。
次のような画面が表示されるので、各項目を入力してください。
| 項目 | 例 | 説明 |
|---|---|---|
| Common Name | *.example.com | ワイルドカード証明書であれば「*.ドメイン名」を指定 |
| Organization | Example Corporation | 企業名 |
| Organizational Unit | IT Department | 組織内の部署名など |
| City/Locality | Tokyo | 所在地（市区町村） |
| State/Province | Tokyo | 都道府県 |
| Country/Region | JP | 国コード（日本の場合はJP） |
| Cryptographic Service Provider | Microsoft RSA SChannel Cryptographic Provider | 通常はデフォルトを選択 |
| Bit Length | 2048または4096 | 組織のポリシーに従って決定 |
入力が完了すると、証明書要求ファイル(.reqや.txt)を保存するよう求められます。後の手順で内部CAに提出するため、分かりやすいフォルダに保管しておきましょう。
2. 内部CAサーバーでの証明書発行
保存した証明書要求ファイルを内部CAが動作するサーバーの証明書発行ポータルなどにアップロードし、発行をリクエストします。GUIのコンソールから直接要求を承認するケースもありますが、多くの場合はWebの証明書発行ページやMMCスナップイン経由で操作することが多いでしょう。
要求が承認されると、新しいワイルドカード証明書（.cerなど）がダウンロード可能となります。
3. IISへの新しい証明書のインポート
再びIISマネージャーを開き、「サーバー証明書」画面で「証明書のインポート」を選択し、ダウンロードした新証明書を取り込みます。
インポート後、一覧に追加された証明書をダブルクリックし、サブジェクト名や有効期限、発行元などを再度チェックし、想定通りの内容になっているか確認してください。
パブリックCAからワイルドカード証明書を取得・更新する手順
外部からのアクセスが多い場合は、グローバルサインやDigiCert、セコムなどのパブリックCAが発行する証明書を使うケースが一般的です。ドメイン所有権の検証が必要ですが、ブラウザで標準的に信頼されるメリットは大きいでしょう。
1. ワイルドカード証明書の申請
まずはパブリックCAのウェブサイトから、ワイルドカード証明書を購入または更新の手続きを行います。その際、CSR（証明書署名要求）を準備する必要があります。CSRは自己署名証明書と同様にIISマネージャーで作成可能です。
ドメイン所有者であることを証明するための手続きが必要です。DNSレコードに指定されたTXTレコードを追加する、もしくは特定のメールアドレス宛に送られる確認メールに返信するなど、認証局の指定する手順に従ってください。
2. 中間証明書のチェーンを含むファイルの受け取り
認証局からは、サーバー証明書だけでなく、中間証明書やルート証明書のチェーンを含む複数のファイルが提供されることがあります。これらを正しくインポートしないと、ブラウザで「発行元が信頼できません」というエラーが表示されることがあります。
IISで証明書をインストールする前に、Windowsサーバーの「中間証明機関」ストアなどに中間証明書をインストールしておくとスムーズです。
3. 新しい証明書のIISへのインポート
IISマネージャーを開き、「サーバー証明書」→「インポート」から、発行されたサーバー証明書を取り込みます。パブリックCAの場合は.p7b形式や.pem形式で提供されるケースもあるため、拡張子に合わせてインポート方法を選択しましょう。
インポートに成功すると、サーバー証明書一覧に新しいワイルドカード証明書が表示されます。
Dynamics CRMおよびADFSへの新証明書適用の流れ
証明書をサーバーにインポートしただけでは、CRM環境やADFSが新しい証明書を利用しません。設定の反映やサービスの再起動が必要となります。
1. Dynamics CRMサイトのバインド設定
- IISマネージャーで「Microsoft Dynamics CRM」のサイトを選択する
- 右ペインの「バインドの編集」をクリック
- ポート443（HTTPS）のバインドを編集し、新しいワイルドカード証明書を選択
これにより、CRMサイトへのHTTPSアクセスに新しい証明書が適用されます。
2. ADFSへの新証明書の設定
ADFS管理コンソールを開き、「サービス」→「証明書」からサービス通信証明書を新しいワイルドカード証明書に置き換えます。
また、PowerShellを利用してADFSの証明書指紋（Thumbprint）を更新する場合は、以下のようにコマンドを実行します（例としてのスクリプトです）。
# 新しい証明書のThumbprintを変数に格納
$newThumbprint = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
# ADFSのService Communication Certificateを更新
Set-AdfsSslCertificate -Thumbprint $newThumbprint
# ADFSのサービス再起動
Restart-Service adfssrvなお、ADFSではトークン署名証明書やトークン暗号化証明書が別途存在します。通常、ワイルドカード証明書は「サービス通信証明書」に設定され、トークン署名証明書としては自己署名証明書が使われるケースが多いです。現行の設定を必ず確認し、誤って署名証明書を更新しないよう注意が必要です。
3. サービス再起動と動作確認
ADFSのサービス（adfssrv）やIISサイトをホストしているアプリケーションプールを再起動して変更を反映させたら、ブラウザからCRMにアクセスし、以下の点を確認します。
- 証明書エラーが表示されず、HTTPSが安全に確立されるか
- クレームベース認証（ADFS認証）で問題なくログインできるか
- ポータルや他の外部連携システムにも問題が波及していないか
必要に応じて、ユーザーや他部署にもテストを依頼し、本番稼働に支障がないかを確認しておきましょう。
トラブルシューティングや注意点
1. バックアップとロールバック手順
証明書の更新作業を行う際は、念のため下記のようなバックアップを取得しておくと安心です。
- 現行のワイルドカード証明書(pfxファイルなど)とその秘密鍵
- Dynamics CRMのIISサイト設定(アプリケーションホスト構成ファイルなど)
- ADFS構成のバックアップ(PowerShellコマンドでエクスポート)
万が一、新しい証明書適用後に不具合が生じた場合でも、これらのバックアップがあれば迅速なロールバックが可能です。
2. サービスアカウントのアクセス権
IISやADFSが動作しているサービスアカウントに、証明書の秘密鍵を読み取る権限が付与されているかを確認します。権限が不足していると、ADFSが証明書を読み取れず、認証が失敗することがあります。
Windows証明書ストアの「コンピューターアカウント」→「個人」ストアで対象の証明書を右クリックし、「すべてのタスク」→「管理者としてキーのプロパティを管理」などを選択してNT SERVICE\adfssrvなどに権限を与えます。
3. 証明書チェーンのインストール漏れ
パブリックCAの証明書を使う場合、中間証明書やルート証明書が正しくインストールされていないと、不明な発行元扱いとなり、ブラウザ側で警告が表示されます。特に複数の中間証明書が存在する場合は順序にも注意が必要で、認証局のドキュメントどおりにインポートしましょう。
4. 既存証明書との競合
サーバー上に既存のワイルドカード証明書が複数残っていると、どの証明書が有効になっているのか混乱しがちです。バインド設定を変更しても、誤って古い証明書が使われたままになっているケースもあるため、不要な証明書はきちんと削除するか、有効期限切れの証明書を明示的に「信頼しない」設定にしておくとよいでしょう。
まとめ
Dynamics CRM 2016オンプレミス環境でのワイルドカード証明書の作成と更新は、IIS、ADFS、さらには内部CAまたはパブリックCAなど、複数の要素を正しく連携させる必要があります。大まかな流れとしては、証明書の取得（自己署名またはパブリックCA）、IISへのインポート、CRMサイトおよびADFSへの適用、そして動作確認というステップに分けて進めます。
特にクレームベース認証が絡む場合は、ADFSの設定が正しく更新されているかが重要です。サービス通信証明書やトークン署名証明書、暗号化証明書を混同しないよう注意して作業しましょう。
証明書管理は地味に見えて、システム全体のセキュリティや利便性を左右する重要なプロセスです。本記事を参考に、ワイルドカード証明書を活用した安全・安心なDynamics CRM運用体制を整えてください。
コメント