Using Certbot for TLS-SNI Challenge on pfSense Firewalls

Hi,

short’ish summary: 90 days ++ ago we set up a Zimbra 8.7 OS Edition server on a CentOS 7. All went well, except for the LetsEncrypt part (https://wiki.zimbra.com/wiki/Installing_a_LetsEncrypt_SSL_Certificate); certbot was not able to complete (sorry, haven’t got the full details right here).
We needed certs for this + two additional domains. We were running late in the deployment, so eventually we would make it work, using pfSense for generating certificates, then issuing certs and copy the needed files to Zimbra and the other hosts + a cumbersome process to prepare the files, verify them and deploy…but it worked.

Time has come to renew but no go so far. We aim to make it work as intended with certbot + a cronjob for auto renewal, so how to proceed from here?

I tried ./letsencrypt-auto certonly --standalone and certbot-auto certonly --standalone. Both return following error(s)

[root@post letsencrypt]# ./letsencrypt-auto certonly --standalone
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Please enter in your domain name(s) (comma and/or space separated) (Enter 'c’
to cancel):FQDN-1 FQDN-2
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for FQDN-1
tls-sni-01 challenge for FQDN-2
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. FQDN-1 (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested 07754eeda814862d64130f3ef145a362.6c0075519e38c40b4c047079e09afb65.acme.invalid from [our fw IP Addr]:443. Received 1 certificate(s), first certificate had names “FQDN-2, FQDN-1”, FQDN-2 (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested db9e5f445aeff7ae51241124ec17ae16.3b856784a501ef54cfa860e73912df39.acme.invalid from [our fw IP Addr]:443. Received 1 certificate(s), first certificate had names “FQDN-2, FQDN-1”

IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: FQDN-1
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested

07754eeda814862d64130f3ef145a362.6c0075519e38c40b4c047079e09afb65.acme.invalid
from [our fw IP Addr]:443. Received 1 certificate(s), first
certificate had names “FQDN-2, FQDN-1”

Domain: FQDN-2
Type: unauthorized
Detail: Incorrect validation certificate for tls-sni-01 challenge.
Requested

db9e5f445aeff7ae51241124ec17ae16.3b856784a501ef54cfa860e73912df39.acme.invalid
from [our fw IP Addr]:443. Received 1 certificate(s), first
certificate had names “FQDN-2, FQDN-1”

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.

Obviously the real domain names and IP address have been hidden :wink:

Thanks in advance - looking forward to a speedy reply :slight_smile:

hi @des

A) This is a help question not really a server question.
B) Obfuscating domain names means most of the troubleshooting will be on you
C) Search for TLS-SNI Challenge in the forum (there are several common errors that keep cropping up)
D) Search for IPV6 in the forum - this has also caught a few people out recently

Without domains it’s hard to assist you as we can’t verify your configurations are such that will allow the TLS -SNI challenge to pass

My suspicion is that standalone is not able to spin up a web server that binds to port 443 as you have that bound to a reverse proxy or something else on pfSense.

Andrei

Presuming worst case scenario - pfSense is only proxy/forwarding HTTPS and keeps HTTP local.
And all the additional complexities involved with Zimbra…

I would continue getting the certs (and renewing them) as you have done already - because that worked.
Then copy the public and private keys onto the Zimbra server.
Assumptions: (change as needed)

  1. using /tmp directory
  2. private key file = server.private.key
  3. public cert file = server.public.key
  4. cert/chain file = CA.key (this may need some massaging to include and exclude correct intermediate and such)
    You should be able to follow these steps (making sure each works as expected along the way) to install the new cert:

su - zimbra
chown zimbra:zimbra /tmp/server.private.key
chown zimbra:zimbra /tmp/server.public.key
chown zimbra:zimbra /tmp/CA.key
/opt/zimbra/bin/zmcertmgr verifycrt comm /tmp/server.private.key /tmp/server.public.key
(((look for “Valid certificate chain: server.public.key: OK”)))
cp /tmp/server.private.key /opt/zimbra/ssl/zimbra/commercial/commercial.key
/opt/zimbra/bin/zmcertmgr deploycrt comm server.public.key CA.key
(((look for NO ERRORS)))
zmcontrol restart
exit

Thanks for in-depth reply :slight_smile: but the solution was actually quite simple. It turned out to be ‘just’ a port 443 NAT rule, which was in the way - allocated to a certain IP.
Problem solved - our Zimbra runs on the updated cert :slight_smile:

/des

----- Original meddelelse -----

1 Like

does it renew automatically (properly)?

Actually, what I did this time was spin up an additional CentOS 7, install certbot, temporarily change the NAT rule to point to this server and generate the needed certs with multiple -d FQDN. Then copy to Zimbra and the others, verify and deploy. The pfSense way around things using their acme module was a bit messy, as that does not provide the files as described in https://wiki.zimbra.com/wiki/Installing_a_LetsEncrypt_SSL_Certificate - I always prefer to be able to do these things ‘by the book’ as recommended by the vendor :wink:

Auto update has not been in play yet - I’ll prepare that for the next update sometime within the following 90 days.

/des

----- Original meddelelse -----

Good luck and check this post when it comes time to renew - it seems promising:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.