Use SSL Certificates from Public CA or Create a Private CA?

Photo by Markus Winkler on Unsplash

In this post we are going to take a deep dive into what you should use for SSL certificates. Often this question pops up when new or existing infrastructure is deployed and can be a good topic for an internal discussion. Hopefully by the end of this post you’ll have a deep insight into both options and will be able to go in with full confidence in the next discussion.

Context

Let’s say you are part of the infrastructure team (DevOps, SRE, Platform) or a Full Stack Dev and are deploying Kubernetes cluster or deploying a public facing app in the Cloud (AWS, Azure, GCP, etc). One colleague suggested we should use Let’s Encrypt as a CA, another one suggests that all our websites are private so maybe we should use a Private CA. Now as a bonus, the CTO suggests we should use SAN certificates and wildcards. All the above mumbo jumbo is confusing right? Let’s break it down below.

Public CA SSL certificates

A Public CA is a Public Certificate Authority which essentially means they are recognised by most browsers (Chrome, Firefox, Safari, etc) as trusted certificate issuers which keep the internet a safe place. For more information check out this link: https://www.digicert.com/blog/what-is-a-certificate-authority.

Who are these trusted CAs?

Amazon, Microsoft, Google, Digicert, Let’s Encrypt to name a few. Most off-the-shelf container images will trust these CAs.

How does your browser know to trust these CAs?

Most likely your operating system was shipped with a CA certificate from the CAs. In Linux distributions normally the ca-certificates package (yum, apt, apk, etc) will download the popular CAs. If you see a padlock next to the URL, your browser trusts the SSL certificate issued by that CA.

Which CA is the best one for the Cloud?

It is recommended to use the Certificate Management service that your Cloud provider provides. For example for AWS use ACM (Amazon Certificate Manager), Azure use Azure Keyvault and Google uses Google-Managed SSL.

Why should we use managed SSL certificates that the Cloud providers provide?

• Native integrations with other services. For example if you use ACM in AWS, you can reference the ARN in CloudFront, EKS, S3, VPN endpoints and any managed service provided by AWS.
• Certificate renewal is automatic and managed.
• No dependence on other third party providers, everything is self-contained within the Cloud provider.

When should we NOT use managed SSL certificates?

• When we want to be “Cloud agnostic”, most of the time people misuse this assumption. 80% of the time companies stick with whatever Cloud provider they go with the first time unless you have a multi-cloud product or working around a limitation of the current Cloud provider. If you know your company won’t change its Cloud provider then stick with native SSL certificate providers.
• Air gapped environments (no public internet access), these require a private CA.
• Any other product limitations that prevents us from using managed Certificates.

Cert Manager for all Kubernetes clusters?

Cert Manager is great for using the Let’s Encrypt CA (by default) to issue SSL certificates and keep renewing them automatically. Most Cloud providers have native integrations with their managed SSL services, consider using them, if renewal comes around and cert-manager pod is down your certificate won’t renew. Keep in mind Let’s Encrypt also goes down sometimes: https://letsencrypt.status.io/. The same also holds true for managed Cloud services too, Cloud providers can be down too.

Tooling for Let’s Encrypt

As Let’s Encrypt has gone up in popularity many proxies come with Let’s Encrypt out of the box. For example Caddy and Traefik automatically fetch an SSL certificate. These can be super useful when doing quick deployments or proof of concepts.

Private CA SSL certificates

A Private CA is managed by you or the company you work for. No other browser or TLS based server will trust your CA unless you explicitly make them trust your CA. Cloud providers allow you to upload your own CA certificate and give the same services as if you are using a Public CA.

Why should one use a Private CA?

• When the internet is not reachable. It is not possible to fetch the certificate. However if using a managed SSL service you can use “internal” endpoints to fetch the managed certificate.
• A Private CA adds an additional layer of security, only authorised clients which trust the private CA can talk to the TLS endpoint. Great for internal facing applications.
• Free of charge. There is no cost associated with rolling your own CA. Managed SSL services are free too but to use them anywhere useful you’ll need to pay for that service (ELB, CloudFront, S3 etc).
• Private Clouds.

Is there an overhead of using a Private CA?

Yes, you’ll have the secure the private key for the CA. You’ll have to roll the CA to all clients and make them trust your CA. You’ll have to manage the renewal and deployment of the SSL Certificate. When building your container images you’ll have to trust the CA. No native integrations with Cloud technologies unless you load onto managed SSL services otherwise you’ll have to roll your own proxy (NGINX, traefik, etc).

What is a SAN certificate?

A SAN (Subject Alternative Name) certificate allows multiple different domains for a single SSL certificate. For example I can use one certificate for dev.google.com, dev-env.gmail.com, prod.example.com which makes it a SAN certificate.

What is a wildcard certificate?

A wildcard certificate allows multiple sub-domains on a single certificate. For example, if I issue a certificate for *.google.com, I can use it for dev.google.com, uat.google.com and test.google.com. However I cannot use it for test.dev.google.com. This is because test.dev.google.com is a sub-sub domain of *.google.com not a sub-domain of *.google.com.

SANs and Wildcards together?

To make things easier to manage many opt to use wildcards for their Kubernetes deployments, this helps to stay within Cloud Provider and Let’s Encrypt limitations. SANs however can be tricky, try not to share SANs for segregated environments, for example I wouldn’t use a SAN for dev.google.com and prod.google.com (imagine they are different CAs), if the key for dev.google.com is compromised you’ll have to rotate prod.google.com too.

Conclusion

Above is not an exhaustive list of considerations for deploying SSL certificates in production but rather an insight into whats our there and best practices. Hopefully now you can decide if you want a Public CA or Private CA or use SANs and wildcards.