Catalyst 9800 WLCでのCSR証明書の生成とダウンロード

はじめに

このドキュメントでは、Catalyst 9800で証明書を生成、ダウンロード、およびインストールする全体的なプロセスについて説明します

前提条件

要件

次の項目に関する知識があることが推奨されます。

• 9800 WLC、アクセスポイント(AP)の基本動作用の設定方法
• OpenSSL アプリケーションを使用する方法
• 公開キーインフラストラクチャ(PKI)とデジタル証明書

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• 9800-CL、Cisco IOS® XEバージョン17.9.4
• OpenSSLアプリケーション（バージョン3.1.3）

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

設定

16.10.Xでは、9800はWeb認証とWeb管理で異なる証明書をサポートしません。Webログインポータルでは、常にデフォルトの証明書が使用されます。

16.11.Xでは、Web認証用の専用証明書を設定し、グローバルパラメータマップ内にトラストポイントを定義できます。

9800 WLCの証明書を取得するには、2つのオプションがあります。

1. OpenSSLまたはその他のSSLアプリケーションを使用して証明書署名要求(CSR)を生成します。認証局(CA)によって署名されたPKCS12証明書を生成（OpenSSLを使用）するか、取得し、9800 WLCに直接ロードします。これは、秘密キーがその証明書にバンドルされていることを意味します。
2. 9800 WLCを使用して生成された CSRの場合、CAによって署名された証明書を取得し、チェーン内の各証明書を9800 WLCに手動でロードします。
   

ニーズに最も適したソリューションを使用してください。

オプション1:WLCへの既存のPKCS12署名付き証明書のロード

ステップ1：証明書署名要求の作成

証明書がない場合は、証明書署名要求(CSR)を生成してCAに送信する必要があります。

（OpenSSLがインストールされているラップトップの）現在のディレクトリから「openssl.conf」という名前のテキストファイルを作成し、これらの行をコピーして貼り付け、新しく作成したCSRのSubject Alternate Names(SAN)フィールドに含めます。

[ req ]
default_bits       = 4096
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt             = no
[ req_distinguished_name ]
countryName                 = <Country Name (2 letter code)>
stateOrProvinceName         = <State or Province Name (full name)>
localityName               = <Locality Name (eg, city)>
organizationName           = <Organization Name (eg, company)>
commonName                 = <Common Name (e.g. server FQDN or YOUR name)>
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = testdomain.com
DNS.2   = example.com
DNS.3   = webadmin.com
IP.1    = <WLC_IP_ADDRESS> (note : this is optionnal, but can be added in case you want to access your WLC using the IP address instead of FQDN)

DNS.Xの名前をSAN（サブジェクトの別名）に置き換えます。メインフィールドを、必要な証明書の詳細情報に置き換えます。SANフィールド(DNS.x)内にCommon Nameが繰り返し入力されていることを確認します。Google Chromeでは、証明書を信頼するために、URLに含まれる名前がSANフィールドに含まれている必要があります。

Web管理者の場合は、管理者がブラウザのアドレス・バーのURLに入力した内容に関係なく証明書が一致するように、SANフィールドにURLのバリエーション(ホスト名のみ、または完全修飾ドメイン名(FQDN)など)を入力する必要もあります。

次のコマンドを使用して、OpenSSLからCSRを生成します。

openssl req -out myCSR.csr -newkey rsa:4096 -nodes -keyout private.key -config openssl.conf

コマンドにフルパスが指定されていない場合、CSRはmyCSR.csrとして生成され、そのキーはOpenSSLの実行元のディレクトリにprivate.keyとして生成されます。

手順2:CSRの内容を確認します。

CSRの内容をコピーしてオンラインツール（Googleで「CSRデコーダ」と入力するなど）に貼り付け、内容を確認できます。SAN（サブジェクトの別名）がCSRに含まれていることを確認します。これは、一部のブラウザで必要とされるためです。 

また、次のコマンドを使用して、OpenSSLでCSRの内容を確認することもできます（CSRのIPアドレスを確認します）。

openssl req -noout -text -in myCSR.csr 

手順3:CAにCSRを送信します。

その後、このCSRをCAに提供して署名を行い、証明書を受け取ることができます。チェーン全体がCAからダウンロードされ、証明書がさらに操作する必要がある場合に備えて、証明書がBase64形式であることを確認します。通常、署名付きデバイス証明書、ルートCA証明書、および1つ以上の中間CA証明書など、複数のファイルをCAから受け取ります。

手順4:WLCでpkcs12ファイルを作成またはインポートします。

OpenSSLを使用してコンピュータ上でCSRを生成した場合、CAが独自の証明書および最終的な中間証明書とともに署名付き証明書のみを提供する可能性があります。その場合は、OpenSSLを使用してPKCS12ファイルを自分で生成する必要があります。CAが秘密キーにもアクセスできる場合は、PKCS12ファイル（PFXファイル）を直接提供できます。この場合、コントローラにファイルをインポートするだけで済みます。これを行うには、「PKCS12ファイルのインポート」セクションを参照してください。 

PKCS12ファイルの作成

PEMまたはCRT形式の秘密キーファイルと証明書があり、それらをPKCS12(.pfx)形式で組み合わせて9800 WLCにアップロードするような状況に陥る可能性があります。また、9800 WLCにインポートする前に、このpfxファイルにも含める必要がある1つ以上のCA証明書を保持することもできます。 

最初に、すべての中間CAとルートCAファイルを1つのファイルに結合する必要があります。 内容をコピーして貼り付けます（.pem形式でファイルを保存します）。

----- BEGIN Certificate --------
<intermediate CA cert>
------END Certificate --------
-----BEGIN Certificate -----
<root CA cert>
-----END Certificate--------

次に、次のコマンドを使用して、.pfxファイルを作成できます。 

For versions older than 17.12.1 : 
openssl pkcs12 -export -macalg sha1 -legacy -descert -out chaincert.pfx -inkey  -in  -certfile 
       
       
 
       
 
      For version 17.12.1 or above : 
openssl pkcs12 -export -out chaincert.pfx -inkey  -in  -certfile 
      

作成したPKCS12ファイルを確認します。

次のコマンドを使用して、PKCS12ファイルの内容を確認できます（内容を確認します）。

openssl pkcs12 -info -in 
    
    

この出力には、完全な証明書チェーンと秘密キーが表示されます。このファイルは、先ほど設定したパスワードで保護されています。 

PKCS12ファイルのインポート

これで、GUIまたはCLIを使用して、9800 WLCで.pfxファイルをインポートできます。 

GUI を使用する場合：

9800 WLC GUIを開き、Configuration > Security > PKI Managementの順に選択し、Add Certificate タブをクリックします。Import PKCS12 Certificateメニューを展開します。.pfxファイルがコンピュータに保存されている場合は、Transport TypeドロップダウンリストでDesktop (HTTPS)オプションを選択します。これにより、ブラウザを介したHTTPアップロードが可能になります。Certificate Passwordは、PKCS12証明書が生成されたときに使用されたパスワードです。

情報が正しいことを確認し、Importをクリックします。その後、Key Pair Generationタブに、この新しいトラストポイントの新しい証明書キーペアがインストールされたことが表示されます。インポートが成功すると、9800 WLCはマルチレベルCA用の追加トラストポイントも作成します。

CLI を使用する場合：

9800# configure terminal
9800(config)#crypto pki import 
    
    
      pkcs12 [tftp:// 
     
       / 
      
        | ftp:// 
       
         / 
        
          | 
         http:// 
          
            / 
            
           | bootflash: 
         
           ] password 
           
          
         
        
       
      
    

注：マルチレベルCA用に追加のトラストポイントを作成するには、9800 WLCの証明書ファイル名とトラストポイント名の両方が正確に一致していることが重要です。

オプション2:9800 WLCでのキーおよび証明書署名要求(CSR)の定義

手順1：汎用RSAキーペアを生成します。

Configuration > Security > PKI Managementの順に移動し、Key Pair Generationタブを選択してから、+ Addをクリックします。詳細を入力し、Key Exportableチェックボックスにチェックマークが入っていることを確認してから、Generateをクリックします。

CLI による設定：

9800(config)#crypto key generate rsa general-keys label 9800-keys exportable
The name for the keys will be: 9800-keys
Choose the size of the key modulus in the range of 512 to 4096 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [1024]: 4096
% Generating 4096 bit RSA keys, keys will be exportable...
[OK] (elapsed time was 9 seconds)

手順2:9800 WLCでCSRを生成します。

Add Certificateタブに移動し、Generate Certificate Signing Requestを展開して詳細を入力し、ドロップダウンリストから以前に作成したキーペアを選択します。ドメイン名が9800 WLC上のクライアントアクセスに定義されたURL（Web管理ページ、Web認証ページなど）に一致することが重要です。証明書名はトラストポイント名なので、用途に基づいて名前を付けることができます。

注:9800 WLCは、共通名にワイルドカードパラメータを含む証明書をサポートします。

情報が正しいことを確認し、Generateをクリックします。元のフォームの横のテキストボックスにCSRが表示されます

Copyは、コピーをクリップボードに保存します。これにより、コピーをテキストエディタに貼り付けてCSRを保存することができます。  
Save to deviceは、CSRのコピーを作成し、bootflash:/csrに保存します。これを確認するには、次のコマンドを実行します。

9800#dir bootflash:/csr
Directory of bootflash:/csr/

1046531 -rw- 1844 Sep 28 2021 18:33:49 +00:00 9800-CSR1632856570.csr

26458804224 bytes total (21492699136 bytes free)
9800#more bootflash:/csr/9800-CSR1632856570.csr
-----BEGIN CERTIFICATE REQUEST-----
<Certificate Request>
-----END CERTIFICATE REQUEST-----

CLI による設定：

9800(config)#crypto pki trustpoint 9800-CSR
9800(ca-trustpoint)#enrollment terminal pem
9800(ca-trustpoint)#revocation-check none
9800(ca-trustpoint)#subject-name C=BE, ST=Brussels, L=Brussels, O=Cisco Systems, OU=Wireless TAC, CN=mywlc.local-domain
9800(ca-trustpoint)#rsakeypair 9800-keys
9800(ca-trustpoint)#subject-alt-name example.com,guestportal.com,webadmin.com
9800(ca-trustpoint)#exit

(config)#crypto pki enroll 9800-CSR
% Start certificate enrollment ..

% The subject name in the certificate will include: C=BE, ST=Brussels, L=Brussels, O=Cisco Systems, OU=Wireless TAC, CN=mywlc.local-domain
% The subject name in the certificate will include: mywlc
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:

-----BEGIN CERTIFICATE REQUEST-----
<Certificate Request>
-----END CERTIFICATE REQUEST-----

---End - This line not part of the certificate request---

Redisplay enrollment request? [yes/no]: no

サブジェクト名の構成に使用できるパラメーター：

C：国。2文字の大文字のみにする必要があります。

ST:州(Some State)。州名または都道府県名を指します。

L:ロケーション名。市区町村を指します。

O:組織名。会社を指します。

OU:組織単位名。セクションを参照できます。

CN:（共通名）証明書の発行先のサブジェクトを指し、アクセスする特定のIPアドレス（ワイヤレス管理IP、仮想IPなど）またはFQDNを使用して構成されたホスト名を指定する必要があります。

注：サブジェクト代替名を追加する場合、Cisco Bug ID CSCvt15177により、17.8.1より前のバージョンのCisco IOS XEでは使用できません .このシナリオでは、SANが存在しないために一部のブラウザアラートが発生する場合があります。これを回避するには、オプション1に示すように、キーとCSRをオフボックスで作成します。

手順3:CSRをCA（認証局）に送信します。

完全な文字列をCAに送信して署名してもらう必要があります。

-----BEGIN CERTIFICATE REQUEST-----
<Certificate Request>
-----END CERTIFICATE REQUEST-----

Windows Server CAを使用して証明書に署名する場合は、署名付き証明書をBase64形式でダウンロードします。それ以外の場合は、Windows cert managerなどのユーティリティを使用してエクスポートする必要があります。

通常、署名付きデバイス証明書、中間CA（存在する場合）、およびルートCA証明書をCAから受け取ります。

手順4:9800 WLCに対してCAを認証します。

証明書がルートCAによって直接署名されている場合は、手順4aの指示を確認できます（すべての作業はGUIを使用して実行できます）。
証明書がマルチレベルCAによって署名されている場合は、ステップ4b（この場合はCLIが必要）に記載されている手順に進みます。

手順4a：ルートCAを認証する 

9800に発行者CAを信頼させます。.pem形式(Base64)で発行者CA証明書をダウンロードまたは取得します。同じメニュー内でAuthentication Root CAセクションを展開し、Trustpointドロップダウンリストから以前に定義したトラストポイントを選択し、発行者CA証明書を貼り付けます。詳細が正しく設定されていることを確認し、Authenticateをクリックします。

CLI による設定：

9800(config)# crypto pki authenticate 9800-CSR

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

    
    
      -----END CERTIFICATE----- 
    

Certificate has the following attributes:
       Fingerprint MD5: DD05391A 05B62573 A38C18DD CDA2337C
      Fingerprint SHA1: 596DD2DC 4BF26768 CFB14546 BC992C3F F1408809

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported

手順4b：マルチレベルCAを認証する

複数の認可レベルが存在するシナリオでは、追加のCAレベルごとに新しいトラストポイントが必要です。証明書がルートCAによって直接署名されている場合は、1つのトラストポイント（CSRの生成時に作成されたトラストポイント）のみが必要であるため、手順4aを参照してください。 

中間CAとルートCAが1つずつある場合は、2つのトラストポイントが必要です。つまり、作成済みのトラストポイント（デバイス証明書と中間CA証明書を含み、ルートCAトラストポイントを参照するトラストポイント）と、ルートCA証明書を含む新しいトラストポイントです。2つの中間証明書がある場合は、3つのトラストポイントが必要です。以下同様です。これらの追加トラストポイントには、認証証明書のみが含まれ、次のレベルの認証をポイントします。このプロセスはCLIでのみ実行できます。 

CLI設定（中間CAが1つの場合の例）: 

9800(config)#crypto pki trustpoint RootCA
9800(ca-trustpoint)#enrollment terminal
9800(ca-trustpoint)#chain-validation stop
9800(ca-trustpoint)#revocation-check none
9800(ca-trustpoint)#exit
9800(config)#crypto pki authenticate RootCA

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

    
    
-----END CERTIFICATE-----

Certificate has the following attributes:
Fingerprint MD5: 6CAC00D5 C5932D01 B514E413 D41B37A8
Fingerprint SHA1: 5ABD5667 26B7BD0D 83BDFC34 543297B7 3D3B3F24

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
% Certificate successfully imported

9800(config)#crypto pki trustpoint 9800-CSR <<< This is the trustpoint created with the CSR
9800(ca-trustpoint)#chain-validation continue RootCA <<< This is the trustpoint created above
9800(config)#crypto pki authenticate 9800-CSR

Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----

    
     
    
-----END CERTIFICATE-----

Certificate has the following attributes: 
Fingerprint MD5: DD05391A 05B62573 A38C18DD CDA2337C 
Fingerprint SHA1: 596DD2DC 4BF26768 CFB14546 BC992C3F F1408809 
Certificate validated - Signed by existing trustpoint CA certificate.

Trustpoint CA certificate accepted. 
% Certificate successfully imported

注：認証チェーンに複数の中間CAがある場合、追加の認証レベルごとに新しいトラスポイントを生成する必要があります。このトラストポイントは、コマンドchain-validation continue <trustpoint-name>を使用して、次のレベルの証明書を含むトラストポイントを参照する必要があります。

CLIの設定（2つの中間CAを使用した簡略化された例）: 

9800(config)#crypto pki trustpoint RootCA
9800(ca-trustpoint)#enrollment terminal
9800(ca-trustpoint)#chain-validation stop
9800(ca-trustpoint)#revocation-check none
9800(ca-trustpoint)#exit
9800(config)#crypto pki authenticate RootCA
-----BEGIN CERTIFICATE-----

    
    
-----END CERTIFICATE-----
9800(config)#crypto pki trustpoint Inter2 <<< This is the trustpoint for the 1st intermediate CA (from top of the chain)
9800(ca-trustpoint)#enrollment terminal
9800(ca-trustpoint)#chain-validation continue RootCA <<< This is the trustpoint created above
9800(config)#crypto pki authenticate Inter2
-----BEGIN CERTIFICATE-----

    
     
    
-----END CERTIFICATE-----
9800(config)#crypto pki trustpoint 9800-CSR <<< This is the trustpoint created with the CSR
9800(ca-trustpoint)#chain-validation continue Inter2 <<< This is the trustpoint created above
9800(config)#crypto pki authenticate 9800-CSR
-----BEGIN CERTIFICATE-----

    
     
    
-----END CERTIFICATE-----

手順5：デバイス署名証明書を9800にインポートする

9800 WLCに署名付き証明書をロードします。同じメニューでImport Device Certificateセクションを展開します。以前に定義したトラストポイントを選択し、CAから提供された署名付きデバイス証明書を貼り付けます。証明書情報を確認したら、importをクリックします。

CLI による設定：

9800(config)#crypto pki import 9800-CSR certificate

Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself

-----BEGIN CERTIFICATE-----
< 9800 device certificate >
-----END CERTIFICATE-----

% Router Certificate successfully imported

この時点で、デバイス証明書がすべてのCAとともに9800 WLCにインポートされ、証明書を使用する準備が整います（GUIアクセス、WebAuthなど）

新しい証明書の使用

Web管理（GUIアクセス）

Administration > Management > HTTP/HTTPS/Netconfの順に移動し、Trust Pointsドロップダウンリストから、インポートされた証明書を選択します。

CLI による設定：

9800(config)#ip http secure-trustpoint 9800.pfx
9800(config)#no ip http secure-server
9800(config)#ip http secure-server

ローカル Web 認証

Configuration > Security > Web Authに移動し、global パラメータマップを選択し、Trustpointドロップダウンリストからインポートされたトラストポイントを選択します。Update & Applyをクリックして変更を保存します。仮想IPv4ホスト名が証明書の共通名と一致することを確認します。

CLI による設定：

9800(config)#parameter-map type webauth global
9800(config-params-parameter-map)#type webauth
9800(config-params-parameter-map)#virtual-ip ipv4 192.0.2.1 virtual-host mywlc.local-domain
9800(config-params-parameter-map)#trustpoint 9800-CSR

証明書の使用状況を更新するには、HTTPサービスを再起動します。

9800(config)#no ip http server
9800(config)#ip http server 

.

ハイアベイラビリティの考慮事項

ステートフルスイッチオーバー(SSO)ハイアベイラビリティ(HA SSO)用に設定された9800ペアでは、最初の一括同期ですべての証明書がプライマリからセカンダリに複製されます。これには、RSAキーがエクスポート不可能に設定されている場合でも、コントローラ自体で秘密キーが生成された証明書が含まれます。HAペアが確立されると、インストールされた新しい証明書が両方のコントローラにインストールされ、すべての証明書がリアルタイムで複製されます。

障害発生後、前のセカンダリの現在アクティブなコントローラは、プライマリから透過的に継承された証明書を使用します。

証明書がWebブラウザで信頼されていることを確認する方法

証明書がWebブラウザで信頼されていることを確認するための重要な考慮事項がいくつかあります。

• 共通名（またはSANフィールド）は、ブラウザがアクセスするURLと一致する必要があります。
• 有効期間内である必要があります。
• このルートは、ブラウザが信頼するルートを持つCAまたはCAのチェーンによって発行される必要があります。このため、Webサーバによって提供される証明書には、クライアントブラウザ（通常はルートCA）によって信頼された証明書が必ずしも含まれるとは限らない、チェーンのすべての証明書が含まれている必要があります。
• 失効リストが含まれている場合は、ブラウザでダウンロードできる必要があり、証明書CNはリストされません。

確認

次のコマンドを使用して、証明書の設定を確認できます。

9800#show crypto pki certificate 9800.pfx

Certificate
Status: Available
Certificate Serial Number (hex): 1236
Certificate Usage: General Purpose
Issuer:
cn=Chuu Intermediate CA
ou=Chuu Wireless
o=Chuu Inc
st=CDMX
c=MX
Subject:
Name: alz-9800
e=user@example.com
cn=alz-9800
ou=Cisco Systems
o=Wireless TAC
l=CDMX
st=CDMX
c=MX
Validity Date:
start date: 17:54:45 Pacific Sep 28 2021
end date: 17:54:45 Pacific Sep 26 2031
Associated Trustpoints: 9800.pfx

CA Certificate
Status: Available
Certificate Serial Number (hex): 1000
Certificate Usage: Signature
Issuer:
cn=Chuu Root CA
ou=Chuu Wireless
o=Chuu Inc
l=Iztapalapa
st=CDMX
c=MX
Subject:
cn=Chuu Intermediate CA
ou=Chuu Wireless
o=Chuu Inc
st=CDMX
c=MX
Validity Date:
start date: 05:10:34 Pacific Apr 29 2020
end date: 05:10:34 Pacific Apr 27 2030
Associated Trustpoints: 9800.pfx

9800#show ip http server secure status

HTTP secure server status: Enabled
HTTP secure server port: 443
HTTP secure server ciphersuite: 3des-ede-cbc-sha aes-128-cbc-sha
 aes-256-cbc-sha dhe-aes-128-cbc-sha ecdhe-rsa-3des-ede-cbc-sha
 rsa-aes-cbc-sha2 rsa-aes-gcm-sha2 dhe-aes-cbc-sha2 dhe-aes-gcm-sha2
 ecdhe-rsa-aes-cbc-sha2 ecdhe-rsa-aes-gcm-sha2
HTTP secure server TLS version: TLSv1.2 TLSv1.1 TLSv1.0
HTTP secure server client authentication: Disabled
HTTP secure server trustpoint: 9800.pfx
HTTP secure server active session modules: ALL

9800で証明書チェーンを確認できます。中間CAによって発行されたデバイス証明書の場合、中間CA自体がルートCAによって発行された場合は、2つの証明書のグループによって1つのトラストポイントが与えられるため、各レベルに独自のトラストポイントが与えられます。この場合、9800 WLCにはデバイス証明書（WLC証明書）と発行側CA（中間CA）のある9800.pfxがあります。次に、その中間CAを発行したルートCAを持つ別のトラストポイントを指定します。

9800#show crypto pki certificate 9800.pfx
Certificate
Status: Available
Certificate Serial Number (hex): 1236
Certificate Usage: General Purpose
Issuer:
cn=Chuu Intermediate CA
ou=Chuu Wireless
o=Chuu Inc
st=CDMX
c=MX
Subject:
Name: alz-9800
e=user@example.com
cn=alz-9800
ou=Cisco Systems
o=Wireless TAC
l=CDMX
st=CDMX
c=MX
Validity Date:
start date: 17:54:45 Pacific Sep 28 2021
end date: 17:54:45 Pacific Sep 26 2031
Associated Trustpoints: 9800.pfx

CA Certificate
Status: Available
Certificate Serial Number (hex): 1000
Certificate Usage: Signature
Issuer:
cn=Chuu Root CA
ou=Chuu Wireless
o=Chuu Inc
l=Iztapalapa
st=CDMX
c=MX
Subject:
cn=Chuu Intermediate CA
ou=Chuu Wireless
o=Chuu Inc
st=CDMX
c=MX
Validity Date:
start date: 05:10:34 Pacific Apr 29 2020
end date: 05:10:34 Pacific Apr 27 2030
Associated Trustpoints: 9800.pfx

9800#show crypto pki certificate 9800.pfx-rrr1
CA Certificate
Status: Available
Certificate Serial Number (hex): 00
Certificate Usage: Signature
Issuer:
cn=Chuu Root CA
ou=Chuu Wireless
o=Chuu Inc
l=Iztapalapa
st=CDMX
c=MX
Subject:
cn=Chuu Root CA
ou=Chuu Wireless
o=Chuu Inc
l=Iztapalapa
st=CDMX
c=MX
Validity Date:
start date: 04:58:05 Pacific Apr 29 2020
end date: 04:58:05 Pacific Apr 27 2030
Associated Trustpoints: 9800-CSR 9800.pfx-rrr1

OpenSSLを使用した証明書の検証

OpenSSLは、証明書自体の確認や変換操作を行う場合に便利です。

OpenSSLで証明書を表示するには、次の手順を実行します。

openssl x509 -in 
    
    
      -text 
    

CSRの内容を表示するには、次の手順を実行します。

openssl req -noout -text -in 
    
    

9800 WLC上の終了証明書を確認する必要があるが、ブラウザ以外のものを使用する場合、OpenSSLでこれを実行して詳細を確認できます。

openssl s_client -showcerts -verify 5 -connect 
    
    
      :443 
    

<wlcURL>は、9800のwebadminのURL（仮想IP）またはゲストポータルのURL（仮想IP）で置き換えることができます。IPアドレスを入力することもできます。これにより、どの証明書チェーンが受信されたかを確認できますが、ホスト名の代わりにIPアドレスを使用する場合、証明書の検証が100%正しいことは不可能です。

コンテンツを表示し、PKCS12(.pfx)証明書または証明書チェーンを確認するには、次の手順を実行します。

openssl pkcs12 -info -in 
    
    

次に、証明書のチェーンに対するこのコマンドの例を示します。この場合、デバイス証明書は、「intermediate.com」という中間CAによってTechnical Assistance Center(TAC)に発行され、それ自体は「root.com」というルートCAによって発行されます。

openssl pkcs12 -info -in chainscript2.pfx
Enter Import Password:
MAC Iteration 2048
MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Certificate bag
Bag Attributes
localKeyID: 1D 36 8F C2 4B 18 0B 0D B2 57 A2 55 18 96 7A 8B 57 F9 CD FD
subject=/C=BE/ST=Diegem/L=Diegem/O=Cisco/CN=TAC
issuer=/C=BE/ST=Diegem/O=Cisco/OU=TAC/CN=intermediate.com/emailAddress=int@int.com
-----BEGIN CERTIFICATE-----
< Device certificate >
-----END CERTIFICATE-----
Certificate bag
Bag Attributes: <No Attributes>
subject=/C=BE/ST=Diegem/O=Cisco/OU=TAC/CN=intermediate.com/emailAddress=int@int.com
issuer=/C=BE/ST=Diegem/L=Diegem/O=Cisco/OU=TAC/CN=RootCA.root.com/emailAddress=root@root.com
-----BEGIN CERTIFICATE-----
< Intermediate certificate >
-----END CERTIFICATE-----
Certificate bag
Bag Attributes: <No Attributes>
subject=/C=BE/ST=Diegem/L=Diegem/O=Cisco/OU=TAC/CN=RootCA.root.com/emailAddress=root@root.com
issuer=/C=BE/ST=Diegem/L=Diegem/O=Cisco/OU=TAC/CN=RootCA.root.com/emailAddress=root@root.com
-----BEGIN CERTIFICATE-----
< Root certificate >
-----END CERTIFICATE-----
PKCS7 Data
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Bag Attributes
localKeyID: 1D 36 8F C2 4B 18 0B 0D B2 57 A2 55 18 96 7A 8B 57 F9 CD FD
Key Attributes: <No Attributes>
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----BEGIN ENCRYPTED PRIVATE KEY-----
< Private key >
-----END ENCRYPTED PRIVATE KEY-----

トラブルシュート

トラブルシューティングを行うには、このコマンドを使用します。リモートセッション（SSHまたはtelnet）で実行した場合、出力を表示するにはterminal monitorが必要です。

9800#debug crypto pki transactions

正常なシナリオデバッグ出力

次の出力は、9800で証明書のインポートが正常に行われたときに予期される出力を示しています。このドキュメントを参考にして、障害の状態を確認してください。

Sep 28 17:35:23.242: CRYPTO_PKI: Copying pkcs12 from bootflash:9800.pfx
Sep 28 17:35:23.322: CRYPTO_PKI: Creating trustpoint 9800.pfx
Sep 28 17:35:23.322: %PKI-6-TRUSTPOINT_CREATE: Trustpoint: 9800.pfx created succesfully
Sep 28 17:35:23.324: CRYPTO_PKI: examining cert:
Sep 28 17:35:23.324: CRYPTO_PKI: issuerName=cn=Chuu Intermediate CA,ou=Chuu Wireless,o=Chuu Inc,st=CDMX,c=MX
Sep 28 17:35:23.324: CRYPTO_PKI: subjectname=e=user@example.com,cn=alz-9800,ou=Cisco Systems,o=Wireless TAC,l=CDMX,st=CDMX,c=MX
Sep 28 17:35:23.324: CRYPTO_PKI: adding RSA Keypair
Sep 28 17:35:23.324: CRYPTO_PKI: bitValue of ET_KEY_USAGE = 140
Sep 28 17:35:23.324: CRYPTO_PKI: Certificate Key Usage = GENERAL_PURPOSE
Sep 28 17:35:23.324: %CRYPTO_ENGINE-5-KEY_ADDITION: A key named 9800.pfx has been generated or imported by pki-pkcs12
Sep 28 17:35:23.331: CRYPTO_PKI: adding as a router certificate.Public key in cert and stored public key 9800.pfx match

Sep 28 17:35:23.333: CRYPTO_PKI: examining cert:
Sep 28 17:35:23.333: CRYPTO_PKI: issuerName=cn=Chuu Root CA,ou=Chuu Wireless,o=Chuu Inc,l=Iztapalapa,st=CDMX,c=MX
Sep 28 17:35:23.333: CRYPTO_PKI: subjectname=cn=Chuu Intermediate CA,ou=Chuu Wireless,o=Chuu Inc,st=CDMX,c=MX
Sep 28 17:35:23.333: CRYPTO_PKI: no matching private key presents.

[...]

Sep 28 17:35:23.335: CRYPTO_PKI: Setting the key_type as RSA
Sep 28 17:35:23.335: CRYPTO_PKI: Attempting to insert the peer's public key into cache
Sep 28 17:35:23.335: CRYPTO_PKI:Peer's public inserted successfully with key id 21
Sep 28 17:35:23.336: Calling pkiSendCertInstallTrap to send alert
Sep 28 17:35:23.337: CRYPTO_PKI: Deleting cached key having key id 31
Sep 28 17:35:23.337: CRYPTO_PKI: Attempting to insert the peer's public key into cache
Sep 28 17:35:23.337: CRYPTO_PKI:Peer's public inserted successfully with key id 32
Sep 28 17:35:23.338: CRYPTO_PKI: (A0323) Session started - identity selected (9800.pfx)
Sep 28 17:35:23.338: CRYPTO_PKI: Rcvd request to end PKI session A0323.
Sep 28 17:35:23.338: CRYPTO_PKI
alz-9800#: PKI session A0323 has ended. Freeing all resources.
Sep 28 17:35:23.338: CRYPTO_PKI: unlocked trustpoint 9800.pfx, refcount is 0
Sep 28 17:35:23.338: CRYPTO_PKI: Expiring peer's cached key with key id 32Public key in cert and stored public key 9800.pfx match

Sep 28 17:35:23.341: Calling pkiSendCertInstallTrap to send alert
Sep 28 17:35:23.341: CRYPTO_PKI: cert verified and inserted.
Sep 28 17:35:23.402: CRYPTO_PKI: Creating trustpoint 9800.pfx-rrr1
Sep 28 17:35:23.402: %PKI-6-TRUSTPOINT_CREATE: Trustpoint: 9800.pfx-rrr1 created succesfully
Sep 28 17:35:23.403: CRYPTO_PKI: Setting the key_type as RSA
Sep 28 17:35:23.404: CRYPTO_PKI: Attempting to insert the peer's public key into cache
Sep 28 17:35:23.404: CRYPTO_PKI:Peer's public inserted successfully with key id 22
Sep 28 17:35:23.405: Calling pkiSendCertInstallTrap to send alert
Sep 28 17:35:23.406: CRYPTO_PKI: no CRLs present (expected)
Sep 28 17:35:23.406: %PKI-6-PKCS12_IMPORT_SUCCESS: PKCS #12 import in to trustpoint 9800.pfx successfully imported.

CAのないPKCS12証明書のインポートの試行

証明書をインポートして「CA cert is not found.」というエラーが表示された場合は、.pfxファイルにチェーン全体が含まれていないか、1つのCAが存在しないことを意味します。

9800(config)#crypto pki import pkcs12.pfx pkcs12 bootflash:pks12.pfx password 
    
    
% Importing pkcs12...
Source filename [pks12.pfx]?
Reading file from bootflash:pks12.pfx
% Warning: CA cert is not found. The imported certs might not be usable.

openssl pkcs12 -info -in <path to cert>コマンドを実行し、秘密キーが1つの証明書だけが表示される場合は、CAが存在しないことを意味します。原則として、このコマンドは証明書のチェーン全体を一覧表示するのが理想的です。すでにクライアントブラウザで認識されている場合は、最上位のルートCAを含める必要はありません。

これを修正する1つの方法は、PEMへのPKCS12の設定を解除し、チェーンを正しく再構築することです。次の例では、デバイス(WLC)証明書とそのキーのみが含まれる.pfxファイルがありました。これは、PKCS12ファイルに存在しない中間CAによって発行され、次に既知のルートCAによって署名されました。

ステップ 1：秘密キーをエクスポートします。

openssl pkcs12 -in 
    
    
      -out cert.key -nocerts -nodes 
    

ステップ 2：証明書をPEMとしてエクスポートします。

openssl pkcs12 -in 
    
    
      -out certificate.pem -nokeys -clcerts 
    

ステップ 3：中間CA証明書をPEMとしてダウンロードします。

CAのソースはその性質に依存します。パブリックCAの場合、オンライン検索でリポジトリを見つけるのに十分です。そうでない場合、CA管理者はBase64形式(.pem)で証明書を提供する必要があります。CAに複数のレベルがある場合は、オプション1のインポートプロセスの最後に示したような1つのファイルにグループ化します。

ステップ 4：キー、デバイス証明書、およびCA証明書からPKCS 12を再構築します。

openssl pkcs12 -export -out fixedcertchain.pfx -inkey cert.key -in certificate.pem -certfile CA.pem

これで「fixedcertchain.pfx」が完成しました。このファイルをCatalyst 9800にインポートできます。

秘密キーをエクスポートしています

別のWLCに移行する場合、またはWLCを復元する場合、秘密キーをエクスポートして別の場所に移動するという状況に陥ることがあります。

#crypto key export rsa 
    
    
      pem terminal aes 
      
    

注意と制限

• Cisco IOS® XEは、2099年以降の有効なCA証明書をサポートしません。Cisco Bug ID CSCvp64208
• Cisco IOS® XEは、SHA256メッセージダイジェストPKCS 12バンドルをサポートしません（SHA256証明書はサポートされますが、PKCS12バンドル自体がSHA256で署名されている場合はサポートされません）。CSCvz41428。これは、17.12.1 で修正されています。 
• WLCがユーザ証明書を伝送する必要があり、NAC/ISEアプライアンスがインターネット経由で到達可能な場合（SD-WAN展開など）は、フラグメンテーションを確認できます。証明書のサイズはほとんどの場合1500バイト（証明書メッセージを伝送するためにいくつかのRADIUSパケットが送信されることを意味します）よりも大きく、ネットワークパス上に複数の異なるMTUがある場合は、RADIUSパケット自体のフラグメンテーションが発生する可能性があります。このような場合、インターネットの気象によって引き起こされる可能性がある遅延やジッタなどの問題を回避するために、WLCトラフィックのすべてのUDPデータグラムを同じパス経由で送信することを推奨します