Introduction

I use SSL certificates for everything. I am constantly creating them for internal systems and cloud services. This includes services such as web servers, SQL servers, anything where you might use a paid SSL certificate, or a self-signed certificate and you want to reduce your costs or deploy a more secure encryption method.

Let’s Encrypt provides free SSL certificates and an easy process to request and validate SSL certificates. This article also shows a very easy method to request CA issued SSL certificates from Let’s Encrypt using Google Cloud Shell.

Standards and certifications, such as the Payment Card Industry Data Security Standard (PCI), require connection security using TLS. TLS requires an SSL certificate. Failure to do so can mean the loss of the ability to process credit cards and other penalties. Without data encryption, you expose your systems to breaches, data loss and lost system control.

I will not cover how to install the SSL certificate once you receive the certificate and private key. Installation of SSL certificates is vendor and software version specific. Consult the documentation for the webserver, database server, etc. that you are deploying. This article covers obtaining an SSL certificate, which is the hard part.

What is an SSL Certificate?

An SSL Certificate binds together:

  • A domain name, server name or hostname.
  • An organizational identity, such as company name and location.

The depth of details bound to an SSL certificate varies based upon the type of validation performed by the Certificate Authority (CA) before issuing the SSL certificate.

An SSL Certificate is a set of one or more small data files that digitally bind a cryptographic key to an organization’s details. When installed on a web server, it activates the padlock, the https protocol and allows secure connections from a web server to a browser. When installed on a service, such as Microsoft SQL Server, it secures communications between systems.

Types of SSL Certificates

  • DV – Domain Validated – CABF OID 2.23.140.1.2.1
  • OV – Organization Validated – CABF OID 2.23.140.1.2.2
  • EV – Extended Validated – CABF OID 2.23.140.1.1
  • Misc types such as Self Signed, Individual Validated, Test, Code Signing, etc.

SSL certificates can also be single domain, multiple domain, and wildcard for each type. This is really just a marketing feature as all SSL certificates support one or more domain names including wildcard domain names.

Technically, there is no difference between the certificates (excluding misc certificate types) except for the amount and type of information stored in the certificate. It is the time and processes that the CA completes to validate not only the domain name but the organization that controls the domain name. For services that provide financial transactions, strongly consider EV SSL certificates.

Which Type of SSL Certificate Should I Use?

The answer depends on who you ask, the purpose of the certificate, how much effort you will spend obtaining a certificate and the price you are willing to pay.

Who you ask

Ask a commercial certificate authority (CA) and they will say you need an Extended Validation (EV) certificate. This is the most expensive certificate. The reason for the price is that the CA spends significant effort to verify you, your company and the name in the certificate. This is the most trusted certificate. However, browsers and TLS protocol stacks could care less. I recommend EV certificates for any network communications involving financial, legal, medical and health transactions. I want to know that the vendor’s identity has been thoroughly vetted. Examples are my bank, hospital, doctor, local, state and federal governments. Not long ago an EV certificate cost over $1,000.00. Today, you can purchase a CommodoCA EV certificate for $199.00 per year.

For all regular use cases where financial or identity are not issues, Let’s Encrypt Domain Validated (DV) certificates are fine. The benefits are several. First, they are easy to obtain. You only need to prove that you control the domain name. Second, they are free. This removes the price burden that prevents many from encrypting all network traffic.

Purpose of the certificate

As I mentioned above, companies/governments involved in financial, legal, medical and health transactions should use Extended Validation certificates. Consider this an investment and the cost of doing business. For most other business purposes, Organization Validated (OV) and Domain Validated certificates are fine. Organization Validated certificates cost $158.00 per year from CommodoCA. However, I would pay the difference ($41.00) and select an EV certificate over an OV certificate otherwise I would go with a Domain Validated certificate from Let’s Encrypt for free.

How much effort you will spend obtaining a certificate

A commercial certificate authority (CA) will make a considerable effort to validate your company, registration information, D&B credit listing, phone numbers, business address, and licenses, etc before you can receive an EV certificate. This is one of the reasons for the cost. You will need to be detailed with all the forms, licenses, etc. that they require. A Domain Validated certificate takes almost no effort as the CA will limit verification to matching your name and address with the domain registrar and verify that you control the domain. Let’s Encrypt does not verify your identity, only that you control the domain.

The price you are willing to pay

Let’s Encrypt certificates are free, commercial CA certificates must be purchased. CommodoCA starts at $88.00 and goes up to $417.00. Network Solutions starts at $59.99 and goes up to $579.00. These prices are per year, with some requiring a two year payment upfront.

Let’s Encrypt

I have years of experience with commercial CAs. I value and respect the validation effort that they expend before issuing a certificate. For commercial financial transactions, such as a website that processes credit card information, I always recommend an EV certificate. For just about everything else I use Let’s Encrypt. It is rare that I will even use a self-signed certificate for internal network traffic.

Let’s Encrypt only issues DV (Domain Validation) SSL certificates. If you require OV (Organization Validation) or EV (Extended Validation) SSL certificates, you will need to go to a commercial CA such as Comodo or Network Solutions.

To a web server or cloud service, the type (DV, OV, EV) of SSL certificate makes absolutely no difference. The client (web browser or an actual person) may care. If I am connecting to my bank and they only have a DV SSL certificate, I am going to question why. The key is to evaluate the value of what you are protecting and the cost if protection fails. A DV SSL certificate for a website contact form is just fine. To process my credit card will require an EV certificate. I want whoever is transferring money to be fully validated at the extended validation level and not just domain validated.

CA Issued SSL Certificate

An SSL Certificate, also known as a Public Key Certificate, is used to prove the ownership of a public key. In TLS, the server is required to present a certificate as part of the initial connection setup. The client will perform the certification path validation algorithm. The subject of the certificate will be used to match the hostname of the server. A mismatch will result in validation failure.

Where does the server hostname come from? In this article, we will create a DNS name that points to the server’s IP address. The actual IP does not matter for certificate requests to Let’s Encrypt but does matter during the certification path validation. This means that you can request SSL certificates for services that you have not deployed yet. I create a wildcard certificate for my domain so that I can quickly deploy test services and have TLS enabled at the start.

Request a Let’s Encrypt SSL Certificate

You will need the following:

  • The server’s public IP address.
  • Access to your domain’s DNS server.
  • Knowledge of how to configure A, CNAME and TXT DNS resource records.
  • The hostname that you want to use. For example www for www.mydomain.com.
  • Access to the Google Cloud Console and the ability to launch Cloud Shell.

Step 1: Create the DNS Entry

In your DNS server for the domain that you will be using, create either an A resource record or a CNAME resource record. For example, create the DNS A resource record www with the value public ip address of server. Once this is complete, wait a while for the resource record to become available. Ten minutes is usually enough, however, if the are previous entries, then you will also need to wait for the TTL to expire. I use MxToolbox to perform a DNS Lookup. Once I have verified that the correct DNS resource record has been created, I continue with the next step.

Step 2: Launch Cloud Shell

Log in to the Google Cloud Console. Click on the Activate Cloud Shell icon located in the toolbar right-hand side.

Step 3: Request an SSL Certificate from Let’s Encrypt

In this step, we will request the SSL certificate and also create the required TXT records that Let’s Encrypt requires to verify that you control the domain name.

In the example below, I will create one SSL certificate for both jhanley.dev and www.jhanley.dev. Change this to match your domain name(s) that you require. If you instead want a wildcard certificate valid for all subdomains, specify the root domain jhanley.dev and the wildcard domain *.jhanley.dev.

In this article, I show how to create DNS Resource Records for a new domain. The process is similar for other DNS servers.

  1. In Cloud Shell, create a working directory and change to that directory.
  2. Download the Let’s Encrypt Certbot program
    • wget https://dl.eff.org/certbot-auto
  3. Make the Certbot program executable:
    • chmod +x certbot-auto
  4. Request the SSL Certificate. Change the DNS name to match your DNS name configured in your DNS Server
    • ./certbot-auto certonly --manual --preferred-challenges dns -d 'jhanley.dev' -d 'www.jhanley.dev'
  5. The Certbot program will ask you questions and then request that you create a DNS TXT resource record for each domain name. This record will look like: _acme-challenge.jhanley.dev and _acme-challenge.www.jhanley.dev. Certbot will validate one record at a time. Once you create the requested record, double-check that it is correct before pressing ENTER. I use MxToolbox to verify that the TXT resource record is published and the value is correct. Wait at least 5 minutes for the DNS record to become publically available. If you do not wait, the Certbot process will fail. Repeat until all required records are created and validated.
  6. Once Certbot has verified the DNS resource records, an SSL certificate will be issued and download to your Cloud Shell VM. Typically the files will be located at /etc/letsencrypt/live/jhanley.dev. Notice that the path contains the domain name. Change the path to match what Let’s Encrypt displayed.
  7. Download each file that Certbot created. You will need them for your server:
    • cert.pem – SSL Certificate
    • privkey.pem – Private Key
    • chain.pem – Intermediate Certificates
    • fullchain.pem – SSL Certificate plus Intermediate Certificates in one file.

The above steps as a single script:

Edit the domain names and run this script in Cloud Shell.

Example using a wildcard

Edit the domain names and run this script in Cloud Shell.

Summary

In this article, we discussed the certificate authorities, and CA issued SSL certificates. We then obtained an SSL certificate signed by Let’s Encrypt. Save your SSL certificates and private keys in a secure location. They will be ready for installation when you deploy new services.

More Information

Credits

I write free articles about technology. Recently, I learned about Pexels.com which provides free images. The image in this article is courtesy of Pixabay at Pexels.

Related Posts