簡介
本檔案介紹在Catalyst 9800上產生、下載和安裝憑證的整體程式
必要條件
需求
思科建議您瞭解以下主題:
- 如何設定9800 WLC(存取點(AP))的基本操作
- 如何使用 OpenSSL 應用程式
- 公開金鑰基礎架構(PKI)和數位憑證
採用元件
本文中的資訊係根據以下軟體和硬體版本:
- 9800-CL,Cisco IOS® XE版本17.9.4
- OpenSSL應用程式(3.1.3版)
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
設定
在16.10.X上,9800s不支援Web驗證和Web管理的其他憑證。Web登入門戶始終使用預設證書。
在16.11.X上,可以配置用於Web身份驗證的專用證書,在全局引數對映中定義信任點。
有兩個選項可用來取得9800 WLC的憑證。
- 使用OpenSSL或任何其他的SSL應用程式產生憑證簽署請求(CSR)。產生(使用OpenSSL)或取得您的憑證授權單位(CA)簽署的PKCS12憑證,並將其直接載入到9800 WLC。這表示私密金鑰與該憑證相捆綁。
- 使用9800 WLC產生 CSR,由CA簽署,然後手動將鏈結中的每個憑證載入9800 WLC。
使用最符合您需求的產品。
選項1 -在WLC上載入預先存在的PKCS12簽名證書
第1步:建立證書簽名請求
如果您還沒有憑證,則需要產生憑證簽署請求(CSR)以提交給您的CA。
從您目前的目錄(在已安裝OpenSSL的膝上型電腦上)建立名為「openssl.conf」的文字檔案,複製並貼上這些行,以便在新建立的CSR中包含使用者替代名稱(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)中重複使用公用名。Google Chrome要求URL中的名稱位於SAN欄位中,以便信任證書。
如果是Web管理員,您還需要使用URL的變化形式填充SAN欄位(例如,僅主機名,或完全限定域名(FQDN)),以便證書與瀏覽器位址列中URL中的管理員型別無關。
使用以下命令從OpenSSL產生CSR:
openssl req -out myCSR.csr -newkey rsa:4096 -nodes -keyout private.key -config openssl.conf
除非提供命令的完整路徑,否則CSR會在執行OpenSSL的來源目錄中產生myCSR.csr和其private.key。
注意:確保private.key檔案在用於加密通訊時處於安全狀態
第2步:驗證CSR的內容
您可以將CSR的內容複製貼上到線上工具(例如,在Google上輸入「CSR解碼器」)以檢查其內容。請確定SAN (主體替代名稱)已包含在CSR中,因為有些瀏覽器需要它。
您也可以使用以下命令使用OpenSSL驗證CSR的內容:
openssl req -noout -text -in myCSR.csr
第3步:將CSR提交給您的CA
然後,您可以向您的CA提供此CSR,以便簽署此CSR並接收回證書。確保從CA下載完整的證書鏈,並且證書採用Base64格式,以防需要進一步處理。您通常會從您的CA收到多個檔案:簽名的裝置憑證、根CA憑證以及一個或多個中間CA憑證。
第4步:在WLC上建立和/或導入pkcs12檔案
如果您使用OpenSSL在電腦上產生CSR,您的CA可能會只提供您簽署的憑證、其自己的憑證和最終的中間憑證。在這種情況下,您需要使用OpenSSL自行生成PKCS12檔案。如果CA也可以存取您的私密金鑰,它可以直接提供PKCS12檔案(PFX檔案),在這種情況下,您只需要將檔案匯入控制器上。請參閱「導入PKCS12檔案」一節以執行此操作。
建立PKCS12檔案
最終可能會出現以下情況:您有PEM或CRT格式的私密金鑰檔案和憑證,且希望將它們組合成PKCS12 (.pfx)格式,以便上傳到9800 WLC。您也可以在匯入9800 WLC之前,有一或多個CA憑證也需要包含在此pfx檔案中。
您需要做的第一件事情是將所有中間CA和根CA檔案合併到單個檔案中。 將內容複製並貼在一起(以.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
提示:配置.pfx檔案的密碼時,請勿使用ASCII字元: *、^、()、[]、、''和+。使用這些ASCII字元會導致組態錯誤,且不會將憑證匯入控制器。
注意:由於思科漏洞ID CSCvz41428,17.12.1之前的版本需要「-macalg sha1」標誌。此外,還需要「-legacy -descert」,因為OpenSSL版本3通常預設限制傳統演算法的使用。但是,17.12.1版和更高版本支援較新的演算法,因此如果希望在這些版本上導入pfx檔案,則不需要這些標誌。
驗證已建立的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檔案儲存在電腦上,請在傳輸型別下拉選單中選擇案頭(HTTPS)選項,這樣就可以透過瀏覽器進行HTTP上傳。Certificate Password是指生成PKCS12證書時使用的口令。
驗證資訊是否正確,然後按一下導入。之後,您會在Key Pair Generation頁籤中看到此新信任點的新證書金鑰對。成功導入後,9800 WLC還會為多級CA建立另一個信任點。
注意:當特定ASCII字元包含在.pfx檔案的密碼中時,將顯示以下錯誤:配置從bootflash pfx CRYPTO PKI導入PKCS12操作失敗錯誤HMAC可能導致錯誤口令或損壞的PKCS12在密碼中包含以下字元導致錯誤: *、^、()、[]、 \當包含字元(」和+)時,將顯示以下錯誤:「配置時出錯」。憑證未匯入到WLC。
附註:目前,當特定信任點用於webauth或webadmin時,9800 WLC不會顯示完整憑證鏈結,而是顯示裝置憑證及其直接頒發者。此問題可透過思科漏洞ID CSCwa23606進行跟蹤,已在思科IOS® XE 17.8中修復。
使用CLI:
9800# configure terminal
9800(config)#crypto pki import
pkcs12 [tftp://
/
| ftp://
/
|
http://
/
| bootflash:
] password
注意:證書檔名和信任點名稱必須與9800 WLC完全匹配,才能為多級CA建立任何其他信任點。
選項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
複製會將副本儲存到剪貼簿,以便您可以將其貼上到文本編輯器中並儲存CSR。
儲存至裝置會建立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:國家/地區,只能有兩個大寫字母。
ST:某些州,是指州或省名稱。
L:位置名稱,指城市。
O:組織名稱,是指公司。
OU:組織單位名稱,請參閱一節。
CN:(公用名)指頒發證書的對象,您必須指定要訪問的特定IP地址(無線管理IP、虛擬IP等)或配置的主機名與FQDN。
注意:如果要增加備用主體名稱,在17.8.1之前的Cisco IOS XE版本上由於思科漏洞ID CSCvt而無法使用15177 .此情況可能導致由於SAN不存在而導致的某些瀏覽器警報,為了避免出現這種情況,請按照選項1中的說明在框外建立金鑰和CSR。
第3步:將您的CSR提交給您的CA(證書頒發機構)
完整的字串需要傳送到CA才能進行簽名。
-----BEGIN CERTIFICATE REQUEST-----
<Certificate Request>
-----END CERTIFICATE REQUEST-----
如果您使用Windows Server CA來簽署憑證,請以Base64格式下載簽署的憑證。否則,您需要使用Windows證書管理器等實用程式進行導出。
您通常會從您的CA收到簽署的裝置憑證、中間CA(如果有的話)憑證和根CA憑證。
第4步:向9800 WLC驗證CA
如果您的憑證直接由根CA簽署,則可檢查Step4a中的指示(所有作業都可使用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簽署,請參閱步驟4a,因為只需要一個信任點(產生CSR時建立的信任點)。
如果您有一個中間CA和一個根CA,則需要兩個信任點:一個已建立(包含裝置證書和中間CA證書,指根CA信任點)和一個包含根CA證書的新信任點。如果您有2個中間證書,則需要3個信任點……等等。這些額外的信任點僅包含身份驗證證書,並指向下一級別的身份驗證。此過程只能在CLI中完成。
CLI配置(一個中間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
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訪問)
導航到管理>管理> HTTP/HTTPS/Netconf,然後從信任點下拉選單中選擇導入的證書。
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
.
高可用性注意事項
在為狀態切換高可用性(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頒發,則您有一個信任點(按兩個證書的組劃分),因此每個級別都有自己的信任點。在這種情況下,9800 WLC的9800.pfx包含裝置憑證(WLC憑證)及其核發CA(中繼CA)。然後另一個信任點與發出該中間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
您可以使用9800的WebAdmin或訪客輸入網站(虛擬IP)的URL來取代<wlcURL>。您還可以將IP地址放在此處。它會告訴您收到的證書鏈是什麼,但使用IP地址而不是主機名時,證書驗證永遠不可能是100%正確的。
要檢視內容和驗證PKCS12 (.pfx)證書或證書鏈,請執行以下操作:
openssl pkcs12 -info -in
以下是憑證鏈結上此指令的範例,其中裝置憑證是由稱為「intermediate.com」的中間CA(本身由稱為「root.com」的根CA核發)核發給技術協助中心(TAC):
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憑證」,則表示.pfx檔案不包含整個憑證鏈結,或者有一個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>命令,且只顯示一個證書和一個私鑰,則表示CA不存在。根據經驗,此指令最好會列出您的整個憑證鏈結。如果客戶端瀏覽器已經知道頂層根CA,則不需要包含它。
解決此問題的一種方法是將PKCS12解構為PEM並正確重建鏈。在下一個範例中,我們有一個.pfx檔案,其中只包含裝置(WLC)憑證及其金鑰。它是由一個中間CA(不存在於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導入過程結束時顯示的檔案。
步驟 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證書:思科漏洞ID CSCvp64208
- Cisco IOS® XE不支援SHA256消息摘要PKCS 12捆綁包(支援SHA256證書,但如果PKCS12捆綁包本身已與SHA256簽名,則不支援SHA256證書):CSCvz41428。此問題已在 17.12.1 中修正。
- 如果WLC需要攜帶使用者證書,並且可以透過網際網路訪問NAC/ISE裝置(例如,在SD-WAN部署中),則可以看到分段。憑證幾乎總是大於1500位元組(這表示傳送了多個RADIUS封包來傳輸憑證訊息),且如果整個網路路徑中有多個不同的MTU,則可能會發生RADIUS封包本身的過度分段。在此類情況下,我們建議您透過同一路徑為WLC流量傳送所有UDP資料包,以避免可能導致網際網路天氣延遲或抖動等問題