The server could not connect to the client to verify the domain

Try stop apache, execute the command and then start apache. Apache using port 443.

I use Nginx.

After so much trials and setting up new VPS from scratch, I deleted Cloudflare from the domain, and certbot worked like charm.

I hope this helps someone not to destroy a Linode (like my case) or a Droplet.

Cheers!

I stopped apache service and then worked like a charm

I am new here, first post. Could somebody kindly list for the certbot on a linux/apache server to do this command,

certbot-auto --apache certonly

Which ports needs to be enabled? Normally I do not have 443 or 80 used at all. There are many servers which use only special ports. Even ssl ones can work over any specified ports, if they need to be discovered by public searches.

The command does find all my virtual servers, they are on various ports. I am not currently running any ssl encrypted.

Perhaps the command has options to specify instead of 80, 443 which ports are already open? It looks like the bot, changes the apache2.conf and sets up new pages and runs the server with these modified settings and resets them after the verfication. Just like it scans for the virutal servers, it should include the portnumber associated with the virtual servers? Currently the virtual server listings are incomplete, IMO. Then the user can select the subdomains, (yes the certificates will be issued for subdomains not the fully qualified virtual hosts with ports), but certbot can use the ports that it scanned to perform the verification?

As you might have guessed, but my verification failed; I read all the msgs here. I have not seen a complete pre-requites of ports etc for the current test to work. Please list them.

Thank you very much!
Cordially, Cqc

To make my above question complete,
I did open both ports 80, 443, but I do not have any use for them in my apache2.conf. On running the test, the error I get is,

Failed authorization procedure. my.domain.com (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify

Also the apache error log, during this test shows:
AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist

Hi @Cqc,

This method does use inbound port 443. There is a slight chance that you’ve found a bug in Certbot in terms of its ability to reconfigure your Apache appropriately, but more likely in these situations is that there is some other firewall or network configuration that prevents inbound connections on port 443. Another possibility is a DNS error, or a DNS AAAA record advertising an IPv6 address that is not actually routed to your server.

Schoen,

Thank you for the prompt reply.

A. I think I see two possibly unrelated problems.

  1. In the apache error log, Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist

This occurs only if apache is running, when certboot is started. So if I first stop appache and then run certbook it does not happen [CHECKED]. BTW, the /var/lib/letsencrypt/ dir does exist after the run, but it only has has entry backups dir within it.

  1. The verification failing, even after working around as above.

I am pretty sure, I had opened up 443 during my last tests; my isp does not block any ports.

As for the DNS A record
my sub domains are often used from outside, so they can be accessed.

When I do a
dig my.domain.com @mainns.domain.com, I do see the A record resolving to my ip #.

Is how the verification is done published? Details?

Does your verification set up a virtual server (using your constructed apache conf delta as an include file) at my.domain.com:443, and try to access the material you put into your temp set up server pages? Of course to access my domain, the dns lookup need to resolve my.domain.com. Is my understanding correct?

You may even have optimized to avoid dns propagation delay by finding the primary dns server and look up there (this does not matter in my case, since my sub domains have been in use for a long time).

The following may help you. My server apache2.4 on Raspberry Pie 3, sw Respbian (which I understand is basically Debian). Do you know if the current certbot has successfully run on the above configurattion?

Looking forward to your help.

Yes, you can see the code that performs it at

The validation methods are specified in

Yes, except it's not the material on a page (for TLS-SNI-01 validation on port 443), but the content of a temporary self-signed certificate in the TLS handshake. It doesn't even go as far as making an HTTP request at all.

Using HTTP-01 validation on port 80, it uses an existing virtual host and adds a single file at a specified location; then the CA tries to access that file over HTTP on the existing site. (If you don't have an existing web server, you can also use --standalone in Certbot to run a temporary one, which can authenticate using either of these two methods.)

This is correct, it goes directly to the authoritative name server, not a cache.

I don't think this error matters because there are no files being served in the TLS-SNI-01 challenge. I think this error is common and doesn't prevent validations from succeeding (though perhaps we should do something to eliminate it).

Thank you very much! These give me enough materials to do some more experiments.

A side question:
In your dns lookup, if the records are set up this way, thru CNAME, would you find it?

my.domain.com. 3599 IN CNAME xx.domain.com.
xx.domain.com. 3599 IN A nn.nn.nn.nn (nn being the ip#)

While I experimented already without the above indirection, many are setup with CNAME, and I dont have to recongure them for letsscript going forward.

A CNAME is fine.

By the one, one more thing to check might be DNSSEC. Let’s Encrypt does not require DNSSEC at all, but does require that your DNSSEC signatures be valid if DNSSEC is enabled.

Yes this was my case, I did not have any v.server on :80 or :443, but I simply opened them up. So if I can simply run the following, with the above, I can avoid a lot of setups and changes just to try this.

certbot-auto --apache certonly --standalone

correct?

Nope! apache and standalone are both authenticator plugins, but you can only use one or the other. The Apache plugin uses TLS-SNI-01 on port 443 (by reconfiguring an existing Apache server) and the standalone plugin uses either TLS-SNI-01 on port 443 or HTTP-01 on port 80, depending on the value of --preferred-challenges, but assumes that you don't have an existing server running. You have to pick one or the other.

However, the Apache plugin can also be used to install a certificate in Apache after it's obtained, so it is valid to run

cerbot-auto -a standalone -i apache

which means "use standalone to obtain the certificate, and then use apache to install it".

Thank you, very quick reply!!

Well, --standalone ran successfully (I am glad i did not try that first, I leaned a bit more this way :slight_smile: )

Now I like to do a manual install of the cert and key in my apache2.conf. So the only two I need are the privatekey.pem and the fullchanin.pem. Do I simply point to locations at

(for the benefit of other vistors here)
SSLEngine On
SSLCertificateKeyFile /etc/letsencrypt/live/my.domain.com/privkey.pem
SSLCertificateFile /etc/letsencrypt/live/my.domain.com/fullchain.pem

I assume if repeat the --standalone requestt, it will use the same private key?
It it a 2048 bit encryption?

Oh! I see a lot of options in a file left behind in the
/etc/letsencrypt/options-ssl-apache.conf
file! Do I need any of these stuff added to my apache2.conf??

That looks plausible.

Nope, a new one every time! I'm responsible for adding a feature that would let you choose to use the same private key (which is useful for things like HPKP), but I haven't finished that feature yet.

Yes, that's the default. You can change the key size with --rsa-key-size. There are many other things that affect the strength and nature of the encryption between your server and a visitor. (For most users with modern browsers contacting your site, the server public key is not being used directly to protect the session, but is being used to authenticate your server's identity in a separate key exchange protocol using Diffie-Hellman or Elliptic Curve Diffie-Hellman.)

There should already be an Include directive which is including that file from the -le-ssl.conf file.

First, thank you very much for the wonderful support!

I have my website running with SSL for the first time!!! And my Chromium Os (CloudReady version) browser already accepts these certificates!!

Hmmm??? I used standalone. So my apache2.conf was not touched, correctly. So how do these get included? I do not see any trace of an -le-ssl.conf file anywhere. I do not see how my current apache2.conf could be using any of that :frowning: Help please!

Check in: /etc/apache2/sites-enabled

Lastly, before I go, if the certbot is under your organizaion control, I suggest / recommend the enhancements I had proposed in my first email.

1.When auuto or certonly run, decouple the terms virutal servers from sub-domains in all the msgs. There can be #of SubDomains X #of ports listened to VirtuualServers.

  1. You issue certificates for sub-domains (or soon *.domains). The user already have some ports they listen to (do not assume 80, or 443). So in your certifcattion/verfication process just use tthe ports that are already in the listen directives of apache2.conf.

2B. A better algorithm would be:
When you list the subdomains as you currently do, for the user to manually select the desired one, instead list the virtual servers avaialble, INCLUDING THE :port.

So when a user selects my.domain.com:nnnn, you verify using port nnnn, and issue certificate for my.domain.com.

When you implement tthis in your certbot, a lot more clients would run automatically, and a ton of questions to support will go away!!

Thank you again for all your support!