Guest Yossi Sara Posted August 28, 2008 Posted August 28, 2008 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 Quote
Guest S. Pidgorny Posted August 28, 2008 Posted August 28, 2008 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/...dows-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:<span style="color:blue"> > 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 > </span> Quote
Guest powersnakop@gmail.com Posted August 28, 2008 Posted August 28, 2008 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' Quote
Guest James McIllece [MS] Posted August 28, 2008 Posted August 28, 2008 powersnakop@gmail.com wrote in news:8c1bc430-020c-4687-80b1- bbfa3ee02007@l64g2000hse.googlegroups.com: <span style="color:blue"> > 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' > </span> 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. Quote
Guest powersnakop@gmail.com Posted September 1, 2008 Posted September 1, 2008 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'. Quote
Guest S. Pidgorny Posted September 1, 2008 Posted September 1, 2008 powersnakop@gmail.com wrote:<span style="color:blue"> > 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'.</span> 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 Quote
Guest Han Valk Posted September 20, 2008 Posted September 20, 2008 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]" <jamesmci@online.microsoft.com> wrote: Snip<span style="color:blue"> > >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. ></span> Snip<span style="color:blue"> >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. ></span> Quote
Guest Paul Adare - MVP Posted September 20, 2008 Posted September 20, 2008 On Sat, 20 Sep 2008 10:07:18 +0200, Han Valk wrote: <span style="color:blue"> > Does this mean that if my root cert has no CDP entries, as per best > practise, CRL check will fail?!</span> 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. Quote
Guest Borderman Posted October 14, 2008 Posted October 14, 2008 Hi. Did you solve this issue? We are expereing the same thing over here. "powersnakop@gmail.com" wrote: <span style="color:blue"> > 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' > > </span> Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.