Failure to obtain certificate - Ubuntu 16.04 - Nextcloud 13 - Nginx


#1

I’m in the midst of rebuilding a nextcloud server. Before the crash it had been running for some years with letsencrypt.

the domain is cloud.gregorigroup.com

Command:
letsencrypt certonly -a webroot --webroot-path=/var/www/letsencrypt --rsa-key-size 4096 -d cloud.gregorigroup.com

Response:
http://cloud.gregorigroup.com/.well-known/acme-challenge/W_19u3zaGLyBKoq5s8AeFiQM7TaGgQoSXIaYTr9nuvY:
Timeout during connect (likely firewall problem)

Regarding the “fire wall”… I completely disabled it to verify that it was not the problem.

Using these two curl commands indicates that port 80 is not responding… it appears that nginx is redirecting to port 443

curl -IkL -m20 http://cloud.gregorigroup.com/test
curl -IkL -m20 http://cloud.gregorigroup.com:443/test

Any help would be appreciated.
Thanks,
Wayne


#2

Hi,

There seems to be a problem with your port / firewall , since no port respond to query from outside (port 80 & 443)

Can you check if you entered the wrong address? Or something wrong with your server?

Thank you


#3

I’m afraid that I was messing around with the system this morning… it’s back up now… 443 should respond… 80 is blocked


#4

I think that this allows us to piece together an explanation of what you’re experiencing.

Around the beginning of this year a security problem was found with the TLS-SNI-01 validation method (which uses port 443). This has to do with certain large shared hosting providers’ configurations and might allow one user of a hosting provider to inappropriately obtain a certificate for a different user, in some circumstances.

Because of this, the use of this method was restricted by Let’s Encrypt:


In particular:

TLS-SNI can be used for revalidating and reissuing certificates for domain names that have previously-issued Let’s Encrypt certificates. This is limited to the account that issued the most recent certificate for any given domain name. It applies whether or not the certificate used TLS-SNI for validation. It applies only to fully-qualified domain names, not subdomains.

Since you have a new server, you presumably have a new Let’s Encrypt account (the account is automatically generated the first time you use a Let’s Encrypt client on a particular machine). That new account isn’t eligible to use TLS-SNI-01 validation on port 443 because it isn’t the most recent account that issued a certificate for your domain.

Your options are:

  • Find the account file in /etc/letsencrypt/accounts on the old machine and install it on the new server (removing the account that was automatically created on the new server)
  • Permanently unblock port 80
  • Temporarily unblock port 80 and issue a certificate, then re-block it (because then the account would be the most recent account to have issued a certificate for that name) (per @jsha’s observation below, this method is not suggested because it may make your renewals fail again at some point in the future)
  • Temporarily or permanently use the DNS-01 challenge method instead to issue your certificate)

Note that -a webroot always uses exclusively port 80, not port 443. This has always been true for the whole history of the project. If port 80 has always been blocked on your server, you were presumably previously using -a apache, -a nginx, or -a standalone, which could have used TLS-SNI-01 on port 443.


#5

Please don’t recommend this. It’s a very bad idea and will lead to problems down the road.


#6

Sorry, I meant to add a note discouraging this solution (because of the possible future stronger deprecation of TLS-SNI-01) and then I forgot to. I’ll refrain from suggesting this option in the future.


#7

As it turns out, it appears, that the only reasonable solution is to the DNS challenge (I tried copying over the backup directory… but the renew relies on port 80) … To that end I’ve added the text record to my Godaddy DNS… it seems to have propagated to some servers but not others… the link that their tech support gave me shows the propagation… but mxtools does not… and Letsencrypt is not finding it…
https://mxtoolbox.com/SuperTool.aspx?action=a%3Agregorigroup.com&run=toolpage#

The Godaddy Tech support link:
Godaddy Verification Link

Ever come up against this?
Wayne


#8

When I follow the “Godaddy Verification Link” here, it has an extra %0d%0a at the end of the name, but anyway it doesn’t return a particular Let’s Encrypt challenge (whether or not I delete the spurious %0d%0a). Was there a particular challenge value that you were trying to post? Did Godaddy tech support tell you that that challenge value had been posted in your DNS zone?


#9

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