Root CA and Subordinate CA
We will hear these terminology from the PKI authentication happening in various communication made between server and users. Certificate Authority (CA) is basically a company or an organization who has the rights to create a certificate for a certain server for its public key validity. Users will rely on certificates to authenticate the data they receive from servers by comparing the certifcate they receive with the valid certificate database their software had provided. Commonly, CAs will request the software to put up their certificate so that user can trust the data sent with the specific certificate.
The server or subject of the certificate has to request a certificate from the CA. Afterwards, the subject will receive their certificate from the CA and use it to prove its vailidity to their users. However, as the number of CAs overloads, it is becoming harder to trust new CA. That is where the role of root CA comes in. Root CA can verify a CA by providing them a certificate to proof that the specific CA is to be trusted. Root CA also holds its own private key which needs to have a higher security than the others.
Fundementally, root CA is the anchor of trust in the PKI tree where it stands in the top of the hierarchy of CAs and all CA below it is called subordinate CA. A subordinate CA who publishes certificate for its child CA would be called an intermediate CA as it is standing between the root CA and the CA that will be providing the certificates to users. Thus, the issuing CA is also a subordinate CA which is located in the bottom most of the PKI tree.
Root CA holds all of the essential information on certificates such as their issuing policy, CRLs, private keys and other related components. Therefore, it needs higher protection regarding its sensitive data it holds. Establishing subordinate CAs is also purposed to improve security for the root CA to reduce the risk of root CA private key getting compromised.
Creating Subordinate CA private key and certificate
In an Active Directory environment, a certificate services could be implemented. The first server installing the certificate services would be the root CA and it will have their own private key. After it has been established, other computers in the domain that establishes another certificate services would be joining an previously created CA.
The new server installing certificate services could select a parent CA which might be the root CA or intermediate CA. After this point, this server would be considered a subordinate CA and able to establish its own private key and certificate.
Certificate For a Public Website
As what we have established in a Windows Server environment, this type of certificate is considered a private certificate. These certificates are issued by private CAs which is located in a local network. It is used to secure and authenticate the systems locally to establish a higher security in the local network.
For a public website, a private certificate cannot be used as a form of trust in communication with the client as it may not be considered safe. Contacting public website means we are communicating with a source that we don’t know. Users will not want to contact a website who don’t have a trusted CA that is not included in the user’s trusted CAs. Therefore, having the signature of a public CA proves that the source can be trusted as the user could also check the validity of that specific CA.
Even though you can actually use self-published CA for a public website, a lot of things need to be a consideration as it has many downsides. We may think that publishing a CA personally would be much more simple and inexpensive. However, maintaining public certificates requires a large amount of resources and security. Many user applications are now equipped with the already well-known certificates recognition. Therefore, using a public CA might actually be more advantageous to a server.
Certificate Revocation List
Certificate Revocation List (CRL) contains number of certificates that have been revoked and considered invalid. This list will help the user’s browser or software to check if the particular certificate is still to be trusted or not. There are certain reasons why a published certificate is verdicted as a untrusted certificate, but most of the time, it is because the private key that the web server has has been compromised. Therefore, without the CRL, user will get their data stolen in the hand of the people who has stolen the server’s private key.
Web server could report to their CA and indicate that their certificate is compromised. The CA will then insert the specific certificate to the CRL database where all of the list are stored. To check the validity of a certificate, a web browser accesses this list and check if the certificate is on the list or not. The unavailability of the certificate in CRL means it is a pass. However, CRL is obtained in a form of full list which is considered a large amount of data by the user and some data still need to be parsed. This is seen as an inefficient way of communicating the CRL, though every browser might not have the same protocol.
Another method of checking revocation list is the Online Certificate Status Protocol (OCSP). With this method, a request from the user will be replied with the particular certificate’s status to check its validity. OCSP is requested through a specific server that will reply with the status for a faster communication. This special server is created due to CAs responsibility which is supporting web server’s request.
Active Directory Certificate Sevices for an Organization
Establishing a CA in a Windows Server using their certificate services for non-public use would be considered a private CA. By using this kind of method, the network is building a strong security system by enhancing the trust mechanism in the network. Private CA shares the same purpose as a public CA, it is to establish trust to the rightful communicators.
In an enterprise scheme, the root CA would possess the ultimate certificate informations and their identities. Then, from the root CA, subordinate CAs are the one responsible of issuing the certificates to the end users. These certificate will ensure that every user, servers and clients are to be trusted in the network. This reduces the risk of man-in-the-middle (MITM) attacks which intercepts information in between communication. Thus, servers will communicate only with users who has the correct certificates.
Marcellus's Blog 