Clients connected via Virtual Private Network (VPN) do not renew certificates automatically

Assume the following scenario:

• Client computers automatically obtain certificates from an Active Directory integrated certificate authority (Enterprise Certification Authority).
• Expiring certificates are renewed automatically when the clients are on the internal network.
• However, expiring certificates are not automatically renewed when clients are connected via Virtual Private Network (VPN).
• This can result in clients not renewing their certificate in time before it expires and no longer being able to connect to the VPN.

Backgrounds

For a detailed description of how manual and automatic certificate request from an Active Directory integrated certificate authority works, see the article "Basics of manual and automatic Certificate Enrollment via Lightweight Directory Access Protocol (LDAP) and Remote Procedure Call / Distributed Common Object Model (RPC/DCOM)„.

By default, all domain members automatically replicate the Active Directory forest's Public Key Services object through the autoenrollment process. The triggers for this are:

• When the user logs in (for computers, when the computer account logs in, i.e. at system startup).
• By timer every 8 hours.
• When updating group policies, assuming there has been a change.

If this process is started and the corresponding setting for automatic certificate request and renewal is set, the above triggers will also trigger certificate request and renewal.

If a client is connected via VPN, it is possible that none of the triggers apply:

• When the user logs on, i.e. when the computer account logs on, i.e. when the system starts up, often a VPN connection has not yet been established, so the client does not have access to the network.
• Per timer every 8 hours often does not apply, because the VPN connection is usually not maintained for that long.
• When updating group policies, assuming there has been a change - often does not apply, as the trigger only takes effect when group policies change.

If none of these triggers apply, the autoenrollment process is never triggered (at least not while the client is connected to the network), and client certificates may expire.

Solution: Set up a scheduled task with an additional trigger

The solution is to set up a group policy that creates another trigger for the autoenrollment process via the Group Policy Preferences (GPP). For example, if the VPN client logs an event when the VPN connection is established, this event can serve as a trigger.

First, a new Group Policy object is created via the Group Policy Management Console (gpmc.msc).

This is given a meaningful name.

Then the group policy object is edited.

Under "Computer Configuration" - "Preferences" - "Control Panel Settings" - "Scheduled Tasks", right-click to create a new scheduled task for "At least Windows 7".

In the "General" tab, the action is set to "Create" and a meaningful name is assigned to the task.

In the "Security Options" click on "Change User or Group...".

Enter "SYSTEM" as the object name and click on "Check Names".

Then the "SYSTEM" object is selected and confirmed with "OK".

Back in the "Security Options", "Run whether user is logged on or not" and "run with highest privileges" are selected.

In the "Triggers" tab, click on "New...".

The following describes the setup of a trigger based on the event logs of the Windows-integrated VPN client. For your own environment, it must be determined whether the VPN client used generates events at all and what they look like. If there is no way to intercept an event, a timed trigger, for example hourly, would also be a valid option. However, the update should not take place too often, since a certain network load is incurred here, which increases with the number of connected clients.

In the upper selection field, the trigger is set to "On an event". Select "Custom" in the settings and then click on "New Event Filter".

In the following dialog, you can either create an event filter from the existing options or define your own filter using the "XML" tab.

Here is an example of the Windows internal VPN client that has established a connection named "ADCS Lab VPN".

{QueryList}
{Query Id="0" Path="Application"}
{Select Path="Application"}*[System[(Level=4 or Level=0) and (EventID=20225)]] and *[EventData[Data='ADCS Labor VPN']]{/Select}
{/Query}
{/QueryList}

A very good, reliable alternative is to use the connection to the internal network as a trigger.

This information can be found in event no. 10000 of the NetworkProfile source (in the Microsoft-Windows-NetworkProfile/Operational event log). It is necessary to additionally filter for the fact that a connection to the domain was detected (category 2).

{QueryList>
{Query Id="0" Path="Microsoft-Windows-NetworkProfile/Operational">
{Select Path="Microsoft-Windows-NetworkProfile/Operational">*[System[(EventID=10000)]] and *[EventData[(Data[@Name="Category"] = "2")]]{/Select>
{/Query>
{/QueryList>

It is important that a small delay is built into the trigger settings, as it may take a few seconds to actually use the connection when the VPN connection is established. 30 seconds to one minute should work optimally.

In the "Actions" tab, click on "New...".

Then click on "Browse...".

The folder "C:\Windows\System32\" is selected and after the certutil.exe wanted.

The command is also given the "-pulse" argument

In the "Settings" tab, "Allow task to be run on demand" is selected.

The group policy can now be linked to the client computers.

The clients should apply the new group policy after 90 minutes if the domain is working with the default settings. After that, the autoenrollment process should be triggered for each VPN connection.

Related links:

• Basics of manual and automatic Certificate Enrollment via Lightweight Directory Access Protocol (LDAP) and Remote Procedure Call / Distributed Common Object Model (RPC/DCOM)
• Manually running the autoenrollment process