【Active Directory証明書サービス】ERR_SSL_KEY_USAGE_INCOMPATIBLE / NET::ERR_CERT_COMMON_NAME_INVALID への対応

この記事の内容

  • 最新のChromeやEdgeでIISの自己署名証明書が使用できなくなった問題の背景を解説します
  • Windows Active Directory証明書サービス（AD CS）を使ったエンタープライズCAの構築手順を紹介します
  • WebサーバーへのSSL証明書発行から、IISへのバインドまでの一連の流れを説明します
  • CA証明書をグループポリシーで配布し、クライアントに信頼させる方法を解説します
  • Subject Alternative Name（SAN）を含む証明書を発行するためのcertutilコマンドによる設定変更を紹介します

はじめに

IISの自己署名証明書を使ったHTTPS構成は、以前は「安全ではありません」という警告をスキップすれば表示できていました。しかし現在の最新版ChromeおよびEdge（Chromiumベース）では、ERR_SSL_KEY_USAGE_INCOMPATIBLEというエラーが表示され、そもそもページを表示できなくなっています。

これはブラウザ側のチェックが厳格化されたことが原因です。この記事では、正しい方法でWindows CAを立て、証明書を発行することでこの問題を解消する手順を解説します。

検証環境の構築はもちろん、企業内で証明局を立てて証明書を運用する場面にも応用できる内容です。

現象の確認

IISで自己署名証明書を作成し、WebサイトにHTTPSバインドを設定した状態でアクセスすると、以下のエラーが発生します。

ERR_SSL_KEY_USAGE_INCOMPATIBLE

「安全ではありません」の警告をスキップしようとしても、ページを表示できません。ChromeでもEdgeでも同様の挙動となります。

この問題を解消するためには、IISの簡易的な自己署名証明書の使用をやめ、Active Directory証明書サービス（AD CS） を使ってきちんとした証明書を発行する構成に切り替える必要があります。

全体の流れ

解決までの手順は大きく分けると以下の通りです。

  1. ドメインコントローラーにAD CSをインストールしてCAを構築する
  2. CAのWebインターフェースをHTTPS化する
  3. CAでSAN（Subject Alternative Name）を有効化する
  4. WebサーバーからCSR（証明書署名要求）を作成する
  5. WebのインターフェースからSAN付きで証明書を要求・発行する
  6. 発行された証明書をIISにバインドする
  7. CA証明書をグループポリシーで配布し、クライアントに信頼させる

Step 1: AD CSのインストール

ドメインコントローラーに移動し、サーバーマネージャーから役割の追加を行います。

[役割と機能の追加] → [Active Directory証明書サービス] を選択します。

役割サービスの選択画面では、以下の2つを選択します。

  • 証明機関
  • 証明機関Web登録

証明機関Web登録はWebアプリケーションとして動作するため、IISの機能も同時にインストールされます。インストールが完了したら、画面上部のびっくりマークから構成を実施します。

AD CS構成のポイント

項目選択内容
セットアップの種類エンタープライズCA
CAの種類ルートCA
秘密キー新しい秘密キーを作成する
有効期限5年（検証環境の場合は長めに設定可）

エンタープライズCA はActive Directory環境と連携し、多くの便利な機能が利用できます。スタンドアロンCAはADに依存せずオフラインでも使用できますが、今回はドメイン環境との連携を活かしてエンタープライズCAを使用します。

構成が完了したら、[ツール] → [証明機関] からCAが正常に動作していることを確認します。証明書テンプレートの一覧も確認しておきましょう。Webサーバー向けの証明書は 「Web サーバー」 テンプレートを使用します。

Step 2: CA WebサイトのHTTPS化

証明機関Web登録のWebサイト（certsrv）は、デフォルトではHTTPでのみ動作します。このサイトを使って証明書を要求する際、最新のブラウザではHTTPSが必要なため、先にHTTPS化しておきます。

IISマネージャーで [既定のWebサイト] → [バインド] から443番ポートのHTTPSバインドを追加します。証明書には、AD CSセットアップ時に自動生成されたエンタープライズCA証明書を使用します。

Step 3: CA側でSANを有効化する（重要）

最新のブラウザで証明書を有効と認識させるには、証明書に Subject Alternative Name（SAN） が含まれている必要があります。しかし、デフォルト状態のWindows CAはリクエストに含まれたSAN属性を証明書に反映しません。

これを有効にするには、CAが稼働しているサーバーでコマンドプロンプトを管理者権限で開き、以下のコマンドを実行します。

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

次に、設定を反映させるためCertSvcを再起動します。

net stop certsvc
net start certsvc

このコマンドを実行することで、証明書要求の属性としてSANを受け入れるようになります。

Step 4: WebサーバーでCSRを作成する

IISを稼働させているWebサーバーに移動します。まず古い自己署名証明書を削除し、新しい証明書要求を作成します。

IISマネージャーで [サーバー証明書] を開き、[証明書の要求の作成] をクリックします。

項目入力内容
共通名iis01.dv1.example.net（サイトのFQDN）
組織 / 組織単位など適切な値を入力
ビット長2048以上推奨
出力ファイルC:\certrequest.txt（任意のパス）

[終了] をクリックすると、CSRファイルが生成されます。この時点で内部的には公開鍵と秘密鍵のペアが作成され、証明書は「証明書の登録要求」ストアに保留された状態になります。

Step 5: WebインターフェースでSAN付き証明書を要求する

Internet Explorerなどで以下のURLにアクセスします。

https://dc01.dv1.example.net/certsrv

資格情報の入力とサイトの信頼済み登録を行った後、以下の手順で進めます。

  1. [証明書の要求] → [証明書の要求の詳細設定]
  2. [保存された要求を使用して証明書を要求または更新する] を選択
  3. [保存された要求] フィールドに、先ほど作成したCSRファイルの内容を貼り付ける
  4. 証明書テンプレートで [Web サーバー] を選択

追加属性へのSAN指定（最重要）

[追加属性] フィールドに以下の形式でSANを入力します。

san:dns=iis01.dv1.example.net

複数のFQDNやホスト名を含める場合は & で区切ります。

san:dns=iis01.dv1.example.net&dns=iis01

入力後、[送信] をクリックすると証明書が即時発行されます。発行された証明書をダウンロードして保存します。

Step 6: 証明書の要求を完了してIISにバインドする

IISマネージャーの [サーバー証明書] から [証明書の要求の完了] をクリックし、先ほどダウンロードした証明書ファイルを選択します。フレンドリ名に分かりやすい名前を付けて、証明書ストアは [個人] を選択します。

証明書のMMCスナップイン（certlm.msc）で確認すると、[証明書の登録要求] にあった保留中の要求がなくなり、[個人] → [証明書] に新しい証明書が追加されます。

証明書の詳細で [サブジェクトの別名] フィールドに先ほど指定したDNS名が含まれていることを確認します。

最後にIISのバインドを編集し、443番ポートの証明書をこの新しい証明書に変更します。

Step 7: CA証明書をグループポリシーで配布する

クライアントがCA発行の証明書を信頼するには、そのCAのルート証明書が [信頼されたルート証明機関] ストアに存在する必要があります。

1台ずつ手動でインポートするのは非効率なため、グループポリシーを使って配布します。

CA証明書のダウンロード

https://dc01.dv1.example.net/certsrv のホーム画面から、[CA証明書、証明書チェーン、またはCRLのダウンロード] を選択してCA証明書をダウンロードします。

グループポリシーへの登録

ドメインコントローラーでグループポリシー管理エディターを開き、以下の場所に移動します。

コンピ└ューWタiーn└のd構oセ成wキsュ└のリ設テ公定ィ開のキ└設ー定の信ポ頼リさシれーたルート証明機関

[インポート] からダウンロードしたCA証明書をインポートします。これにより、ドメイン内のすべてのコンピューターに対してポリシーが適用されます。

クライアントでグループポリシーを即時更新するには、コマンドプロンプトで以下を実行します。

gpupdate /force

動作確認

すべての設定が完了したら、クライアントからWebサーバーにHTTPSでアクセスします。

https://iis01.dv1.example.net

アドレスバーに鍵アイコンが表示され、証明書エラーなしでページが表示されれば成功です。

まとめ

今回の対応を通じて解決した問題は以下の2つです。

エラー原因解決策
ERR_SSL_KEY_USAGE_INCOMPATIBLEIIS自己署名証明書の用途が不適切AD CSのWebサーバーテンプレートで正しい証明書を発行
NET::ERR_CERT_COMMON_NAME_INVALID証明書にSAN（サブジェクトの別名）がないcertutilコマンドでCA側のSAN受け入れを有効化し、要求時にsan:dns=...属性を指定

整理すると、作業の流れは次のようになります。

  1. AD CSでエンタープライズCAを構築する
  2. certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 を実行してSANを有効化する
  3. CertSvcを再起動する
  4. IISからCSRを作成し、Web登録インターフェース経由でSAN属性を付けて証明書を要求する
  5. 発行された証明書をIISにバインドする
  6. CA証明書をグループポリシーでクライアントに配布する

ブラウザのセキュリティ仕様は今後も継続的に強化されていきます。SSL/TLS証明書まわりは変化の激しい分野であるため、証明書の基礎をしっかり理解した上で、仕様変更に柔軟に対応できる知識を身に付けておくことが重要です。