When it comes down to it, PKI is based on trust. Clients must be able to trust the root CA in order to build a chain of trust and accept a certificate. Not only is trust the key to PKI, but it is also the key to understanding public vs private certificate authorities. Just because they are both CAs doesn’t necessarily mean that one is better than the other – they have different characteristics that apply to different scenarios. As such, before we can understand the difference between a public CA and a private CA, it is vital to define exactly what each type of CA is.
Publicly trusted certificate authorities (CAs) are trusted third parties that meet the requirements of popular certificate stores such as Microsoft, Apple, and Mozilla. As such, public CAs are automatically trusted by the device’s operating system – with a public CA, individuals within an organization do not need to register their certificates since the certificate is trusted without individual interference. These certificates are mostly used for publicly facing websites such as our very own keytos.io.
There are many methods to request a publicly trusted CA for a domain which we will not get into the specifics of in this article; however, as a broad understanding of how to request a publicly trusted CA for a domain, the organization must prove the domain ownership to the issuing/subordinate CA. In that way, the CA acts as an authority. Check out this blog on issuing/subordinate certificate authorities vs root certificate authorities to learn more about how they help verify domain ownership.
A great example of this is the process of getting your driver’s license. When you get your driver’s license, you have to go to the DMV and prove that you are who you say you are with documentation such as your passport and birth certificate. Once the DMV has this information and can verify that you are who you say you are, they issue you a driver’s license (a certificate). Now that you have this license (certificate), you can use it without others needing anything else to verify your identity – for example, you can then go to a bar and give the bouncer your driver’s license, and they will be able to verify your identity without needing the birth certificate or passport that you used to verify yourself at the DMV. The bouncer assumes that the DMV already did all of the validation so they can trust that your driver’s license is accurate. That driver’s license serves as a public certificate, and the process at the DMV serves as the process of requesting a public certificate.
To issue all of the certificates required for all websites around the world – all without relying on a single party or government – there are hundreds of certificate authorities. Previously, some of these issuers were found to issue rogue certificates without the knowledge of the domain owners, thus allowing bad actors to impersonate those domain owners.
To combat this, Google has pushed a requirement that all certificates be pushed to at least two Certificate Transparency Logs, or CT Logs. CT Logs allow companies to monitor if a certificate for one of their domains was issued without their permission. While monitoring logs might seem incredibly tedious, EZCA offers free domain monitoring for our premium CA customers. To learn more about CT Logs, check out our blog outlining the definition and history behind Certificate Transparency Logs.
Privately trusted CAs are generated internally by an organization. In order to be trusted by devices, the certificate chain must be pushed to all devices by group policy, MDM, or manual installation. Check out our documentation on how to push private trusted certificates to all devices to learn more.
Private CAs are mainly used for internal certificates where that certificate will never have to be validated by an external party. Some examples where a private CA needs to be used include internal sites, application authentication, user authentication, and device authentication.
While publicly trusted certificate authorities are great for public sites, many organizations have sites only available in their intranet. These sites cannot be validated by a public CA since the domain is only available internally in the company network. A private CA allows you to authenticate that the server you are connecting to is a valid server that has passed the issuance requirements set by your organization and established an encrypted connection.
Another great example of where a private CA can help improve security and reliability is in application authentication. While application authentication can be accomplished via self-signed certificates, this forces you to use thumbprint.
Although certificate thumbprint pinning is a valid way to verify a certificate, it is not recommended. One of the main drawbacks of using thumbprint pinning is the inability to rotate the certificate. Using a private CA enables you to conduct subject name validation, which 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, allowing for shorter certificate validity periods while preventing outages by a poorly rotated certificate. This authentication at scale has become vastly more important with the growth of Internet of Things (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 used 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 certificate authority trusted by Active Directory to issue the user a certificate containing the user’s UPN, allowing the user to easily authenticate to resources without needing to remember long, complex passwords, all while protecting the user’s identity via cryptographic based authentication.
One of the main uses of private Certificate Authorities is to issue internal authentication certificates for users and devices for device authentication into VPNs and Wi-Fi. These certificates are usually issued by mobile device management (MDM) tools such as Intune. Learn how to deploy certificates through Intune SCEP here.
So, now that we know what a public CA and a private CA are, what is the biggest difference between the two? It all comes back to one word: trust. The key difference between a public certificate authority and a 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.
Ultimately, as long as you know which certificate is best for your organization and you are following certificate management best practices, you will be just fine. Both public and private certificates have their valid use cases – which one you and your organization should use entirely depends on your unique scenario.
To learn more about which CA you and your organization should use and about our log monitoring services, check out our certificate management tool, EZCA or schedule a free PKI assessment with one of our experts today! Additionally, to learn more about the foundations of PKI, feel free to check out our PKI Basics Series playlist on YouTube!
