Establishing and maintaining public key infrastructures (PKIs) is considered complex and time consuming. Moreover, they can be expensive if you want to use public certificates to improve security. That said, no other system provides an equivalent level of safety. In this article, I introduce the main components of a PKI and show practical implementation options using examples such as email encryption in Outlook and VPN access.

Microsoft's operating systems and applications provide many safety features for improving data protection. Very often, these measures focus on enhanced login security through a stronger and improved password policy, additional software for login security, or the use of firewalls on servers and clients or centrally on gateway servers to the Internet. A feature rarely used to improve security in Windows environments is based on a PKI that relies on certificates issued for various applications, services, and procedures.

All too often, sensitive data transfers are still transmitted without protection, email with sensitive content is not encrypted, or the latest business report is transferred in the clear over FTP. Logging on to the web interface of a third-party solution to inventory software relies on Active Directory (AD) authorization, but the username or password are transmitted in clear text via HTTP. These examples show how a lack of understanding or expertise in the field of encrypted connections can cause security problems.

PKI Components

A PKI comprises the certification authority (CA), a registration authority (RA), and a validation authority (VA). The CA issues certificates, which are requested by the RA and validated and approved by the VA. Additional components include, for example, a revocation list distribution point in the form of a certificate revocation list (CRL) and the Online Certificate Status Protocol (OCSP) to verify the validity of certificates.

Certification authorities come in private and commercial flavors. A private – or internal – CA is operated by the IT department on your local network, and the trust extends only to the computers that are located on the corporate network. In the case of an enterprise CA with a Windows server, for example, all the members of the AD forest trust each other.

A commercial CA typically provides services against payment. In contrast to a private CA, the trustworthiness of a commercial CA is ensured by the fact that most manufacturers of operating systems, web browsers, and applications have already implemented their CA's root CA certificates, so that the client can validate the certificates without seeing error messages.

Certification authorities can be hierarchically structured, as well. The root CA is the root of a CA hierarchy, which can include intermediate CAs. Below the intermediate CAs, you then find the issuing CA.

For many versions now, Windows servers have provided functionality for setting up a CA infrastructure. For the optimal integration of a CA in an AD environment, an AD integrated enterprise CA should be used, because the integration also allows issuing certificates automatically; ensuring the trustworthiness of the root CA certificate by its automatic addition to the certificate store of all AD domain members; and other features, such as automatic key archival and storing of the public certificates of users in AD.

Requesting a Certificate

Commercial CA certificates are typically requested through a web interface and issued after final verification of the requester's identity. When you use a Windows CA, the certification authority and the certificate template settings determine how certificates are issued. By default, certificates are almost always issued without the interaction of the CA manager. You should modify this behavior in the certificate templates or in the properties of the CA issuing the certificates, so that the approval of the CA administrators is necessary for each certificate request.

Certificates can be requested in different ways from the internal CA. The typical approach in previous versions of Windows server – requesting certificates in a web interface – is outdated. The recommended approach is now a Certificate Microsoft Management Console (MMC) snap-in, or the use of PowerShell or command-line programs. Many applications, such as the Internet Information Server (IIS) provide options for requesting certificates in the graphical front end. Some applications can only create a certificate request process in the form of a certificate request file. The generated request file must then be submitted manually to the CA administrators, and the certificate request completed in the CA management console. Then, the system transmits the generated certificate to the requester.

Encryption and Digital Signatures in Outlook

Two approaches have been established for digitally signing or encrypting email: PGP (Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail Extensions). Whereas PGP is not natively available in Windows systems and applications such as Microsoft Outlook, S/MIME is included in the current versions (Figure 1).

Figure 1: S/MIME is the only on-board tool for encrypting email in Outlook.

A Windows Server CA is capable of issuing email encryption certificates for users and distributing them automatically via Group Policy, as well as automating the configuration of the Outlook client. The public key for the email certificate can be stored for each user in AD. This means that any user can exchange email encrypted or signed with other AD users. Optionally, you can configure the CA to archive private encryption certificates: If a user no longer has access to their private key, a trusted CA administrator, a key recovery agent (KRA), can restore the certificate with the private key and make it available to the user.

To set up email encryption for Microsoft Outlook users in an AD infrastructure, take the following steps:

• Configure the CA for key archiving (optional).
• Configure a key recovery agent (if key archival is necessary).
• Create a new certificate template from the "User" certificate template.
• Configure the certificate template (security, validity, key material, archival, and where appropriate, auto-enrollment).
• Create group policies for auto-enrollment of certificates.
• Import the administrative template files (ADM/ADMX) for the version of Outlook in Group Policy Management.
• Create group policies for the automatic encryption and signature feature in Outlook [1].