Introduction and Problem
>> The customer is setting up Secure SRST on his gateway, and while trying to authenticate the Cisco Manufacturing_CA certificate, gets an error from the CME refusing to accept the certificate.
Trustpoint 'Cisco_Manufacturing_CA' is a subordinate CA.
Authentication failed - could not validate certificate
% Error in saving certificate: status = FAIL
>> 3945 router. c3900-universalk9-mz.SPA.152-4.M5.bin -- test router
Production routers:
2911 -- 15.1(4)M7 -- the import of CMCA worked without any trustpool config.
2911 -- 15.2(4)M1 -- Here, the import of the CMCA is not working.
Actions Taken
>> On taking debug crypto pki all, we see the following when we try to authenticate the CMCA certificate using the terminal. The CME chooses another trustpoint called Trustpool1 instead of the trustpoint for the CMCA which was created by the customer.
>> Post this, the CRL (Certificate Revocation List) location that is mentioned in the certificate is looked up by the CME, and it tries to create an http connection to it. After this, it fails.
>> The Cisco Manufacturing CA certificate contains the following information for CRL.
Extension: CRLDistributionPoints (OID.2.5.29.31)
Critical: false
[
distributionPoint
fullName: 1 names
1) http://www.cisco.com/security/pki/crl/crca2048.crl (uri)
>> This router does not have connection to the internet so it cannot reach Cisco's CRL lists.
Dec 12 08:03:44.526: CRYPTO_PKI: Create a list of suitable trustpoints
Dec 12 08:03:44.526: CRYPTO_PKI: Suitable trustpoints are: Trustpool1,Cisco_Root_CA_2048,
Dec 12 08:03:44.526: CRYPTO_PKI: Attempting to validate certificate using Trustpool1
Dec 12 08:03:44.534: CRYPTO_PKI: Select crl(cn=Cisco Root CA 2048,o=Cisco Systems)
Dec 12 08:03:44.534: CRYPTO_PKI: Matching CRL not found
Dec 12 08:03:44.534: CRYPTO_PKI: Retreive CRL using HTTP URI
Dec 12 08:03:44.534: CRYPTO_PKI: status = 0: poll CRL /nCRYPTO_PKI: processing CRYPTO_HTTP_GET_CRL but session id (0) is not validCRYPTO_PKI: Bypassing SCEP capabilies request 0
Dec 12 08:03:44.534: CRYPTO_PKI: status = 65535: failed to send out the pki message
Dec 12 08:03:44.538: CRYPTO_PKI: status = 106: Blocking chain verification callback received status
>> Another point to be noted here is that the customer had no issues while authenticating trustpoints for CAPF, CAP-RTP-001, Cisco_Root_CA_2048. The issue only came into the picture when the authentication of the CMCA was being attempted.
Solution
>> The problem was solved by doing the following on the router.
Router(config)#crypto pki trustpool policy
Router(ca-trustpool)#revo
Router(ca-trustpool)#revocation-check no
Router(ca-trustpool)#revocation-check none
Analysis
>> The 3 certificates that got authenticated (CAPF, CAP-RTP-001, Cisco_Root_CA_2048) must be Root certificates, in other words, self-signed certificates at the top of PKI trust hierarchy. This means that the CME starts trusting them by simply importing [as long as the validity period is good]. No revocation check is performed since there is no revocation that happens for Root certificates.
>> Now CMCA, on the other hand is a Sub-ordinate CA, signed by another root CA [look for the Issuer-name in the CMCA certificate]. This issuer chooses to revoke the certificate of CMCA, and if it ever to be revoked, the information will be in a CRL, and the location of this CRL is embedded in CMCA's certificate by its issuer, namely the CDP.
>> So, whenever you import a certificate signed by an upper CA, the client [on which you are importing the certificate] will try to validate the certificate, one of the things it does is fetch the CRL file from CDP [open up an http connection to the server in the CDP URL]. If for some reason this connection is not established, client will mark the certificate invalid simply because it could not verify whether the certificate is revoked.
>> Bottomline, either allow this HTTP connection to happen, and let the client download the CRL file, or turn off revocation-check.
For most customers, crl revocation must be disabled for the trustpool. The CRL is located in the cloud, which many devices do not have access to.
>> The Trustpool store was created to mimic the uses of Built-in Certificate Stores in OSs and Browers.
