000022181 - How to use SCEP with nCipher HSM

Document created by RSA Customer Support Employee on Jun 16, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000022181
Applies To
Keon certificate Authority 6.5.1

Microsoft Windows 2000
Sun Solaris 2.8
SCEP

nCipher

HSM
IssueHow to use SCEP with nCipher HSM
CRYPTO_PKI:Received PKI message (PKCS7) for trustpoint non-persist-scep: 10 bytes

 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A
CauseWhere an nCipher HSM is used to sign SCEP certificates then certain rules apply, due to the original design of the SCEP protocol from Cisco there is a mandatory requirement for the private key of the selected CA to be available during the request phase of the SCEP transaction; this is regardless of whether SCEP autovetting is enabled or disabled for the jurisdiction.
The reason for this is that when a Cisco router submits a SCEP request it mandates one of three responses from the CA (or RA)
 
    1)  SUCCESS - this is where autovetting has occurred and the Cisco router receives a signed certificate
    2)  FAILURE - with a reject reason
    3)  PENDING - acceptance of the request but autovetting is disabled.
 
The problem is that in all instances the response has to be sent back as signed PKCS#7 data which implicitly will need the private key of the CA available to carry out this task.
 
This means that you need to plan how to use the nCipher card sets carefully (especially where multiple card sets are used) when used for SCEP signing and where the chosen cardset does not meet the requirements that a SCEP request will not only fail to produce a signed certificate but that the response from KCA cannot fall into any of the specified categories that are in the Cisco specification (since it does not cater for this eventuality).  The basic rule is that the PIN of either card must be available at all times and that if the cardset is non-persistent that the card is still in the nCipher card reader.
 
In terms of KCA, the HTTP response that is returned will be totally invalid and will generate an unavoidable CERTFAIL error on the Cisco router.  Where debugging is enabled at the Cisco router the expected response will be:
 
Jul 26 23:36:08.690: CRYPTO_PKI: http connection opened
Jul 26 23:36:15.293: CRYPTO_PKI:  received msg of 188 bytes
Jul 26 23:36:15.293: CRYPTO_PKI: HTTP response header:
 HTTP/1.1 200 OK
Date: Tue, 26 Jul 2005 23:33:56 GMT
Server: Apache/1.3.26 (Win32) mod_ssl/2.8.10 SSL-C
Cache-Control: max-age=0
Connection: close
Content-Type: text/html
 

Jul 26 23:36:15.297: CRYPTO_PKI:Received pki message (PKCS7) for trustpoint non-persist-scep: 10 bytes
 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A                          ..........
 
Jul 26 23:36:15.337: E ../cert-c/source/p7contnt.c(167) : Error #706h
Jul 26 23:36:15.337: pkcs7 verify data returned status 0x706
Jul 26 23:36:15.337: CRYPTO_PKI: status = 1798: failed to verify
Jul 26 23:36:15.337: %PKI-6-CERTFAIL: Certificate enrollment failed.
Jul 26 23:36:15.337: CRYPTO_PKI: All enrollment requests completed for trustpoint non-persist-scep.
In this specific example "non-persist-scep" is the local name of the trustpoint that has been configured in the Cisco router and this would differ for every site.
 
Although this error does not conform to the draft SCEP specification from Cisco it is the only possible response that the KCA can give under the circumstances (since to supply any additional data in the non-PKCS#7 packet could be considered a security risk - basically the unencrypted traffic should give no indication as to what data can be delivered via the HTTP port).
Resolution
When designing and configuring a KCA system to allow SCEP enrollment where an nCipher HSM is used great care should be taken over the configuration of the nCipher card sets.  Chapter 7. "Starting and Stopping Keon CA" of the "RSA Keon certificate Authority 6.5.1 Administrator's Guide" gives details of both the setpin and promptpin directives which are likely to play a part in this design.
 
Due to the nature of the way that routers are configured for enrollment and re-enrollment it is common to want to configure the Keon Certificate Authority for Auto-vetting since this allows the entire process to occur without administrator (or vettor) intervention.
Legacy Article IDa27216

Attachments

    Outcomes