Secure Your Site for Free: Let’s Encrypt SSL Setup on CentOS with Docker

Overview

Let’s Encrypt aims to provide free SSL certificates for every site, accelerating the transition from HTTP to HTTPS. With HTTP/2, HTTPS performance is significantly better than HTTP/1.x in many scenarios.

Features

Free: any site can obtain a valid certificate for its domain at no cost.

Automatic: the entire request and configuration process on the web server is fully automated, with background renewal support.

Secure: uses the latest industry‑standard security technologies and best practices.

Transparent: issuance and revocation records are open for audit.

Open: follows open standards and allows custom plugins.

Collaborative: a community effort that benefits the whole Internet, not controlled by a single organization.

Preparation

Operating System: CentOS 6.6

Installation

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto run --debug

Installing may pull many third‑party libraries, which is not ideal for production environments; using Docker is recommended.

docker run -it --rm -p 443:443 -p 80:80 --name letsencrypt \
    -v "/etc/letsencrypt:/etc/letsencrypt" \
    -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
    quay.io/letsencrypt/letsencrypt:latest auth

The official Let’s Encrypt Docker image is used.

Quick Start

Generate a certificate for the domain coocla.org:

letsencrypt -d coocla.org certonly

After a successful run, the /etc/letsencrypt directory contains the following structure:

/etc/letsencrypt/
├── accounts
│   └── acme-staging.api.letsencrypt.org
│       └── directory
│           └── a68aa061212sd65a51234eaeadda9081
│               ├── meta.json
│               ├── private_key.json
│               └── regr.json
├── archive
│   └── coocla.org
│       ├── cert1.pem
│       ├── chain1.pem
│       ├── fullchain1.pem
│       └── privkey1.pem
├── csr
│   └── 0000_csr-letsencrypt.pem
├── keys
│   └── 0000_key-letsencrypt.pem
├── live
│   └── coocla.org
│       ├── cert.pem -> ../../archive/coocla.org/cert1.pem
│       ├── chain.pem -> ../../archive/coocla.org/chain1.pem
│       ├── fullchain.pem -> ../../archive/coocla.org/fullchain1.pem
│       └── privkey.pem -> ../../archive/coocla.org/privkey1.pem
└── renewal
    └── coocla.org.conf

The live directory contains symlinks to the latest certificate and private key. csr and keys store the current authorization key pair. accounts holds management information for the certificates (related to ACME). renewal stores domain‑specific renewal configuration.

Use the obtained certificate and private key to configure your web server.

Note: Let’s Encrypt certificates are trusted only from 2015‑11‑17 onward; older certificates may trigger browser trust errors.

Principle

Let’s Encrypt uses the ACME protocol to enable automatic, unattended issuance of browser‑trusted certificates. The process involves two steps:

1. The client proves to the CA that it controls a domain. 2. The client can request, renew, or revoke certificates for that domain.

Domain Validation

The CA validates the server administrator via public‑key challenges. When the client first contacts the CA, it generates a new key pair and informs the CA which domains it controls. The CA then issues challenges, such as providing a DNS record or placing a specific resource at https://coocla.org. The client must satisfy these challenges to prove control.

Certificate Issuance, Renewal, and Revocation

For issuance, renewal, or revocation, the client sends the certificate management information and the authorized key pair to the CA. To obtain a certificate, the client creates a PKCS#10 Certificate Signing Request (CSR) signed with the private key corresponding to the public key. The CA verifies the signatures and, if valid, issues a certificate bound to the provided public key.

Revocation works similarly: the client signs a revocation request with the authorized key, the CA validates it, and then publishes the revocation via CRLs or OCSP so browsers know not to trust the certificate.

Officially Supported Plugins

standalone – supported, not installed by default

apache – supported and installed by default

webroot – supported, not installed by default

manual – supported, not installed by default

nginx – supported and installed by default

Certificate Locations

All generated keys and certificates are stored under /etc/letsencrypt/live/$domain. These are symlinks to the latest files, while /etc/letsencrypt/archive and /etc/letsencrypt/keys contain all historic versions.

/etc/letsencrypt/archive and /etc/letsencrypt/keys contain all keys and certificates. Only the symlinks in /etc/letsencrypt/live point to the most recent versions.

Key files you will use:

privkey.pem – private key (used as SSLCertificateKeyFile in Apache or ssl_certificate_key in Nginx). cert.pem – server certificate. chain.pem – intermediate certificates required by browsers. fullchain.pem – concatenation of cert.pem and chain.pem .

When configuring a server, you must use chain.pem or fullchain.pem; using only cert.pem will cause errors.

Configuration File

# Use a 4096‑bit RSA key
rsa-key-size = 4096

# Use the staging server for testing
server = https://acme-staging.api.letsencrypt.org/directory

# Uncomment to specify an email address
# email = [email protected]

# Use the text interface instead of ncurses
# text = True

# Use the standalone authenticator on port 443
# authenticator = standalone
# standalone-supported-challenges = tls-sni-01

# Disable webroot validation; specify the webroot path instead
# authenticator = webroot
# webroot-path = /usr/share/nginx/html

The default configuration files are loaded from:

/etc/letsencrypt/cli.ini $XDG_CONFIG_HOME/letsencrypt/cli.ini ~/.config/letsencrypt/cli.ini

Note

1. Let’s Encrypt certificates are valid for 90 days, so they must be renewed at least every three months. 2. Because of the validation process, the client must run on the server that resolves the domain name.

Renewal can be performed by re‑executing the same Let’s Encrypt command, using appropriate CLI options, configuration files, or scheduling via cron.