CRL Checking....

I am working in a Windows 2003 server environment with Windows XP SP2 clients.
We are using Smart Card Login (or trying to) and we keep getting an error that
states: "The revocation function was unable to check revocation for the
certificate"

Now the root CA is offline. We have loaded all the CRL's on the Domain
Controller
and the client. However we continue to get this error.

Is there a way to disable CRL checking for Smart Card logon so that we can
verify that all other settings are correct?

Thanks for any pointers.

Brian
Tue Feb 13 12:21:05 CST 2007

In article <E72D8A9E-D53C-47F7-8AA5-47E10CA97914@microsoft.com>,
Joe@discussions.microsoft.com says...
> I am working in a Windows 2003 server environment with Windows XP SP2 clients.
> We are using Smart Card Login (or trying to) and we keep getting an error that
> states: "The revocation function was unable to check revocation for the
> certificate"
>
> Now the root CA is offline. We have loaded all the CRL's on the Domain
> Controller
> and the client. However we continue to get this error.
>
> Is there a way to disable CRL checking for Smart Card logon so that we can
> verify that all other settings are correct?
>
> Thanks for any pointers.
>
You need to fix your infrastructure, not stop CRL checking. What you
need to do is run certutil -verify -urlfetch <smartcardcert.cer> against
one of the smart card certs.

My guess is that you incorrectly set up the offline CAs and do not
reference valid URLs for CRL publication. This means that you need to
fix the errors and redeploy both CA and smart card certs.
Brian

Joe
Tue Feb 13 12:43:01 CST 2007

Brian,

Thank you for not answering the question.

These certificates and the exact setup are working in our Dev environment,
but are failing in production. So, since it is all setup exactly the same and
it works one place and not the other, then there has to be something else.

So, by turning off CRL checking (since that is the error) we can verify that
all other pieces are working correctly. If something else is triggering this
error, then we can correct that and turn CRL checking back on.

"Brian Komar [MVP]" wrote:

> In article <E72D8A9E-D53C-47F7-8AA5-47E10CA97914@microsoft.com>,
> Joe@discussions.microsoft.com says...
> > I am working in a Windows 2003 server environment with Windows XP SP2 clients.
> > We are using Smart Card Login (or trying to) and we keep getting an error that
> > states: "The revocation function was unable to check revocation for the
> > certificate"
> >
> > Now the root CA is offline. We have loaded all the CRL's on the Domain
> > Controller
> > and the client. However we continue to get this error.
> >
> > Is there a way to disable CRL checking for Smart Card logon so that we can
> > verify that all other settings are correct?
> >
> > Thanks for any pointers.
> >
> You need to fix your infrastructure, not stop CRL checking. What you
> need to do is run certutil -verify -urlfetch <smartcardcert.cer> against
> one of the smart card certs.
>
> My guess is that you incorrectly set up the offline CAs and do not
> reference valid URLs for CRL publication. This means that you need to
> fix the errors and redeploy both CA and smart card certs.
> Brian
>

Brian
Wed Feb 14 08:47:16 CST 2007

As I stated earlier, you cannot turn off CRL checking for smart card
certs.
Please run the certutil command provided earlier and post the output for
assistance. This command will detail the exact nature of your CRL
checking error.
Brian

In article <95D091D1-D3E3-4D87-B9FB-D32D0CEFF2F3@microsoft.com>,
Joe@discussions.microsoft.com says...
> Brian,
>
> Thank you for not answering the question.
>
> These certificates and the exact setup are working in our Dev environment,
> but are failing in production. So, since it is all setup exactly the same and
> it works one place and not the other, then there has to be something else.
>
> So, by turning off CRL checking (since that is the error) we can verify that
> all other pieces are working correctly. If something else is triggering this
> error, then we can correct that and turn CRL checking back on.
>
> "Brian Komar [MVP]" wrote:
>
> > In article <E72D8A9E-D53C-47F7-8AA5-47E10CA97914@microsoft.com>,
> > Joe@discussions.microsoft.com says...
> > > I am working in a Windows 2003 server environment with Windows XP SP2 clients.
> > > We are using Smart Card Login (or trying to) and we keep getting an error that
> > > states: "The revocation function was unable to check revocation for the
> > > certificate"
> > >
> > > Now the root CA is offline. We have loaded all the CRL's on the Domain
> > > Controller
> > > and the client. However we continue to get this error.
> > >
> > > Is there a way to disable CRL checking for Smart Card logon so that we can
> > > verify that all other settings are correct?
> > >
> > > Thanks for any pointers.
> > >
> > You need to fix your infrastructure, not stop CRL checking. What you
> > need to do is run certutil -verify -urlfetch <smartcardcert.cer> against
> > one of the smart card certs.
> >
> > My guess is that you incorrectly set up the offline CAs and do not
> > reference valid URLs for CRL publication. This means that you need to
> > fix the errors and redeploy both CA and smart card certs.
> > Brian
> >
>

Paul
Thu Feb 15 07:58:39 CST 2007

In article <95D091D1-D3E3-4D87-B9FB-D32D0CEFF2F3@microsoft.com>,
in the microsoft.public.security news group, =?Utf-8?B?Sm9l?=
<Joe@discussions.microsoft.com> says...

> Thank you for not answering the question.

Brian did answer the question you just didn't happen to like the
answer he gave you. You may want to listen to him.

http://www.amazon.com/Microsoft-Windows-Server-Certificate-
Security/dp/0735620210/ref=pd_sim_b_2/105-0439668-9812462

or

http://tinyurl.com/3az7ld

Note who the author is and check out some of the reviews.

--
Paul Adare
MVP - Windows - Virtual Machine
http://www.identit.ca
"The English language, complete with irony, satire, and sarcasm,
has survived for centuries without smileys. Only the new crop of
modern computer geeks finds it impossible to detect a joke that
is not clearly labeled as such."
Ray Shea

Paul
Thu Feb 15 08:15:10 CST 2007

In article <MPG.203e3118c4db83df98a3e7@msnews.microsoft.com>, in
the microsoft.public.security news group, Paul Adare
<padare@newsguy.com> says...

> Brian did answer the question you just didn't happen to like the
> answer he gave you. You may want to listen to him.
>

This link should also be something you peruse, and again, not
the list of authors.

http://www.microsoft.com/technet/prodtechnol/winxppro/support/ts
htcrl.mspx

or

http://tinyurl.com/4kbmn

--
Paul Adare
MVP - Windows - Virtual Machine
http://www.identit.ca
"The English language, complete with irony, satire, and sarcasm,
has survived for centuries without smileys. Only the new crop of
modern computer geeks finds it impossible to detect a joke that
is not clearly labeled as such."
Ray Shea

Paul
Thu Feb 15 08:21:52 CST 2007

In article <MPG.203e34fd35dabf8c98a3e9@msnews.microsoft.com>, in
the microsoft.public.security news group, Paul Adare
<padare@newsguy.com> says...

> not
>

err, note, not not. :-)

--
Paul Adare
MVP - Windows - Virtual Machine
http://www.identit.ca
"The English language, complete with irony, satire, and sarcasm,
has survived for centuries without smileys. Only the new crop of
modern computer geeks finds it impossible to detect a joke that
is not clearly labeled as such."
Ray Shea

alun
Sun Feb 18 17:06:29 CST 2007

"Joe" <Joe@discussions.microsoft.com> wrote in message
news:95D091D1-D3E3-4D87-B9FB-D32D0CEFF2F3@microsoft.com...
> Brian,
>
> Thank you for not answering the question.

There's a lot of that going around. There's a few causes:
1. Your question wasn't well-phrased, so nobody understood what you were
trying to say.
2. You asked a question that was meaningless, and the answerer tried his
best to figure out what the question was supposed to be.
3. Your question took as a basic assumption something that is incorrect, and
the answerer suggested that you should step back from the question based on
a fallacy, and proceed to correcting the fallacy before asking the next
question.
4. You asked a good question, and some idiot decided that the best use of
his time that day would be to frustrate you by posting random advice that
had no bearing on your question.

You appear to have jumped straight to step 4 without considering 1 through
3.

> These certificates and the exact setup are working in our Dev environment,
> but are failing in production. So, since it is all setup exactly the same
> and
> it works one place and not the other, then there has to be something else.

Then the setup is not exactly the same. Perhaps the biggest difference is
that it is not in the "same place". Are the certificates pointing to CRL
hosting sites on the Dev environment, which is presumably not reachable from
the Production environment (at least, I'd hope they're separated)?

> So, by turning off CRL checking (since that is the error) we can verify
> that
> all other pieces are working correctly. If something else is triggering
> this
> error, then we can correct that and turn CRL checking back on.

Given that CRL checking is the only thing that you have identified as
failing so far, it seems like it would be relatively easy to trace and fix.

What is the problem with following Brian's advice, and just trying to look
at the CRL sources to see whether they can be reached at all? Humour Brian -
it took him longer to type his answer than it will for you to try it.

Alun.
~~~~
--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.

Magnus
Wed Feb 28 09:19:29 CST 2007

>Is there a way to disable CRL checking for Smart Card logon so that we can
>verify that all other settings are correct?

So, I have deduced, that it is NOT possible to turn off CRL checking in
Windows when using SmartCards.

It is unfortunate that it is so. That would really be a useful feature.

Why, you might ask, would anyone willingly *lower* their security settings?

Because:

Imagine that you are using a high-security CA with frequent CRL publishing.
(So that a lost smartcard will be revoked quickly, say in days or in a week.)

One day, for one reason or another, the CRL-file is inaccessible. (Can be a
third-party CA that is having problems, can be problem with AD replication,
can be configuration error with IIS etc).

Soon, workers will not be able to log in using their smartcards (when the
presumably cached copy of the CRL will time-out on the DCs).

Now, in an *agile* business, the Security Manager is faced with a Risk
Management Decision:
1) accept potentially revoked smartcards
OR
2) shutting out the workers of the IT-environment.

However, since turning off CRL checking is NOT possible in Windows, the
Security Manager cannot make that decision, it is made *for* him.

And depending on the business you are in, that might or might not be a good
Risk Management Decision.

One way to remedy this deficiency in Windows is to implement an automated
way of turning off "Require SmartCard-logon" if such a scenario would arise.
I would prefer temporarily disabling CRL-checking.

Just my 0,50 SEK

/Magnus

MagnusLf
Wed Feb 28 09:23:06 CST 2007

just found http://support.microsoft.com/default.aspx/kb/887578 which (if it
works, calling Microsoft right now) completely solves my problems.

<happy>Magnus</happy>

Brian
Wed Feb 28 09:50:46 CST 2007

Why not fix your CRL publication problems in the first place. Your=20
endless rants are quite tiresome (and boring)...
A high-security CA would be set up *correctly* so that CRL publication=20
issues would not happen. Even in the case of a failed CA, the existing=20
CRL can be re-signed.
Your refusal to even publish the results from certutil -verify -urlfetch=20
is astonishing
Oh well,
Brian

In article <9006811F-357E-4780-80FE-702E5FDF1341@microsoft.com>, =3D?Utf-
8?B?TWFnbnVzIEzDtsO2Zg=3D=3D?=3D <Magnus L=F6=F6f@discussions.microsoft.com=
>=20
says...
> >Is there a way to disable CRL checking for Smart Card logon so that we c=
an
> >verify that all other settings are correct?=20
>=20
> So, I have deduced, that it is NOT possible to turn off CRL checking in=
=20
> Windows when using SmartCards.
>=20
> It is unfortunate that it is so. That would really be a useful feature.
>=20
> Why, you might ask, would anyone willingly *lower* their security setting=
s?
>=20
> Because:
>=20
> Imagine that you are using a high-security CA with frequent CRL publishin=
g.=20
> (So that a lost smartcard will be revoked quickly, say in days or in a we=
ek.)
>=20
> One day, for one reason or another, the CRL-file is inaccessible. (Can be=
a=20
> third-party CA that is having problems, can be problem with AD replicatio=
n,=20
> can be configuration error with IIS etc).
>=20
> Soon, workers will not be able to log in using their smartcards (when the=
=20
> presumably cached copy of the CRL will time-out on the DCs).
>=20
> Now, in an *agile* business, the Security Manager is faced with a Risk=20
> Management Decision:
> 1) accept potentially revoked smartcards=20
> OR=20
> 2) shutting out the workers of the IT-environment.
>=20
> However, since turning off CRL checking is NOT possible in Windows, the=
=20
> Security Manager cannot make that decision, it is made *for* him.=20
>=20
> And depending on the business you are in, that might or might not be a go=
od=20
> Risk Management Decision.=20
>=20
> One way to remedy this deficiency in Windows is to implement an automated=
=20
> way of turning off "Require SmartCard-logon" if such a scenario would ari=
se.=20
> I would prefer temporarily disabling CRL-checking.
>=20
> Just my 0,50 SEK
>=20
> /Magnus
>=20

MagnusLf
Wed Feb 28 10:29:00 CST 2007

Brian, I am *planning*, not having problems.

Of course my CRL publication is working flawlessly - I know my stuff, I
learned it from you.

But my third-party CA *might* be inaccessible in the future. And I am
planning for business continuity.

All I am saying is, a network manager should *be able* to make a Risk
Management Decision:

Potentially allowing revoked smartcards while providing Business Continuity.

That should be up to the network admin to decide.

Thanks to the hotfix above, I *can* provide the admin with Business
Continuity, in case the CRL-file is inaccessible.

/Magnus

btw, If you don't agree, what do you think prompted MS to create the hotfix
(and include it in sp2)? A scenario, such as the one I described, no doubt.

MagnusLf
Wed Feb 28 15:30:13 CST 2007

Back from the lab, I can confirm that the 887578 hotfix works. According to
MS support, it will be included in the next Windows Server Service Pack.

Setting the CRLValidityExtensionPeriod value to '200' (hours), it allowed me
to log on using a week old CRL-file.

After resetting the regvalue to '0', logons failed again as expected.

I rebooted each DC after the config changes for good measure. I am not sure
if it is needed after the value is reset back to 0.

Great!

/M

Paul
Wed Feb 28 21:48:10 CST 2007

In article <9006811F-357E-4780-80FE-702E5FDF1341
@microsoft.com>, in the microsoft.public.security news
group, <=?Utf-8?B?TWFnbnVzIEzDtsO2Zg==?= <Magnus
Lööf@discussions.microsoft.com>> says...

> >Is there a way to disable CRL checking for Smart Card logon so that we can
> >verify that all other settings are correct?
>
> So, I have deduced, that it is NOT possible to turn off CRL checking in
> Windows when using SmartCards.

There was no need for you to "deduce" this, you were told
explicitly this isn't possible.

>
> It is unfortunate that it is so. That would really be a useful feature.
>
> Why, you might ask, would anyone willingly *lower* their security settings?
>
> Because:
>
> Imagine that you are using a high-security CA with frequent CRL publishing.
> (So that a lost smartcard will be revoked quickly, say in days or in a week.)

Then you either need to do the correct thing and disable
the associated AD account, which happens immediately, or
look at OCSP, not CRLs.

>
> One day, for one reason or another, the CRL-file is inaccessible. (Can be a
> third-party CA that is having problems, can be problem with AD replication,
> can be configuration error with IIS etc).

This is why you need to plan for redundant, highly
available CDP locations.

>
> Soon, workers will not be able to log in using their smartcards (when the
> presumably cached copy of the CRL will time-out on the DCs).
>
> Now, in an *agile* business, the Security Manager is faced with a Risk
> Management Decision:
> 1) accept potentially revoked smartcards

Disable the AD account.

> OR
> 2) shutting out the workers of the IT-environment.

Why?

>
> However, since turning off CRL checking is NOT possible in Windows, the
> Security Manager cannot make that decision, it is made *for* him.

No, it isn't. You just need to engineer the solution
correctly.

>
> And depending on the business you are in, that might or might not be a good
> Risk Management Decision.
>
> One way to remedy this deficiency in Windows is to implement an automated
> way of turning off "Require SmartCard-logon" if such a scenario would arise.
> I would prefer temporarily disabling CRL-checking.

Scripting is relatively trivial.

>
> Just my 0,50 SEK
>
> /Magnus
>

--
Paul Adare
MVP - Windows - Virtual Machine
http://www.identit.ca
"The English language, complete with irony, satire, and
sarcasm, has survived for centuries without smileys. Only
the new crop of modern computer geeks finds it impossible
to detect a joke that is not clearly labeled as such."
Ray Shea

MagnusLf
Thu Mar 01 01:43:13 CST 2007

Talk about ranting...

"Paul Adare" wrote:

> >
> > So, I have deduced, that it is NOT possible to turn off CRL checking in
> > Windows when using SmartCards.
>
> There was no need for you to "deduce" this,
>

Don't be a smart ass. I "deduced" it by reading the posts.

I am not sure whether or not you are mixing up me with Joe who wrote the
original post (who was actually having problems). I just stumbled on this
post in search of a way of allowing KDC to use an expired CRL, and thought I
would share some thoughts with the community.

I don't think it is fair to pound, humiliate, flame or accuse me of ranting
(as Brian did).

>you were told
> explicitly this isn't possible.

Yes, I was. Unfortunately, you are wrong.

The KB article I mention turns off the time validity checking, which was
exactly what *I* was talking about in my post (and I am sorry I made the case
for it *before* finding the article).

Splitting hairs again, but I believe Joe (original poster) wanted to disable
CRL checking altogether, because he was having problems.

I want to be able let KDC be lenient by accepting a CRLs validity beyond its
*real* validity lifespan.

> > Imagine that you are using a high-security CA with frequent CRL publishing.
> > (So that a lost smartcard will be revoked quickly, say in days or in a week.)
>
> look at OCSP, not CRLs.
>

Just a plain dumb, ignorant statement. If I was able to use OCSP, I would
not be looking for extending CRL Validity Checking, right?

> >
> > One day, for one reason or another, the CRL-file is inaccessible. (Can be a
> > third-party CA that is having problems, can be problem with AD replication,
> > can be configuration error with IIS etc).
>
> This is why you need to plan for redundant, highly
> available CDP locations.
>

Of course, already done. As you may have deduced (intentional pun), business
continuity is very important to this project.

> >
> > Soon, workers will not be able to log in using their smartcards (when the
> > presumably cached copy of the CRL will time-out on the DCs).
> >
> > Now, in an *agile* business, the Security Manager is faced with a Risk
> > Management Decision:
> > 1) accept potentially revoked smartcards
>
> Disable the AD account.
>
> > OR
> > 2) shutting out the workers of the IT-environment.
>
> Why?

You are getting me wrong. *If* the SecMan would change the registry values
to extend the validity of CRLs, he could potentially, unknowingly, allow
smartcards that were revoked by the third party CA.

That is the negative security effect. The positive business effect would be
that users can log on, even though the CRL has expired.

Of course, if the SecMan knows about a lost smartcard, SecMan should disable
the AD account immediately. (Rather that wait a week for the CRL to come
around, hehe, that would indeed be a rather cumbersome business process.)

>> implement an automated
> > way of turning off "Require SmartCard-logon" if such a scenario would arise.
>
> Scripting is relatively trivial.

Yep, finally, we agree on something.

Since I wanted an open discussion, I just thought I would toss in a
potential (and rather easy) solution if others would come to the same
conclusion as we did in this project.

I did not know at that time that, by installing the hotfix, I actually could
let the SecMan make the decision I was talking about.

Over and out,

/M