The Active Directory Certificate Services has been known by the name since Windows Server 2008, previously it was just called Root Certification Authority. Certificate Authority). It is used to create your own public Key Infrastructure (PKI for short). Something like that can then be used for certificate-based registration on systems, a network policy server with 802.1X or the protection of internal web servers with (SSL) TLS certificates for https. There are many possible uses, these examples are only intended to illustrate the scenarios for which a CA can be used in your own infrastructure.
This is not intended to be an installation guide for the ADCS, but to show the basic concept of a CA structure and the advantages and disadvantages of such a service.
The root CA or root certification authority is the highest authority in the chain of trust. It issues certificates for web servers, for example, which the web server can use to prove its identity and authenticity to third parties if the Root CA is trusted. This is exactly the behavior that we see in our daily web browsing when the green lock appears next to the URL.
Browsers have implemented a list of over 100 generally trusted CAs. This means that not everyone has to have their own CA and make it known to everyone, but can also use third-party certificates to operate their website with HTTPS. Due to its criticality, a root CA should be very well secured and ideally offline to prevent compromise.
A sub CA is a subordinate certification authority that is mostly used to confirm or issue certificates. Sub CAs can therefore be used as a kind of load balancer. They can also be used for different tasks, for example for the separation of TLS and S/MIME or for different locations. Sub CAs can also have other sub CAs under them and the respective higher authority signs the certificates of the subordinate authority, thus creating a chain of trust, i.e. a chain of trust. This has the advantage that in the event of a compromise, not all certificates have to be declared invalid, only those issued by the compromised sub-CA. The root CA is therefore only used to create new sub CAs and the certificate revocation list. Certificate Revocation List, CRL) to sign.
Here is an image of a website's certificate chain.
The ADCS integrates very well into an existing domain, but should be very well secured or offline and considered a Tier 0 asset. In a two or more tier hierarchical concept, the entire Public Key Infrastructure is a Tier 0 asset from an administrative point of view. There are few exceptions, such as the certificate revocation list, which is classified as Tier 1. The certificates, for example for 802.1X to gain access to the network, can be automatically distributed and renewed using group policies. This means that end devices that are domain-integrated can be pushed fully automatically into the correct VLAN with the help of the network policy server (NPS for short), which mains separation influenced and simplified in a very positive way.
Since server administration is supposed to be simplified by many wizards nowadays, the ADCS can be installed very quickly. The problem with this is that it is very easy to get many new gaps and attack vectors into the network if you are not careful and neglect the protection of the CA and the PKI. A very nice example is the combination of the PetitPotam exploit with a relay attack against the CA and the resulting complete compromise of the entire domain.
With my own certification authority or public key infrastructure, I can provide my local services such as web applications with certificates that are trusted within my own structure. This makes it more difficult for attackers to successfully carry out a man-in-the-middle attack, for example, since the encryption would have to be broken and the certificates exchanged. With your own certificates, you can also upgrade the Network Access Control (NAC) via 802.1X and exchange user names and passwords for certificates. However, it is important to secure the tier 0 assets, which represent a CA. An attacker can use this to gain privileges and create persistence in the network. Even if the implementation of ADCS can increase security, an administrative effort is necessary to set it up securely and to manage it continuously.
