Get fetch SSL certificate on DO vps with .NL

[lexg]

Hi ...

So, I've been creating wordpress sites (.com / .net) etc. on a digitalocean vps and have been using easyengine. This is an install script that installes a web environment and has a command to add SSL through letsencrypt as well....

So, this worked perfectly untill now.

I have registered a .NL domain name and installed a second wordpress blog on a VPS that already has a wordpress installation (including SSL through letsencrypt) ..

However, if I try to add SSL to the second domain name (.NL) .. I get this output from EE :

Unable to setup, Let's Encrypt
Please make sure that your site is pointed to
same server on which you are running Let's Encrypt Client
to allow it to verify the site automatically.

Ofcourse, the domain name is on the same servers as the command client I am using ... this is obvious ..

Does anyone know what the problem may be ?

Thanks ,
Lex

[_az]

So you used the procedure on https://easyengine.io/docs/lets-encrypt/ ?

Could you show your /var/log/easyengine/ee.log ?

[lexg]

Hi _az,

That's correct. I used the EE command sudo ee update site.NL --letsencrypt (always worked perfectly). But it seems my many failed attempts to get the certificate leadsd now to a too many attempts problem as well ...

The output of the EE log is:

2018-02-28 07:53:49,461 (WARNING) ee : Please Wait while we fetch SSL Certificate for your site.
It may take time depending upon network.
2018-02-28 07:53:49,461 (DEBUG) ee : Running command: ./letsencrypt-auto certonly --webroot -w /var/www/lexg.nl/htdocs/ -d lexg.nl -d www.lexg.nl --email MYEMAIL@gmail.com --text --agree-tos
2018-02-28 07:53:51,556 (DEBUG) ee : Command Output: ,
Command Error: Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
An unexpected error occurred:
There were too many requests of a given type :: Error creating new authz :: too many failed authorizations recently: see Rate Limits - Let's Encrypt
Please see the logfiles in /var/log/letsencrypt for more details.

2018-02-28 07:53:51,557 (ERROR) ee : Unable to setup, Let's Encrypt
2018-02-28 07:53:51,557 (ERROR) ee : Please make sure that your site is pointed to
same server on which you are running Let's Encrypt Client
to allow it to verify the site automatically.

Output letsencrypt log:

2018-02-28 07:53:51,296:DEBUG:acme.client:JWS payload:
{
"identifier": {
"type": "dns",
"value": "MYSITE.NL"
},
"resource": "new-authz"
}
2018-02-28 07:53:51,302:DEBUG:acme.client:Sending POST request to https://acme-v01.api.letsencrypt.org/acme/new-authz:
{
"protected": "eyJub25jZSI6ICJ2aWpIZUJiUGN1YXh0bTV4b20xWGJrdHlHbEtLTVB4ZTZGUEhlVGNvSllnIiwgImFsZyI6ICJSUzI1NiIsICJqd2siOiB7ImUiOiAiQVFBQiIsICJrdHkiOiAiUlNBI
iwgIm4iOiAidGdaZ1M4RUsyRWVPbU9hX0oxWmJpaUVMdmxwd1gta0lUMjVOb0g5Sm9NalhjTzM0emNCb0wtYUU3OWpaUzY1TVNiOTUwYkJvZjJJTTdFLVB4R1EybEl3azk4ZHdlUV9BU2J3QjYwTzcya05WTk
t2OUFNc3VtdmMtSGNXVW1tbE8xUVotV01VcXZsUl9HVDd2V3FQemI2OS1GZGUtSFZ4aWdJRkRZcGd2cEQ4eEVBWGR0Ymgxem9uNENKVzIxcS15T3QweTBlQ2xBeUdGZmx3cWg5SFZCdnhUNEtUQ25LZEVMd2d
3TzNPTTI5Mi1vZzVEN05NRFJ0S2MxLWc4aUp0cU05Z1R0bFhmYmsybTBaWWZZellZNWg5a0IwNktKYUZHanJEMGhlYlI1bkplM1A1ZzZNUERJWklDNkFEVXYxd29GQjdKWUZLbnRFdDdLMEtPOTlnemdRIn19
",
"payload": "ewogICJpZGVudGlmaWVyIjogewogICAgInR5cGUiOiAiZG5zIiwgCiAgICAidmFsdWUiOiAibGV4Zy5ubCIKICB9LCAKICAicmVzb3VyY2UiOiAibmV3LWF1dGh6Igp9",
"signature": "mWksj75q39-gsrM2X1G6VnfNzqJy51mQHBVmEL5weaxwcbVOPeDIfxg-2MLZ5z1V37oPw8U4HFVjbFyD8O4YdB4b_uBlbLaCrO1jLc1SYpf8V9yCNiXyzFIUOBpvisrGoBTCnjHiuU8cS
2xaNbN9stHPy5ByS5ltXshygDw_QjMRuroRSzogcSjlVO2DCaUhXO02O832i5t1EegzwsY49gIGRA9cOLreOSk1DwphXMxcdZL6ArYfQZuzlrZaTzZmYknZdpQCBtHBj_8ewb8d8ulrMGcauQJ6FvBqeTt60A
F7zi7UqddpYGY3Jr_300AhhfnuAAP4uqt_Kai0tqmlBA"
}
2018-02-28 07:53:51,512:DEBUG:requests.packages.urllib3.connectionpool:https://acme-v01.api.letsencrypt.org:443 "POST /acme/new-authz HTTP/1.1" 429 189
2018-02-28 07:53:51,513:DEBUG:acme.client:Received response:
HTTP 429
Server: nginx
Content-Type: application/problem+json
Content-Length: 189
Boulder-Requester: 28777194
Replay-Nonce: 2pN0cOWgjkEvgEQhiQj3sW1vQExU8CCq-lpFAh3wqU0
Expires: Wed, 28 Feb 2018 07:53:51 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Wed, 28 Feb 2018 07:53:51 GMT
Connection: close

{
"type": "urn:acme:error:rateLimited",
"detail": "Error creating new authz :: too many failed authorizations recently: see Rate Limits - Let's Encrypt",
"status": 429
}
2018-02-28 07:53:51,514:DEBUG:acme.client:Storing nonce: 2pN0cOWgjkEvgEQhiQj3sW1vQExU8CCq-lpFAh3wqU0
2018-02-28 07:53:51,514:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
File "/opt/eff.org/certbot/venv/bin/letsencrypt", line 11, in
sys.exit(main())
File "/opt/eff.org/certbot/venv/local/lib/python2.7/site-packages/certbot/main.py", line 1240, in main

[_az]

The failed authorization rate limit is 5 per hour. So you can try again soon.

@lexg

./letsencrypt-auto certonly --webroot -w /var/www/lexg.nl/htdocs/ -d lexg.nl -d www.lexg.nl

In the meantime, Digital Marketing Strategy for Entrepreneurs is giving a 404.

So in the meantime you will want to figure out why the webroot that EE is passing to Let's Encrypt (/var/www/lexg.nl/htdocs/) doesn't seem to correlate with what document root is used when actually visiting the domain.

[lexg]

Thanks … that’s very odd though … If I look at the nginx.conf it says that root is : root /var/www/lexg.nl/htdocs;

Might this be a permission issue ?

[_az]

I don’t think permission issues would manifest in a 404.

Could you try:

mkdir -p  /var/www/lexg.nl/htdocs/.well-known/acme-challenge/
touch  /var/www/lexg.nl/htdocs/.well-known/acme-challenge/test.txt

and see if that makes http://lexg.nl/.well-known/acme-challenge/test.txt appear?

[lexg]

@_az

Digital Marketing Strategy for Entrepreneurs

yes it does ... It seems like no files are written to the acme-challenge folder while trying to fetch the certificate .. (at least that's what my logic tells me ... and that might be off) ...

Maybe I should wait and try when the rate limit is reset ...

[_az]

@lexg

yes it does

Over IPv4, yeah. Not over IPv6:

$ curl -6 -i http://lexg.nl/.well-known/acme-challenge/test.txt
HTTP/1.1 404 Not Found
Server: nginx
Date: Wed, 28 Feb 2018 09:14:57 GMT
Content-Type: text/html
Content-Length: 162
Connection: keep-alive
Vary: Accept-Encoding

<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

Your nginx virtualhost for that domain looks like it's only bound to IPv4. You need to tell nginx to also respond on IPv6 for that virtualhost, or withdraw the AAAA record for the domain.

Let's Encrypt will always prefer the AAAA record for a domain, if it exists.

[lexg]

That’s a good catch … however surprising … why didn’t I have this problem with the other domain that points to the same server you think ?

After I try some things I will let you know if it worked …

[lexg]

Thanks _az … I removed the IPv6 records in CF dns … and ofcourse it worked now …

Turns out that EE doesn’t configure for IPv6 automatically and at the same time I always enter the AAAA records as well …

That means that I should remove them for other sites as well I think, no ? Since the auto renewal will then try to fetch over IPv6 ?

Lex

[_az]

Well, I guess one way to approach it would be to decide whether you care about IPv6 access.

If you do, make sure the virtual hosts work over IPv6.

If not, there’s no point advertising AAAA records, as it just creates the possibility that IPv6-enabled visitors will be greeted with a broken site.

[lexg]

For simplicity … I will just use Ipv4 … we’ll see what happens in a few years … many thanks for your help again … it would have taken me a few days to figure that one out (as simple as it was) … You saved me alot of time here …thanks !