Vesta: Can not enable LetsEncrypt on "Apache Only" server.

[SCelik]

Operating System (OS/VERSION):

CentOS release 6.8 (Final)

VestaCP Version:

Version: 0.9.8 (x86_64) Release: 17

Installed Software (what you got with the installer):

Apache-Only configuration.

Steps to Reproduce:

Try to enable SSL Support with LetsEncrypt Support on a domain from VestaCP

You got error:

"Error: Invalid response from http://sub.domain.tld/.well-known/acme-challenge/vw59IQNQWzp4Ars8HuPMqIprRgXUJ4eE3vDq__9Jrl0: \"

[alex-connor]

Before you add the certificate Let’s Encrypt, you need to remove your certificate or disable SSL support

[dpeca]

For what domain you are trying to get letsencrypt cert?
For sub.domain.tld or for domain that is public available?

[SCelik]

Alex, SSL support is disabled already.

dpeca, i'm trying to add sll cert to subdomain and it's public available.

I've two identical servers except for, nginx.

Both servers have same OS and version, same php version etc.

One is Apache-Only, the other is Nginx + Apache.

With Nginx + Apache everything works fine.

[robindirksen1]

Did you add dns records A for www.sub.domain.tld and sub.domain.tld?

[SCelik]

No just for sub.domain.tld.
I'll add www.sub.domain.tld and try again.

[robindirksen1]

Yes, Letsencrypt requires an A record for both. Hope this works!

[SCelik]

No it didn't worked. Also in error string it says:

Error: Invalid response from http://sub.domain.tld/.well-known/acme-challenge/YXyss0Q2a1lELU_GSS-QbRErgS-wtQWvlYdW9CR68ak: \

So it doesn't try to get response from www.sub.domain.tld i think issue is related with http alias.

Becouse when i try to open url: "http://sub.domain.tld/.well-known/acme-challenge/" returning 404 response from server.

on the other server:

when i enabled letsencryptssl,

an alias is created for nginx in file:

/home/user/conf/web/nginx.domain.tld.conf_letsencrypt

On apache only server, there is no alias for .well-known/acme-challenge

[SysVoid]

I provide some additional information in my issue above (#971). I think it's due to the fact that the LE script only creates NGINX configuration. I have not investigated, though.

[Skamasle]

The motive of 404 is because a function not create dirs

This does not exists in v-check-letsencrypt-domain

In this else:

else
    acme="$HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge"
    echo "$token" > $acme/$token.$thumb
    chown -R $user:$user $HOMEDIR/$user/web/$r_domain/public_html/.well-known
fi

Two directories missing

need a

mkdir -p $HOMEDIR/$user/web/$r_domain/public_html/.well-known/acme-challenge

If not isnt posible do a

echo "$token" > $acme/$token.$thumb

This only solved 404 something more fail in my test in centos 6

[iandk]

I have the same problem.

I think the best solution would be to use a global ".well-known" directory for the LE challenge.

[pabloko]

I'm on the same issue as updated everithing to stable.

Did some grep on the bin scripts, surprisingly similar to my shitty preview code https://github.com/serghey-rodin/vesta/issues/425#issuecomment-162875068 (wew im not even credited)

At fist removed my .well-known nginx redirector from previous version and encountered this. Had to comment some code and use the old global way with shared webroot to make it work, as i needed it asap.

I didnt extensively test it, but its seems also not grouping domains and subdomain certs. This will need a lot of tweaking and seems not finished to be in a release.

[KuJoe]

I can confirm this issue occurs when the nginx proxy is disabled for a domain. Enabling it for the domain fixes the issue immediately.

[urosg80]

almost solved by @Skamasle the portion of the script he posted was the right one, but the error actually lies in the "echo" line, the information is added backwards it should read:
echo "$token.$thumb" > $acme/$token

[urosg80]

pushed PR #1006

[SCelik]

I can confirm that urog80's patch resolved this issue on Centos 6.x #1006

[didyouexpectthat]

I applied https://github.com/serghey-rodin/vesta/pull/1006 on my machine. I use Debian 8.
It did not resolve an apache2-only domain for me. (I have nginx installed, but disabled support on the domain).
I restarted apache2 and nginx before trying as well.
It does work with default nginx template (but not force-https).
Does force-https affect renewals?

[urosg80]

@didyouexpectthat can you please check that the challenge file is accessible through https and that request for the challenge file on http is actually redirected to the file on https (when force-https) enabled as according to this post on letsencrypt forum redirects should be followed, but first make sure that the challenge file is accessible.

[kmark]

I am receiving the same error on an Ubuntu 14.04.5 LTS / Apache / Nginx configuration. It appears that if you're using the force-https nginx template (or any custom variation of it) this command will fail. The nginx.domain.tld.conf_letsencrypt configuration file is only created for HTTP requests. This means that when http://domain.tld/.well-known/acme-challenge/* is accessed it redirects to HTTPS which has no Let's Encrypt acme-challenge response handler and consequently 404s. The quick fix is to just symlink snginx.domain.tld.conf_letsencrypt to nginx.domain.tld.conf_letsencrypt for any domains that are afflicted.

I should also add that if you have a domain already set up with Let's Encrypt and _then_ you enable force-https the renewal will fail. So to get automatic renewals working you'll need to adopt this symlink workaround, patch the script, or forgo using force-https.

I would definitely consider this a bug, and it's resulting in the same error as the OP, but I assume the reason it's occurring is a bit different and may warrant a separate issue. Maybe #979?

[urosg80]

@kmark and @didyouexpectthat when using "force-https" mode are you using public_shtml or public_html for publishing your website?

Purpose of all of this is to automate everything but without knowing more details no fix can be made.

[didyouexpectthat]

@urosg80 I use public_html.

[kmark]

@urosg80 public_html

[JakeyPrime]

Hmm, still seem to be running into this problem. Any pointers? I tried force updating Vesta and no dice. I'm currently Apache only. CLI returns the same thing.

[anton-reutov]

https://bugs.vestacp.com/issues/483

[picklit]

I applied https://github.com/serghey-rodin/vesta/pull/1006 and it did NOT fix the issue for me. Yes, the .well-known/acme-challenge subdirectory is now successfully created, but I'm still getting the "Error: Invalid response from ..."

[R0adRunn3r]

Same Issue here on vesta 0.9.8 r17... any solutions?

[sudosu0]

@R0adRunn3r if you enable nginx (proxy support) it will work

[anton-reutov]

@R0adRunn3r
https://bugs.vestacp.com/issues/483
read comments

[R0adRunn3r]

@anton-reutov
Thx, applied the commit in the comments and worked perfectly :)