4

I'm reading the following article from Microsoft's TechNet: Certification Authority Naming

Can someone please help to clarify the following:

In Active Directory Domain Services (AD DS), the name that you specify when you configure a server as a CA becomes the common name of the CA, and this name is reflected in every certificate that the CA issues. For this reason, it is important that you do not use the fully qualified domain name for the common name of the CA. This way, malicious users who obtain a copy of a certificate cannot identify and use the fully qualified domain name of the CA to create a potential security vulnerability.

Why does certification authority (CA) name should never be the same as the server's computer name (NetBIOS or DNS / hostname) and what are the risks?

4

Default common name naming scheme in ADCS is <DomainName>-<CAHostName>-CA. For very small and purely internal scenarios would work, however this scheme exposes at least two properties: internal Active Directory domain name and host name. Moreover, if CA sits on a domain controller, it may reveal the domain controller name. For example, Contoso-DC1-CA would tell that internal domain name is Contoso, CA host name is DC1. Thus we can guess that this server also acts as a domain controller. In some terms, this would be a great start for an attacker in internal structure learning.

In addition, default Distinguished Name suffix contains full X.500 path to a domain where CA resides. For example, DC=HQ, DC=Int, DC=Contoso, DC=com. Here we can identify, that company Contoso has at least three AD domains in the LDAP tree: top domain is Contoso (most likely, organization name), child domain is Int (presumably, Internal) and subchild is HQ (presumably, Headquarters)

However, security risks are not that dangerous, because in many cases it is easier to retrieve this (and much more) information in other ways. For example, investigating client certificates, use social engineering tools and so on. Naming recommendations play huge role in flexibility. When CA is sticked to a particular domain and host name, it would be very hard to move CA somewhere else (due to reorganizations) and CA name information would be misleading for corporate users. Eventually, you will have to decommission CA server and move clients to a new CA on a new place.

As a result, it is recommended to build your CAs as they are not tied to any specific domain. Though, organization information shall be included.

Suppose, you are implementing 2-tier ADCS in Contoso Pharmaceuticals and planning to deploy it in the hq.int.contoso.com and west.int.contoso.com domains, then you could use the following names for offline root CA and online issuing CAs:

Root CA common name:
    CN=Contoso Pharmaceuticals Root CA
    OU=Security Division
    O=Constoso Pharmaceuticals Ltd.
    L=Philadelphia
    S=PA
    C=US
Issuing CA (headquarters) common name:
    CN=Contoso Pharmaceuticals Class 3 Client CA
    OU=Security Division
    O=Constoso Pharmaceuticals Ltd.
    L=Philadelphia
    S=PA
    C=US
Issuing CA (west branch) common name:
    CN=Contoso Pharmaceuticals West Coast Class 2 Client CA
    OU=Security Division
    O=Constoso Pharmaceuticals Ltd.
    L=San Francisco
    S=CA
    C=US

This scheme does not reveal internal names and is not tied to any Active Directory domain, in result, it will be easy to perform CA server migration across domains and trees and even forests during reorganizations. On the other hand, they provide enough information to identify the organization who owns these CAs and may provide users some clues about CA location to select the nearest CA. Location addresses are not necessary (because they can be retrieved from public sources), but might be required by laws. At a minimum, Organizational Unit, Organization and Country RDN attributes must be specified in the DN suffix.

ADCS naming is important, but many administrators forget about another thing where naming is important: Authority Information Access and CRL Distribution Points certificate extensions. Default naming scheme reveals much more information (to a potential attacker) than default CA name. And it is hard to migrate CA somewhere else with default CDP and AIA locations. Some time ago I wrote a guide that uses best practices on CDP/AIA URL naming schemes. This might be helpful for you as well: Designing CRL Distribution Points and Authority Information Access locations

  • Thank you so much CryptoGuy! This have answered my question with great details. – DaveIce Aug 7 '16 at 10:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.