VestaCP - Hard Coded Replies in Nginx Config Not working

[steampunkjnkies]

My domain is: http://graphicsfactory.com

It produced this output:

My web server is (include version): nginx,

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):

VestaCP

My nginx config works like so:

location ~ "^/\.well-known/acme-challenge/(.*)$" {
    default_type text/plain;
    return 200 "$1.GnfiMH2S5ViPzsSOGrK2620kfbTIFfpAR2eu8DARu0k";
}

When I test a sample URL using curl it works as expected:

    curl --verbose -4 http://graphicsfactory.com/.well-known/acme-challenge/foo
    *   Trying 45.33.33.185...
    * Connected to graphicsfactory.com (45.33.33.185) port 80 (#0)
    > GET /.well-known/acme-challenge/foo HTTP/1.1
    > Host: graphicsfactory.com
    > User-Agent: curl/7.47.0
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < Server: nginx
    < Date: Fri, 15 Sep 2017 14:33:57 GMT
    < Content-Type: text/plain
    < Content-Length: 47
    < Connection: keep-alive
    < Keep-Alive: timeout=60
    <
    * Connection #0 to host graphicsfactory.com left intact
    foo.GnfiMH2S5ViPzsSOGrK2620kfbTIFfpAR2eu8DARu0k

The error I get when trying to enable LE in VestaCP is:

Error: The key authorization file from the server did not match this challenge [m2RfT_XITIjYDwI90GxKh1qtdOrmLjFFNh-2uj33krw.GnfiMH2S5ViPzsSOGrK2620kfbTIFfpAR2eu8DARu0k] != [m2RfT_XITIjYDwI90GxKh1qtdOrmLjFFNh-2uj33krw.Fa081ei6SkGzsDyYL49JPrBE46agANOaAAByu9-jSrM]

The problem seems to be with the challenge - it seems to be looking for:

.Fa081ei6SkGzsDyYL49JPrBE46agANOaAAByu9-jSrM

I'm assuming this is the old code from the server we have moved from. Is there a way to reset this, so that the code on the new server is the one it's expecting? For the moment, I have had to copy over the crt/icrt/key contents over to the new server, and manually configured them. This won't work in the long run as obviously it won't auto renew on the new server. Any suggestions would be much appreciated

Thanks

Andy

[schoen]

Hi @steampunkjnkies,

This is based on your account key, which is probably different on each machine. I don’t know where it is stored in your environment, but the method you’re using seems to be based on

Neilpang/acme.sh

I should also note that I have never used this mode and so I don’t have personal experience to offer about fixing it. But hopefully this documentation will be sufficient, together with the knowledge that the appropriate account key needs to be used.

[steampunkjnkies]

Thanks for the tip @schoen . So looking into this, I did a grep on the new server and found the file /usr/local/vesta/data/users/admin/ssl/le.conf that holds the following:

EMAIL='myemail@graphicsfactory.com'
EXPONENT='AQAB'
MODULUS='o-qDnQJs97cYY9Vz5Ie9ttu-X11Xffqy5yw2Ie_-C0q7Sja3x-c1Fr_M9iNWt7skyp-Ogp3ISWbSK5dvGi2ud0dNhmax_uFt0ykxh_P-1fbFtagY5YNe9KLpt2RS-qIlyv0TGrGDHJwcp2oHCkI054HOzxVGH_gKdPK2zNTSeE8-735yb96E_jUXZBKDkwavuab9kIokQTaU7v73ooEdeNsaWv5rG0Op2g6I0y_Evky4sRNImkquax5vDJ0q96K-Y-_tvyWOU_JmBNr-yLoUfLzCHX6wwp5qI11Jqo2PWkMpqCAIaO_lNY1MBonB0mxC8a3ysA9LCtwHZkEebIOMbTA8Igaboq3C34XsTE79WMomCFFMSz-RhTXXjAcfRqOVFA1SfZw6ltOpefokgkCc-QLNzEWMWPnY-fFyHmtPeFzctfGkdAvN0FJMVMt6_ZA9MsSUoSpQZgfOTOt5eBqX-5tP0-y-b7oYVtYHzRv3p0jU8AYbr4bv7R2Pht7AsRyVx9-MgsjiMQNZ4obF9co6PiK22sz0oebQ-KLQ95J7pIkvxcFl9sm9yUW_CKUvgAUS0UbdqERLx8bSNeR6S0WzZTXpcAzBq6DTvDRhCjrKCy2Wxiu_QxHe1G8mqoqpNPtpPrEclDR9hHaMI4KYmonCd23JSH7gXvJDSsE7-5cdOxU'
THUMB='GnfiMH2S5ViPzsSOGrK2620kfbTIFfpAR2eu8DARu0k'

I changed the last line to:

THUMB='Fa081ei6SkGzsDyYL49JPrBE46agANOaAAByu9-jSrM'

I then updated my nginx config file to have

location ~ "^/\.well-known/acme-challenge/(.*)$" {
    default_type text/plain;
    return 200 "$1.Fa081ei6SkGzsDyYL49JPrBE46agANOaAAByu9-jSrM";
}

I rebooted nginx, then re-tried setting it up - but now I get an error, but nothing in it:

Error: LE graphicsfactory.com validation

I'm not sure what else to try

Cheers

Andy

[schoen]

I think you could have made the change in the wrong direction, but unfortunately I’m not familiar enough with either Vesta or the stateless challenge method to be confident in that guess.

[steampunkjnkies]

OK, well I managed to find a dirty work around. I added a new test.* sub-domain, and then tried to create the certificate. Because its being seen as a new one, it didn’t care about the old acme challenge code (and now uses the new one)

Phew!

[ahaw021]

hi @steam

The method you have is based on the way that the HTTP challenges work.

In order to prove with HTTP you need to return a valid text file which is in the form

xxxx.yyyy

The yyy component doesn’t change as it’s derived from the account key.

The xxx part changes each time you request.

https://tools.ietf.org/html/draft-ietf-acme-acme-07#section-8.3

So if you are going to use this method (which is quite clever) you need to make sure that the response matches the key you are requesting the challenge with.

Andrei

[steampunkjnkies]

@ahaw021 - yup, I’m aware of that The problem is that the yyyy part didn’t match up on the new server (as you would expect), and because there was already a certificate given on the old server, it was still linked to the OLD challenge code. Adding an extra sub-domain to the certificate has just meant it created a new one, thus getting around the problem

Cheers

Andy