Security /info/alibaba/ssl

Let's Encrypt Part 1

Date Created: June 12, 2018
Last Update: June 21, 2018

Table of Contents

Introduction
What is Let's Encrypt?
What is an SSL Certificate?
Types of SSL Certifictes
What is ACME?
Account Key
Certificate Key
Certificate Signing Request
What is a Certificate Authority?
Introduction Summary

Article Series

NeoPrime - Let's Encrypt Part 1
NeoPrime - Let's Encrypt Part 2
NeoPrime - Let's Encrypt Part 3
NeoPrime - Let's Encrypt Part 4
NeoPrime - Let's Encrypt Part 5

Introduction

In this multipart article, we will learn how to use the Let's Encrypt ACME version 2 API using Python to develop software that can create, install, renew and revoke SSL certificates for Alibaba Cloud. The same principles apply to any computing service that supports X.509 SSL certificates.

These articles will show how to use each ACME API with small, easy to understand Python programs. The source code to these examples is available to download: ACME Examples. We will also show how to use the Alibaba Cloud APIs for automating DNS record changes and installing an SSL certificate into the Alibaba Cloud services (API Gateway and CDN) so that you have a custom domain name for each service protected with SSL.

Why write this article on Let's Encrypt?

  1. I could not find any information explaining how to use the ACME v2 API.
  2. I wanted an automated client for Alibaba API Gateway and Alibaba CDN so that I could request, validate, issue and install an SSL certificate without multiple manual methods. I wanted a single program that I could maintain that would do everything.
  3. I wanted an inexpensive solution for protecting numerous cloud services and purchasing SSL certificates for each service can quickly get expensive.
  4. I wanted the setup of SSL for my services to be fast. Not the long several day process that commercial certificate authorities put you through.
  5. Document for everyone how to use and benefit from Let's Encrypt. They are providing an excellent free service.
As cloud services begin to be accepted universally, popular services such as API Gateway and CDN are difficult to request, issue and install SSL certificates. This article hopefully demonstrates how to do this simply and correctly. The focus is not on website SSL certificates, rather hard to configure cloud services, REST endpoints, etc.

These articles focus on SSL certificates for services that do not have existing Let's Encrypt client support thru certbot or a third-party product. For example, certbot has excellent support for automating Apache web server SSL certificate creation and renewal. However, there is little or poor support for Windows IIS Server. In the last part we will demonstrate creating an SSL certificate for IIS, bundling into the PKCS#12 format and importing into IIS.

Please note that 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 commerical CA such as Comodo. There is no difference between the certificates 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. For services such as a CDN or API Gateway, DV certificates are perfect.

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.

Alibaba Cloud Services that Support Let's Encrypt SSL Certificates:

  • Alibaba Cloud Elastic Compute Service (ECS)
  • Alibaba Cloud CDN (CDN)
  • Alibaba Cloud API Gateway
  • There are many more not listed as I am not testing on other services at this time

Additional Links:

What is Let's Encrypt?

Wikipedia's definition: Let's Encrypt is a certificate authority that provides free X.509 certificates for Transport Layer Security (TLS) encryption via an automated process designed to eliminate the hitherto complex process of manual creation, validation, signing, installation, and renewal of certificates for secure websites. It launched on April 12, 2016.

In other words, Let's Encrypt provides free SSL certificates for your websites and numerous cloud services such as API Gateway, CDN, ECS, etc.


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 vary 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 API Gateway, 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 ceriticates can also be single domain, mutiple 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.


What is ACME?

Reference Documentation: Let's Encrypt ACME v2 Specification - June 14, 2018

ACME stands for: Automatic Certificate Management Environment. ACME is a communications protocol for a client to interface with a CA (Certificate Authority) for the management of SSL certificates (issue, renew, and revoke).

The ACME protocol is based upon passing JSON formatted messages over HTTPS. The requests are signed by a private key and authenticated with the corresponding public key. This keypair is called the Account Key. Note that this keypair is not the same keypair used to create the CSR (Certificate Signing Request).

Account Key:
The Account Key is used to provide the identity of the account that is requesting certificate services. There is no login / password or similar method used. Therefore, it is very important to save your Account Key keypair in a safe location as the Account Key is used to issue, renew and revoke SSL certificates. If you lose the Account Key the certificates that were created under that account will be in limbo. You will not be able to renew or revoke those certificates. In this case you will need to create a new Account Key and issue new SSL certificates to replace the once that you lost control of. If a malicious third party obtained access to your Account Key, they could change the contact email address and revoke your certificates. They would not be able to issue new SSL certificates for your domains as this would require either HTTP or DNS validation of the domain names.

Certificate Key:
The Certificate Key is a keypair used to sign CSRs (Certificate Signing Request). This is not the Account Key even though both are keypairs. For security reasons you do not want to use the Account Key to sign CSRs. Common practice is to create a new Certificate Key for each SSL Certificate.

CSR - Certificate Signing Request:
A CSR is a file (message) sent to a CA (Certificate Authority - Let's Encrypt) to apply for an SSL certificate. The CSR contains details about who is applying for the SSL certificate such as company name, location, domain name, etc. Since Let's Encrypt only issues DV (Domain Validated) SSL certificates, only the domain names are validated and only the domain names are included in the generated SSL certificate plus an optional email address for contact information. Details such as company name, location, etc. are not included.


What is a Certificate Authority?

Certificate authorities (CAs) are entities that cryptographically sign SSL certificates to vouch for their authenticity. Browsers and operating systems have a list of trusted CAs that they use to verify site certificates.

Until recently, most CAs were commercial operations that charged money for their verification and signing services. Let's Encrypt has made this process free for users by completely automating the procedure, and by relying on sponsorship and donations to fund the necessary infrastructure.

Let's Encrypt is a CA that issues Domain Validated SSL certificates. The Let's Encrypt server use the ACME protocol to communicate with ACME clients to request, issue, renew and revoke SSL certificates.


Introduction Summary:

In Part 2, we will cover this in detail, but once you have created your Account Key, Certificate Key and CSR you have everything you need to request an SSL Certificate through Let's Encrypt. Before Let's Encrypt will issue an SSL certificate, it needs to validate your certificate request (called an order in Let's Encrypt terminology) by validating that you control the domain name via either an HTTP validation file or DNS TXT record. The examples in this article series only support DNS validation as most cloud services, such as API Gateway, do not support HTTP file-based validation.

Now would be a good time to go to the ACME Examples Download page and setup Python, the required Python packages and download the example source code.

In Part 2, we will create the Account Key, Certificate Key, Certificate Signing Request (CSR) and then begin working with each ACME API in Python.

Let's Encrypt Part 2.




15220 Main Street, Bellevue, WA 98007
T: 425-528-8500 - F: 425-528-8550 - E: neoprime@neoprime.io

Copyright 2018 NeoPrime LLC