Full interworking of a Cisco PIX firewall with KCA
Originally Published: 2002-08-02
Article Number
Applies To
Sun Solaris
Microsoft Windows 2000
Keon Certificate Authority 6.0.x
Issue
PIX firewall fails to obtain certificate from KCA over SCEP
Cause
Resolution
1. PIX will only use SCEP on port 80, meaning the port numbers for KCA need to be configured to cater for this; therefore, make sure you end up with SCEP on 80, not the default installation value of 446
2. A nextUpdate field in issued CRLs must be present; this is done by manually editing RSAKeon_CA\xudad\conf\xudad.conf to include a "crltimer" entry as shown below:
crltimer md5="d4e78296cb58cc761d807bcfa437d075" 900
The MD5 value is the CA's MD5 value for the particular used. For more information, see the section titled "Rules for Setting Complete CRL Timer Directives" in the Keon Certificate Authority Administrator's Guide.
3. The time on the PIX must be correct; there are three areas where this one gets done incorrectly:
a. Watch out for the year - after a rebuild the system may set itself to be 1993
b. Watch out for UTC time being used rather than local time - there are time zone settings available
c. Small differences between KCA time and PIX time is allowed, but some time differences can cause problems (see notes below)
Having configured all of the above requirements, the following sequence of commands might be used on a PIX to configure the system:
pix-01(config)# no ca id test
pix-01(config)# ca id test 10.1.1.14:/72c838016e450eec35b764f13639a17274487f
pix-01(config)# ca conf test ca 1 10
pix-01(config)# ca auth test
pix-01(config)# ca enroll test 1234 serial
pix-01(config)# ca crl request test
pix-01(config)# show ca crl
NOTE: The URL specified in the second line above is complete and DOES NOT have /pkiclient.exe at the end
Notes on time differences:
- A PIX will reject a generated CRL with an error "Unable to process inner content". The reason for this is that the PIX's current time did not fall within the time interval specified by the CRL's 'thisUpdate' field and 'nextUpdate' field. For example, if the PIX clock was 5 minutes ahead of the KCA installation, and the CRL generation granularity was set to 60 seconds, the PIX time would always be ahead of both thisUpdate and nextUpdate, and thus cause a processing failure 100% of the time.
- In the failure example above, the router and KCA clocks may be synchronized clock to GMT-1/UTC within 10 seconds of variance. This removes the problem completely, and the CRLs will be accepted by the PIX.
- Increasing the update interval of the CRLs would also fix the problem if times cannot be synchronized perfectly
- If the same test were conducted using a different CA (e.g. Microsoft Windows 200 CA), the same granular variance between CRL update intervals and the router's clock will produce exactly the same content processing errors
- In all instances, all equipment is functioning correctly, but the times on the devices must be set correctly
Related Articles
RADIUS cannot be managed after rebooting RSA AM server running 7.1 SP4 full kit. Number of Views How to enable full debug WinSSHD Number of Views RSA Governance & Lifecycle - Full Backup Script for Hardware Appliances or Software-Bundles with RSA-provided Database Number of Views I1912 - The SEL is full of events and is unable to log any more Number of Views AFX Requests fails to process as the Usage Store Manager is full in RSA Governance & Lifecycle Number of Views
Trending Articles
Passwordless Authentication in Windows MFA Agent for Active Directory – Quick Setup Guide RSA Authentication Manager Upgrade Process RSA Authentication Manager 8.9 Release Notes (January 2026) An example of SSO using SAML and ADFS with RSA Identity Management and Governance 6.9.x RSA MFA Agent 2.3.6 for Microsoft Windows Installation and Administration Guide
Don't see what you're looking for?
