As mentioned in the CA Overview, PKI is based on trust. Clients must trust the Root Certificate Authority to build a chain of trust and accept a certificate. The key difference between a publicly trusted and private certificate authority is that all computers and browsers trust publicly trusted Certificate Authorities while private CAs will have to be explicitly added by the IT administrator. Both private and public certificates have their valid use cases. In the following sections we will help you choose which certificate type you should use by showing some sample use cases for each type of certificate.
Publicly trusted CAs are trusted third parties that meet the requirements of popular certificate stores (Microsoft, Apple, and Mozilla) and hence are automatically trusted by the operating system of the device. These certificates are mostly used for publicly facing websites such as keytos.io.
To request a publicly trusted certificate for a domain, the owner must prove ownership of the domain by: adding a TXT DNS entry, serving some specific challenge response at that domain, or pointing a subdomain to a certain endpoint. Once the domain is validated, the certificate is issued and the server will be able to serve the certificate.
To issue all the certificates needed for all the sites around the world, without relying in a single party or government there are hundreds of Certificate Authorities. In the past, some of these issuers where found to issue rogue certificates without the knowledge of the domain owners. Allowing bad actors to impersonate those domain owners. To combat this, Google has pushed a requirement to all certificates to be pushed to at least two Certificate Transparency Logs. These logs allow companies to monitor if a certificate for one of their domains was issued without their permission. While monitoring for logs might seem like a tedious task, EZCA offers free domain monitoring for our premium CA costumers.
Privately trusted CAs are created internally by an organization. To be trusted by devices the certificate chain must be pushed to all devices by: group policy, MDM, or manually installed. Learn more about how to push private trusted certificates to all devices Private CAs are mostly used for internal certificates where that certificate will never have to be validated by an external party. Some examples where private CAs must be used are: Internal sites, Application Authentication, and User Authentication.
While publicly trusted certificates are great for public sites, many organizations have sites only available in their intranet. These sites could not be validated by a public CA since the domain is only available internally in the company network. Private CAs allow you to be able to authenticate that the server you are connecting to is a valid server that has passed the issuance requirements set by your organization and establish and encrypted connection.
Another great example where a private CA can help improve security and reliability is application authentication. While application authentication can be achieved by using self signed certificates, this forces you to use thumbprint. Although certificate thumbprint pinning is a valid way to validate a certificate, it is not recommended. One of the main drawbacks of using thumbprint pinning is the inability of rotating the certificate. Using a private CA allows you to do subject name validation (subject name validation is where you check the subject name to match a specific value such as the application name or ID and that it has been issued by a trusted authority). Enabling subject based authentication allows your code to authenticate the application based on the root of trust, enabling shorter certificate validity periods while preventing outages by a poorly rotated certificate. This authentications at scale has become more important with the growth of IoT where you might have millions of devices making it impossible to manually keep track of their certificate lifecycle.
The best way to create unphishable credentials is by issuing each user a user certificate that can be use to authenticate to Active Directory and Cloud Services. This can be achieved by using PIV authentication or the new certificate-based authentication in Azure Active Directory. These authentication methods work by using a CA trusted by Active Directory to issue the user a certificate containing the user’s UPN. This allows the user to easily authenticate to resources without having to remember long complex passwords while protecting the user’s identity by using cryptographic based authentication.