Roots Discourse

Let's Encrypt error generating certificates


#1

When I modified my wordpress_sites.yml file by adding www redirects, I get an error when I tried provisioning with the command ansible-playbook server.yml -e env=production.

wordpress_sites:
 "MY_NON_WWW_SITE":
 site_hosts:
 - canonical: "MY_NON_WWW_SITE"
 redirects://<------Added this line
 - **MY_WWW_SITE**//<------Added this line
 local_path: ../site # path targeting local Bedrock site directory (relative to Ansible root)
 repo: "MY_GIT_REPO_URL"# replace with your Git repo URL
 repo_subtree_path: site # relative path to your Bedrock/WP directory in your repo
 branch: master
 multisite:
 enabled: false
 ssl:
 enabled: true
 provider: letsencrypt
 cache:
 enabled: true

The error I got was:

non-zero return code

fatal: [165.227.169.116]: FAILED! => {“changed”: false, “cmd”: ["./renew-certs.py"], “delta”: “0:00:02.302412”, “end”: “2017-12-10 18:39:12.997138”, “failed”: true, “rc”: 1, “start”: “2017-12-10 18:39:10.694726”, “stderr”: “”, “stderr_lines”: [], “stdout”: “Generating certificate for MY_NON_WWW_SITE\nError while generating certificate for MY_NON_WWW_SITE\nTraceback (most recent call last):\n File “/usr/local/letsencrypt/acme_tiny.py”, line 198, in \n main(sys.argv[1:])\n File “/usr/local/letsencrypt/acme_tiny.py”, line 194, in main\n signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)\n File “/usr/local/letsencrypt/acme_tiny.py”, line 123, in get_crt\n wellknown_path, wellknown_url))\nValueError: Wrote file to /srv/www/letsencrypt/YKfZ9QrJMgu_iD5bD_GR1h6KPUHSoh3K3VympkbsQuw, but couldn’t download MY_WWW_SITE/.well-known/acme-challenge/YKfZ9QrJMgu_iD5bD_GR1h6KPUHSoh3K3VympkbsQuw”, “stdout_lines”: [“Generating certificate for MY_NON_WWW_SITE”, “Error while generating certificate for MY_NON_WWW_SITE”, “Traceback (most recent call last):”, " File “/usr/local/letsencrypt/acme_tiny.py”, line 198, in “, " main(sys.argv[1:])”, " File “/usr/local/letsencrypt/acme_tiny.py”, line 194, in main", " signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)", " File “/usr/local/letsencrypt/acme_tiny.py”, line 123, in get_crt", " wellknown_path, wellknown_url))", “ValueError: Wrote file to /srv/www/letsencrypt/YKfZ9QrJMgu_iD5bD_GR1h6KPUHSoh3K3VympkbsQuw, but couldn’t download MY_WWW_SITE/.well-known/acme-challenge/YKfZ9QrJMgu_iD5bD_GR1h6KPUHSoh3K3VympkbsQuw”]}

This never happened before with other sites I setup before. The issue seems to be with Let’s Encrypt having issues with generating certificates. I’m using Cloudflare’s free DNS plan and Digital Ocean for hosting.


#2

Does the www record point to the same IP as your non-www record?


#3

I did a ping test and they seem to point to different IPs. I’m using cloudflare and tried adding a Type A www record to point to my non-www record’s IP, but it wouldn’t let me. I get an error that says A CNAME already exists with that host. (Code: 81054) when I tried adding a Type A www record that points to my non-www record’s IP.


#4

That’s definitely the problem then.


#5

I’m facing the exact same problem now. The www record points to an ip address of a dns server which is different from my digital ocean ip address.

The above issue is causing let’s encrypt to fail. How can I resolve this? I’m not able to match the ip addresses of both records.


#6

You can remove the www redirect from wordpress_site.yml (see here). This will stop Trellis from including “www” in the certificate request.


#7

That unfortunately did not solve the problem. This is the entire error message:

non-zero return code
fatal: [188.166.74.85]: FAILED! => {“changed”: false, “cmd”: ["./renew-certs.py"], “delta”: “0:00:04.114761”, “end”: “2018-10-17 14:04:26.410384”, “rc”: 1, “start”: “2018-10-17 14:04:22.295623”, “stderr”: “”, “stderr_lines”: [], “stdout”: “Generating certificate for MYSITE.NL\nError while generating certificate for MYSITE.NL\nTraceback (most recent call last):\n File “/usr/local/letsencrypt/acme_tiny.py”, line 198, in \n main(sys.argv[1:])\n File “/usr/local/letsencrypt/acme_tiny.py”, line 194, in main\n signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)\n File “/usr/local/letsencrypt/acme_tiny.py”, line 149, in get_crt\n domain, challenge_status))\nValueError: MYSITE.NL challenge did not pass: {u’status’: u’invalid’, u’validationRecord’: [{u’url’: u’http://MYSITE.NL/.well-known/acme-challenge/1mjCT8uANy7j6oes02UrEJ9HQiKk_cX-uKBvBdFa9T4’, u’hostname’: u’MYSITE.NL’, u’addressUsed’: u’2a02:2268:ffff:ffff::4’, u’port’: u’80’, u’addressesResolved’: [u’188.166.74.85’, u’2a02:2268:ffff:ffff::4’]}], u’uri’: u’https://acme-v01.api.letsencrypt.org/acme/challenge/SccUvMGW32kteEedCfYxvW_BDG-G14OWDSzwy21iQqQ/8376787436’, u’token’: u’1mjCT8uANy7j6oes02UrEJ9HQiKk_cX-uKBvBdFa9T4’, u’error’: {u’status’: 403, u’type’: u’urn:acme:error:unauthorized’, u’detail’: u’Invalid response from http://MYSITE.NL/.well-known/acme-challenge/1mjCT8uANy7j6oes02UrEJ9HQiKk_cX-uKBvBdFa9T4: “\\n\\n404 Not Found\\n\\n

Not Found

\\n<p”’}, u’type’: u’http-01’}”, “stdout_lines”: [“Generating certificate for MYSITE.NL”, “Error while generating certificate for MYSITE.NL”, “Traceback (most recent call last):”, " File “/usr/local/letsencrypt/acme_tiny.py”, line 198, in “, " main(sys.argv[1:])”, " File “/usr/local/letsencrypt/acme_tiny.py”, line 194, in main", " signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca)", " File “/usr/local/letsencrypt/acme_tiny.py”, line 149, in get_crt", " domain, challenge_status))", “ValueError: MYSITE.NL challenge did not pass: {u’status’: u’invalid’, u’validationRecord’: [{u’url’: u’http://MYSITE.NL/.well-known/acme-challenge/1mjCT8uANy7j6oes02UrEJ9HQiKk_cX-uKBvBdFa9T4’, u’hostname’: u’MYSITE.NL’, u’addressUsed’: u’2a02:2268:ffff:ffff::4’, u’port’: u’80’, u’addressesResolved’: [u’188.166.74.85’, u’2a02:2268:ffff:ffff::4’]}], u’uri’: u’https://acme-v01.api.letsencrypt.org/acme/challenge/SccUvMGW32kteEedCfYxvW_BDG-G14OWDSzwy21iQqQ/8376787436’, u’token’: u’1mjCT8uANy7j6oes02UrEJ9HQiKk_cX-uKBvBdFa9T4’, u’error’: {u’status’: 403, u’type’: u’urn:acme:error:unauthorized’, u’detail’: u’Invalid response from http://MYSITE.NL/.well-known/acme-challenge/1mjCT8uANy7j6oes02UrEJ9HQiKk_cX-uKBvBdFa9T4: “\\n\\n404 Not Found\\n\\n

Not Found

\\n<p”’}, u’type’: u’http-01’}”]}

Maybe somebody can help me out.


#8

Is “mysite.nl” your actual URL, or did you replace that in your error message to hide your URL?

If “mysite.nl” is not your actual URL, and it’s entered in wordpress_sites.yml then Let’s Encrypt won’t work correctly. It needs to know your real URL.


#9

mysite.nl is not the actual url of the website. I replaced it.

The URL matches what is entered in wordpress_sites.yml


#10

The error you received indicates that Let’s Encrypt can’t access your site at the domain you’ve told it your site is on.

Is mysite.nl (or its real URL) accessible? Has DNS recently changed and not yet propagated?


#11

It’s definitely a DNS issue. When I run ping mysite.nl on my server where I’m trying to install the website it says: PING mysite.nl (127.0.1.1) 56(84) bytes of data. the 127.0.1.1 indicates that it’s localhost right?

When I run PING www.mysite.nl it actually returns the correct ip: PING mysite.nl (188.166.74.85) 56(84) bytes of data.

If I ping mysite.nl on my local computer it does return 188.166.74.85.

Does this mean that the DNS changes still have to propagate on the server?


#12

This is normal. Your server refers to itself using local terms. What matters is how your computer, and other computers on the internet (like Let’s Encrypt’s servers), refer to it.

When I run PING www.mysite.nl it actually returns the correct ip: PING mysite.nl (188.166.74.85) 56(84) bytes of data.

This is great, but I thought you said the www record was not usable on this site because it pointed somewhere else? If it points to your server’s correct IP then there’s no need to remove the redirect in wordpress_sites.yml as I suggested here.

If I ping mysite.nl on my local computer it does return 188.166.74.85 .

How recently did you change the DNS record here? The TTL on that DNS record is 14290, or 238 minutes, or around 4 hours. If you updated your DNS less than 4 hours ago then it’s normal for the records not to be working yet.

DNS can take up to 2 days to propagate fully.


#13

This is great, but I thought you said the www record was not usable on this site because it pointed somewhere else? If it points to your server’s correct IP then there’s no need to remove the redirect in wordpress_sites.yml as I suggested here.

Yeah I noticed that. It points to the right spot actually. My mistake. I restored the the www redirect in wordpress_sites.yml again.

Allright, I’ll wait a bit then and hope for the best! Thanks for your quick response @MWDelaney


#14

I had to turn off CloudFlare’s orange cloud to do my initial provision. Possibly because it masks the IP address which may be confusing LetsEncrypt?


#15

Does any of you know if it’s possible to generate the ssl certificates later? So I can continue the installation of trellis now?


#16

I think probably with

 ssl:
 enabled: false

Did you try turning the orange cloud to grey and provisioning?


#17

I’m not using cloudflare unfortunately.

So just disabling ssl for now and later on switch it on and re-provision the server? @ng3


#18

Oh, sorry @bramvdpluijm1, I didn’t realise you weren’t the OP. You might not even use CloudFlare…


#19

If your priority is to get the site up then that’s what I would do.

However it’s probably important to figure out what’s going on with your DNS as well… Do you have access to the DNS records?


#20

I’ve been spending a lot of hours on trying to get SSL working, but I think I’m just gonna get the site up and running without at first. The guy that’s in charge of the DNS says it’s all fine.
He sent me a few pictures because I was sceptic at first.

Maybe you can see something that looks off? Let me know. These are the domain name settings.

In my DigitalOcean droplet I have the following setup:

Any thoughts on this?