Considering enabling Server Name Indication (SNI) on my webserver / 2019-05-04

2019-05-04 Considering enabling Server Name Indication (SNI) on my webserver 1 year ago
Encrypt all the things meme While making a lot of my websites available via HTTPS I started wondering about enabling Server Name Indication (SNI) because the list of hostnames in the one certificate (subjectAltName parameter) keeps growing and they aren't all related.

So on a test system with haproxy I created two separate private keys, two separate certificate signing requests and requested two separate certificates. One for the variants of and one for most of the names. The whole requesting procedure happened on the system where my automated renewal and deployment of LetsEncrypt certificates with dehydrated happens so the request went fine. For the configuration of haproxy I was following HAProxy SNI where 'terminating SSL on the haproxy with SNI' gets a short mention.

So I implemented the configuration as shown in that document and got greeted with an error:
haproxy[ALERT] 123/155523 (3435) : parsing [/etc/haproxy/haproxy.cfg:86] : 'bind :::443' unknown keyword '/etc/haproxy/ssl/webserver-idefix-main.pem'.
And found out that the crt keyword has to be repeated.

This is why I like having a test environment for things like this. Making errors in the certificate configuration on the 'production' server will give visitors scary and/or incomprehensible errors.

So the right configuration for my test is now:
frontend https-in
    bind :::443 v4v6 ssl crt /etc/haproxy/ssl/webserver-campwireless.pem crt /etc/haproxy/ssl/webserver-idefix-main.pem
And testing it shows the different certificates in use when I use the -servername parameter for openssl s_client to test things.
$ openssl s_client -connect -servername -showcerts -verify 3
Server certificate
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Verification: OK
$ openssl s_client -connect -servername -showcerts -verify 3
Server certificate
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Verification: OK
The certificates are quite separate. Generating the certificate signing requests with a separate private key for each request works fine.

So if I upgrade my certificate management to renew, transport, test and install multiple certificate for the main webserver it would work.

Update 2019-05-04: Step one: writing a bit of extra tools to make really sure all the subjectAltName fields in the new certificate requests add up to the same list that was in the old certificate requests. I wanted to be really sure here!

Update 2019-05-05: As you can see if you look very carefully at the certificates I made the move. The hard part was the automated transport, test and install of a bunch of certificates for the webproxy. I decided to use more Makefile smarts to combine the private key and generated certificate into a pem file for the server, and only reload the haproxy configuration after all the pem files are regenerated. The relevant bit:
httpscertificates := $(wildcard /etc/haproxy/ssl/webserver-*.pem)

/etc/haproxy/ssl/certificate-stamp: $(httpscertificates)
        /usr/sbin/service haproxy reload
        touch $@

/etc/haproxy/ssl/%.pem: /etc/haproxy/ssl/%.key /home/dehydrated/remotemanaged/%.crt
        /usr/local/bin/checkcert $^
        cat $^ > $@
The last rule is a generic rule to create a .pem file from a .key and .crt file, making sure first the .key file has the same public key as the .crt file.

The rule for certificate-stamp depends on the already found .pem files and does a reload and touch when one of them was updated.

This rule will not create new .pem files out of itself when a new .key and .crt show up. I will have to run a make for the right target by hand the first time. When adding or removing a certificate I will also have to update the haproxy config file. The next step could be to use a crt-list parameter and list all the found pem files in the file.

Tags: , , , ,

IPv6 check

Running test...
, reachable as PGP encrypted e-mail preferred. PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers

Meningen zijn die van mezelf, wat ik schrijf is beschermd door auteursrecht. Sommige publicaties bevatten een expliciete vermelding dat ze ongevraagd gedeeld mogen worden.
My opinions are my own, what I write is protected by copyrights. Some publications contain an explicit license statement which allows sharing without asking permission.
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews
This page generated by $Id: newsitem.cgi,v 1.54 2020/12/31 15:36:31 koos Exp $ in 0.005766 seconds.