Home > 70-640 Part 6 Certificates
This video will look at the 3 new features that are included in Windows Server 2008 R2 Active Directory Certificate Services.
Download the PDF handout
The new features added are Web Enrollment, certificates enrollment across forests and better support for high-volume CA’s.
A certificate authority (CA) creates certificates that are used by clients on the network. In a domain, a certificate authority can make use of the trust relationship created when a computer is added to the domain. This is referred to as a secure channel and allows a certificate to be transferred to the client securely. If you have a need to issue certificates to computers that are not part of the domain, for example to an external company, this cannot be done using a secure channel since the computer is not part of the domain. To get around this problem, the component Web Enrollment Services can be added to a Windows Server. This component allows external clients to request certificates using the HTTP protocol. These certificates, once approved for issue, can be transferred to the Windows Server using the secure channel to the certificate authority. This helps protect the certificate authority as external clients do not need to access it directly in order to obtain certificates.
Web Enrollment Requirements
In order to use web enrollment you must meet the following requirements.
1) Windows Server 2008 R2 forest level
2) Enterprise CA running Windows Server 2003 or above
3) Client computer running Windows 7 or above
4) Cross forest enrollment requires the CA’s in each forest to be Enterprise or Datacenter editions
Enrollment across Forests
This feature allows clients in one forest to obtain certificates from a CA in another forest. This makes the certificate infrastructure a lot simpler as the two forests only require one certificate infrastructure. In order to use enrollment across forests, the two forests require a forest trust. A forest trust is supported by Windows Sever 2003 function level, however enrollment requires Windows Server 2008 R2 forest level. For this reason, you require a forest trust and the forests to be Windows Server 2008 R2 forest level.
This is a setting found only on Windows Server 2008 R2 certificate Authorities (CA). This setting is called non-persistent certificate processing. When enabled, this setting stops a copy of a certificate being saved to the local certificate database. This improves performance of the certificate authority; however, it does mean that once a certificate is issued it cannot be revoked. Revoking a certificate effectively means canceling the certificate so that it cannot be used. If a CA issues a lot of certificates that are only used for a short period of time, for example Network Access Protection (NAP), this is a good choice for this option. This is because without the revoke option, a client keeps using a certificate until it expires. In the case of NAP, these certificates often have short validity times and thus will expire quickly and thus serve less of a security risk.
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 788-790
“What's New in Active Directory Certificate Services” http://technet.microsoft.com/en-us/library/dd448537(v=ws.10).aspx
This video will look at the different components that make up Active Directory Certificate Services and which services you should look at installing these components on.
Download the PDF handout
Which components to install where?
When looking at which components of certificate services to install where a few points need to be considered. First where is the user or device that is using the certificate located? If they are located over a WAN then additional components may need to be installed closer to the user or device. If the user or device is part of the domain this will make the process simpler. If not, additional components may be required to assist the user or device accessing the certificate infrastructure.
There are 6 components in Active Directory Certificate Services.
Certificate Authority (CA): This is the core component which creates certificates for use. These certificates are issued to users or devices or to a subordinate CA.
Online Responder: This component provides a way for certificates to be checked that is uses a small amount of network traffic.
Network Device Enrollment Service: This component allows non-domain devices like switches and routers to obtain certificates.
Certificate Enrollment Web Service: This allows certificates to be obtained using the web.
Certificate Enrollment Policy Web Service: This component works with Certificate Enrollment Policy Web Service to provide certificates. It provides the policy that is used with Certificate Enrollment Web Service.
Certification Authority Web Enrollment: This component provides a web interface which end users can use to obtain certificates.
Certificate Authority (CA)
The Certificate Authority or CA is the main component of certificate services. It should be remembered that Active Directory Certificate Services is Microsoft’s implementation of certificates. There are other 3rd party implementations of certificates. Microsoft CA can use certificates from these CA’s or these certificates can be used with Microsoft CA’s. A CA’s job is to create and manage certificates. The certificates that it creates can be used by subordinate CA’s or by clients. At the top of the certificate hierarchy is the root CA. If you decide to create your own root CA it is important to be careful which settings you use. The settings used on a CA effect all certificates created below it. This is because certificates form a chain. In order for a certificate to be validated, all certificates in the chain need to be checked.
This component checks if a certificate is valid. The user or device using the certificate can send a query to the online responder and the online responder will send back a response either yes or no if the certificate is valid. The advantage of this is that the response message is always the same size. The other way of doing this is using what is called a Certificate Revocation List or CRL. The CRL contains all certificates that have been revoked so this can become quite large. In order to obtain the CRL the client also requires access to a CA. The second advantage of an online response is that it can talk to the CA on behalf of the client. This means that an online responder can be deployed in locations that you may not normally deploy a CA. For example an area that is accessible on the internet.
Network Device Enrollment Services
This component allows devices on the network to use the Simple Certificate Enrollment Protocol (SCEP). The device will request the certificate from this component. This component will then contact a Certificate Authority on the device’s behalf to obtain a certificate. Network Device Enrollment Services using this method can allocate certificates to devices on the network that are not domain members.
There are 3 components that all relate to web enrollment, or obtaining certificates using HTTP.
Certificate Enrollment Web Services: This component provides certificates using HTTP, however it does not provide a web page to obtain the certificate. HTTP is only used as the communication protocol to obtain the certificate.
Certificate Enrollment Policy Web Service: This component provides policy information to clients for use with the Certificate Enrollment Web service.
Certification Authority Web Enrollment: This provides a web page that a user can use to request a certificate. This is often used when 3rd parties require certificates. The 3rd party can use this web site to request a certificate and the administrator will need to at some stage approve this certificate to be created.
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 779 - 780
“Windows Server 2008 PKI and Certificate Security” pg 33 - 37
“Certificate Enrollment Web Services” http://blogs.technet.com/b/askds/archive/2010/02/01/certificate-enrollment-web-services.aspx
Standalone and Enterprise CA’sA standalone CA does not require any domain membership, however an enterprise CA does. Both have their advantages and disadvantages. This video will look at what features you get and lose which will help you decide which CA is the best choice for you.
Download the PDF handout
Standalone vs Enterprise
At the most basic level, the basic different between a standalone CA and an Enterprise CA is that an Enterprise CA needs to be a member of the domain while a standalone CA does not. If you decide to, you can install a standalone CA on a server that is a member of the domain. It should be remembered that once you install a Certificate Authority, properties for the server like the computer name cannot be changed. For this reason, if you only require a standalone CA, it may be a better choice to not have the server holding that standalone CA a member of the domain. Having the server a member of the domain also means that the server will need to check in with a domain controller once in a while. This essentially means that the server cannot be taken offline for extended periods. In some cases, a standalone CA may only be used to issue a couple of certificates, for example when it is used as a root CA. If this is the case, a non-domain member is a better choice as once the CA has issued these certificates it can stay offline for extended periods of time without issue. Having the CA offline means that the keys that are on the CA are protected from attack. If an attacker was to gain access to these keys, this means any certificates below this would need to be reissued. For this reason, being able to take the standalone CA offline for extended periods helps protect the key and the CA.
A Standalone CA is often used for external services. Since external services often require access from the internet, using a standalone CA means that CA’s can be installed on perimeter or DMZ networks. Since no domain services are required, the CA does not require a domain controller on the perimeter network or a rule to be created in the firewall in order to allow it access to the domain. This helps improve security, as if the CA was to become compromised, that attacker would only have access to what is on the CA and would not have access to any domain information. Enterprise CA’s are often installed on internal networks as they require access to Domain Controllers.
Even though Enterprise CA’s essentially have to be online most of the time to access Domain Services and are domain members this makes them harder to secure and there is more opportunity for an attacker to do damage as they potentially have access to domain resources, but there are some advantages to having an enterprise CA. Since an Enterprise CA is a member of the domain, domain members can use automatic processes in order to obtain certificates. A standalone CA cannot use automatic processes and certificates allocated must be approved manually. This means that an Enterprise CA is a good choice if certificates need to be issued regularly. For example, health certificates that are issued daily to clients before they can access the network. Example of these include Wifi and Network Access Protection (NAP). A NAP client requires a health certificate before they can access the network and these certificates generally have a short life span. Certificates that are once issued and are valid for a few years a standalone CA may be good choice for this. Since on a standalone CA the certificate needs to be approved by an administrator having to manually approve certificates becomes time consuming if they are required to be approved on a regular basis. The exception to this is if there were a lot of certificates being issued. When this occurs, you may want to automate the process even though the certificates are valid for a long time. At the end of the day the decision is based on the amount of administrator time required versus how secure you want your network to be.
The last difference between a standalone CA and an Enterprise CA is the certificate issued can be automatically trusted by the client. In some cases, the certificate is automatically trusted by the client due to the trust relationship that is created when the client is added to the domain. In other cases, Group Policy can be used to set up the client to trust certificates issued by the CA. Either way, when a certificate is issued by a standalone CA, there is no automated system that assists to ensure the client automatically trusts that CA and thus can use the certificate. In order to use certificates from a standalone CA, often a certificate will need to be added to a local certificate store on the client using the certificate and then the client will trust certificates from that CA. Group Policy could also be used to install a standalone certificate on a client computer local certificate store. The point to remember is that there is some process required to get the standalone certificate on to the computer. The standalone certificate authority cannot take advantage of the trust relationship in the domain in order to setup and use certificates.
Standalone CA Example
In a lot of cases, a standalone CA will form the root of the certificate hierarchy. Even though you could also use an enterprise CA, the advantage is that the root CA can issue a certificate to subordinate CA’s and then be taken offline. Since the root CA contains the private key to the whole certificate hierarchy, if this certificate was to be obtained by an attacker, this would compromise all certificates that have been issued in that hierarchy.
A typical deployment of certificates is to have subordinate CA’s placed on a DMZ or perimeter network. This Standalone CA issues certificates directly to clients. Since it does not have the root certificate on it, it offers better security. The disadvantage is that all certificates that are issued need to be approved.
Enterprise CA Example
Often an Enterprise CA will be used when a lot of certificates need to issued and they need to be approved quickly. For example, when a domain user connects up to a wireless device to access the network, a certificate may be issued and used to provide secure communication for the client over the wireless connection. In this case you need to automatically approve the certificate because the user does not have time to wait for the administrator to approve the certificate and an administrator does not have time to manually approve a lot of certificates on a busy network.
Can you combined the two?
Standalone and enterprise CA’s can be combined together in the hierarchy. The most common example of this is to use a standalone root CA at the top of the hierarchy. Since the CA is a standalone, after it has issued the certificate to the subordinate CA’s it can be taken offline. It is possible for the root CA to be installed on removable media. If this is the case, some companies will place the removable media that the server was installed on into a secure area like a safe. Regardless which type of CA you install as the root CA, subordinate CA’s can be standalone or enterprise or a mixture of the two. Often companies will install a standalone CA on the perimeter network and an enterprise CA on the internal network so they get the most features and best security.
“MCTS 70-640 Configuring Windows Server 2008 Active Directory Second edition” pg 780-782
Before a certificate can be used it is a best practice to check the certificate to ensure that it has not been revoked. In order to do this, the list called the Certificate Revocation Lists (CRL) needs to be stored on the network so that clients can access it and also be updated when certificates are revoked.
Download the PDF handout
CRL Distribution Points
To put it in simple terms, a CRL distribution point is a shared location on the network that is used to store the CRL and certificates. A CRL contains all the certificates on the network that have been revoked. A client needs to download this list to determine if the certificate that they are about to use is valid. Certificates are required to be stored in the distribution point to make it simple for clients to obtain them. When a certificate is verified, the root CA and other subordinate CA’s are required in order to verify each part of the certificate chain. A distribution point provides a point on the network for clients to download these certificates, otherwise the certificates would have to be manually installed on the client’s computer.
A CDP stands for CRL Distribution Point. This can be accessible by web, LDAP or file share. The location of the CDP is stored in the certificate so when the client obtains a certificate it knows to look inside the certificate to obtain this information.
This demonstration will create a distribution point that is available via www, files share and LDAP.
1) Open server manager, select roles and then select the option add roles.
2) From the roles screen, select the role Web Server (IIS). No other components are required, so accept all the defaults and complete the wizard.
3) In order to have somewhere to save the files, create a folder on the c drive called CertEntroll
4) To allow clients to access this folder by file sharing, right click the folder and select properties. Then select the sharing tab and then press the button advanced sharing.
5) In the advanced sharing, make sure the tick box “Share this folder is ticked”.
6) The default permissions are read only which will be enough for clients to access. In order to update the CRL additional permissions are required. In order to configure these, press the button permissions and then add the group Cert Publishers with change access so that this group can write to that folder.
7) The NTFS permissions also need to be changed. To do this, select the security tab and then press the button edit. In here you need to add the group Cert Publishers. In order to grant write access, make sure the permission modify and below are ticked.
8) To configure the directory to be available via a web page, this needs to be configured in IIS. To do this, open Internet information Services (IIS) Manager from administrative tools under the start menu.
9) From IIS, expand down through until you reach Default Web Site. Right click Default Web Site and select the option Add Virtual Directory. For alias enter in CertEnroll and then browse to the directory c:\CertEnroll. When clients access the web server on this server, the C:\CertEntroll directory will appear under http://servername/CertEnroll
10) By default IIS will not display the contents of a directory and thus requires the user to know which file in the folder they want to access. To change this, under the virtual directory CertEnroll, select the option Directory Browsing. Once selected, on the far right is an option enable which needs to be selected in order to allow directory browsing.
11) The last option that is required to be configured in IIS is to allow double escaping. This is required by the CRL in order to work. The following file contains a script that enables double escaping http://itfreetraining.com/handouts/certificates/cadownloadfiles.zip. In this file is the script ConfigureWebServer.bat which you need to run. Otherwise you run the commands listed below.
C:\Windows\System32\inetsrv\Appcmd set config "Default Web Site" /section:system.webServer/Security/requestFiltering -allowDoubleEscaping:True
12) Once the command is run. IIS needs to be restarted. This can be done manually or using the command IISReset like what has been done above.
13) In this case, I will copy the root CA and CRL from the root CA to the distribution point. In order to do this, login to the root CA and then access the directory C:\Windows\System32\CertSrv\CertEnroll
14) In this directory is the certificate for the root CA and the CRL for the root CA. In a previous video the root CA was set up, however the root CA was configured never to publish updates to the CRL. Even though the root CA will never publish updates, the base CRL list still needs to be copied from here to the distribution point so clients can check the root CA has not revoked any certificates.
15) The two files from the root ca C:\Windows\System32\CertSrv\CertEnroll need to be copied to the directory c:\CertEnroll on the server that has the CDP on it.
16) The certificate and CRL needs to also be published in Active Directory in order for clients in the domain to be able to use LDAP to locate these files. There is a script in the following download http://itfreetraining.com/handouts/certificates/cadownloadfiles.zip called AddCertAndCRLToAD.bat
This file contains the following two commands.
CertUtil -f -DSPublish RootCA_ITFreeTraining-Root-CA.crt RootCA
CertUtil -f -DSPublish ITFreeTraining-Root-CA.crl RootCA
–f stands for to take information from a file. DSPublish means store in Active Directory. The next parameter indicates the file that is to be stored in active directory, either the certificate or the CRL file. The first command ends with RootCA which tells Active Directory that the certificate is for a Root CA. You could also use SubCA, user or machine depending on which type of certificate you are publishing in Active Directory.
In the case of the second command it also ends with RootCA like the first. However, this is the computer name of the RootCA. In this example, the root CA I have used has the computer name of RootCA. If your RootCA has a different computer name you will need to change this to the name of the RootCA>
Seeing the data in Active Directory
1) Open ADSI Edit from the start menu. Right click ADSI at the top and select the option Connect to. Under the option “Select a well known naming context” select the option Configuration.
2) Expand down through Configuration, Services, Public Key Services and AIA. In this container you should see the certificate for the root CA.
3) Expand down through Configuration, Services, Public Key Services, CDP and Root CA. This should contain the CRL.
Configuring the DNS Server
In this case the domain has a DNS address of .local. If you want to have the distribution point available on the internet, you will need to use an address that is resolvable from the internet. In this case I will create a new zone called ITFreeTraining.com to store a DNS record that will be used to direct a user from the internet to the server in the .local domain. If you do this, you need to ensure that this server is accessible for the internet in order for this to work.
1) To create a new zone, right click on Forward Look up zone and then finish the wizard. For the zone enter in the name ITFreeTraining.com
2) Select the newly created zone and then select from the action menu the option New Alias (CName).
3) Create a DNS record called PKI and link it to the server that you are using as a distribution point.
“AD CS Step by Step Guide: Two Tier PKI Hierarchy Deployment” http://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs-step-by-step-guide-two-tier-pki-hierarchy-deployment.aspx