RADIUS IAS CRL CHECK
Yossi Sara
cert. in the revocation list.
However, when the workstation is turned on, it can establish a
connection to the network.
It seems that the IAS ignores the CRL (or doesn't check CRL at all).
We know that the IAS will ignore new CRL until, that old one has
expired, so we waited until the old CRL expired, and then ran the
check.
Moreover, we added to registery the dword "IgnoreNoRevocationCheck"
and set its value to 0. It still doesn't help.
If we put the workstation's certification in the 'Untrusted
certificates' in the DC, we do get an error of "The certificate is
revoked", yet it was only a test and definitly not a solution.
My question is, how we should tell the IAS to check the new CRL, and
verify the workstations' certificates?
We have the IAS installed on two Domain controller
S. Pidgorny <MVP>
CRL?
Rationale: CRL is cached and doesn't reload every time a client connects.
Some details:
http://blogs.technet.com/pki/archive/2007/09/13/how-to-refresh-the-crl-cache-on-windows-vista.aspx
Crossposting to microsoft.public.internet.radius - maybe James will have
more to add.
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-
* http://sl.mvps.org * http://msmvps.com/blogs/sp *
power...@gmail.com
We restarted both domain controllers with the IAS, before we ran the
test.
The old CRL expired, and we believe it's not a cache issue, since the
expiration date was 2 days ago, and probably not a "CRL grace time"
problem.
We manipulated the date and hour in the whole domain, and the
workstation still established a connection.
We think that the RADIUS just ignores the new CRL.
We even published the CRL through the ldap (the CDP extention contains
http refference for the CRL location using ADSIedit), yet it didn't
help.
As for the link above, the command doesn't work. (It shows the error
written in the blog)
Do you know how long the IAS save it's own cache?
When we use 'cerutil -verify CompCertName', the result is 'Certificate
revoked'
James McIllece [MS]
bbfa3e...@l64g2000hse.googlegroups.com:
The information below might be helpful in this circumstance.
*********************
NPS/IAS Certificate Revocation List (CRL) Checks
By default, the NPS server checks for certificate revocation for all the
certificates in the certificate chain sent by the client computer during
the EAP-TLS and PEAP-TLS authentication process. If certificate revocation
fails for any of the certificates in the chain, the connection attempt is
not authenticated and is denied.
Certificate revocation checking behavior for NPS can be modified with
registry settings.
Because certificate revocation checking can prevent client access due to
the unavailability or expiration of CRLs for each certificate in the
certificate chain, design your PKI for high availability of CRLs. For
example, configure multiple CRL distribution points for each CA in the
certificate hierarchy and configure publication schedules that ensure that
the most current CRL is always available.
Certificate revocation checking is only as accurate as the last published
CRL. For example, if a certificate is revoked, by default the new CRL
containing the newly revoked certificate is not automatically published.
CRLs are typically published based on a configurable schedule. This means
that the revoked certificate can still be used to authenticate because the
published CRL is not current; it does not contain the revoked certificate
and can therefore still be used to create wireless connections. To prevent
this from occurring, the network administrator must manually publish the
new CRL with the newly revoked certificate.
By default, the NPS server uses the CRL distribution points in the
certificates. However, it is also possible to store a local copy of the CRL
on the NPS server. In this case, the local CRL is used during certificate
revocation checking. If a new CRL is manually published to the Active
Directory, the local CRL on the NPS server is not updated. The local CRL is
updated when it expires. This can create a situation wherein a certificate
is revoked, the CRL is manually published, but the NPS server still allows
the connection because the local CRL has not yet been updated.
The certificate revocation check for a certificate can fail because of the
following issues.
The certificate has been revoked
The issuer of the certificate has explicitly revoked the certificate.
The certificate revocation list (CRL) for the certificate is not reachable
or available
CAs maintain CRLs and publish them to specific CRL distribution points. The
CRL distribution points are included in the CRL Distribution Points
property of the certificate. If the CRL distribution points cannot be
contacted to check for certificate revocation, then the certificate
revocation check fails.
Additionally, if there are no CRL distribution points in the certificate,
the NPS server cannot verify that the certificate has not been revoked and
the certificate revocation check fails.
The publisher of the CRL did not issue the certificate
Included in the CRL is the publishing CA. If the publishing CA of the CRL
does not match the issuing CA for the certificate for which certificate
revocation is being checked, then the certificate revocation check fails.
The CRL is not current
Each published CRL has a range of valid dates. If the CRL Next update date
has passed, the CRL is not valid and the certificate revocation check
fails. New CRLs should be published before the expiration date of the last
published CRL.
************
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.
power...@gmail.com
Indeed in 13 (in the registery path) the type is EAP-TLS, and in 25
PEAP-TLS.
We added the NoRevocationCheck, and set its value 0, in both of them.
We changed all other registery values so the CRL should be checked
anyway. The problem occurs in both validation types.
When we use Certutil in order to validate the workstation's
certificate, we recieve a message that 'the certificate is revoked'.
S. Pidgorny <MVP>
Raise a bug with Microsoft support.
Han Valk
practise, CRL check will fail?!
Regards,
Han Valk
On Thu, 28 Aug 2008 13:43:45 -0700, "James McIllece [MS]"
<jame...@online.microsoft.com> wrote:
Snip
>
>By default, the NPS server checks for certificate revocation for all the
>certificates in the certificate chain sent by the client computer during
>the EAP-TLS and PEAP-TLS authentication process. If certificate revocation
>fails for any of the certificates in the chain, the connection attempt is
>not authenticated and is denied.
>
Snip
Paul Adare - MVP
> Does this mean that if my root cert has no CDP entries, as per best
> practise, CRL check will fail?!
No. The application is RFC 3280 compliant which means that CRL checking is
only done up to the last certificate in the chain before a self-signed
(root) certificate.
--
Paul Adare
MVP - Identity Lifecycle Manager
http://www.identit.ca
To err is human; to forgive, beyond the scope of the Operating System.
Borderman
Hi. Did you solve this issue? We are expereing the same thing over here.
Edward Davies
CAs maintain CRLs and publish them to specific CRL distribution points. The CRL distribution points are included in the CRL Distribution Points property of the certificate. If the CRL distribution points cannot be
contacted to check for certificate revocation, then the certificate revocation check fails.
We have three distribustion CRL distribution points. One of the points was offline and the Radius server failed to check the othre two pointss.
can ccomeone please explain how the radius server decides what CRL puiont to use.. I would have expected it to use the other two if one fails ??
> On Thursday, August 28, 2008 3:08 AM YossiSar wrote:
> We revoked a computer certification, and published a new crl with this
> cert. in the revocation list.
> However, when the workstation is turned on, it can establish a
> connection to the network.
> It seems that the IAS ignores the CRL (or doesn't check CRL at all).
>
> We know that the IAS will ignore new CRL until, that old one has
> expired, so we waited until the old CRL expired, and then ran the
> check.
>
> Moreover, we added to registery the dword "IgnoreNoRevocationCheck"
> and set its value to 0. It still doesn't help.
>
> If we put the workstation's certification in the 'Untrusted
> certificates' in the DC, we do get an error of "The certificate is
> revoked", yet it was only a test and definitly not a solution.
> My question is, how we should tell the IAS to check the new CRL, and
> verify the workstations' certificates?
> We have the IAS installed on two Domain controller
>> On Thursday, August 28, 2008 4:42 AM S. Pidgorny wrote:
>> For a clean test, have you tried restarting IAS server after issuing new
>> CRL?
>>
>> Rationale: CRL is cached and doesn't reload every time a client connects.
>>
>> Some details:
>> http://blogs.technet.com/pki/archive/2007/09/13/how-to-refresh-the-crl-cache-on-windows-vista.aspx
>>
>> Crossposting to microsoft.public.internet.radius - maybe James will have
>> more to add.
>>
>>
>> --
>> Svyatoslav Pidgorny, MS MVP - Security, MCSE
>> -= F1 is the key =-
>>
>> * http://sl.mvps.org * http://msmvps.com/blogs/sp *
>>
>> Yossi Sara wrote:
>>> On Thursday, August 28, 2008 4:43 PM James McIllece [MS] wrote:
>>> power...@gmail.com wrote in news:8c1bc430-020c-4687-80b1-
>>> bbfa3e...@l64g2000hse.googlegroups.com:
>>>
>>>
>>> The information below might be helpful in this circumstance.
>>>
>>> *********************
>>>
>>> NPS/IAS Certificate Revocation List (CRL) Checks
>>>
>>> By default, the NPS server checks for certificate revocation for all the
>>> certificates in the certificate chain sent by the client computer during
>>> the EAP-TLS and PEAP-TLS authentication process. If certificate revocation
>>> fails for any of the certificates in the chain, the connection attempt is
>>> not authenticated and is denied.
>>>
>>> contacted to check for certificate revocation, then the certificate
>>> revocation check fails.
>>>
>>> Additionally, if there are no CRL distribution points in the certificate,
>>> the NPS server cannot verify that the certificate has not been revoked and
>>> the certificate revocation check fails.
>>>
>>> The publisher of the CRL did not issue the certificate
>>>
>>> Included in the CRL is the publishing CA. If the publishing CA of the CRL
>>> does not match the issuing CA for the certificate for which certificate
>>> revocation is being checked, then the certificate revocation check fails.
>>> The CRL is not current
>>>
>>> Each published CRL has a range of valid dates. If the CRL Next update date
>>> has passed, the CRL is not valid and the certificate revocation check
>>> fails. New CRLs should be published before the expiration date of the last
>>> published CRL.
>>>
>>> ************
>>> James McIllece, Microsoft
>>>
>>> Please do not send email directly to this alias. This is my online account
>>> name for newsgroup participation only.
>>>
>>> This posting is provided "AS IS" with no warranties, and confers no rights.
>>>> On Friday, August 29, 2008 10:35 PM powersnako wrote:
>>>> Thanks for your replay.
>>>> We restarted both domain controllers with the IAS, before we ran the
>>>> test.
>>>> The old CRL expired, and we believe it's not a cache issue, since the
>>>> expiration date was 2 days ago, and probably not a "CRL grace time"
>>>> problem.
>>>> We manipulated the date and hour in the whole domain, and the
>>>> workstation still established a connection.
>>>> We think that the RADIUS just ignores the new CRL.
>>>> We even published the CRL through the ldap (the CDP extention contains
>>>> http refference for the CRL location using ADSIedit), yet it didn't
>>>> help.
>>>>
>>>> As for the link above, the command doesn't work. (It shows the error
>>>> written in the blog)
>>>> Do you know how long the IAS save it's own cache?
>>>> When we use 'cerutil -verify CompCertName', the result is 'Certificate
>>>> revoked'
>>>>> On Monday, September 01, 2008 5:10 AM S. Pidgorny wrote:
>>>>> Raise a bug with Microsoft support.
>>>>>
>>>>> --
>>>>> Svyatoslav Pidgorny, MS MVP - Security, MCSE
>>>>> -= F1 is the key =-
>>>>>
>>>>> * http://sl.mvps.org * http://msmvps.com/blogs/sp *
>>>>>> On Wednesday, September 03, 2008 7:39 AM powersnako wrote:
>>>>>> Hi James, thanks for you replay.
>>>>>>
>>>>>> Indeed in 13 (in the registery path) the type is EAP-TLS, and in 25
>>>>>> PEAP-TLS.
>>>>>> We added the NoRevocationCheck, and set its value 0, in both of them.
>>>>>> We changed all other registery values so the CRL should be checked
>>>>>> anyway. The problem occurs in both validation types.
>>>>>> When we use Certutil in order to validate the workstation's
>>>>>> certificate, we recieve a message that 'the certificate is revoked'.
>>>>>>> On Saturday, September 20, 2008 4:07 AM Han Valk wrote:
>>>>>>> Does this mean that if my root cert has no CDP entries, as per best
>>>>>>> practise, CRL check will fail?!
>>>>>>>
>>>>>>> Regards,
>>>>>>> Han Valk
>>>>>>>
>>>>>>>
>>>>>>> Snip
>>>>>>> Snip
>>>>>>>>> On Tuesday, October 14, 2008 2:25 PM Borderma wrote:
>>>>>>>>> Hi. Did you solve this issue? We are expereing the same thing over here.
>>>>>>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice
>>>>>>>>> WPF Control?s Default Style or Template by Extending the WPF Designer in Visual Studio 2010
>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/d1ad0a33-d815-4083-8e97-c234fd661095/wpf-controls-default-style-or-template-by-extending-the-wpf-designer-in-visual-studio-2010.aspx