M031097
asked on
ignore CRL during smart card logon (3rd party CA)
Hello,
we're using smart cards (required) provided by a third party to logon to windows. Every now and then the CRL-retrieval fails which obviously is not good. Usually a new CRL is successfully retrieved prior to the old CRL expires but on two occasions it did not.
This meant that all users was locked out and only got a error message when they tried to logon to windows.
So, to minimize the impact if this should happen again I'd like to be able to ignore the expiration-date of a CRL.
Basically:
if a CRL exists, check it
if it's old, ignore it and let the users in
Yes, I am aware that this is a security issue, but it is only during a very limited time that a potential hacker/disgruntled employee can use it.
Is it at all possible to ignore CRL-checking during windows logon?
Is it possible to have the granularity I want?
regards,
M
we're using smart cards (required) provided by a third party to logon to windows. Every now and then the CRL-retrieval fails which obviously is not good. Usually a new CRL is successfully retrieved prior to the old CRL expires but on two occasions it did not.
This meant that all users was locked out and only got a error message when they tried to logon to windows.
So, to minimize the impact if this should happen again I'd like to be able to ignore the expiration-date of a CRL.
Basically:
if a CRL exists, check it
if it's old, ignore it and let the users in
Yes, I am aware that this is a security issue, but it is only during a very limited time that a potential hacker/disgruntled employee can use it.
Is it at all possible to ignore CRL-checking during windows logon?
Is it possible to have the granularity I want?
regards,
M
ASKER
Thanks for your input.
Unfortunately it's not really what I'm after.
The CRLs are created as soon as a certificate is revoked.
So it's not really the CRL-generation that causes problem, it's during the times where
the retrieval from the third-party CA fails, regardless of reason.
And fails for the entire validity of course.
/M
Unfortunately it's not really what I'm after.
The CRLs are created as soon as a certificate is revoked.
So it's not really the CRL-generation that causes problem, it's during the times where
the retrieval from the third-party CA fails, regardless of reason.
And fails for the entire validity of course.
/M
I still hold true to my previous answer, but with this change put into it to make it real.
It sounds to me like there is an issue with how and/or how often they publish their CRLs. Maybe not enough bandwidth, but probably more likely either issuing Base CRLs every revocation instead of Delta CRLs, or having a Base CRL that is just getting out of hand.
1) When certs are revoked either wait until the next CRL publication period, or create a Delta CRL as needed.
2) Adjust certificate lifetimes so that the CRL does not become overly populated (512 key - do not use, 1024 = 1 year, 2048 = 3 year max).
3) Base CRLs are only issued on predetermined schedule. This should be every 1/2 CRL Publication Interval - e.g. weekly CRL should be pushed by automated batch script every 3 or 4 days. This allows for clients to download the new CRL prior to need.
4) Consider extending the CRL publication Interval to reduce the need to check it, if it is being issued to oftten already.
5) Conider issuing the Base CRL more frequently if the Delta CRLs are getting unruly.
6) When issuing certs, consider adding more procedures to the vetting process to reduce revocations during the issuance stage. If not already using certutil -dump to verify (or some other similar process) then that would be a good place to start to cut down on a number of issuance related issues.
7) Implement OCSP. This is automatic with Vista/2008 and most current Linux distros. WinXP/03 and earlier you can shop for 3rd party OCSP client software. This would also require an OCSP server to be set up on the CA end - if this is a big enough place like DoD where htey are revoking certs frequently under legitimate pretenses, then they would likely already have this in place on their end. Otherwise they might want to do this. In a nutshell, OCSP sends info about the cert (about the cert - not you) to the OCSP responder which checks its database and send you back its reply saying if that single cert is good or not. No more big giant CRL downloads, only tiny 16k OCSP responses. The OCSP responder gets updated by CRL and is authorized by the CA. In MS CAs this is best done when upgrading from 2003 to 2008 CA (and is one of many major reasons to do so). Plus it cuts down on their bandwidth costs. It technically can be done under 2003, but its a mess - do it when upgarding to 08, trust me.
8) Here is the big one - time to close out this CRL and start a new one - this is assuming that the CA isn't coming from a major non-commercial CA like DoD. In other words, the CRL is too big, time to make it so that the old one can just be downloaded and left alone, and all new certs are issued so that they are checked against a new CRL. This can be done a number of different ways:
7a) Issue a new CA cert for the issuing CA (can still keep the same CA keyset). This is actually the suggested option in most cases. The root CA should hopefully be a different server, so impact should be nominal.
7b) CRL partitioning or other alternate method of splitting up the CRL into chunks.
It sounds to me like there is an issue with how and/or how often they publish their CRLs. Maybe not enough bandwidth, but probably more likely either issuing Base CRLs every revocation instead of Delta CRLs, or having a Base CRL that is just getting out of hand.
1) When certs are revoked either wait until the next CRL publication period, or create a Delta CRL as needed.
2) Adjust certificate lifetimes so that the CRL does not become overly populated (512 key - do not use, 1024 = 1 year, 2048 = 3 year max).
3) Base CRLs are only issued on predetermined schedule. This should be every 1/2 CRL Publication Interval - e.g. weekly CRL should be pushed by automated batch script every 3 or 4 days. This allows for clients to download the new CRL prior to need.
4) Consider extending the CRL publication Interval to reduce the need to check it, if it is being issued to oftten already.
5) Conider issuing the Base CRL more frequently if the Delta CRLs are getting unruly.
6) When issuing certs, consider adding more procedures to the vetting process to reduce revocations during the issuance stage. If not already using certutil -dump to verify (or some other similar process) then that would be a good place to start to cut down on a number of issuance related issues.
7) Implement OCSP. This is automatic with Vista/2008 and most current Linux distros. WinXP/03 and earlier you can shop for 3rd party OCSP client software. This would also require an OCSP server to be set up on the CA end - if this is a big enough place like DoD where htey are revoking certs frequently under legitimate pretenses, then they would likely already have this in place on their end. Otherwise they might want to do this. In a nutshell, OCSP sends info about the cert (about the cert - not you) to the OCSP responder which checks its database and send you back its reply saying if that single cert is good or not. No more big giant CRL downloads, only tiny 16k OCSP responses. The OCSP responder gets updated by CRL and is authorized by the CA. In MS CAs this is best done when upgrading from 2003 to 2008 CA (and is one of many major reasons to do so). Plus it cuts down on their bandwidth costs. It technically can be done under 2003, but its a mess - do it when upgarding to 08, trust me.
8) Here is the big one - time to close out this CRL and start a new one - this is assuming that the CA isn't coming from a major non-commercial CA like DoD. In other words, the CRL is too big, time to make it so that the old one can just be downloaded and left alone, and all new certs are issued so that they are checked against a new CRL. This can be done a number of different ways:
7a) Issue a new CA cert for the issuing CA (can still keep the same CA keyset). This is actually the suggested option in most cases. The root CA should hopefully be a different server, so impact should be nominal.
7b) CRL partitioning or other alternate method of splitting up the CRL into chunks.
ASKER
Hi again,
I am sorry, I might have been unclear but you're missing the point.
In 99% of the time everything works fine.
It is not the CRL in itself that is the problem it is how Windows uses the CRL.
When you use a third-party CA you trust that CA... in every way... BUT, if
you cannot download the new CRL during the old CRLs validity (again, for
whatever reason), what will you do?
You do have many valid points, but the main problem is, that if you fail the 3rd
party CRL download....well what then?
I am sorry, I might have been unclear but you're missing the point.
In 99% of the time everything works fine.
It is not the CRL in itself that is the problem it is how Windows uses the CRL.
When you use a third-party CA you trust that CA... in every way... BUT, if
you cannot download the new CRL during the old CRLs validity (again, for
whatever reason), what will you do?
You do have many valid points, but the main problem is, that if you fail the 3rd
party CRL download....well what then?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The main idea of getting them to publish the CRL by script instead of automatically is so that the clients do have the ability to download it early. The CRL should not expire in less than a full day, even in secure environments. Usually in normal environments once a week or month is plenty. Then you push a script to cut a new CRL well before the old one expires, cutting down on latency issues (not to mention giving the CA admin time to recover in case of failure right before the CRL expires).
ASKER
It seems that what I want to do is not possible.
A sort-of dynamic disabling of CRL-checking.
Any way, thanks for your input
Regards,
M
Normally the CRL will automatically publish itself at 90% of the lifespan, if memory serves. What is normally done is to publish it at least at the halfway point. By this I mean that if it publishes once per week, have it scripted to do so every 3 days, if once per day then script every 12 hours, etc. This way there is plenty of overlap.
Sometimes they don't think of scripting copying the CRL from the windows\system32\certsrv\c
If you want to be extra helpful to them, I have a generic script for doing so in this article you could send them:
https://www.experts-exchange.com/questions/23813051/Subordinate-Certificate-authority-CRL-Downloading-how-is-it-done.html
This way you do not compromise your security for their shortcomings. Bypassing this type of setting is really not a good idea if cert logon is required.
Note: if it is just a connection issue to the CRL, the first time the client connects it will cache the CRL and a method to validate the cert offline. This is done mainly for laptops. The previous 10 user accounts that log in (using or not using certs) will be cached by default.