Keon certificate Authority 6.5.1
Microsoft Windows 2000
Sun Solaris 2.8
|Issue||How 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
|Cause||Where 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:
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).
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 ID||a27216|