Back to post index

Let's Encrypt all the things!
Tags: [letsencrypt] [encryption] [openbsd]
Published: 12 Dec 2015 21:09

Let’s Encrypt entered public beta recently, offering a free and automated resource for getting signed certificates for your domain. I jumped at the chance to test this on the OpenBSD VPS that hosts this site and answers email. Here’s how I did it:

I chose the awesome acme-tiny Let’s Encrypt client because it is a tiny (auditable) Python script that performs all the required steps for getting one of these certificates. The only prerequisites are Python and OpenSSL.


There are two places that these certificates will be used: for HTTPS and SMTPS connections. For HTTPS, I’m going to use stunnel in front of the existing varnish cache to provide a SSL endpoint - varnish does not support SSL / TLS yet (perhaps never). For SMTPS, OpenSMTPD has TLS baked in.

getting certificates with acme-tiny

In the directory /root/letsencrypt/, generate the appropriate key and CSR files:

openssl genrsa 4096 > account.key
openssl genrsa 4096 > domain.key
openssl req -new -sha256 -key domain.key -subj "/" > domain.csr

In /root/letsencrypt/, I created



mkdir -p "${WEB_DIR}"

[ -e "${RUN_DIR}" ] || exit 1
[ -e "${WEB_DIR}" ] || exit 1

python2.7 /home/jwm/src/acme-tiny/ \
        --account-key "${RUN_DIR}/account.key" \
        --csr "${RUN_DIR}/domain.csr" \
        --acme-dir "${WEB_DIR}" > "${RUN_DIR}/signed.crt"

if [ ${rc} -ne 0 ];
        echo " failed with ${rc}"
        exit 1

if [ ! -e "${RUN_DIR}/intermediate.pem" ];
        echo "Downloading intermediate.pem"
        ftp -o "${RUN_DIR}/intermediate.pem"

        if [ ${rc} -ne 0 ];
                echo "ftp failed with ${rc}"
                exit 1

cat "${RUN_DIR}/signed.crt" "${RUN_DIR}/intermediate.pem" > "${RUN_DIR}/chained.pem"

cp "${RUN_DIR}/chained.pem" "${CERT_DIR}/stunnel.pem"
cp "${RUN_DIR}/domain.key" "${CERT_DIR}/stunnel.key"

chmod 0600 "${CERT_DIR}/stunnel.pem"
chmod 0600 "${CERT_DIR}/stunnel.key"

# restart all services that use these keys
rcctl restart stunnel
rcctl restart smtpd

exit 0

This script:

stunnel configuration

Here’s my stunnel.conf:

chroot = /var/stunnel/
; It is recommended to drop root privileges if stunnel is started by root
setuid = _stunnel
setgid = _stunnel

; PID file is created inside the chroot jail (if enabled)
pid = /

output = /stunnel.log
debug = info

accept  = 443
connect = 80
cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.key

Enable it with

# rcctl enable stunnel

httpd and varnish require no changes - stunnel sits in front of varnish so the cache is still functional.

Open up the HTTPS port with the following pf rule:

pass in on $ext_if inet proto tcp to ($ext_if) port 443

opensmtpd configuration

Here are the changes required for /etc/mail/smtpd.conf:

-listen on vio0
+pki certificate "/etc/stunnel/stunnel.pem"
+pki key "/etc/stunnel/stunnel.key"
+listen on vio0 secure pki hostname

After restarting smtpd, look for TLS sessions in the /var/log/maillog:

Dec 10 21:10:55 enamel smtpd[19313]: smtp-in: Started TLS on session
759fc069292a4848: version=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384,

There are no pf rule changes required: STARTTLS is advertised by OpenSMTPD on the same smtp port (SMTPS is deprecated). Unknown endpoints still need to pass spamd before they can communicate with OpenSMTPD because spamd does not perform any part of the SMTP protocol except a barebones handshake, and this includes advertising any STARTTLS capability.

testing and verification provides the ability to test these two new encryption protocols:

The webserver test found that the weak ECDHE_RSA_WITH_RC4_128_SHA cipher is supported by stunnel. To only allow strong ciphers, modify stunnel.conf:

 debug = info

 +ciphers =


The webserver test also found that HSTS was not offered. Modifying httpd.conf fixed this:

 server "default" {
         listen on lo0 port 8080
+        hsts
         root "/htdocs/default"

The mailserver test did not find problems.

blocking IPv6 traffic

I noticed the following in stunnel’s log file:

21:23:58 LOG5[0]: Service [https] accepted connection from IPv4:38534
21:23:58 LOG5[1]: Service [https] accepted connection from IPv4:38536
21:23:58 LOG5[0]: Service [https] connected remote server from ::1:22429
21:23:58 LOG5[1]: Service [https] connected remote server from
21:24:03 LOG5[1]: Connection closed: 0 byte(s) sent to SSL, 0 byte(s) sent to socket
21:24:07 LOG5[0]: Connection closed: 232 byte(s) sent to SSL, 381 byte(s) sent to socket

The HTTPS connections took on the order of seconds to complete, and stunnel seemed to be using IPv6 when varnish was not configured for it. Blocking IPv6 with pf caused the connections to complete quickly:

block quick on lo inet6
block quick on $ext_if inet6


I put a call for /root/letsencrypt/ into /etc/daily.local so that (unnecessarily) a new certificate is generated every day. I did this because I wanted the process to be easily scriptable and already the daily.local run showed errors:

/root/letsencrypt/[15]: python2.7: not found failed with 127

Once these errors are fixed, the call to can be moved into /etc/weekly.local or /etc/monthly.local - Let’s Encrypt certificates expire after 90 days so this is mandatory.

offering only HTTPS resources

If all resources on a page are provided over HTTPS, Firefox shows a closed lock:

If any resource on a page is grabbed by a HTTP connection, Firefox will show a warning:

I had to verify each blog page to make sure that no resources were explicitly offered over HTTP, like in the case of page on Smyslov’s fans.