Certificates: The differences between different types of Certification Authorities (CAs)
What are the differences between a public and private CA? What are the benefits of each, and what are the drawbacks? What are the use cases? After reading this article, you'll understand.
This article helpfully details the key points that are worth considering for each of the 3 most commonly encountered types of certification authority:
- Public (Let's Encrypt) CA with Automated Certificate Management Environment (ACME) support
- Other Commercial Public Certification Authorities
- Internal/Private Certification Authority using Microsoft's Active Directory Certificate Services (ADCS)
Worth noting, there are other options for ACME based Public CAs, and other tooling that can be used for internal CAs, but these are the most commonly encountered types and would account for probably 99% of the installations you would see out in the workplace.
Lets Consider:
Let’s Encrypt Public Certification Authority
A modern secure certificate authority which is suited to automatically renewing HTTPS certificates specifically.
Link: https://letsencrypt.org/
Example/Typical Use Cases:
Used widely on any HTTPS endpoint including public internet websites, and internal services.
Ownership of the CA:
Created by a non-profit (Internet Security Research Group (ISRG)), funded by many organisations including top tech companies and the Electronic Frontier Foundation (EFF)
Security & Assurance:
Considered secure
Technical Complexity:
On devices with native support it is very straightforward. Renewal automation is very possible and common. Non-native support requires more technical skill.
Flexibility:
Minimal, you can only issue Domain Validated Server Authentication certificates using FQDNs that you can prove ownership of at the time of issue.
Cost:
Totally free, donations optional
Maintenance:
Once set up, typically none, other than some monitoring to check/fix for errors in the automated renewal processes. It is possible that breaking changes may be implemented so it is important to regularly check announcements from Let's Encrypt and device vendors as applicable.
Support:
Lets Encrypt official guidance, online community guidance, device vendor documentation
Root Certificate Authority / Issuer:
ISRG Root CA X1/X2
Root Certificate Trusted By:
Trusted by 99% of devices around the world from 99% of vendors - however some legacy/end-of-life operating systems may lack trust for the Root Authority required.
Certificate Validity Length/Period:
90 days only, possible that this will decrease in the future to just 6 days.
Certificate Validity Rules:
Domain Validated: You must prove ownership of the domain name via either HTTP or DNS validation checks upon your certificate request (these are typically automated).
Valid Domains / SANs:
Your FQDN Common Name (CN) plus up to 100 validated Subject Alternative Names (SANs) per certificate.
Certificate Purposes:
Server Authentication (only)
Renewal Automation:
ACME Integration with integrated support from thousands of vendors
Lets Consider:
A Commercial Public Certification Authority
I would consider these the legacy choice, and have been around since the advent of HTTPS on the internet.
Example/Typical Use Cases:
Used widely on any HTTPS endpoint such as Production front ends of public websites, Wi-Fi guest portals, as well as email servers. Sometimes required to be used for customer websites by insurance policies.
Ownership of the CA:
Various Private companies
Security & Assurance:
Considered secure, but entirely dependent on the ownership and reputation of the Certification Authority itself.
Technical Complexity:
Straightforward for issuing certificates but typically no renewal technical automation. Oftentimes, a manual Purchase Order (PO) process is required within the organisation for each certificate, unless a subscription is negotiated.
Flexibility:
More options but restricted to the validity rules stated. Multiple types of certificate purposes offered including Server Auth, Code Signing, etc.
Cost:
Typically, a cost per certificate, varied costs depending on numerous variables and vendor pricing. Not unusual to see around £100 per certificate issued. Paid subscriptions for unlimited certificates are sometimes available.
Maintenance:
Renewal reminders are a must, as the process can take a while if your organisation's purchase order process is slow. Once order is received, certificates are issued quickly but will require manual installation/deployment unless ACME is supported by the CA and the device(s).
Support:
Depending on vendor but typically well documented with telephone & email support available to paying customers.
Root Certificate Authority / Issuer:
Depends on the vendor, an example would be AAAA Certificate Services (Sectigo)
Root Certificate Trusted By:
Depends on the vendor, but typically the Roots are trusted by 99% of devices around the world from 99% of vendors.
Certificate Validity Length/Period:
Typically, 1 year only
Certificate Validity Rules:
Domain & Organisation Validated: You must own the root/apex domain name, this is typically completed with a DNS or email verification. You must be able to prove organisation ownership for Organisation Validation (OV) certificates, this typically would require sharing documents around the company’s incorporation or other legal document.
Valid Domains / SANs:
Only FQDNs that use the validated suffixes for your organisation, but typically unlimited Subject Alternative Names (SANs) that are also validated.
Certificate Purposes:
Server Authentication, Client Authentication, Code Signing typically available but often more purposes available.
Renewal Automation:
Proprietary automation portals, occasionally ACME support
Lets Consider:
A Private/Internal Certification Authority implemented with ADCS.
This is the most common type of private CA, but there are other types, such as those run utilising OpenSSL under Linux (not covered here).
Example/Typical Use Cases:
Intranet services/sites, SCCM, Active Directory, RDP, Microsoft Servers
Ownership of the CA:
Your organisation
Security & Assurance:
Considered secure if implemented following security best practices, insecure if not.
Technical Complexity:
Complex. A security best-practices deployment of ADCS infrastructure requires a number of organisational policy considerations and technical modifications to the default out-of-box role installation.
Flexibility:
Very flexible, custom certificate purposes, custom validity rules, custom CNs, SANs, etc.
Cost:
The Active Directory Certificate Services (ADCS) role is included with Windows Server licencing. At least two dedicated Windows Servers are required for a best practices deployment.
Maintenance:
High level of infrastructure maintenance. Offline Root CA must be kept securely isolated. Online Issuing CA must be kept up-to-date and maintained. Root and Issuing CA certificates will require renewal and processes to complete – this must be followed before expiration to avoid disruption to all devices using certificates issued by the CA.
Support:
Extensive from Microsoft but requires significant effort from technical persons to become competent and be able to provide a secure environment. May require a consultant to implement in many cases
Root Certificate Authority / Issuer:
Your organisation's offline root CA.
Root Certificate Trusted By:
Trusted only by internal assets, where the root and intermediate certificates have been already installed (typically deployed via GPO or other scripts).
Certificate Validity Length/Period:
Entirely configurable based on ADCS certificate templates, for any length of time.
A typical implementation would see: 10 YEAR Root CA lifetime, 5 YEAR Issuing CA lifetime, 1-2 YEAR Device Certificate lifetime.
Certificate Validity Rules:
Entirely up to your configuration, configurable based on ADCS certificate templates feature. Possible to create highly insecure configurations if not closely considering the options.
Valid Domains / SANs:
Totally configurable. DNS hostnames, FQDNs, IP addresses, metadata, any domain
Certificate Purposes:
Any, configurable with ADCS certificate templates
Renewal Automation:
Certificate GPOs for Windows, difficult to automate other platforms.
Conclusion
As you can see, there are many pros and cons to each of the different types of commonly encountered certification authorities. As is typical, there is rarely a one-size fits all answer, it depends entirely on your organisations specific needs.
That said, Lets Encrypt comes closes to being the one size fits all solution, provided you only require HTTPS endpoint certificates. If you need other types of certificates, such as Code Signing, or Client Authentication, you'll have to look at the other options.
A private CA is oftentimes a requirement to increase your internal systems security, and is typically used in most organisations. But to do so without careful consideration would in-fact decrease your security posture. A poorly implemented ADCS environment is a typical attack vector utilised by malicious actors. It is therefore incredibly important to be aware of the technical and organisational processes required in order to successfully implement an internal/private CA.
Ryan Drake
Infrastructure Insider - Editor-in-Chief
Copyright 2025, All Rights Reserved.