# Intermediate CA

{% hint style="warning" %}
SCEPman Enterprise Edition のみ
{% endhint %}

別の Root CA を主要な認証局として使用したい場合は、中間 CA 証明書を作成して、SCEPman を下位認証局として運用できます。正しい証明書を Azure Key Vault で直接作成し、Root CA で署名するための CSR をダウンロードできます。署名済みの要求はアップロードして、Azure Key Vault に取り込むことができます。この記事では、必要な手順を詳しく案内します。

## Key Vault のアクセス許可

CSR を作成し、中間 CA 証明書を取り込むために、ユーザー アカウントに Azure Key Vault へのアクセスを許可する必要があります。アクセス許可の割り当て方法は、Key Vault のアクセス構成によって異なります。

{% tabs %}
{% tab title="Azure RBAC" %}

1. Azure Portal で Azure Key Vault に移動します
2. 次をクリックします **アクセス制御 (IAM)** 左側のナビゲーション ペインで
3. 次をクリックします **ロールの割り当て** 新しいロールの割り当てを追加します

<figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FZUqsPTRdUk5IhmZZlBVD%2Fimage.png?alt=media&#x26;token=325c2296-4f6b-476d-b003-29cf3674556f" alt=""><figcaption><p>Key Vault に新しいロールの割り当てを追加</p></figcaption></figure>

4. を選択し、 **Key Vault Certificate Officer** ロールを選択し、 **次へ**

<figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FptcaAY0strUu3qIgkTdc%2Fimage.png?alt=media&#x26;token=6bf4adc2-da77-4ece-ba68-09c61fc6905e" alt=""><figcaption></figcaption></figure>

5. 次に、AAD 管理者アカウントを検索して追加し、 **メンバー** セクションでロールの割り当てを続行します

ロールの割り当てを追加した後、Azure AD アカウントは CSR の作成と証明書のアップロードが許可されます。
{% endtab %}

{% tab title="Vault Access Policies" %}

1. Azure Portal で Azure Key Vault に移動します
2. 次をクリックします **Access policies** 左側のナビゲーション ペインで
3. 次をクリックします **作成** を選択し、 **証明書管理** テンプレートを選択してから、次へ

<figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FD2mWeiZ7YnQuRN0rdypW%2F2023-06-14%2016_20_43-IntermediateCert.png?alt=media&#x26;token=da6b385e-8902-4b53-8a9f-25f3573d6532" alt=""><figcaption></figcaption></figure>

<figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2F37QHfqcQRHNboM4yQkTb%2F2023-06-14%2016_23_37-IntermediateCert.png?alt=media&#x26;token=3cc22a95-8f13-4487-b270-083efa2779bd" alt=""><figcaption></figcaption></figure>

4. 次に、AAD 管理者アカウントを検索して追加し、 **プリンシパル** セクションで、次へ、次へと進み、作成します

<figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FIj3S2D7wkNquLnBJSUQe%2F2023-06-14%2017_06_33-.png?alt=media&#x26;token=195c03cb-a120-434b-8aa1-c44d4b2d26f6" alt=""><figcaption></figcaption></figure>

アクセス許可を追加した後、Azure AD アカウントは CSR の作成と証明書のアップロードが許可されます。
{% endtab %}
{% endtabs %}

## 管理システムに対する Key Vault ネットワークを開放する

を使用している場合 [Private Endpoint](https://docs.scepman.com/ja/azure-no/private-endpoints) Key Vault では、クライアントがネットワーク レベルで Key Vault にアクセスできるようにする例外を追加する必要があります。Private Endpoint を使用していない場合は、この部分をスキップできます。

* Azure Portal で Azure Key Vault に移動します。
* ［設定］の下にある Networking ブレードに移動します。
* 現在「パブリック アクセスを無効にする」が選択されている場合は、「特定の仮想ネットワークと IP アドレスからのパブリック アクセスを許可する」に切り替えます。
* 後で [SCEPman PowerShell モジュールを実行する](#creating-intermediate-ca-certificate-with-the-scepman-powershell-module)クライアントの IP アドレスを追加します。 [Azure Cloud Shell を使用していて](https://learn.microsoft.com/en-us/azure/cloud-shell/vnet/overview)VNET に接続されている場合は、この VNET を追加できます。それ以外の場合、最も簡単な方法は Cloud Shell のパブリック IP アドレスを一時的に許可することです。Key Vault は強力な認証で保護されているためです。次のようなコマンドを使って `(Invoke-WebRequest -UseBasicParsing -uri "http://ifconfig.me/ip").Content` セッションのパブリック IP アドレスを確認できます。

## Azure App Service の設定を更新する

次の手順は、次の手順で作成する中間 CA のサブジェクト名に合わせて Azure App Service の構成を更新することです。

1. Azure App Service に移動します
2. 次をクリックします **Environment variables** 左側のナビゲーション ペインで
3. で **アプリケーション設定、** 次の設定を編集する必要があります。
   1. `AppConfig:KeyVaultConfig:RootCertificateConfig:CertificateName`\
      これを、中間 CA 用に推奨する共通名 (CN) に変更します。
   2. `AppConfig:KeyVaultConfig:RootCertificateConfig:Subject`\
      サブジェクト名の CN 値のみを、上で使用した共通名に合わせて変更します。
4. 次をクリックします **適用して確認します。**
5. Azure を再起動し **App Service** 変更を適用してから、SCEPman の URL に移動します。

{% hint style="warning" %}
CertificateName 変数は、Azure Key Vault で作成される証明書オブジェクトに直接対応することに注意してください。そのため、使用できるのは英数字とダッシュを含む証明書名のみです。&#x20;
{% endhint %}

<figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FvO2YgKtltBesm2Eme7ix%2Fimage.png?alt=media&#x26;token=9ec3f21e-b6eb-47c5-8e10-3e2cbe519669" alt=""><figcaption></figcaption></figure>

## SCEPman PowerShell モジュールを使用した中間 CA 証明書の作成

{% hint style="warning" %}
このモジュールを正しく機能させるには、次を備えたワークステーションが必要です [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) （としても知られています `az`がインストールされていること。Azure CLI は [Azure Cloud Shell](https://docs.microsoft.com/en-us/azure/cloud-shell/overview)にプリインストールされており、このモジュールを実行するための推奨環境です。
{% endhint %}

SCEPman PowerShell モジュールのバージョン 1.9 以降を使用して、中間 CA 証明書用の CSR を作成できます。次のコマンドで、PowerShell Gallery からモジュールの最新バージョンをインストールできます。

```powershell
Install-Module -Name SCEPman -Scope CurrentUser -Force
```

次に、証明書に表示する組織名をモジュールに指定できます。

```powershell
Reset-IntermediateCaPolicy -Organization "My Organization"
```

中間 CA のサブジェクトを、上で使用したものと一致するように設定します `AppConfig:KeyVaultConfig:RootCertificateConfig:Subject` (必要に応じて、CSR の内容を制御するために追加設定を変更できます):

{% code lineNumbers="true" %}

```
$policy = Get-IntermediateCaPolicy
$policy.policy.x509_props.subject = "CN=YOUR_CN_FROM_ABOVE,OU=YOUR_TENANT_ID,O=YOUR_ORGANIZATION"
# $policy の追加設定をいくつか変更する
Set-IntermediateCaPolicy -Policy $policy
```

{% endcode %}

最後に、次のコマンド（または環境に応じた類似のコマンド）で CSR を作成できます。

```powershell
New-IntermediateCA -SCEPmanAppServiceName "app-scepman-example" -SearchAllSubscriptions 6>&1
```

このコマンドは、署名のために Root CA に送信する CSR を出力します。

## 中間 CA 証明書を発行する

次に、CSR を Root CA に送信し、発行済みの中間 CA 証明書を取得します。証明書をディスクに (.cer) 保存しておくと、次の手順で Azure Key Vault の秘密鍵とアップロードおよび結合できます。

### ADCS Enterprise Root CA の特別な手順

Active Directory Certificate Services を AD 統合 Root CA として使用しており、Certificate Template を選択する必要がある場合は、次の Key Usage を含める必要があります: "CRLSign"、"DigitalSignature"、"KeyEncipherment"、および "KeyCertSign"。KeyEncipherment は既定のテンプレート "Subordinate Certificate Authority" には含まれておらず、新しいテンプレートでも選択できません。この問題に遭遇した場合の解決策は以下を参照してください。 **これは Stand-alone Root CA には適用されません**。これらは CSR から Key Usage を正しく取得するためです。

#### 概要

SubCA テンプレートを複製するか、必要に応じて使用できます。その後、CSR に基づいてテンプレートを使って証明書を発行するだけです。この証明書には *誤った Key Usage* (0x86) が含まれます。その後、次を使用して、調整した Key Usage 拡張を使って証明書に再署名します。 `certutil -sign`.

#### 手順

1. SubCA 証明書を要求して発行します。
2. 新しい SubCA 証明書を Root CA 上のファイル（例: c:\temp\SubCA.cer）にエクスポートします。 **Base-64 エンコードされた X.509** 形式を選択します。
3. 下に示す内容を含むファイル「extfile.txt」を Root CA に作成します（例: c:\temp\extfile.txt）。
4. コマンド ラインを起動して実行します: `certutil -sign "c:\temp\SubCA.cer" "c:\temp\SubCAwithKeyEncipher.cer" @c:\temp\extfile.txt`
5. 証明書 SubCAwithKeyEncipher.cer には、要求したキー使用法 (0xA6) が含まれるようになりました。サムプリント（署名）は変わりましたが、シリアル番号は変わっていません。
6. ADCS の発行済み証明書の一覧には古い証明書が含まれています。シリアル番号は変わっていないため、古いハンドルを使って新しい証明書を管理できます。たとえば、古い証明書を失効すると新しい証明書も失効します。これが望ましくない場合は、次を使用して古い証明書エントリを削除できます。 `certutil -deleterow` その後、次を使用して新しい証明書をインポートします。 `certutil -importcert`.

#### extfile.txt

```
[Extensions]
2.5.29.15=AwIBpg==
Critical=2.5.29.15
```

## 中間 CA 証明書をアップロードする

1. Azure Key Vault で証明書をクリックし、 **Certificate Operation**
2. すると、次のオプションが表示されます **Download CSR** および **Merge Signed Request**

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-9b845d790796a34cb0e9296434373a502ddfee92%2Fscreenshot-2020-10-19-at-16.01.18.png?alt=media)

1. 次をクリックします **Merge Signed Request** そして中間 CA 証明書をアップロードします。署名済みの要求をアップロードすると、Azure Key Vault の **完了済み**

{% hint style="warning" %}
中間 CA 証明書は PEM 形式（Base64 エンコード）である必要があります。バイナリの DER 形式を使用すると、詳細に「Property x5c has invalid value X5C must have at least one valid item」というエラーメッセージが表示されます。
{% endhint %}

## CA の適合性を確認する

SCEPman のステータス ページでは、新しい構成を確認し、新しい中間 CA 証明書をダウンロードして Endpoint Manager 経由で展開できます。

SCEPman ホームページにアクセスして、CA 証明書がすべての要件を満たしているか確認してください。ホームページの「CA Suitability」の横に表示される内容を確認してください。たとえば、 *CA Certificate is missing Key Usage "Key Encipherment"*&#x3068;表示されている場合は、 [中間 CA 証明書を発行する](#issue-the-intermediate-ca-certificate) に戻って証明書の発行を修正してください。

## Intermediate CAs と Intune SCEP プロファイル

Android プラットフォームでは、Intune の SCEP 構成プロファイルは Root CA を参照する必要があり、Intermediate CA ではありません。そうしないと、構成プロファイルは失敗します。Windows では逆で、Intune の SCEP 構成プロファイルは Intermediate CA を参照する必要があり、Root CA ではありません。iOS と macOS については、どちらの方法が優れているかについて結論的な情報はありません。
