# Failed authorization procedure: Connection refused **URL:** \ **Category:** Help\ **Created:** [October 17, 2017, 1:19am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402 "2017-10-17T01:19:37Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 1:19am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/1 "2017-10-17T01:19:37Z")
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](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: [speegs.com](http://speegs.com) I ran this command: sudo certbot --apache -d [speegs.com](http://speegs.com) -d [www.speegs.com](http://www.speegs.com) It produced this output: Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Obtaining a new certificate Performing the following challenges: tls-sni-01 challenge for [speegs.com](http://speegs.com) tls-sni-01 challenge for [www.speegs.com](http://www.speegs.com) Waiting for verification… Cleaning up challenges Failed authorization procedure. [www.speegs.com](http://www.speegs.com) (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Connection refused, [speegs.com](http://speegs.com) (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Connection refused IMPORTANT NOTES: - The following errors were reported by the server: My web server is (include version): Apache/2.4.28 (Unix) The operating system my web server runs on is (include version):Linux arch-cloud 4.13.6-1 My hosting provider, if applicable, is:Digital Ocean 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 ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [October 17, 2017, 1:26am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/2 "2017-10-17T01:26:10Z")
> [@jcspeegs](#): > > The server could not connect to the client to verify the domain :: Connection refused, [speegs.com](http://speegs.com) (tls-sni-01): This means LE was unable to reach your server for TLS-SNI-01 authentication. Which means port 443 access is not fully functional. As can be seen from the following tests: wget [https://speegs.com/](https://speegs.com/) --2017-10-16 21:22:28-- [https://speegs.com/](https://speegs.com/) Resolving [speegs.com](http://speegs.com) ([speegs.com](http://speegs.com))... 138.68.227.68 Connecting to [speegs.com](http://speegs.com) ([speegs.com](http://speegs.com))|138.68.227.68|:443... failed: Connection refused. wget [https://www.speegs.com/](https://www.speegs.com/) --2017-10-16 21:23:05-- [https://www.speegs.com/](https://www.speegs.com/) Resolving [www.speegs.com](http://www.speegs.com) ([www.speegs.com](http://www.speegs.com))... 138.68.227.68 Connecting to [www.speegs.com](http://www.speegs.com) ([www.speegs.com](http://www.speegs.com))|138.68.227.68|:443... failed: Connection refused. ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 1:29am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/3 "2017-10-17T01:29:00Z")
Thank you for the quick response. Does port 443 need to be manually configured? What paths can i explore to remedy this? I have previously held letsencrypt certs without having to take manual action to address port 443. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [October 17, 2017, 1:53am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/4 "2017-10-17T01:53:15Z")
> [@jcspeegs](#): > > I ran this command: sudo certbot --apache -d [speegs.com](http://speegs.com) -d [www.speegs.com](http://www.speegs.com) The "--apache" plugin can only validate cert auths over TLS-SNI-01. Which means HTTPS = port 443. > [@jcspeegs](#): > > I have previously held letsencrypt certs without having to take manual action to address port 443 You mention previous certs and not using port 443. Do you happen to recall the command used to generate the certs and the domain? ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 1:59am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/5 "2017-10-17T01:59:33Z")
Yes, it was the interactive tool: sudo certbot --apache (granted an ubuntu 14.04 os) The domain was the same domain: [speegs.com](http://speegs.com). I am attempting to migrate servers I read an article about certbot discussing that certbot does not require manual port configuration and that if permissions were set right, then port 443 would be configured as needed by the script. I am not opposed to manual configuration, but I have not found content discussing the requirements. ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 2:29am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/6 "2017-10-17T02:29:57Z")
Do you have any suggestions I might explore around how to address this? I have gone through the certbot documentation, followed the apache arch wiki to configure httpd.conf and letsecncrypt arch wiki to configure /etc/httpd/conf/extra/httpd-acme.conf. Hoping to be able to troubleshoot this issue and avoid rolling back to my old server. Thanks. ---
**Author:** ![Patches](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/patches/32/17145_2.png) [@Patches](https://community.letsencrypt.org/u/Patches)\ **Post date:** [October 17, 2017, 3:14am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/7 "2017-10-17T03:14:40Z")
You shouldn’t have to manually configure Apache to listen on 443. Sometimes doing so makes it easier to figure out why it isn’t working when certbot configures it for you, though. You may have to configure the firewall built into your operating system or the one in the DigitalOcean control panel to allow connections on port 443. Strangely, port 443 appears to be open on your server, though. Are you trying to obtain a certificate for the domain before you roll over the A record to that server? Unfortunately that isn’t possible; you’ll need to copy the certificate or use DNS authentication. ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 3:29am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/8 "2017-10-17T03:29:27Z")
Thanks for the reply Patches. I can confirm that port 443 was closed while I was experiencing this issue, however I needed to roll back to my old server due to time constraints. In my past experience I haven’t needed to manually configure port 443 to get the authorization to succeed, which is what was causing my confusion. I verified that my previous server did not have the Digital Ocean control panel based firewall enabled, which makes me think I should look into my vhost configuration? But I welcome other suggestions too as I was banging my head against that wall all day (ouch). ---
**Author:** ![Patches](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/patches/32/17145_2.png) [@Patches](https://community.letsencrypt.org/u/Patches)\ **Post date:** [October 17, 2017, 3:40am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/9 "2017-10-17T03:40:43Z")
Maybe next time try `rsync`ing over `/etc/letsencrypt`, and then you can just run `certbot install --apache -d yourdomain.com` to configure Apache with your old certificate. You can then test if HTTPS works (e.g. by accessing it via it’s IP address and ignoring the certificate error) and iron out any firewall issues you may have. Once that works, you can roll over your A record (with zero downtime!) and after waiting out the TTL you can try a `certbot renew --force-renewal` once to make sure you can renew okay going forward. ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 4:06am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/10 "2017-10-17T04:06:26Z")
After moving /etc/letsencrypt over and running: sudo certbot install --apache -d [speegs.com](http://speegs.com) I got an error requiring the parameters: --cert-path and --key-path. So looking at /etc/letsencrypt/live i see symlinks pointing to cert.pem, privkey.pem, etc. When specifying these paths for --cert-path and --key-path I receive an error as follows: sudo certbot install --apache --cert-path /etc/letsencrypt/live/cert.pem --key-path /etc/letsencrypt/live/privkey.pem -d [speegs.com](http://speegs.com),[www.speegs.com](http://www.speegs.com) Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator None, Installer apache Created an SSL vhost at /etc/httpd/conf/extra/nextcloud-le-ssl.conf Cannot find a cert or key directive in /files/etc/httpd/conf/extra/nextcloud-le-ssl.conf/IfModule/VirtualHost. VirtualHost was not modified Unable to find cert and/or key directives IMPORTANT NOTES: - Unable to install the certificate Should I be pointing --cert-path and --key-path somewhere else? ---
**Author:** ![Patches](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/patches/32/17145_2.png) [@Patches](https://community.letsencrypt.org/u/Patches)\ **Post date:** [October 17, 2017, 8:53am UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/11 "2017-10-17T08:53:44Z")
Sorry I forgot `install` was so simple-minded. > [@jcspeegs](#): > > /etc/letsencrypt/live/cert.pem Those directories should contain your domain name, e.g. `/etc/letsencrypt/live/yourdomain.com/cert.pem`. Although your error looks weird, like it's not creating the virtual host properly? Hopefully it's just the path. I noticed my version of certbot (whatever comes with the latest Debian stable) complains that it needs a `--fullchain-path` only after I have specified a cert and key path, but once I specified that it worked correctly, and I was able to visit the test domain in my browser without any warnings. ```plaintext $ sudo certbot install -d mydomain.com --cert-path /etc/letsencrypt/live/mydomain.com/cert.pem --key-path /etc/letsencrypt/live/mydomain.com/privkey.pem --fullchain-path /etc/letsencrypt/live/mydomain.com/fullchain.pem Saving debug log to /var/log/letsencrypt/letsencrypt.log Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf Enabled Apache socache_shmcb module Enabled Apache ssl module Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf Please choose whether HTTPS access is required or optional. ------------------------------------------------------------------------------- 1: Easy - Allow both HTTP and HTTPS access to these sites 2: Secure - Make all requests redirect to secure HTTPS access ------------------------------------------------------------------------------- Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Enabled Apache rewrite module Redirecting vhost in /etc/apache2/sites-available/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf ``` ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 1:49pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/12 "2017-10-17T13:49:41Z")
After updating the --cert-path and --priv-key paths to contain my domain, I receive a complaint stating: Cannot find a cert or key directive in /files/etc/httpd/conf/extra/nextcloud-le-ssl.conf/IfModule/VirtualHost. VirtualHost was not modified ``` sudo certbot install --apache --cert-path /etc/letsencrypt/live/speegs.com/cert.pem --key-path /etc/letsencrypt/live/speegs.com/privkey.pem -d speegs.com,www.speegs.com Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator None, Installer apache Created an SSL vhost at /etc/httpd/conf/extra/nextcloud-le-ssl.conf Cannot find a cert or key directive in /files/etc/httpd/conf/extra/nextcloud-le-ssl.conf/IfModule/VirtualHost. VirtualHost was not modified Unable to find cert and/or key directives IMPORTANT NOTES: - Unable to install the certificate ``` What might cuase this vhost issue? ---
**Author:** ![paulmarc](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/paulmarc/32/17365_2.png) [@paulmarc](https://community.letsencrypt.org/u/paulmarc)\ **Post date:** [October 17, 2017, 2:20pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/13 "2017-10-17T14:20:03Z")
@jcspeegs, if you don’t mind, can you post the Apache configuration file you’re using for your site? ---
**Author:** ![paulmarc](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/paulmarc/32/17365_2.png) [@paulmarc](https://community.letsencrypt.org/u/paulmarc)\ **Post date:** [October 17, 2017, 2:22pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/14 "2017-10-17T14:22:29Z")
> [@jcspeegs](#): > > VirtualHost was not modified Kindly also send the output of this: `apachectl -S` ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 6:56pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/16 "2017-10-17T18:56:21Z")
Hi @paulmarc - Thanks for the continued support, I am making progress slowly but surely. 1. I noticed that a few ssl related Apache modules had not been loaded in my config, which allowed me to get past the authorization issue 2. Then when running the certbot install command with my base domain and corresponding www sub-domain, I received an error that no vhost existed for the www sub-domain. I fixed this by adding an Alias in my vhost declaration Now, the certbot install command runs without error, but when i test my site using [https://ip-address](https://ip-address), I get a message stating: > Your connection is not private. ---
**Author:** ![Patches](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/patches/32/17145_2.png) [@Patches](https://community.letsencrypt.org/u/Patches)\ **Post date:** [October 17, 2017, 7:05pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/17 "2017-10-17T19:05:32Z")
You should expect a security warning until you move over your A record and the website is properly available at the domain name listed on the certificate. You can examine the certificate by clicking the broken lock icon in most browsers or with Chrome by pressing F12 and going to the Security tab. If the name on the certificate matches the domain you’ll be using with the server in the future you should be all good. You can then bypass the security warning so you can make sure all the non-security things are working before moving your A record. ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 7:22pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/18 "2017-10-17T19:22:11Z")
Ok thanks. Yes, I was able to verify that the cert being shown is assigned to the domain that I will be using. However, when I continue past the warning, I receive an error that the page does not exist. The strange part is that if I initiate an ssh tunnel to the ip-address:80, then the page loads fine. I also notice that even though I prompted certbot for the http -\> https redirect, visiting [http://ip-address](http://ip-address) successfully loads the requested page and does not redirect. ---
**Author:** ![Patches](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/patches/32/17145_2.png) [@Patches](https://community.letsencrypt.org/u/Patches)\ **Post date:** [October 17, 2017, 7:33pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/19 "2017-10-17T19:33:13Z")
Depending on your web server configuration, your virtual host may not be accessible by IP. You can use [this Chrome extension](https://chrome.google.com/webstore/detail/virtual-hosts/aiehidpclglccialeifedhajckcpedom?hl=en) or [this Firefox extension](https://addons.mozilla.org/en-US/firefox/addon/header-tool/) to alter the Host header to match your normal domain for testing. Or, you could add a [hosts file entry](https://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/) temporarily mapping your domain to the new IP address to properly test it. (You won’t get a certificate warning this way either!) Make sure and remove it when your done though so you don’t forget about it or your website may become broken for just you in the future. ---
**Author:** ![jcspeegs](https://avatars.discourse-cdn.com/v4/letter/j/9e8a1a/32.png) [@jcspeegs](https://community.letsencrypt.org/u/jcspeegs)\ **Post date:** [October 17, 2017, 8:15pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/20 "2017-10-17T20:15:30Z")
@Patches, @paulmarc - Thank you both for your support through this. I’m not sure what caused the [https://ip-address.com](https://ip-address.com) requests to fail, however after switching my a name record the site is working with https and http redirect. I also ran a dry-run cert install to test for updates and was successful. Again, thanks for your support. I will be making a donation to the project as a small thank you. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [November 16, 2017, 8:15pm UTC](https://community.letsencrypt.org/t/failed-authorization-procedure-connection-refused/44402/21 "2017-11-16T20:15:51Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.