Failed authorization procedure: Connection refused

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., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command: sudo certbot --apache -d -d

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
tls-sni-01 challenge for
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Connection refused, (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Connection refused


  • The following errors were reported by the server:

    Type: connection
    Detail: Connection refused

    Type: connection
    Detail: 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, 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.

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

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:

--2017-10-16 21:22:28--
Resolving (
Connecting to (||:443... failed: Connection refused.

--2017-10-16 21:23:05--
Resolving (
Connecting to (||:443... failed: Connection refused.

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.

The "--apache" plugin can only validate cert auths over TLS-SNI-01.
Which means HTTPS = 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?

Yes, it was the interactive tool: sudo certbot --apache (granted an ubuntu 14.04 os)
The domain was the same domain: 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.

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.

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.

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).

Maybe next time try rsyncing over /etc/letsencrypt, and then you can just run certbot install --apache -d 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.

After moving /etc/letsencrypt over and running: sudo certbot install --apache -d 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,

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


  • Unable to install the certificate

Should I be pointing --cert-path and --key-path somewhere else?

Sorry I forgot install was so simple-minded.

Those directories should contain your domain name, e.g. /etc/letsencrypt/live/

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.

$ sudo certbot install -d --cert-path /etc/letsencrypt/live/ --key-path /etc/letsencrypt/live/ --fullchain-path /etc/letsencrypt/live/
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

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/ --key-path /etc/letsencrypt/live/ -d,

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

 - Unable to install the certificate

What might cuase this vhost issue?

@jcspeegs, if you don’t mind, can you post the Apache configuration file you’re using for your site?

Kindly also send the output of this:
apachectl -S

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, I get a message stating:

Your connection is not private.

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.

1 Like

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 successfully loads the requested page and does not redirect.

Depending on your web server configuration, your virtual host may not be accessible by IP.

You can use this Chrome extension or this Firefox extension to alter the Host header to match your normal domain for testing.

Or, you could add a hosts file entry 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.


@Patches, @paulmarc - Thank you both for your support through this. I’m not sure what caused the 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.


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