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

[albinantony2904]

I am using ubuntu 16.04 and apache server.
I tried to run the command sudo certbot --apache under following conditions

• with apache running
• stopping apache service
  -with port 80 in apache default conf file
  -with port 443

Still, I couldn’t succeed to setup ssl certificate. After some failure trials now I am getting an error like
There were too many requests of a given type :: Error creating new authz :: Too many invalid authorizations recently. .Please somebody help me out.

[Osiris]

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:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

[albinantony2904]

My domain is: www.quriousfly.io

I ran this command: sudo certbot --apache

It produced this output: Failed authorization procedure. www.quriousfly.io (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

My web server is (include version): apache 2

The operating system my web server runs on is (include version): ubuntu 16.04 on aws-ec2
My hosting provider, if applicable, is: namecheap

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

[bytecamp]

You are using tls-sni authorization, but connections to port 443 (https) don't succeed:

$ telnet www.quriousfly.io 443
Trying 13.126.72.26...

Switch to http-01 authorization which uses port 80.

[torkild]

Apologies for entering in on this.
I have the same issue. How do you switch to use http-01 ?

[bytecamp]

There is a parameter --preferred-challenges which could help on that.
So try running certbot with adding --preferred-challenges http

[Osiris]

@bytecamp

There is a parameter --preferred-challenges which could help on that.

So try running certbot with adding --preferred-challenges http

That won't directly help for the apache plugin. See the table with a very nice and clear overview of the different plugins for certbot with their capabilities and supported challenges: Getting certificates (and choosing plugins).

You can see there the apache plugin only supports the tls-sni-01 challenge. Those challenges are for the authentication feature of the plugin. The installation feature isn't coupled to challenges.

So for authentication using the http-01 challenge, you could use the webroot, standalone or manual plugin. For the first plugin (webroot), http-01 is the only supported challenge. Therefore, --preferred-challenges isn't necessary. For the latter two plugins, you can indeed select a challenge type with that option.

If you'd like to use the http-01 challenge with an already configured webserver, I would recommend the webroot plugin for authentication purposes. NOTE: you can combine different plugins for different features. I.e., you can use the apache plugin as installer (by using -i apache on the command line) combined with the webroot plugin as authenticator (by using -a webroot -w /path/to/applicable/webroot/ on the command line).
I would recommend the above combination of plugins: the apache plugin for installing the certificate into the webserver and the webroot plugin for authentication using http-01 on port 80.

But I think the problem of the topicstater warrents a different aproach than just selecting another plugin. It seems somehow acccess to port 443 is blocked. If access to port 443 is blocked, the resulting HTTPS site is blocked too. So choosing another plugin for issuance of the certificate is only part of the solution: having a HTTPS site which isn't reachable because port 443 is blocked isn't useful at all!

So in my opinion @albinantony2904 and @torkild should be looking into the problem of "why isn't my server accessible by port 443" in stead of only looking into the issuance of a certificate. Look at things like firewalls blocking every port but a few (i.e., 80, 22).

[bytecamp]

@Osiris

So in my opinion @albinantony2904 and @torkild should be looking into the problem of “why isn’t my server accessible by port 443” in stead of only looking into the issuance of a certificate.

I totally agree with you, network related problems should be fixed first.