Unreadable

Securing VPNs with Certificates

When using site-to-site VPN connections with protocols like L2TP over IPsec, it is standard procedure to work with certificates, thus avoiding insecure Pre-Shared Keys (PSKs). Given the increasing trend toward the use of mobile devices (which are not always company property) to set up a VPN connection to the corporate network, it is important to ensure that only desired devices can establish a VPN connection. In addition to solutions such as network access control (NAC), you can also use client-side certificates, on the basis of which the devices or users then authenticate. Only users or devices that have access to the certificates can successfully establish a connection to the corporate network.

Current Microsoft client operating systems such as Windows 10, as well as some older versions, offer the possibility of establishing a VPN connection on the basis of certificates. Windows 10 provides a wizard for users that lets you use smart cards as credentials (Figure 3); these can be classic smart cards in the form of a USB stick or a virtual smart card [2]. Windows 8 was the first operating system to support the creation of virtual smart cards that act like traditional cards by storing certificates for authentication. Like conventional smart cards, access is protected by a PIN.

Figure 3: On Windows 10, VPN connections can be secured with a certificate on a smart card.

Certificates for DirectAccess

DirectAccess is still a fairly recent Microsoft VPN technology, which saw the light of day for the first time in Windows Server 2008 R2. It became more widespread in Forefront Unified Access Gateway (UAG) and is still used as a server role in Windows Server 2012 and R2 after Microsoft discontinued the standalone product. The special feature of DirectAccess is that you do not need a traditional VPN client; instead, the DirectAccess capabilities are built in to the client operating system as of Windows 7. After initializing the network stack, the computer establishes a VPN connection and is already connected to the corporate network without a user login.

DirectAccess relies heavily on the use of certificates, both on the client and server sides; if the simplified DirectAccess Setup Wizard is not used, that eliminates the need for a PKI. An internal Windows PKI is recommended for a professional implementation of DirectAccess. If you are using Windows 7 as a client or using multisite DirectAccess, the use of a PKI is imperative. The Network Location Server (NLS) needs a web server certificate issued for the internal DNS's fully qualified domain name (FQDN). The CRL distribution point must be accessible via HTTP from the Internet, and the certificate must be trusted on all of the components involved in DirectAccess. For IPsec communications with DirectAccess clients, the DirectAccess server needs a computer certificate from the internal CA that is issued to the FQDN of the internal DNS name. For the IP-HTTPS communication of DirectAccess clients with the DirectAccess server, you need a web server certificate whose common name (CN) matches the external DNS FQDN; this is used by DirectAccess clients on the Internet to reach the DirectAccess server. For an advanced DirectAccess configuration of the IPsec connection, DirectAccess clients need a computer certificate issued for the name of the computer.

Conclusions

An internal PKI provides the basis for secure communication of almost all infrastructure components. If you use AD, you should always choose to use the built-in certification authority. If you need to issue certificates in an environment without AD or in a demilitarized zone, you should consider a standalone CA. For all forms of PKI, you should always plan and consider both the technical aspects of and the management processes for establishing the PKI. A carefully implemented PKI can then be the basis for protecting many processes and procedures; it is guaranteed to improve security significantly in Windows environments.