Discussion:
RADIUS IAS CRL CHECK
(too old to reply)
p***@gmail.com
2008-08-27 14:07:38 UTC
Permalink
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 controllers.
S. Pidgorny <MVP>
2008-08-28 08:42:30 UTC
Permalink
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 *
Post by p***@gmail.com
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
p***@gmail.com
2008-08-28 13:30:27 UTC
Permalink
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'
James McIllece [MS]
2008-08-28 20:43:45 UTC
Permalink
Post by p***@gmail.com
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'
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.
p***@gmail.com
2008-09-01 06:12:23 UTC
Permalink
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'.
S. Pidgorny <MVP>
2008-09-01 09:10:04 UTC
Permalink
Post by p***@gmail.com
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'.
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 *
Han Valk
2008-09-20 08:07:18 UTC
Permalink
Does this mean that if my root cert has no CDP entries, as per best
practise, CRL check will fail?!

Regards,
Han Valk

On Thu, 28 Aug 2008 13:43:45 -0700, "James McIllece [MS]"
<***@online.microsoft.com> wrote:

Snip
Post by James McIllece [MS]
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
Post by James McIllece [MS]
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.
Paul Adare - MVP
2008-09-20 08:22:23 UTC
Permalink
Post by Han Valk
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
2008-10-14 18:25:15 UTC
Permalink
Hi. Did you solve this issue? We are expereing the same thing over here.
Post by p***@gmail.com
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'
Miguelito
2008-11-20 10:21:01 UTC
Permalink
Post by p***@gmail.com
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 controllers.
Hola ,creo que tu problema es porque no tienes paciencia, a mí me ocurrió lo
mismo. Te explicEl período de publicación de una CRL lo establece el
administrador de la entidad emisora de certificados. No obstante, el período
de validez de la CRL se extiende desde el período de publicación para
permitir la replicación de Active Directory. De forma predeterminada, los
Servicios de Certificate Server extienden el período de publicación un 10%
(hasta un máximo de 12 horas) para establecer el período de validez. De este
modo, por ejemplo, si una entidad emisora de certificados publica una CRL
cada 24 horas, el período de validez se establece en 26,4 horas.
Además, existe una desfase de reloj de 10 minutos más que se agregan al
período de validez en cualquier extremo del período de publicación, por lo
que una CRL será válida 10 minutos antes del inicio de su período de
publicación para admitir cualquier variación en la configuración del reloj
del equipo

Espero que te ayude

Loading...