UCS 4.3 and Let's encrypt app


#1

My domain is: cloudfrate.ddns.net

I ran this command: Installed let’s encrypt app from the App Center in UCS 4.3 and entered the above domain (wich is reachable without the encryption but there’s the warning page) in the “app settings” panel, I also checked apache and postfix.

It produced this output:

My web server is (include version): Apache 2.4.2 via UCS4.3

The operating system my web server runs on is (include version): debian64 ? I used the appliance for virtualbox to install it

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

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

Thanks for the help !


#2

Hi @Sarcasthik,

I’m not familiar with this environment, but could you use your root access to make a text file called /var/www/.well-known/acme-challenge/test.txt on this system?


#3

Hello @schoen,

thanks for taking some time to help.
I think i’ve succeded in creating this file using sudo nano /var/www/.well-known/acme-challenge/test.txt
What would be the next step ?

Sorry, my knowledge with linux and its terminal is fairly limited… And again thank you.


#4

It looks like the Let’s Encrypt client application’s self-test is failing, maybe erroneously because the challenge file might in fact be properly accessible from the Internet.

Could you try running this command on your server?

curl -v http://cloudfrate.ddns.net/.well-known/acme-challenge/test.txt


#5

This is what I get :

1

Connexion terminée par expiration du délai = connection delay expired


#6

If this is a residential network setup, you might need to stick the domain into /etc/hosts with the LAN-local IP address (or even 127.0.0.1) on the machine where the Let’s Encrypt client runs, to force the self-test to succeed.

With many residential router/modem combos, port forwarding etc do not function properly against the WAN address from inside the network.


#7

Yes, I think @_az’s explanation makes sense. In any case, this is probably the reason for the application’s failure. It’s trying to test whether the challenge file it created is visible from the Internet. Even though the answer should be yes, the server doesn’t succeed in connecting to itself from itself, so it doesn’t detect the fact that the challenge file is indeed already publicly visible.


#8

It is indeed a residential network, but the hosts file already contains 127.0.0.1

2

Or maybe I misunderstood, should I go and edit one of the three files mentionned in the screenshot and put the dns cloudfrate.ddns.net there ?


#9

On the UCS server/appliance, have a line in /etc/hosts like:

127.0.0.1 cloudfrate.ddns.net

and also retry the curl command to confirm it is working.


#10

The purpose of this change is to bypass the public DNS lookup, so that instead of connecting to 92.154.81.105 (like other Internet users outside of your network would), the server itself will connect to 127.0.0.1 (a special Internet loopback address meaning “this machine”). This is because of @_az’s observation that your router or firewall don’t seem to allow your server to connect to itself using its public Internet address, even though people outside of your network can do so.


#11

Just like that, WOW ! thanks a ton I was struggling for so long with this, not one second I regret posting even if I felt dumb, I learned a lot today thanks to you guys !

Cheers !


#12

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