はじめに
このドキュメントでは、Cisco ISEのTLS/SSL証明書、ISE証明書の種類と役割、および一般的なタスクの実行方法とトラブルシューティング方法について説明します。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Cisco Identity Services Engine(ISE)
- さまざまなタイプのISEおよびAAA導入を説明するために使用される用語。
- RADIUSプロトコルとAAAの基本
- SSL/TLSおよびx509証明書
- 公開キーインフラストラクチャ(PKI)の基本
使用するコンポーネント
このドキュメントの情報は、Cisco ISEリリース2.4 ~ 2.7のソフトウェアとハードウェアのバージョンに基づくものです。 ISEのバージョン2.4から2.7までを対象としていますが、特に断りのない限り、他のISE 2.xソフトウェアリリースと類似または同一である必要があります。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
サーバ証明書
サーバ証明書は、サーバがサーバのIDをクライアントに提示して信頼性を確保し、安全な通信チャネルを提供するために使用されます。これらは、自己署名(サーバが自身に証明書を発行する場所)または認証局(組織の内部または有名なベンダーから)によって発行されます。
サーバ証明書は通常、サーバのホスト名または完全修飾ドメイン名(FQDN)に対して発行されるか、ワイルドカード証明書(*.domain.com
)にすることもできます。 発行先のホスト、ドメイン、またはサブドメインは、通常、Common Name(CN)フィールドまたはSubject Alternative Name(SAN)フィールドに示されます。
ワイルドカード証明書は、ワイルドカード表記(ホスト名の代わりにアスタリスクを使用)を使用することにより、組織内の複数のホストで同じ証明書を共有できるSSL証明書です。たとえば、ワイルドカード証明書のサブジェクト名のCN値またはSAN値は、*.company.com
のような形式で、このドメインの任意のホスト(server1.com
、server2.com
など)を保護するために使用できます。
証明書は通常、公開キー暗号化または非対称暗号化を使用します。
- 公開キー:公開キーは、いずれかのフィールドの証明書に含まれており、デバイスが公開キーと通信しようとしたときにシステムによって公開されます。
- 秘密キー:秘密キーはエンドシステムに対して秘密であり、公開キーとペアになっています。公開キーで暗号化されたデータは、特定のペア秘密キーでのみ復号化でき、その逆も可能です。
ISE証明書
Cisco ISEは公開キーインフラストラクチャ(PKI)を利用して、エンドポイント、ユーザ、管理者などとのセキュアな通信や、マルチノード導入環境におけるCisco ISEノード間のセキュアな通信を提供します。PKIは、x.509デジタル証明書を使用して、メッセージの暗号化と復号化のための公開キーを転送し、ユーザおよびデバイスから提示される他の証明書の信頼性を検証します。Cisco ISEには、通常使用される証明書の2つのカテゴリがあります。
- システム証明書:クライアントに対してCisco ISEノードを識別するサーバ証明書です。各Cisco ISEノードには独自のローカル証明書があり、それぞれが対応する秘密キーとともにノードに保存されます。
- 信頼できる証明書ストア証明書:これは、さまざまな目的でISEに提示される証明書を検証するために使用される認証局(CA)証明書です。証明書ストア内のこれらの証明書は、プライマリ管理ノードで管理され、分散されたCisco ISE環境の他のすべてのノードに複製されます。証明書ストアには、BYOD用に作成されたISEの内部認証局によってISEノード用に生成された証明書も含まれています。
システム証明書
システム証明書は、1つ以上のロールに使用できます。それぞれの役割は異なる目的を果たします。次に、それぞれの役割について説明します。
- Admin:これは、443(管理GUI)を介したすべての通信を保護するために使用されます。また、レプリケーションや、ここに記載されていないポート/使用に対しても使用されます。
- ポータル:これは、集中型Web認証(CWA)ポータル、ゲスト、BYOD、クライアントプロビジョニング、ネイティブサプリカントプロビジョニングポータルなどのポータル経由のHTTP通信を保護するために使用されます。各ポータルは、ポータルグループタグ(デフォルトはDefault Portal Group Tag)にマッピングする必要があります。このタグにより、特にタグ付けされた証明書が使用されます。証明書のEditオプションのPortal Group Tag nameドロップダウンメニューでは、新しいタグを作成したり、既存のタグを選択したりできます。
- EAP:802.1x認証のためにクライアントに提示する証明書を指定するロールです。証明書は、EAP-TLS、PEAP、EAP-FASTなどのほぼすべての可能なEAP方式で使用されます。PEAPやFASTなどのトンネリングされたEAP方式では、Transport Layer Security(TLS)を使用してクレデンシャル交換が保護されます。クライアントのクレデンシャルは、このトンネルが確立されてセキュアな交換が行われるまで、サーバに送信されません。
- RADIUS DTLS:このロールは、ネットワークアクセスデバイス(NAD)とISE間のRADIUSトラフィックを暗号化するためのDTLS接続(UDP経由のTLS接続)に使用される証明書を指定します。この機能が動作するには、NADがDTLS暗号化に対応している必要があります。
- SAML:サーバ証明書は、SAML IDプロバイダー(IdP)との通信を保護するために使用されます。 SAML用に指定された証明書は、Admin、EAP認証などの他のサービスには使用できません。
- ISEメッセージングサービス:2.6以降、ISEはレガシーSyslogプロトコルの代わりにISEメッセージングサービスを使用してデータをログします。これは、この通信の暗号化に使用されます。
- PxGrid:この証明書は、ISE上のPxGridサービスに使用されます。
ISEをインストールすると、デフォルトの自己署名サーバ証明書
が生成されます。デフォルトでは、これはEAP認証、管理者、ポータル、およびRADIUS DTLSに割り当てられます。これらのロールは、内部CAまたは既知のCA署名付き証明書に移動することをお勧めします。

ヒント:ISEサーバのFQDNとIPアドレスの両方をISEシステム証明書のSANフィールドに追加することをお勧めします。 一般に、Cisco ISEでの証明書認証が、証明書による検証機能のわずかな違いによる影響を受けないようにするため、ネットワークに導入されるすべてのCisco ISEノードで小文字のホスト名を使用します。
注:ISE証明書の形式は、プライバシー強化メール(PEM)またはDistinguished Encoding Rules(DER)である必要があります。
信頼された証明書ストア
認証局(CA)証明書はAdministration > System > Certificates > Certificate Store
に保存する必要があり、ISEがこれらの証明書をエンドポイント、デバイス、またはその他のISEノードによって提示された証明書の検証に使用することを確認するために、クライアント認証の信頼
ユースケースを持っている必要があります。

基本タスク
証明書には有効期限があり、取り消したり、いずれかの時点で交換を要求したりできます。ISEサーバ証明書の有効期限が切れると、新しい有効な証明書で置き換えない限り、重大な問題が発生する可能性があります。
注:拡張認証プロトコル(EAP)に使用される証明書の有効期限が切れると、クライアントはそのISE証明書を信頼しなくなるため、クライアント認証が失敗する可能性があります。ポータルに使用される証明書の有効期限が切れると、クライアントとブラウザはポータルへの接続を拒否できます。管理使用証明書の期限が切れると、リスクがさらに大きくなり、管理者がISEにログインできなくなり、分散導入が本来の機能を停止する可能性があります。
自己署名証明書の生成
新しい自己署名証明書を生成するには、Administration > System > Certificates > System Certificates
の順に選択します。Generate Self Signed Certificate
をクリックします。

このリストでは、「自己署名証明書の生成」ページのフィールドについて説明します。
自己署名証明書の設定フィールド名の使用ガイドライン:
- ノードの選択: (必須)システム証明書の生成に必要なノード。
- CN:(SANが指定されていない場合は必須)デフォルトでは、CNは自己署名証明書が生成されるISEノードのFQDNです。
- 組織単位(OU):組織単位の名前。例:エンジニアリング
- 組織(O):組織名(例:Cisco)。
- 市区町村(L): (省略形を使用しない)市区町村名。たとえば、San Jose。
- 都道府県(ST): (省略形を使用しない)都道府県名。たとえば、Californiaなどです。
- 国(C):国名。2文字のISO国番号が必要です。たとえば、米国です。
- SAN:証明書に関連付けられているIPアドレス、DNS名、またはUniform Resource Identifier(URI)。
- Key Type:公開キーの作成に使用するアルゴリズム(RSAまたはECDSA)を指定します。
- キーの長さ:公開キーのビットサイズを指定します。これらのオプションはRSAで使用できます: 512 1024 2048 4096これらのオプションはECDSAで使用できます: 256 384。
- Digest to Sign With:ハッシュアルゴリズムSHA-1またはSHA-256のいずれかを選択します。
- 証明書ポリシー:証明書が準拠する必要がある証明書ポリシーOIDまたはOIDのリストを入力します。OIDを区切るには、カンマまたはスペースを使用します。
- 有効期限TTL:証明書が期限切れになるまでの日数を指定します。
- フレンドリ名:証明書のフレンドリ名を入力します。名前を指定しない場合、Cisco ISEは
<common name> # <issuer> # <nnnnn>
の形式で名前を自動的に作成します。ここで、<nnnnn>
は一意の5桁の番号です。
- Allow Wildcard Certificates:このチェックボックスをオンにして、自己署名ワイルドカード証明書(サブジェクトまたはSANのDNS名の任意のCNにアスタリスク(*)を含む証明書)を生成します。たとえば、SANに割り当てられるDNS名は
*.domain.com
です。
- 使用法:このシステム証明書を使用する必要があるサービスを選択します。使用できるオプションは次のとおりです。
- [管理(Admin)]
- EAP Authentication
- RADIUSのDTLS
- pxGrid
- SAML
- ポータル


注:RSAとECDSAの公開キーは、同じセキュリティレベルでもキーの長さが異なる場合があります。パブリックCA署名付き証明書を取得する場合、またはFIPS準拠のポリシー管理システムとしてCisco ISEを導入する場合は、2048を選択します。
自己署名証明書の更新
既存の自己署名証明書を表示するには、ISEコンソールで、Administration > System > Certificates > System Certificates
の順に移動します。同じISEサーバFQDNで指定されている場合は、「Issued To」と「Issued By」を持つすべての証明書が自己署名証明書です。この証明書を選択し、Edit
をクリックします。
Renew Self Signed Certificate
の下で、Renewal Period
ボックスにチェックマークを入れて、必要に応じて有効期限TTLを設定します。最後に、Save
をクリックします。
信頼できる証明書のインストール
Base 64でエンコードされた証明書を、ルートCA、中間CA、信頼に必要なホストから取得します。
1. 次の図に示すように、ISEノードにログインし、Administration > System > Certificate > Certificate Management > Trusted Certificates
の順に選択し、Import
をクリックします。

2. 次のページで、取得したCA証明書を(前述と同じ順序で)アップロードします。 追跡を続けるために、証明書の目的を説明する分かりやすい名前と説明を割り当てます。
用途に応じて、次のチェックボックスをオンにします。
- ISE内での認証の信頼:これは、同じ信頼できるCA証明書が信頼できる証明書ストアにロードされている場合に、新しいISEノードを追加することです。
- クライアント認証とsyslogの信頼:証明書を使用して、EAPを使用してISEに接続するエンドポイントの認証や、セキュアなsyslogサーバの信頼を行うには、これを有効にします。
- シスコサービスの認証に対する信頼:これは、フィードサービスなどの外部シスコサービスを信頼する場合にのみ必要です。
3. 最後に、Submit
をクリックします。これで、証明書が信頼ストアに表示され、すべてのセカンダリISEノードに同期される必要があります(導入環境の場合)。

CA署名付き証明書のインストール
ルートCA証明書と中間CA証明書が信頼できる証明書ストアに追加されると、証明書署名要求(CSR)を発行でき、CSRに基づいて署名された証明書をISEノードにバインドできます。
1. これを行うには、Administration > System > Certificates > Certificate Signing Requests
の順に移動し、Generate Certificate Signing Requests (CSR)
をクリックしてCSRを生成します。
2. 表示されるページのUsageセクションで、ドロップダウンメニューから使用するロールを選択します。
証明書が複数のロールに使用される場合は、Multi-Useを選択します。証明書が生成されたら、必要に応じてロールを変更できます。ほとんどの場合、証明書は[Used For]ドロップダウンで[Multi-use]に使用するように設定できます。これにより、すべてのISE Webポータルで証明書を使用できるようになります。
3. ISEノードの横にあるチェックボックスをオンにして、証明書を生成するノードを選択します。
4. ワイルドカード証明書のインストールと生成を目的とする場合は、Allow Wildcard Certificates
ボックスにチェックマークを付けます。


5. ホストまたは組織の詳細(組織単位、組織、市、州、および国)に基づいてサブジェクト情報を入力します。
6. これを完了するには、Generate
をクリックし、表示されるポップアップでExport
をクリックします。


これにより、作成されたBase 64でエンコードされた証明書要求要求がダウンロードされます。このPEMファイルを署名のためにCAに送信し、署名済み証明書CERファイル(Base 64エンコード)を取得する必要があります。
注:CNフィールドの下で、ISEがノードのFQDNを自動入力します。
注:ISE 1.3および1.4では、pxGridを使用するために少なくとも2つのCSRを発行する必要がありました。1つはpxGrid専用で、もう1つは残りのサービス専用です。2.0以降では、これはすべて1つのCSRに対して行われます。
注:証明書がEAP認証に使用される場合、Windowsサプリカントがサーバ証明書を拒否するため、*記号をサブジェクトCNフィールドに含めることはできません。サプリカントでValidate Server Identityが無効になっている場合でも、CNフィールドに「*」が含まれているとSSLハンドシェイクが失敗する可能性があります。代わりに、CNフィールドで汎用FQDNを使用でき、SAN DNS Nameフィールドで*.domain.com
を使用できます。一部の認証局(CA)は、CSRにワイルドカードが含まれていなくても、証明書のCNに自動的にワイルドカード(*)を追加できます。このシナリオでは、このアクションを防ぐために特別な要求を発行する必要があります。
7. 証明書がCAによって署名されたら(ビデオに示されているように、CSRから生成され、Microsoft CAが使用されている場合はここ)、ISE GUIに戻り、Administration > System > Certificates > Certificate Management > Certificate Signing Requestの順に移動します。 前に作成したCSRの横にあるチェックボックスをオンにして、Bind Certificateボタンをクリックします。

8. 次に、受信した署名付き証明書をアップロードし、ISEのフレンドリ名を指定します。次に、証明書の必要性に応じて(AdminやEAP認証、ポータルなど)、使用法の横にあるボックスを選択し、次の図に示すようにSubmit
をクリックします。

この証明書に管理ロールが選択されている場合、ISEノードはサービスを再起動する必要があります。VMに割り当てられたバージョンとリソースによっては、10 ~ 15分かかる場合があります。アプリケーションのステータスを確認するには、ISEコマンドラインを開いて、show application status ise
コマンドを発行します。


証明書のインポート時に管理者ロールまたはポータルロールを選択した場合は、ブラウザの管理者ページまたはポータルページにアクセスしたときに新しい証明書が配置されていることを確認できます。ブラウザでロック記号を選択し、証明書の下で、パスは完全なチェーンが存在し、マシンによって信頼されていることを確認します。証明書チェーンが正しく構築されていて、その証明書チェーンがブラウザで信頼されている限り、ブラウザは新しい管理者またはポータル証明書を信頼する必要があります。
注:現在のCA署名付きシステム証明書を更新するには、新しいCSRを生成し、同じオプションで署名付き証明書をシステム証明書にバインドします。アクティブになる前に新しい証明書をISEにインストールすることが可能であるため、古い証明書が期限切れになる前に新しい証明書のインストールを計画します。古い証明書の有効期限と新しい証明書の開始日が重なることにより、証明書を更新し、ダウンタイムをほとんどまたは発生させずに交換を計画する時間を確保できます。開始日が古い証明書の失効日より前である新しい証明書を取得します。この 2 つの日付の間の期間が移行期間です。新しい証明書が有効な日付範囲に入ったら、必要なプロトコル(Admin/EAP/Portal)を有効にします。 Admin usageが有効になっている場合は、サービスが再起動されることに注意してください。
ヒント: 管理者証明書とEAP証明書には社内CAを、ゲスト/スポンサー/ホットスポット/その他のポータル用には公開署名証明書使用することをお勧めします。その理由は、ユーザまたはゲストがネットワークにアクセスし、ISEポータルがゲストポータル用にプライベート署名付き証明書を使用する場合、証明書エラーが発生するか、またはブラウザにポータルページからの証明書をブロックさせる可能性があるためです。これらをすべて回避するには、ポータルで使用する公開署名証明書を使用して、ユーザエクスペリエンスを向上させます。また、各導入ノードのIPアドレスをSANフィールドに追加して、IPアドレスを使用してサーバにアクセスするときに証明書に関する警告が表示されないようにする必要があります。
バックアップ証明書と秘密キー
次のファイルをエクスポートすることをお勧めします。
1. すべてのシステム証明書(展開内のすべてのノードから取得)とその秘密キー(再インストールするために必要)を安全な場所に保存します。証明書の設定(証明書が使用されたサービス)をメモしておきます。
2. プライマリ管理ノードの信頼された証明書ストアからのすべての証明書。証明書の設定(証明書が使用されたサービス)をメモしておきます。
3. すべての認証局証明書。
そのために –
Administration > System > Certificates > Certificate Management > System Certificates
の順に移動します。証明書を選択し、Export
をクリックします。Export Certificates
and Private
Keysオプションボタンを選択する。秘密キーのパスワードを入力し、パスワードを確認します。[Export] をクリックします。
Administration > System > Certificates > Certificate Management > Trusted Certificates
の順に選択します。証明書を選択し、Export
をクリックします。Save File
をクリックして、証明書をエクスポートします。
Administration > System > Certificates > Certificate Authority > Certificate Authority Certificates
の順に移動します。証明書を選択し、Export
をクリックします。Export Certificates
and Private
Keysオプションボタンを選択する。秘密キーのパスワードとパスワードの確認を入力します。[Export] をクリックします。Save File
をクリックして、証明書をエクスポートします。
トラブルシュート
証明書の有効性の確認
Cisco ISE Trusted CertificatesまたはSystem Certificatesストアのいずれかの証明書の有効期限が切れている場合、アップグレードプロセスは失敗します。アップグレードの前に、Trusted CertificatesウィンドウとSystem Certificatesウィンドウ(Administration > System > Certificates > Certificate Management
)のExpiration Dateフィールドの有効性を確認し、必要に応じて更新してください。
また、CA Certificatesウィンドウ(Administration > System > Certificates > Certificate Authority > Certificate Authority Certificates
)にある証明書のExpiration Dateフィールドの有効性を確認し、必要に応じてアップグレードの前に証明書を書き換えます。
証明書の削除
ISE内の証明書が期限切れまたは未使用の場合は、削除する必要があります。削除する前に、証明書を(該当する場合は秘密キーを使用して)エクスポートしてください。
期限切れの証明書を削除するには、Administration > System > Certificates > Certificate Management
の順に選択します。System Certificates Store
をクリックします。期限切れの証明書を選択し、Delete
をクリックします。
信頼できる証明書ストアと認証局(CA)証明書ストアについても同じ説明を参照してください。
サプリカントが802.1x認証でISEサーバ証明書を信頼しない
ISEがSSLハンドシェイクプロセスの完全な証明書チェーンを送信するかどうかを確認します。
サーバ証明書を必要とするEAP方式(つまり、PEAP)で、クライアントOS設定でValidate Server Identityが選択されている場合、サプリカントは、認証プロセスの一部として、ローカルの信頼ストアにある証明書を使用して証明書チェーンを検証します。SSLハンドシェイクプロセスの一環として、ISEは自身の証明書を提示するだけでなく、自身のチェーンに含まれるルート証明書や中間証明書も提示します。チェーンが不完全な場合、または信頼ストアにこのチェーンがない場合、サプリカントはサーバIDを検証できません。
証明書チェーンがクライアントに返されていることを確認するため、認証時にISE(Operations > Diagnostic Tools > General Tools > TCP Dump
)またはエンドポイント上のWiresharkキャプチャからパケットキャプチャを取得します。Wiresharkでキャプチャを開き、フィルタssl.handshake.certificates
を適用して、アクセスチャレンジを見つけます。
選択したら、Expand Radius Protocol > Attribute Value Pairs > EAP-Message Last segment > Extensible Authentication Protocol > Secure Sockets Layer > Certificate > Certificates
の順に選択します。
チェーンが不完全な場合は、ISE Administration > Certificates > Trusted Certificates
の順に選択し、ルート証明書または中間証明書(あるいはその両方)が存在することを確認します。証明書チェーンが正常に渡された場合は、チェーン自体がここで説明する方法で有効であることを確認する必要があります。
各証明書(サーバ、中間、およびルート)を開き、信頼のチェーンを確認して、各証明書のサブジェクトキー識別子(SKI)が、チェーン内の次の証明書の認証局キー識別子(AKI)と一致するようにします。
ISE証明書チェーンは正しいが、認証中にエンドポイントがISEサーバ証明書を拒否する
ISEがSSLハンドシェイクの完全な証明書チェーンを提示し、サプリカントが引き続き証明書チェーンを拒否する場合、次のステップは、ルート証明書または中間証明書(あるいはその両方)がクライアントのローカル信頼ストアにあることを確認することです。
これをWindowsデバイスから確認するには、mmc.exe
(Microsoft管理コンソール)を起動し、File > Add-Remove Snap-in
に移動します。available snap-insカラムから、Certificates
を選択し、Add
をクリックします。使用している認証の種類(ユーザまたはマシン)に応じて、自分のユーザアカウント
またはコンピュータアカウント
を選択し、OK
をクリックします。
コンソールビューで、Trusted Root Certification AuthoritiesおよびIntermediate Certification Authoritiesの順に選択し、ローカルの信頼ストアにルート証明書および中間証明書が存在することを確認します。
これがサーバIDチェックの問題であることを確認する簡単な方法として、サプリカントプロファイル設定でValidate Server Certificateのチェックマークを外して、もう一度テストします。
よく寄せられる質問(FAQ)
ISEが証明書がすでに存在するという警告をスローした場合の対応
このメッセージは、ISEがまったく同じOUパラメータを持つシステム証明書を検出し、重複する証明書をインストールしようとしたことを意味します。重複したシステム証明書はサポートされていないため、新しい証明書が異なることを確認するために、市/州/部署の値を少し異なる値に変更することを推奨します。
ブラウザで、ISEからのポータルページが信頼できないサーバによって表示されることを示す警告が表示されるのはなぜですか。
これは、ブラウザがサーバのID証明書を信頼しない場合に発生します。
まず、ブラウザに表示されるポータル証明書が予想どおりであり、ポータル用にISEで設定されていることを確認します。
次に、FQDN経由でポータルにアクセスします。IPアドレスが使用されている場合は、証明書のSANフィールドとCNフィールドにFQDNとIPアドレスの両方が含まれていることを確認します。
最後に、ポータル証明書チェーン(ISEポータル、中間CA、ルートCA証明書)がクライアントOSやブラウザソフトウェアにインポートされ、信頼されていることを確認します。
注:iOS、Android OS、およびChrome/Firefoxブラウザの新しいバージョンの一部では、証明書のセキュリティに対して厳格な要件があります。これらのポイントが満たされている場合でも、ポータルCAと中間CAがSHA-256未満であれば、接続を拒否できます。
証明書が無効なためにアップグレードが失敗する場合の対処法
Cisco ISE Trusted CertificatesまたはSystem Certificatesストアのいずれかの証明書の有効期限が切れている場合、アップグレードプロセスは失敗します。アップグレードの前に、Trusted CertificatesウィンドウとSystem Certificatesウィンドウ(Administration > System > Certificates > Certificate Management
)のExpiration Dateフィールドの有効性を確認し、必要に応じて更新してください。
また、CA Certificatesウィンドウ(Administration > System > Certificates > Certificate Authority > Certificate Authority Certificates
)にある証明書のExpiration Dateフィールドの有効性を確認し、必要に応じてアップグレードの前に証明書を書き換えます。
ISEをアップグレードする前に、内部CA証明書チェーンが有効であることを確認します。
Administration > System > Certificates > Certificate Authority Certificates
の順に移動します。展開内の各ノードで、Friendly Name列のCertificate Services Endpoint Sub CAで証明書を選択します。Viewをクリックし、Certificate Statusが適切なメッセージであり、表示されていることを確認します。
証明書チェーンが壊れている場合は、Cisco ISEのアップグレードプロセスが開始される前に問題を修正してください。この問題を修正するには、Administration > System > Certificates > Certificate Management > Certificate Signing Requests
の順に移動し、ISEルートCAオプション用に1つを生成します。
関連情報