Certificates Overview
Public Key Infrastructure (PKI) is implemented in Windows in the form of certificate services. Certificates can be used to provide both authentication and encryption for a Windows network.
Use the buttons below to navigate through the lesson
A certificate contains a public key and a set of attributes, like the user’s name and e-mail address. Certificates can be issued to computers as well as users. Certificate Services are used throughout Windows. IPSec (encryption over a network), Kerberos, IIS (Internet Web Server) and Encrypting File System (EFS) all use certificates. An example of using certificate services is SSL (secure sockets layer). Using SSL, web traffic can be encrypted and kept secure. SSL is commonly used by banks and catalogue companies for online transactions.
If the key associated with a certificate is lost, so is the data. Microsoft provides a solution to this problem known as recovery keys . Windows Server allows the Administrator to define a recovery policy that specifies who may recover data. These users are called recovery agents.
Consider the case of a user who encrypts a file using EFS and then leaves the company. The file can be recovered by the recovery agent, who has a copy of the key used to encrypt the file.
Certificate Authorities
Certificate Authorities (CAs) issue certificates on the network. CAs can also issue certificates to other CAs. They can revoke certificates they have issued. There are two different types of certificate authorities; Stand-Alone and Enterprise.
Certificate Authorities can also exist at two levels; Root and Subordinate. Subordinate CAs exist below root CAs or other subordinate CAs. A Certificate Authority can be hosted on a Windows Server 2008 machine.
Stand-Alone Certificate Authorities
Stand-Alone CAs don’t make use of the Active Directory and are ideal for issuing certificates for external use and in workgroup environments. Stand-Alone CAs automatically mark certificate requests as “pending” for the administrator to approve. Stand-Alone CAs are less secure than Enterprise CAs as they can’t make use of Active Directory Security.
Certificates issued by a stand-alone CA can’t be published – they must be manually distributed.
Stand-alone certificates can be issued for smartcard logons.
Enterprise Certificate Authorities
Enterprise CAs issue and revoke certificates for an enterprise and work within Active Directory for greater security. Enterprise CAs have the following features:
Enterprise CAs publish certificates to Active Directory, which means any client in the enterprise can get them.
Enterprise CAs will accept or reject a certificate automatically based on the requestor’s security permissions. Enterprise CAs will never mark a request as pending (i.e. waiting for an administrator to approve). Enterprise CAs can issue certificates which can be used to logon to the domain. These are ideal for devices such as smartcards and fingerprint readers.
Certificate Authorities
Certificate Authorities can vary in size. Some CAs can issue certificates to millions of clients, such as Verisign, which is a commercial CA. Certificate services can also set up an individual CA for each department in a company. Each CA is responsible for choosing which attributes it will include in a certificate and how it will verify those attributes.
Certificate Authorities (CAs) also store a list of revoked certificates. These lists are called Certificate Revocation Lists (CRLs). Certificate Publishers make certificates and CRLs publicly available. A good certificate publisher would allow clients to automatically obtain the certificates they need. Microsoft Certificate Authorities can publish certificates in the Active Directory or a Shared Folder.
Cryptographic Service Providers
Microsoft provides cryptographic libraries. These libraries can be used by applications to perform both public and private key encryption. Certificate Services can also use Certificate Trust Lists (CTLs). When you put a CA certificate on the CTL you are telling the users on the domain that it is okay to trust certificates issued from this CA.
Microsoft Certificate services supports using predefined instructions that tell the CA what to do with incoming requests and what to do after the request is approved.
A policy module is a set of rules which tells the CA how to handle incoming requests.
An exit module is a set of rules which tells the CA how and where to publish the newly issued certificate.
Microsoft’s Standard Policy Module does the following:
- Each incoming request is processed or marked as pending depending on the type of CA. Stand-alone CAs mark incoming requests as pending.
- It adds an attribute to the certificate to state where the issuing CAs certificate can be obtained. This allows the certificate’s authenticity to be verified.
- It adds an attribute to the certificate that specifies where the issuing CA’s CRLs are located.
An exit module does the following things:
- Once the certificate has been issued it allows it to be published.
- Microsoft’s standard exit modules can publish certificates to Active Directory, a shared folder or by e-mailing it to the requestor.
- It can also publish the Certificate Revocation List (CRL). (This feature needs to be enabled manually).
Certificate Services Hierarchy Structure
A Microsoft Certificate Server can assume one of four distinct roles:
- Enterprise root CA
- Enterprise subordinate CA
- Stand-alone root CA
- Stand-alone subordinate CA
Root Certificate Authorities
Enterprise Root CAs sit at the top of a certificate tree. Enterprise Root CAs can issue certificates to either users or subordinate CAs. In order for a CA to issue certificates it needs its certificates signed by another CA. Since a Root CA is at the top of the hierarchy, it signs its own certificates.
Subordinate Certificate Authorities
Subordinate CAs appear below the root CAs in a certificate hierarchy. Subordinate CAs need a certificate from a Root CA in order to be allowed to issue certificates. By setting permissions at the subordinate CA level, you can have greater control over who can request and revoke certificates. Subordinate CAs can be configured to issue different certificates. e.g. One certificate authority could issue User certificates, whilst another may issue computer certificates.
