Configuring and Using PKI in Your Microsoft Network
Public Key Infrastructure (PKI) can become a fairly complex environment and deployment, as it involves multiple components that all need to work together smoothly. Understanding the theory of how it all works will help in building a solid foundation for this complex technology in your organization. Although there is always something new to learn in PKI, this white paper gives you a great overview of the core configuration of your Microsoft CAs.
Public Key Infrastructure (PKI) has become an essential service to implement and maintain proper security on many networks. The PKI service that Microsoft offers meets that objective by providing a set of tools to guarantee the information stays in a secure state. By definition, a secure state is part of the CIA triad: confidentiality (data remains seen by authorized entities), integrity (data cannot be tempered with), and availability (data remains online and can be accessed). As discussed in my previous white paper (Fundamentals of the PKI Infrastructure), PKI reinforces this idea by applying the first two types of security, but also provides some additional protection, as we will soon discover.
In this white paper, we will explore the practical use of the PKI and its configuration. We have seen many organizations using this technology, but some require an appropriate setup and additional configuration to take advantage of the numerous possibilities PKI has to offer. We will be looking at configuring the core components of the PKI role, as well as how it is possible to secure different types of servers using this technology.
This white paper is part of a two-part series on the PKI. The first white paper, Fundamentals of the PKI Infrastructure, can be found within the cybersecurity section of the white papers.
Conceptual Overview of the PKI
PKI is the practical application of a set of security technologies to help data protection.
PKI relies on two types of encryption: symmetric and asymmetric. These types of encryption work together by scrambling the data using an algorithm that makes the information unreadable by unauthorized entities, providing secrecy.
Symmetric encryption encrypts the data itself, while asymmetric encryption makes sure the transfer of session keys generated by symmetric encryption is kept secret. Different keys are generated at that point, and are available to cipher and decipher the information.
These two types of encryption, along with keys, work with certificates-the piece of information that can be used to validate users and computers and perform secure data transfer. Certificates can be obtained from specific servers, such as Certificate Authorities (CA), which are individual servers performing maintenance and operations of the entire PKI infrastructure.
CAs are active in issuing certificates to computers, users, or others CAs in hierarchies. Requests can be processed automatically, or by manual approval, depending on properties of the certificates and authentication methods to Active Directory, which can be actively involved in the process of certificate issue.
When a certificate is issued, it has a validity period, and can be revoked and then found in a certificate revocation list (CRL) that is published within the organization. Although certificates and the PKI seem quite complex to understand, creating a PKI in your company is all about establishing trust between computers within your organization. It makes sure computers know each other when exchanging information. Thus, PKI prevents man-in-the-middle attacks, session hijacking, data tampering, and integrity attacks, and performs non-repudiation as well as authentication between peers.
Before you begin with the configuration with the PKI, here is a graphical overview from my first PKI white paper, outlining the most common components in that structure:
Planning the Microsoft PKI
The setup of the PKI can be straightforward, but will mainly depend on the plan for the configuration of that role. You have to know answers to the below questions before you start with setup.
Does your organization require a PKI?
Despite its very important security role, not all organizations require PKI. Installing a security service such as PKI will require active maintenance and configuration. There are scenarios when such an infrastructure is not necessary. For example, if your objective is to secure a web server that is mainly going to be accessed by the outside world (for example a vendor portal), then it is not practical to issue a web server certificate from a private CA. If you're a small company, getting a certificate from an external CA is just fine. There is a fee for this operation, but don't forget the CA also costs time and internal resources when it comes to its maintenance and configuration.