This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
We are using ACS v18.104.22.168.3 in 802.1X certificate based authentication. Now, when we added CRL functionality into ACS it fails in CRL validation and gives following error message:
LastErrorMessage=CRL PKI verification failed
Certificate Revocation list Url=http://crl.download.net/XXXX/deviceCA.crl
We have installed root, device and server certificates from CA, but for management we are still using self-signed certificate.
Question is, which certificate is used when validating downloaded CRL file - one used for EAP-TLS or one used for management interface?
How I can check which certificate ACS server is using for CRL validation?
thanks for clearing this.
Mit freundlichen Grüßen
Security Network Services
Tel.: +49 251 7133 2402
Fax.: +49 251 7133 92402
Mobil: +49 172 2623879
VR Netze GmbH
Weseler Straße 480
Geschäftsführer: Winfried Richert, Martin Schauer
Sitz: Münster/Westf., Registergericht: AG Münster, HRB 10235
An: Karsten Jaschultowski
Datum: 16.04.2012 07:59
It actually works in ASC 5.3 and I had verified also that it works, In ACS actually CRL is downloaded based on time we specified in CRL download option time and it chekes the client certificate from CRL list, if client certificate is revoked and ACS downloaded the CRL after that it will not fail authetication of that client.
This is basic functionality of CRL and oit should always work
Did you have to change the format of the CRL to get it to work with ACS? - or was the issue the CA chain used?
(the CRL %20 URL problem is another trip up point - on ACS the %20 entries in a http CRL path must be converted to whitespace character)
I'm using Microsoft PKI and trying to figure if I have to do 'something' to the format of the CRL to get ACS to be able to read it properly
Are you using Microsoft PKI and if so how/what did you change with respect to the CRL format?
I solved this problem by converting CRL file into .PEM format with openssl and I'm using this method in two cases; one where we are using Microsoft PKI and other where CA is unix based.
We didn't notice any problems with %20 conversion as I took care that there is no spaces in CRL URL.
So to summarize, conversion from .DER to .PEM is necessary (and this applies also to ISE installations).
But can't help groaning - would think that after all this time this would be taken care of under the hood of ACS (and definitley ISE!)
So to have a timely mechanism for CRL propogation for EAP/TLS we have to look at;
Set the Microsoft PKI to publish new CRL file (not a delta) on say daily basis and
Set a timed batch job to run oppenssl after that to do PEM conversion and
Set ACS to retrieve CRL after all that
Pity there not an app for that... :-(