Microsoft's official enterprise support blog for AD DS and more
Hi, Brantley here. I would like to share some information with you about how digital certificates work. Understanding the concepts about how certificates work is important when troubleshooting PKI issues.
Let’s start by defining digital certificate: digital certificates are electronic credentials that are used to assert the online identities of individuals, computers and other entities on a network. The concept of digital certificates is much like the concept of a driver’s license. Like a drivers’ license, a certificate is issued by a central authority that has validated the identity of the person (or computer, application, services, etc) requesting the certificate. Now that we have defined digital certificates let us move on to the details.
Certificates issued by Windows Server 2003 and earlier are based on standards established by the Public-Key Infrastructure X.509 Working Group of the Internet Engineering Task Force. Version 1 of the standard defines a set of fields that should exist in every X.509 digital certificate. Version 2 added two more fields in order to support X.500 directory access control. Finally, version 3 introduced the concept of a Certificate Extension. Certificate extensions are simply fields that may be specified in standards or may be defined by a registered by a vendor, individual, or community. The Windows Certificate Server included in Windows 2000 and later supports X.509 Version 3 digital certificates.
The format of a v3 digital certificate is illustrated below.
X.509 Version 3 Certificate
As can be seen, a digital certificate links a subject identity and a public/private key in a signed and therefore verifiable digital document.
Example User Certificate
When double clicking on a certificate in Windows the Details tab displays the fields mentioned above. This is an easy way of visually verifying the Validity dates and the Subject.
The Certification Path tab displays the certificate path from the root down to the certificate being evaluated.
Basic Certificate Validation:
For a certificate to function properly, the following items must validate correctly (at a minimum):
1. Subject name: The subject of the certificate must match the resource subject that is being used. For example, when using https the subject in the certificate being used on the web server must match the https URL that users will use to connect to the https website. Subject name is analogous to the name on a driver’s license.
2. Validity Period: The (Valid From) and (Valid To) must be within the time frame the certificate is planning on being used. This is much like the expiration of a driver’s license. Validity period is analogous to the expiration date on a driver’s license.
3. Trust: The certificate must be used by a trusted Certificate Authority. Trust is analogous to the State that issued a driver’s license. Because the State that issued the license is a member of the union that makes up the United States we trust the issuer of the license.
4. Chain Building: Chain building is the process of building a trust chain, or certification path, from the end certificate to a root CA that is trusted by the security principal. The chain-building process will validate the certification path by checking each certificate in the certification path from the end certificate to the root CA’s certificate.
5. Key Usage: To help control the usage of a certificate outside of its intended purpose, the optional Enhanced Key Usage extension can be included in the certificate by the CA. The Enhanced Key Usage extension contains a list of usages for which the certificate is valid. These usages, also known as intended purposes, are displayed on the General tab of the certificate dialog box. This is important when evaluating why a certificate may not be working correctly. Key Usage is analogous to driver’s license endorsements (types of vehicles that can be driven with this license).
6. Revocation Checking: Each certificate in the certificate chain is verified to ensure that none of the certificates are revoked. A certificate can be revoked prior to the expiration date to disavow the certificate. Revocation Checking is analogous to checking a driver’s license against a State database to verify that a driver’s license has not been revoked for a violation.
Certificates issued by Windows Server 2003 and earlier are based on standards established by the Public-Key Infrastructure X.509 Working Group of the Internet Engineering Task Force. The Windows Certificate Server included in Windows 2000 and later supports X.509 Version 3 digital certificates. Subject Name, Validity Period, Trust, Chaining, Key Usage, and Revocation need to be validated for a certificate to function properly.
- Brantley Whitley
Why EV SSL Certificate can make IE 7 addressbar keeping Green?
Does Windows 2003 or Windows 2008 can issued EV SSL Certificate?
EV certs make the address bar green as an extra visual cue to the user that the certificate is 'super trusted' due to an independent audit of the issuer's company and IT implementation.
For more information:
I'm new to this, neverly really understood it, but your drivers license anaolgy is quite helpful. I have a question, maybe you can help me with, the short version is how would I go about configuring a Windows AD 2008 to use a Unix/Linux CA as it's authority? I currently have no CA in place at all in the forest or domain. But I do have Exchange 2007 SP1(with it's own self signed cert).
The long version of my question is as follows:
I am deploying a dev (and hopefully a production)Windows 2008 forest and domain currently. I work in an environment that has a Unix(I think Linux specifically) based CA. In our current Windows AD 2003 Production environment i completely ignored the Unix CA and built a VERY basic Windows CA, beyond DC's, workstations, and an occassional program, nothing has ever requested any certs from this windows ca, and that environment will be completely decommissioned and no data will be needed from it when the new environment is ready.
I need to deploy two new environments now one for dev and one for production, both using windows 2008 enterprise edition servers, both in their own forests and their own domains, completely seperate from each other.
the unix and new production namespaces is in the following form:
the new dev namespace will be:
i would like to play nice now and use the unix/Linux CA somehow, do I just install the certificate services (which I have not done in Windows 2008 yet) and create it as a "subordinate CA"? Or is it trickier than that?
My desired endstate (which our directory integration contracter is requesting of me/us) is that our new environment be ssl enabled, denying all requests of AD on port 389, AND that our AD LDS (aka ADAM) machines are also SSL enabled. We are using the MS ILM product to flow some information into ADAM whihc then a linux webserver running Plone will pull from for accounts, passwords etc, and we want to disable all non SSL binds(?).
Since pki has never been something I could wrap my head around, especially with regard to integrating to a non Windows CA, do you have any pointers, or whitepapers, links, steps which you could pass on?
Thanks VERY much for your time,
Thanks for your question. Let me see if I completely understand the scenario you're describing. You already have a non-Windows Certification Authority implemented in your environment. You are setting up two separate Windows-based environments -- Dev and
Production -- and you want to be able to issue digital certificates to your LDAP servers -- both ADDS and ADLDS -- for SSL/TLS.
You don't mention any other types of certificates you may wish to issue, and that would affect how you would set up your Windows-based PKI. We don't have any documentation that specifically discusses subordinating a Windows Server 2008 CA to a non-Windows
CA, but the process is actually pretty simple. Let's look at three different options for you to consider.
The first option is to completely forego a Windows-based PKI. You could issue all Secure LDAP certificates directly from the non-Windows CA. The requirements for such certificates are documented in the following KB article:
321051 How to enable LDAP over SSL with a third-party certification authority
The benefit of this approach is that it eliminates a Windows service that you may not actually need. The downside is that much of the process of requesting, renewing and managing your Secure LDAP certificates must be performed manually. A strict process
should be implemented to manage the lifecycle of the certificates issued to your Windows servers, but, depending on the number of servers you will need to manage, this investment may actually be preferable to managing a Windows PKI.
A second option is to install Active Directory Certificate Services (ADCS) on a server in the root domain of each forest. You would install the CA as an Enterprise CA subordinate to the non-Windows CA. Prior to actually installing ADCS, you would first publish
the root certificate of your non-Windows CA into Active Directory in each forest. This will ensure that every Windows computer belonging to each forest will trust your non-Windows CA.
To publish a root CA certificate in Active Directory, you can run the following command:
Certutil -dspublish RootCaCert.cer RootCA
Where RootCaCert.cer is the base64 encoded digital certificate belonging to your non-Windows root CA.
Once this is done, you can install ADCS on a server in the root domain. During the install, you will be given the option to save the Subordinate CA certificate request to a file. This file must be processed by your non-Windows root CA which will then issue
the subordinate CA certificate. Once the SubCA certificate has been installed, your ADCS issuing CA will automatically issue certificates to all of your domain controllers suitable for Secure LDAP. You will still need to manually request certificates for your
ADLDS servers, but this process is documented here:
The result will be a two-tier hierarchy consisting of the root CA and two issuing CAs, one in each forest. This is a good option if you have to issue certificates to more servers than you can to manage manually. Certificate lifecycle on the ADDS servers
can be managed automatically, and the request and renewal process for ADLDS servers is greatly simplified.
A third option is to install ADCS as described above -- Enterprise Subordinate CAs in the root domain of each forest -- with the intention of managing them as Intermediate CAs. You would then install a third tier of CAs subordinate to the Intermediates and
these CAs will actually be used to issue certificates. Now, you would only do this if you have already considered that you might want to issue certificates for other purposes to users and computers belonging to your two forests. This design allows great flexibility
for current and future certificate needs. You could easily add more issuing CAs to this third tier to provide a measure of load balancing and fault-tolerance, and also for implementing differing levels of requirements for obtaining a certificate (for example,
High, Medium, and Low Assurance). The trade-off is that you will also increase your planning and management requirements. Again, I would only recommend this configuration if you think that you will need a flexible PKI capable of supporting many thousands of
users and computers, many different certificate-based technologies, or multiple sets of requirements for issuing different types of certificates.
Based on what you've already described, I think the second option may be best for your institution. If you would like to learn more about Active Directory Certificate Services in Windows Server 2008, I invite you to review the technology portal at
If you find that you require more targeted technical assistance you can submit a online support request through the Microsoft Help and Support site:
Senior Support Escalation Engineer
Hola a todos. Soy Tolu Igbon, del equipo de Directorio Activo. Un caso común que tratamos en el área
I have a question about Domain Controller certificates. I have multiple independent domains and a single enterprise CA on Windows 2008 Enterprise on one of the domains. I created a custom template for the domain controllers from other domains so I am able to use LDAP over SSL. This works well when you connected to an individual domain controller. When we use a alias that provides round robin functionality, this doesn't work anymore.
In #1 above, you say that the subject needs to be the same as the name of the resource people use to connect to it. I've made 2 certificated with the same template and parameters, one with the DC server name, and one with the alias. The DC name always works, the alias does work when connecting using LDP.exe.
Any ideas on this one? I've been working though this for over a month.
Hey Jason Boig IMF.
In regard to your question, you will have to configure a subject alternate name in the request file and the request will have to me manually submitted.
Please see the following -
931351 How to add a Subject Alternative Name to a secure LDAP certificate
On 2008 or higher this is an alternative way to accomplish the same thing -
To give you a little more information.
1. Duplicate the "Domain Controller Authentication" Template.
2. then edit the template, and click on the "Subject Name" tab.
3. select "Supply in the request".
4. click on the "Security" tab.
5. Add/Verify the "Domain Controllers" and "Administrators" group has Enroll permissions.
6. Click OK.
7. In the CA Snapin console, select the "Certificate Templates" folder.
8. Right Click and select "New" then "Certificate Template to Issue".
9. select the template you created in step 1.
Once that is done, you can enroll for the template on each DC individually. You are not going to be able to enroll for this certificate via autoenrollment.
Enroll for the new template via the Certificates MMC. You will need to add the domain controllers, and alternate DNS name in the Subject Alternate Name (SAN). You do this under the "Alternate name" section of the Subject tab.
Review the blog that Jim gave you earlier for a visual diagram of the UI.