Multiple servers, NAT

[Etuldan]

My domain is:
mail.renaud-goud.fr

I ran this command:
./certbot-auto certonly --standalone -d mail.renaud-goud.fr

It produced this output:
Failed authorization procedure. mail.renaud-goud.fr (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for TLS-SNI-01 challenge. Requested xxxxxxxxx.acme.invalid from IP:443. Received certificate containing ‘carddav.renaud-goud.fr, cloud.renaud-goud.fr, […]’

My operating system is (include version):
Debian jessie - Raspberry PI

My web server is (include version):
/

My hosting provider, if applicable, is:
Home

I can login to a root shell on my machine (yes or no, or I don’t know):
Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
No

Details :
I already have a ‘full’ web nginx http server sucessfully configured with Letsencrypt working, on carddav.renaud-goud.fr and cloud.renaud-goud.fr . It’s behind a NAT router, port 80 opened.

I have another server, for mail, on which I wanna have also a letsencrypt for mail server. No webserver is running on it.
I set-up a reverse proxy on my ‘main’ server (the http one), to redirect the subdomain mail.renaud-goud.fr:80 to the mail server IP, port 80.

But when I run the certbot tool to generate a certificate on the mail server (with standalone, as creating a temp http/80 server is OK on it), the certbot tool seems to be connected to the nginx/http server.

So, how can I ‘bypass’ the nginx proxy detection ? (I can’t open another port on my router, only 80, 443 and mail ports)

[Osiris]

It’s using the tls-sni-01 challenge, which operates through port 443. What you actually want is the http-01 challenge. This can be arranged by using the --standalone-supported-challenges http-01 attribute.

[Etuldan]

Well, thanks a lot, it works.
I need now to tweak my postfix conf, to disable a lot of unsecure protocols (SSL, RC4, …) but this is out of scope of this post !

I still have a question :
On my mail server, as you said, I now use the http-01 challenge (so, the standalone webserver is listening on 80 , plain)
But, on my ‘main’ webserver, I made some nginx aliases for the subfolder .wellknown, to the ‘webroot’ (so my certbot is configured as webroot, and I don’t have to shutdown my whole webserver for a cert renew). I made the aliases for both 80 and 443 ports, and I’m using the default certbot conf (no supported-challenges argument). So, the certbot is ‘listening’ on 80 (plain) or 443 (ciphered) (or both ?)

If it’s listening only on 443, and I decide later to also configure my mail server to listen only on 443, will it works ?

[Osiris]

The tls-sni-01 challenge is very distinct compared to the http-01 challenge: the http-01 challenge simply puts a file with a token inside in /.well-known/acme-challenge/ for the ACME server to download and verify… Quite simple… The tls-sni-01 challenge is very different: it incorporates the token as the common name in a temporary self signed certificate. Then, when using the stand alone plugin (the Apache plugin simply adds a configuration file), it serves this certificate in a “fake” virtual host (same as the common name in the temporary certificate of course). Next, the ACME server will connect to the IP address of the FQDN you want a Let’s Encrypt certificate for, but asks for the “fake” virtual host in the SNI extension of the TLS ClientHello.

So the tls-sni-01 isn’t as simple as forwarding stuff on port 443 on your main server to port 443 on your mail server: that’s not gonna work, because the required TLS server stuff will not be known on your main server.

[Etuldan]

OK.
Thanks for explanation.
So my ‘main’ webserver is certainly configured as http-01 challenge (as webroot).
And both servers listening on 80, the 1rst one with a proxy to the 2nd one for a particular domain seems to be working. )

Again, thanks a lot !!

Out of topic : is a https-01 challenge is available/planned (a similar way as http-01, without opening the port 80 but only the 443 , so .well-known/acme-challenge on port 443 only ) ?

[tialaramex]

Alas although a port 443 TLS version of the HTTP challenge was intended, during testing people found that bulk hosts with bad config meant it could be used to get certificates for other people’s sites (on the same bulk host) if those people didn’t have HTTPS sites set by up properly.

A version of the challenge resistant to this problem has been talked about but don’t hold your breath.

[mcgurrin]

As a note, while proxying the tls-01 challenge is much harder than the http-01 challenge, it is possible with some tools like haproxy, just not with most web servers and it does require a more advanced configuration. If you really want to avoid opening port 80 you could use that method and place haproxy on port 443 and let it forward traffic to the webserver for normal web traffic. The write up is at https://www.cloudoptimizedsmb.com/articles/20160409-00/using-haproxy-to-split-letsencrypt-acme-challenges-from-regular-traffic and can also be adapted to make your existing web server terminate the ssl connection (in that example I do terminate the ssl on haproxy for non acme tls-01 requests).