Article

Tech Tuesday: SSL Certificate Options

4 April 2017 | Louis Bougeard | About a 7 minute read
Tags: ANDtech, aws, Certbot, cloudflare, DevOps, DNS, EC2, ELB, https, letsencrypt, london tech jobs, nginx, ssl, ssl certificates, tech, website security


Defining how you secure your data is an important non-functional requirement to consider when developing applications. One of our key focuses at AND Digital is making sure the products we build are both secure and robust.

How could your data be compromised? How could an attacker gain access to sensitive data such as usernames and passwords, customer data, private and personal data? Is data end-to-end encrypted? Is it encrypted in situ?

In this post we’ll look specifically at securing inflight data, transmitted from your users, to your service. In particular we’ll look at a scenario where you are using a DNS / CDN provider who also provides free SAN (Subject Alternative Names) certificates from browser to their service, where SSL termination occurs, a service like Cloudflare’s Flexible SSL offering (which is one of the services we have been using at AND Digital).

A common scenario is to terminate SSL at an external CDN or load balancer provider. To fully secure inflight data you need to encrypt it from browser all the way to your server, not only from browser to the external provider to ensure that data is only in an decrypted state once in the DMZ.

 

Self-signed certificates

Self-signed certificates are certificates which you create yourself, without a Certificate Authority verifying your identity or ownership of the domain you are securing.

A services like Cloudflare or Akamai allows you to use self-signed certificates on your origin server. Their service is called Flexible SSL. When traffic hits Cloudflare from the browser, Cloudflare is configured to reverse proxy the traffic to your origin server (it’s a customised version of NGINX). CDN providers such as Cloudflare or Akamai can be setup to reverse proxy traffic over https using a self-signed certificate without verifying that origin certificate.

Pros:

  • Free
  • Cost is labor only, to generate and install the certificate
  • Can be a very long lived certificate (multi years)

Cons:

  • Certificates cannot be revoked by an authority
  • If an attacker spoofed your certificate in anyway they could impersonate you
  • Cloudflare does not verify the identity or ownership of the certificate, as there is no Certificate Authority involved.

 

Paid certificates issued by a certificate authority

The traditional option is simply purchasing a certificate from a Certificate Authority, such as Comodo, THAWTE, Digicert or Godaddy. There are a wide variety of options, from single domain certificates, to extended validation certificates to confirm and present in the address bar the identify of the certificate owner, to wild card certificates for apex and sub domains.

Pros:

  • You own the certificate
  • The certificate can be used wherever you require SSL termination (Cloudflare or AWS, for example)
  • You own the process

Cons:

  • Costly, hundreds of pounds for a multi-year wildcard certificate
  • You need to manually generate a Certificate Signing Request
  • You need to manually install the certificate
  • You need to manually renew (and remember to renew) the certificate

 

That said, companies like Cloudflare are now making this substantially cheaper.

SSL

 

 

Free certificates from a provider

AWS offers free certificates through their AWS Certificate Manager service. These certificates are automatically managed by Cert Manager, they are renewed automatically.

However the service requires you run your servers (EC2 instances) behind ELB (Elastic Load Balancer). This is great option if you are running behind ELB.

Pros:

  • Free
  • No CSR (certificate signing request needed)
  • Automatic deployment
  • Automatic renewal
  • Little to zero maintainance

Cons:

  • You have to run a project to set this up
  • Requires ELB (Elastic Load Balancer), all your services must be behind ELB
  • You need to remember to ensure all your services are behind ELB
  • You are indirectly paying for the certificate through your ELB usage
  • When you have a single EC2 instance running your service, you have ELB in front, but it’s not really being used, as there is nothing to load balance to (you have only 1 service!)
  • ELB is redundant for a single service

 

Let’s Encrypt certificates

https://letsencrypt.org is an (exciting) initiative to provide free certificates to anyone who can verify that they own a domain. The service defines a protocol called ACME, “for automating the management of domain-validation certificates, based on a simple JSON-over-HTTPS interface”.

There are many Let’s Encrypt clients in a variety of languages which can ‘talk’ the ACME protocol and communicate with the Let’s Encrypt Certificate Authority, from simple Shell Scripts, to golang clients, to the official client, written in Python, formerly known simply as the Letsencrypt Client, now known as Certbot (https://certbot.eff.org).

To use Let’s Encrypt, you run one of these client on local machine or server, providing a list domains you would like to create a certificate for (such as AND Digital.com app.AND Digital.com boost.AND Digital.com). You also provide one of a variety of mechanisms for the Let’s Encrypt certificate authority to verify that you own the domain, called a ‘challenge’. You have the option of HTTP challenge, where you host a file with a token produced by Let’s Encrypt / ACME verifying to the CA that you own the domain as you could put the file there, an option to run a temporary stand-alone web server for the challenge, or a DNS Challenge, where during certificate generation you add temporary DNS records through a ‘hook’ script with the tokens generated by Let’s Encrypt / ACME verifying again to the CA that you own the domain.

Pros:

  • Free
  • Cost is labor only, to set up a Let’s Encrypt client and the certificate deployment pipeline

Cons:

  • Might not be supported by all clients, specifically older root certificate bundles (e.g. Java 7 JVM doesn’t always accept Let’s Encrypt and you need to add to your JVM CA Certs).
  • Certificates are short lived (90 day certificates), but automating renewal is the point
  • Learning curve can be steep
  • No support for wildcard certificates

There are also issues with this if you were using another provider previously: https://support.cloudflare.com/hc/en-us/articles/214820528-How-to-Validate-a-Let-s-Encrypt-Certificate-on-a-Site-Already-Active-on-CloudFlare

 

Conclusion

While implementations vary between platforms and stacks, one thing is clear: securing inflight data with an SSL certificate is the default in web applications of today. With widely supported free solutions, the cost of the certificate itself is not an issue for even the tiniest of websites.

Read More From This Author

Share this blog post

Related Articles

Careers

We’re looking for bright, dynamic people to join our team!

Discover More Roles