TLS-SNI-01 challenge on LXD containers

[philthynz]

I have an LXD server running a few containers, I use HAProxy to send the SNI requests to the container MDNS name.

The HAProxy config looks like this:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    tcp
    option  tcplog
    option  dontlognull
    timeout connect 30s
    timeout client  3600s
    timeout server  3600s
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

## redirect port 80 to 443
frontend localhost80
    bind *:80
    mode http
    redirect scheme https code 301 if !{ ssl_fc }

## bind 443
frontend localhost443
    bind *:443
    option tcplog
    mode tcp
    acl tls req.ssl_hello_type 1
    tcp-request inspect-delay 5s
    tcp-request content accept if tls

## bind 443 to sni names
    acl is_zabbix req.ssl_sni -i zabbix.mydomain
    acl is_seafile req.ssl_sni -i seafile.mydomain
    acl is_firefly-iii req.ssl_sni -i firefly-iii.mydomain

## which backend to use for requests
    use_backend zabbix if is_zabbix
    use_backend seafile if is_seafile
    use_backend firefly-iii if is_firefly-iii

## backend lxc containers
backend zabbix
    mode tcp
    server is_zabbix zabbix.lxd:443 check
    
backend seafile
    mode tcp
    server is_seafile seafile.lxd:443 check

backend firefly-iii
    mode tcp
    server is_firefly-iii firefly-iii.lxd:443 check

That redirects all http traffic to https and provides each web interface.

With each LXC container I am using the DNS challenge to manually renew the certificates.

I would like to find an automated way via the TLS-SNI-01 challenge.

I have tried this and have some errors:

root@zabbix:~# certbot -d zabbix.mydomain --standalone --preferred-challenges tls-sni certonly --keep-until-expiring
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for zabbix.mydomain
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. zabbix.mydomain (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Error getting validation data

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: zabbix.mydomain
   Type:   connection
   Detail: Error getting validation data

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

I would image the SNI requests would still go through HAProxy as the same DNS name zabbix.mydomain. Or do I have to forward different requests in HAProxy?

[schoen]

Hi @philthynz,

The TLS-SNI-01 challenge uses an unpredictable random SNI name, which will be a random string followed by .acme.invalid. It doesn’t use the domain name for which you’re requesting the certificate. (An older even-more-obsolete challenge method called HTTPS-01 did do that, and was disabled for security reasons even before Let’s Encrypt rolled out.)

You might be aware that TLS-SNI-01 itself has also been disabled for security reasons for new issuance, although it’s permitted for renewals, and it may be disabled for renewals in the future as well. So your configuration is not necessarily very future-proof if it relies on TLS-SNI-01 at all.

There is a new method called TLS-ALPN-01 which also uses port 443, but I think it requires a different kind of forwarding that haproxy might not know how to do.