[SOLVED] New certificat request after hosting services migration


#1

Hy we are an hosting provider and we have some issues getting certificate for the domain sosmediterranee.ch

My domain is: sosmediterranee.ch

I ran this command: /opt/certbot/certbot-auto certonly --webroot -w /etc/letsencrypt/webrootauth/ -d www.sosmediterranee.ch -d sosmediterranee.ch

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sosmediterranee.ch
http-01 challenge for www.sosmediterranee.ch
Using the webroot path /etc/letsencrypt/webrootauth for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. www.sosmediterranee.ch (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.sosmediterranee.ch/.well-known/acme-challenge/WmQwVAJo-WEF034OyOFkLOs5GhMWnpqQ76nxp4Nmc20: Timeout after connect (your server may be slow or overloaded), sosmediterranee.ch (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://sosmediterranee.ch/.well-known/acme-challenge/yvrtq6gfQDUAdN1UU_hfFDZQqsRaRzec4RMIh8CFc0c: Timeout after connect (your server may be slow or overloaded)

IMPORTANT NOTES:

My web server is (include version): apache 2.4

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

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

The thing that seems strange to me is that I can see LE validation server request on my server and receiving a 200 return code as you can see below :
www.sosmediterranee.ch:80 64.78.149.164 - - [13/Sep/2018:10:51:17 +0200] “GET /.well-known/acme-challenge/HWCjpOBbrOiUwvWkEtiLGQml7-IOpWzi8_O2NgBmurk HTTP/1.1” 200 443 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)”
www.sosmediterranee.ch:80 64.78.149.164 - - [13/Sep/2018:10:51:18 +0200] “GET /.well-known/acme-challenge/iM2JnEn4jjtAyAcqtoLQeEblPrJoGgQfazXAPXZrY0c HTTP/1.1” 200 443 “-” “Mozilla/5.0 (compatible; Let’s Encrypt validation server; +https://www.letsencrypt.org)”

Our customer was hosted by another provider before today and already have a LE certificate (that seems to be still active). I think it can be part of the problem. Do I need to ask my customer to contact his previous hoster to revoke his certificate before I can create one?

Thank you for your help


#2

Hi @NetOxygen

there are more then one check per domain. So one may work, the other may fail.

No. This is not relevant. You can have a lot of active certificates

https://transparencyreport.google.com/https/certificates?cert_search_auth=&cert_search_cert=&cert_search=include_expired:false;include_subdomains:false;domain:sosmediterranee.ch&lu=cert_search

Sometimes the installation doesn’t work, users produce 5 certificates with the same domain name set in one day and hit the letsencrypt - limit.

PS: Fetching

http://www.sosmediterranee.ch/.well-known/acme-challenge/WmQwVAJo-WEF034OyOFkLOs5GhMWnpqQ76nxp4Nmc20

via browser I get a 403. I should see the file or get a 404 status. Fetching a wrong file

http://www.sosmediterranee.ch/.well-known/acme-challenge/WmQwVAJo

I have again a 403. But this is not your “Timeout error”. If the server blocks /.well-known/acmen-challenge/, this is wrong.


#3

Hi Juergen,

Thanks for the quick answer.

So, you advice to wait until tomorrow and try again?

I tried to fetch the document during the certificate validation and it worked. I have a lot of other websites on the same servers and I was able to create LE certificates for them with no problem So I don’t think it is the cause of our problem.


#4

This is not your problem. Users create 5 certificates, but the installation part doesn’t work (special configuration or something else). But the CT - logs have the new certificates. Your certificate creation doesn’t work. So it isn’t an installation problem of an existing new certificate.

What’s the difference between the other domain installations and this domain installation? Is there a firewall?

And the 403 - status is wrong, may be part of the “real problem”.

Upps - what’s that: A loop:

D:\temp>download http://sosmediterranee.ch/ -h
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 0
Cache-Control: max-age=0
Content-Type: text/html; charset=UTF-8
Date: Thu, 13 Sep 2018 10:04:34 GMT
Expires: Thu, 13 Sep 2018 10:04:34 GMT
Location: https://sosmediterranee.ch/
Server: Apache

Status: 301 MovedPermanently

But then:

D:\temp>download https://sosmediterranee.ch/ -h
SSL error: RemoteCertificateNameMismatch
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Length: 234
Cache-Control: max-age=0
Content-Type: text/html; charset=iso-8859-1
Date: Thu, 13 Sep 2018 10:04:45 GMT
Expires: Thu, 13 Sep 2018 10:04:45 GMT
Location: http://sosmediterranee.ch/
Server: Apache

Status: 301 MovedPermanently

Your http - connection is very slow. Perhaps this is the “Timeout”.

PS:

D:\temp>download http://sosmediterranee.ch/.well-known/acme-challenge/1234 -h
Error (1): Der Remoteserver hat einen Fehler zurückgegeben: (403) Unzulässig.
ProtocolError
403

is very quickly. Is there a very long redirect / block - list?


#5

I can not think of any relevant difference. The only one I can see is that it’s a Wordpress that the customer transfer from his previous hosting provider. It as a plugin to enfore SSL, so that may be part of the problem. For our customer we have added a virtualhost to redirect https to http on site that doesn’t have SSL enabled. That was the loop you encounter I think.
I clean the documentRoot to eliminate problem introduced by the old Wordpress.
I also create the virtualhost for https://sosmediterrannee.ch (with an unmatching cert but this eliminate the loop).
But the error is still the same.

Something strange : using staging env gave me a certificate :
/opt/certbot/certbot-auto certonly --webroot -w /etc/letsencrypt/webrootauth/ -d sosmediterranee.ch --staging
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for sosmediterranee.ch
Using the webroot path /etc/letsencrypt/webrootauth for all unmatched domains.
Waiting for verification…
Cleaning up challenges

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at:
    /etc/letsencrypt/live/sosmediterranee.ch/fullchain.pem
    Your key file has been saved at:
    /etc/letsencrypt/live/sosmediterranee.ch/privkey.pem
    Your cert will expire on 2018-12-12. To obtain a new or tweaked
    version of this certificate in the future, simply run certbot-auto
    again. To non-interactively renew all of your certificates, run
    “certbot-auto renew”

#6

And the same command without --staging?

That may block or redirect /.well-known/acme-challenge/ and produce the 403 status. Or there is a redirect to another folder and the account doesn’t have access -> 403 instead of 404.


#7

I have cleaned the DocumentRoot and just add an empty index.html. So there is no https enforcement anymore.
The command without staging still give me the same error.

I have done some more tests and I think that this is more a network related problem.
Doing an ngrep while certificate request let me see that I receive the request from LE server on .well-known/… but the answer never reaches LE server, I can see my server continuously resent the TCP packet.
Si try to ping LE server from my server with no luck, but that works on another server that can obtain certificate.
I will explore this way and get back to you when I manage to solve my problem.
Have you ever heard about an IP black list on LE server?


#8

Now it’s better, but not good.

This is good:

D:\temp>download http://sosmediterranee.ch/.well-known/acme-challenge/1234 -h
Error (1): Der Remoteserver hat einen Fehler zurĂĽckgegeben: (404) Nicht gefunden.
ProtocolError
404

A 500 is not good:

D:\temp>download http://sosmediterranee.ch/ -h
Error (1): Der Remoteserver hat einen Fehler zurĂĽckgegeben: (500) Interner Serverfehler.
ProtocolError
500

But the root is fast, so this problem is fixed.


#9

My problem is solved. It was a network issue.
There was a lot of packet loss so LE server never received our reponse when it was looking for acme-challenge.

Thank you Juergen for looking into this.