Click here to get back home

revoking ipsec certificate doesn't work
 Home | NewsGroups | Search | About
Login Password
Register Now!
 microsoft.public.windows.server.security    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
revoking ipsec certificate doesn't work Franz Schenk 09-15-2005
Posted by Franz Schenk on September 15, 2005, 4:01 pm
Please log in for more thread options
 imagine the following scenario:

- have a Windows 2003 SP1 VPN Server with standalone or enterprise
certification authority, allowing only L2TP/IPSec connections with
certificate based authentication.
- have an external company that has a computer with an installed computer
IPSec certificate from our CA for VPN access.
- The external company has knowledge of several user accounts/password that
have VPN dial in permissions to our VPN server.

- Need to disable VPN access for this external company as fast as possible.
But it's not possible to change all these user accounts/passwords.

Thought that this one is easy: Go to the certification authority, revoke the
certificate that was issued to the computer of the external company, then
manually publish the CRL and delta CRL.

Have tested this scenario, doesn't work at all. The computer from the
external company still has the IPSec certificate after several hours and
several reboots, and is able to connect to the VPN server.

Any advice, aolutions, suggestions?
Thank you all in advance for your help!
Franz




Posted by Steven L Umbach on September 15, 2005, 10:22 am
Please log in for more thread options
 Certificate revocation is not immediate on client computers. There are two
types of CRL for Windows computers - the regular and delta. The regular was
what was used until Windows 2003/XP and by default has a weekly publish
schedule. The delta CRL by default is published daily. Until your VPN server
refreshes its CRL cache with the delta CRL that contains the revoked
certificate it will not know that the certificate is revoked. I don't know
of a way to "flush the cache" to speed this up.

While revoking the certificate was a good thing to do I would not rely on
that alone to prevent access. I don't know how securely your PKI is managed
but there may be the possibility that they have other certificates. You
really need to disable the ability of the user accounts that they can use
from logging on via VPN in the dial up properties of those accounts or maybe
consider shutting down the VPN until you can decide on the best way to
proceed whether it be change the account passwords, etc. If you have a
specific Remote Access Policy that allows that company access you may also
be able to modify that policy to prevent access. --- Steve

> imagine the following scenario:
>
> - have a Windows 2003 SP1 VPN Server with standalone or enterprise
> certification authority, allowing only L2TP/IPSec connections with
> certificate based authentication.
> - have an external company that has a computer with an installed computer
> IPSec certificate from our CA for VPN access.
> - The external company has knowledge of several user accounts/password
> that have VPN dial in permissions to our VPN server.
>
> - Need to disable VPN access for this external company as fast as
> possible. But it's not possible to change all these user
> accounts/passwords.
>
> Thought that this one is easy: Go to the certification authority, revoke
> the certificate that was issued to the computer of the external company,
> then manually publish the CRL and delta CRL.
>
> Have tested this scenario, doesn't work at all. The computer from the
> external company still has the IPSec certificate after several hours and
> several reboots, and is able to connect to the VPN server.
>
> Any advice, aolutions, suggestions?
> Thank you all in advance for your help!
> Franz
>




Posted by Franz Schenk on September 23, 2005, 4:06 pm
Please log in for more thread options
Thank you for your information.

It's possible to publish manually the update delta and full CRL using the CA
MMC SnapIn on the Server. I also have verified that this CRL is published in
AD and in a file.
Despite of that, my test VPN client (or the VPN server) never checks if the
certificate using for the L2TP/IPSec connection is revoked or not. The Win
XP SP2 client can establish the L2TP/IPSec VPN connection to the Windows
Server 2003 SP1 without any problem after the certificate is revoked nearly
a week ago.

Where is any documentation from MS how the process of verifying the validity
of the certificate when establishing a VPN connection shoud work? Is this MS
security?

Thanks all in advance for any help
Franz

> Certificate revocation is not immediate on client computers. There are two
> types of CRL for Windows computers - the regular and delta. The regular
> was what was used until Windows 2003/XP and by default has a weekly
> publish schedule. The delta CRL by default is published daily. Until your
> VPN server refreshes its CRL cache with the delta CRL that contains the
> revoked certificate it will not know that the certificate is revoked. I
> don't know of a way to "flush the cache" to speed this up.
>
> While revoking the certificate was a good thing to do I would not rely on
> that alone to prevent access. I don't know how securely your PKI is
> managed but there may be the possibility that they have other
> certificates. You really need to disable the ability of the user accounts
> that they can use from logging on via VPN in the dial up properties of
> those accounts or maybe consider shutting down the VPN until you can
> decide on the best way to proceed whether it be change the account
> passwords, etc. If you have a specific Remote Access Policy that allows
> that company access you may also be able to modify that policy to prevent
> access. --- Steve
>
>> imagine the following scenario:
>>
>> - have a Windows 2003 SP1 VPN Server with standalone or enterprise
>> certification authority, allowing only L2TP/IPSec connections with
>> certificate based authentication.
>> - have an external company that has a computer with an installed computer
>> IPSec certificate from our CA for VPN access.
>> - The external company has knowledge of several user accounts/password
>> that have VPN dial in permissions to our VPN server.
>>
>> - Need to disable VPN access for this external company as fast as
>> possible. But it's not possible to change all these user
>> accounts/passwords.
>>
>> Thought that this one is easy: Go to the certification authority, revoke
>> the certificate that was issued to the computer of the external company,
>> then manually publish the CRL and delta CRL.
>>
>> Have tested this scenario, doesn't work at all. The computer from the
>> external company still has the IPSec certificate after several hours and
>> several reboots, and is able to connect to the VPN server.
>>
>> Any advice, aolutions, suggestions?
>> Thank you all in advance for your help!
>> Franz
>>
>
>




Posted by Brian Komar [MVP] on September 23, 2005, 10:18 pm
Please log in for more thread options
franz.schenkNOSPAM@fititNO-_SPAM.ch says...
> Thank you for your information.
>
> It's possible to publish manually the update delta and full CRL using the CA
> MMC SnapIn on the Server. I also have verified that this CRL is published in
> AD and in a file.
> Despite of that, my test VPN client (or the VPN server) never checks if the
> certificate using for the L2TP/IPSec connection is revoked or not. The Win
> XP SP2 client can establish the L2TP/IPSec VPN connection to the Windows
> Server 2003 SP1 without any problem after the certificate is revoked nearly
> a week ago.
>
<snip>
There are a couple of possibilities here:
1) did you enable CRL checking for IPSec. in my whitepaper on
Certificate Status and Revocation, I include a section discussing CRL
checking for IPSec connections. Ensure that you have enabled the
following registry setting at both the client and the server (moreso the
server in your case):
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent
\Oakley\
StrongCrlCheck

This Reg_DWORD data type can be assigned values from 0-2, with the
following meanings:

=3F 0 =3F Disables CRL checking for certificate-based IPSec authentication

=3F 1 =3F Enables CRL checking and fails the validation process only if the
CRL explicitly indicates that the certificate is revoked. All other
failures, including when the CDP URL is unavailable, will be ignored.

=3F 2 =3F Enables CRL checking and fails certificate validation on any CRL
check errors.

For maximum validation, set a value of 2, although a value of 1 would
work in your case.

2) The second issue may be that you have not modified the default CRL
publication interval. The default value is to publish the base CRL every
7 days. If you look at the troubleshooting whitepaper, you will see that
a client will not download an updated CRL if a time valid CRL exists in
the client's cache. The client will only download an updated CRL when
the previous CRL expires from the cache (as per RFC 3280). For the
details, see the whitepaper at
http://www.microsoft.com/technet/security/topics/cryptographyetc/tshtcrl
..mspx

Brian



Posted by Franz Schenk on September 26, 2005, 11:15 am
Please log in for more thread options
Hi Brian

Thank you very much for your help! Your whitepaper explains the whole matter
to me, although this paper is hard to find: A search on MS Technet with the
keywords "certificate revocation" reveals your whitpaper at position thirty
or so.

Some points are not clear to me. You write in your paper:
"Internet Protocol Security (IPSec)
CRL checking is not enabled by default in Windows 2000. With the release of
Windows 2000 SP2, an additional registry key was added that can enable CRL
checking for IPSec certificate-based authentication."

- Is my understanding and my expericence correct, that IPSec CRL checking is
not enabled by default also with Windows XP and with Windows XP SP2? At
least on my test machine, the registry key you mentioned is not present by
default.

- Is my conclusion correct, that certificate revocation in combination with
IPSec doesn't work at all whithout distributing this registry key to all
client systems?

- Is the following also correct, that relying on certificate revocation in
an IPSec client server environment is wrong, when distributing certificates
to computers that are not member of the domain? (A malicous user with a
computer that does not belong to the domain can delete this registry key and
can use the certificate for IPSec VPN connections until the certificate is
expired)?

Thank you in advance for your help!
Franz


> franz.schenkNOSPAM@fititNO-_SPAM.ch says...
>> Thank you for your information.
>>
>> It's possible to publish manually the update delta and full CRL using the
>> CA
>> MMC SnapIn on the Server. I also have verified that this CRL is published
>> in
>> AD and in a file.
>> Despite of that, my test VPN client (or the VPN server) never checks if
>> the
>> certificate using for the L2TP/IPSec connection is revoked or not. The
>> Win
>> XP SP2 client can establish the L2TP/IPSec VPN connection to the Windows
>> Server 2003 SP1 without any problem after the certificate is revoked
>> nearly
>> a week ago.
>>
> <snip>
> There are a couple of possibilities here:
> 1) did you enable CRL checking for IPSec. in my whitepaper on
> Certificate Status and Revocation, I include a section discussing CRL
> checking for IPSec connections. Ensure that you have enabled the
> following registry setting at both the client and the server (moreso the
> server in your case):
> - HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PolicyAgent
> \Oakley\
> StrongCrlCheck
>
> This Reg_DWORD data type can be assigned values from 0-2, with the
> following meanings:
>
> =3F 0 =3F Disables CRL checking for certificate-based IPSec authentication
>
> =3F 1 =3F Enables CRL checking and fails the validation process only if
> the
> CRL explicitly indicates that the certificate is revoked. All other
> failures, including when the CDP URL is unavailable, will be ignored.
>
> =3F 2 =3F Enables CRL checking and fails certificate validation on any CRL
> check errors.
>
> For maximum validation, set a value of 2, although a value of 1 would
> work in your case.
>
> 2) The second issue may be that you have not modified the default CRL
> publication interval. The default value is to publish the base CRL every
> 7 days. If you look at the troubleshooting whitepaper, you will see that
> a client will not download an updated CRL if a time valid CRL exists in
> the client's cache. The client will only download an updated CRL when
> the previous CRL expires from the cache (as per RFC 3280). For the
> details, see the whitepaper at
> http://www.microsoft.com/technet/security/topics/cryptographyetc/tshtcrl
> .mspx
>
> Brian
>




Similar ThreadsPosted
Q: L2TP/IPsec certificate selection June 6, 2005, 7:49 pm
How Policies Work November 17, 2006, 2:43 pm
how do I work out who/what enabled a service October 3, 2005, 10:48 pm
FileSystemAuditing doesn't work good October 17, 2006, 8:34 am
How does runas with /netonly option work? February 8, 2006, 8:12 am
special permissions on folder don't work April 28, 2006, 1:54 am
STOP what you’re doing - It doesn’t work! LT69 July 28, 2006, 7:17 pm
Importing certificates does not work on Vista: February 5, 2008, 2:31 pm
Access Based Enumeration really doesn't work May 13, 2008, 11:13 am
Network drives show disconnected, sometimes, but still work? November 30, 2007, 8:31 pm

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap