Expanding a Certifcate fails with TLS Handshake Error

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: zimbra-proxy01.bamboozlehost.com

I ran this command: ./letsencrypt-auto certonly --standalone -d zimbra-proxy01.bamboozlehost.com -d imap.airbox.mu -d imap.cbox.mu -d webmail.airbox.mu -d webmail.cbox.mu -d webmail.bamboozlehost.com -d imap.bamboozlehost.com -d wm.uae.email -d mail.uae.email -d wm.onld.om -d mail.bamboozle.me -d mail.viva.bh -d mail.safiairways.com -d pop.bamboozle.me -d imap.bamboozle.me -d incoming.bamboozle.me -d mail.kfnlegal.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None

It produced this output: (E)xpand/©ancel: E
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for imap.airbox.mu
tls-sni-01 challenge for imap.bamboozle.me

http-01 challenge for mail.kfnlegal.com
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. mail.kfnlegal.com (http-01): urn:ietf:params:acme:error:tls :: The server experienced a TLS error during domain verification :: Fetching https://mail.kfnlegal.com/.well-known/acme-challenge/EYN-eZYFsKJCka7a6u_xWtMTda_m5my0HmdJsMUwAWA: remote error: tls: handshake failure

IMPORTANT NOTES:

My web server is (include version): Nginx, Zimbra

The operating system my web server runs on is (include version): Ubuntu 14.04, Zimbra Proxy Server

My hosting provider, if applicable, is: Ourselves

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

2

@bamboozle, have you changed anything in your configuration since you tried it? Currently it looks like the TLS connection to this server should succeed (the invalid certificate shouldn’t block the validation or cause the error that you saw).

3

Is it possible that you have a firewall that interferes with incoming connections from some IP addresses?

4

No, funny thing is that it tries to add the addtional domain using http-01 while all others use sni. But there is no firewall blocking anything.

5

The reason for that is that the tls-sni-01 method is only offered for your domains that already have a Let's Encrypt certificate, but not for the new domains, as a matter of policy. Then the client defaults to preferring this method where available.

... although I don't really understand why it would succeed with the standalone challenge if you have an existing web server listening on port 443. Did you stop your existing server before running this command?

6

Actually following this one right to the letter.
https://wiki.zimbra.com/wiki/Installing_a_LetsEncrypt_SSL_Certificate

Stopping all services (Nginx and Apache) running the script and normally it works fine but that one throws an error.

7

The thing I don't understand is why this domain would redirect to https when it's using standalone challenges.....

8

Yes, that's what's puzzling me most too!

@bamboozle, it seems to me that you must not really have stopped everything somehow (but I'm still not sure how we could see the exact combination of results that you encountered).

Could you run ss -tlp right after the web service stop commands and show the output here?

9

here you go

State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 5 127.0.0.1:7171 : users:(("java",30763,148))
LISTEN 0 128 :11211 : users:(("memcached",30976,26))
LISTEN 0 128 :ssh : users:(("sshd",872,3))
LISTEN 0 128 :::11211 ::: users:(("memcached",30976,27))
LISTEN 0 128 :::http-alt ::: users:(("apache2",5980,4),("apache2",5884,4),("apache2",1083,4))
LISTEN 0 128 :::ssh :::* users:(("sshd",872,4))

10

That’s strange! Could you then run the letsencrypt-auto command again and then post the corresponding log from /var/log/letsencrypt?

11

You don’t have a separate machine (or container) acting as a reverse proxy or load balancer in addition to this server, do you?

12

No thats the standard zimbra proxy. And as you see we have done this for quite some time with a lot of domains…

2018-09-03 01:29:40,770:DEBUG:certbot.plugins.standalone:Stopping server at :::80…
2018-09-03 01:29:40,828:DEBUG:certbot.plugins.standalone:Stopping server at :::443…
2018-09-03 01:29:40,877:DEBUG:acme.crypto_util:Performing handshake with (’::ffff:5.32.38.54’, 59070, 0, 0)
2018-09-03 01:29:40,942:DEBUG:acme.crypto_util:Server name (mail.bamboozle.me) not recognized, dropping SSL
2018-09-03 01:29:40,943:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File “/opt/eff.org/certbot/venv/bin/letsencrypt”, line 11, in
sys.exit(main())
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py”, line 1364, in main
return config.func(config, plugins)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py”, line 1254, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py”, line 115, in _get_and_save_cert
renewal.renew_cert(config, domains, le_client, lineage)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/renewal.py”, line 305, in renew_cert
new_cert, new_chain, new_key, _ = le_client.obtain_certificate(domains, new_key)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/client.py”, line 334, in obtain_certificate
orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/client.py”, line 370, in _get_order_and_authorizations
authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py”, line 82, in handle_authorizations
self._respond(aauthzrs, resp, best_effort)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py”, line 155, in _respond
self._poll_challenges(aauthzrs, chall_update, best_effort)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py”, line 226, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)
FailedChallenges: Failed authorization procedure. mail.kfnlegal.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify t$

13

Well, that's some progress toward understanding what's going on: the standalone plugin's tls-sni-01 handler attempted to handle an HTTP-301-redirected http-01 challenge. So that accounts for the TLS handshake failure error from the CA side. But I still don't know how we got to this point (the standalone plugin shouldn't have generated the HTTP 301).

So two other questions:

  • could we see the rest of the log file?
  • are you positive there's no other firewall or proxy that might be redirecting HTTP requests to HTTPS even when nginx is stopped?
14

Here you go

2018-09-03 01:29:40,378:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/acme/authz/0H6W7_mHUZ8BJGMkntsjl3qII7BV3fcMPGPIZXg2Re8.
2018-09-03 01:29:40,760:DEBUG:requests.packages.urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "GET /acme/authz/0H6W7_mHUZ8BJGMkntsjl3qII7BV3fcMPGPIZXg2Re8 H$
2018-09-03 01:29:40,762:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Content-Type: application/json
Content-Length: 1515
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800
Expires: Sun, 02 Sep 2018 21:29:40 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Sun, 02 Sep 2018 21:29:40 GMT
Connection: keep-alive

{
“identifier”: {
“type”: “dns”,
“value”: “mail.kfnlegal.com”
},
“status”: “invalid”,
“expires”: “2018-09-09T21:29:15Z”,
“challenges”: [
{
“type”: “dns-01”,
“status”: “invalid”,
“url”: “https://acme-v02.api.letsencrypt.org/acme/challenge/0H6W7_mHUZ8BJGMkntsjl3qII7BV3fcMPGPIZXg2Re8/6995731537”,
“token”: “rc0sYFe7hu-d0snEjvhGjvDyazIKoypBWa4uKRUCQIE”
},
{
“type”: “tls-alpn-01”,
“status”: “invalid”,
“type”: “tls-alpn-01”,
“status”: “invalid”,
“url”: “https://acme-v02.api.letsencrypt.org/acme/challenge/0H6W7_mHUZ8BJGMkntsjl3qII7BV3fcMPGPIZXg2Re8/6995731538”,
“token”: “Jo2G0HOVrDRyu56HCek6PiIxWtXHE7I-WuU-Tiz4Kwg”
},
{
“type”: “http-01”,
“status”: “invalid”,
“error”: {
“type”: “urn:ietf:params:acme:error:connection”,
“detail”: “Fetching http://mail.kfnlegal.com/.well-known/acme-challenge/Wjy_T7ZECUYzMvbww_1fPBQ4o0qpBYRp5lu9X351NRw: Connection refused”,
“status”: 400
},
“url”: “https://acme-v02.api.letsencrypt.org/acme/challenge/0H6W7_mHUZ8BJGMkntsjl3qII7BV3fcMPGPIZXg2Re8/6995731539”,
“token”: “Wjy_T7ZECUYzMvbww_1fPBQ4o0qpBYRp5lu9X351NRw”,
“validationRecord”: [
{
“url”: “http://mail.kfnlegal.com/.well-known/acme-challenge/Wjy_T7ZECUYzMvbww_1fPBQ4o0qpBYRp5lu9X351NRw”,
“hostname”: “mail.kfnlegal.com”,
“port”: “80”,
“addressesResolved”: [
“185.93.245.38”
],
“addressUsed”: “185.93.245.38”
}
]
}
]
}
2018-09-03 01:29:40,764:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: mail.kfnlegal.com
Type: connection
Detail: Fetching http://mail.kfnlegal.com/.well-known/acme-challenge/Wjy_T7ZECUYzMvbww_1fPBQ4o0qpBYRp5lu9X351NRw: Connection refused

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, $
2018-09-03 01:29:40,764:DEBUG:certbot.error_handler:Encountered exception:
Traceback (most recent call last):
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py”, line 82, in handle_authorizations
self._respond(aauthzrs, resp, best_effort)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py”, line 155, in _respond
self._poll_challenges(aauthzrs, chall_update, best_effort)
File “/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/auth_handler.py”, line 226, in _poll_challenges
raise errors.FailedChallenges(all_failed_achalls)
FailedChallenges: Failed authorization procedure. mail.kfnlegal.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify t$

2018-09-03 01:29:40,765:DEBUG:certbot.error_handler:Calling registered functions
2018-09-03 01:29:40,765:INFO:certbot.auth_handler:Cleaning up challenges
2018-09-03 01:29:40,770:DEBUG:certbot.plugins.standalone:Stopping server at :::80…
2018-09-03 01:29:40,828:DEBUG:certbot.plugins.standalone:Stopping server at :::443…

15

Yes, nothing else is running on the system. The KVM Firewall is set to accept 0.0.0.0/0 so that should not be it.

16

That's a different validation error from the one before—how repeatable are your specific failure messages?

17

Just checked - all of them are the same from the TLS error message but the https and http vary.

18

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