# Enabling Letsencrypt fails

**URL:** https://discourse.roots.io/t/enabling-letsencrypt-fails/6446
**Category:** trellis
**Created:** 2016-04-12T14:26:57Z
**Posts:** 6

## Post 1 by @jurgenv — 2016-04-12T14:26:58Z

Hi everyone,

For some reason I had to disable SSL. Now, when I’m trying to get it up and running again, I get the error below. The message suggests that I should check the DNS records. They’re fine, since I had Let’s Encrypt working just days ago.

Can someone explain this to me?

> failed: [dev.xxx.nl] =\> (item={u’stdout’: u’404’, u’cmd’: [u’curl’, u’-s’, u’-o’, u’/dev/null’, u’-w’, u’%{http\_code}‘, u’[http://dev.xxx.nl/.well-known/acme-challenge/ping.txt](http://dev.xxx.nl/.well-known/acme-challenge/ping.txt)’], u’end’: u’2016-04-12 14:19:24.389636’, ‘\_ansible\_no\_log’: False, u’warnings’: , u’changed’: False, u’start’: u’2016-04-12 14:19:24.229176’, u’delta’: u’0:00:00.160460’, ‘item’: [{u’multisite’: {u’enabled’: True, u’subdomains’: True}, u’env’: {u’domain\_current\_site’: u’dev.xxx.nl’, u’db\_user’: u’medialog\_user’, u’disable\_wp\_cron’: True, u’wp\_siteurl’: u’[https://dev.xxx.nl/wp](https://dev.xxx.nl/wp)’, u’db\_name’: u’medialog\_staging’, u’wp\_env’: u’staging’, u’wp\_home’: u’[https://dev.xxx.nl](https://dev.xxx.nl)’}, u’cache’: {u’duration’: u’30s’, u’enabled’: False}, u’repo’: u’git@bitbucket.org:xxx.git’, u’ssl’: {u’enabled’: True, u’provider’: u’letsencrypt’}, u’local\_path’: u’…/medialog-multisite’, u’branch’: u’master’}, u’dev.xxx.nl’], u’rc’: 0, ‘invocation’: {‘module\_name’: u’command’, u’module\_args’: {u’creates’: None, u’executable’: None, u’chdir’: None, u’\_raw\_params’: u’curl -s -o /dev/null -w “%{http\_code}” [http://dev.xxx.nl/.well-known/acme-challenge/ping.txt](http://dev.xxx.nl/.well-known/acme-challenge/ping.txt)’, u’removes’: None, u’warn’: False, u’\_uses\_shell’: False}}, ‘stdout\_lines’: [u’404’], u’stderr’: u’'}) =\> {“failed”: true, “item”: {“\_ansible\_no\_log”: false, “changed”: false, “cmd”: [“curl”, “-s”, “-o”, “/dev/null”, “-w”, “%{http\_code}”, “[http://dev.xxx.nl/.well-known/acme-challenge/ping.txt](http://dev.xxx.nl/.well-known/acme-challenge/ping.txt)”], “delta”: “0:00:00.160460”, “end”: “2016-04-12 14:19:24.389636”, “invocation”: {“module\_args”: {“\_raw\_params”: “curl -s -o /dev/null -w "%{http\_code}" [http://dev.xxx.nl/.well-known/acme-challenge/ping.txt](http://dev.xxx.nl/.well-known/acme-challenge/ping.txt)”, “\_uses\_shell”: false, “chdir”: null, “creates”: null, “executable”: null, “removes”: null, “warn”: false}, “module\_name”: “command”}, “item”: [{“branch”: “master”, “cache”: {“duration”: “30s”, “enabled”: false}, “env”: {“db\_name”: “medialog\_staging”, “db\_user”: “medialog\_user”, “disable\_wp\_cron”: true, “domain\_current\_site”: “dev.xxx.nl”, “wp\_env”: “staging”, “wp\_home”: “[https://dev.xxx.nl](https://dev.xxx.nl)”, “wp\_siteurl”: “[https://dev.xxx.nl/wp](https://dev.xxx.nl/wp)”}, “local\_path”: “…/medialog-multisite”, “multisite”: {“enabled”: true, “subdomains”: true}, “repo”: “[git@bitbucket.org](mailto:git@bitbucket.org):xxx.git”, “ssl”: {“enabled”: true, “provider”: “letsencrypt”}}, “dev.xxx.nl”], “rc”: 0, “start”: “2016-04-12 14:19:24.229176”, “stderr”: “”, “stdout”: “404”, “stdout\_lines”: [“404”], “warnings”: }, “msg”: “Could not access the challenge file for the domain: dev.xxx.nl. Let’s Encrypt requires every domain/host be publicly accessible. Make sure that a valid DNS record exists for dev.xxx.nl and that it points to this server’s IP. If you don’t want this domain in your SSL certificate, then remove it from `site_hosts`. See [https://roots.io/trellis/docs/ssl](https://roots.io/trellis/docs/ssl) for more details.\n”}

---

## Post 2 by @swalkinshaw — 2016-04-12T14:29:35Z

Sounds like you’re running into the same issue as this thread: [LetsEncrypt Acme Challenge error](https://discourse.roots.io/t/letsencrypt-acme-challenge-error/6295/2?u=swalkinshaw)

See my solution there.

---

## Post 3 by @jurgenv — 2016-04-12T14:55:23Z

That doesn’t seem to work for me. Removing my site.conf only gave the same error, removing the no\_default.conf as well gives me a new error. (Just so you know: I have only a very basic understanding of nginx etc.)

> failed: [dev.xxx.nl] =\> (item=({u’multisite’: {u’enabled’: True, u’subdomains’: True}, u’env’: {u’domain\_current\_site’: u’dev.xxx.nl’, u’db\_user’: u’medialog\_user’, u’disable\_wp\_cron’: True, u’wp\_siteurl’: u’[https://dev.xxx.nl/wp](https://dev.xxx.nl/wp)’, u’db\_name’: u’medialog\_staging’, u’wp\_env’: u’staging’, u’wp\_home’: u’[https://dev.xxx.nl](https://dev.xxx.nl)’}, u’cache’: {u’duration’: u’30s’, u’enabled’: False}, u’repo’: u’git@bitbucket.org:reconcept/medialog-multisite.git’, u’ssl’: {u’enabled’: True, u’provider’: u’letsencrypt’}, u’local\_path’: u’…/medialog-multisite’, u’branch’: u’master’}, u’dev.xxx.nl’)) =\> {“changed”: false, “cmd”: [“curl”, “-s”, “-o”, “/dev/null”, “-w”, “%{http\_code}”, “[http://dev.xxx.nl/.well-known/acme-challenge/ping.txt](http://dev.xxx.nl/.well-known/acme-challenge/ping.txt)”], “delta”: “0:00:00.068572”, “end”: “2016-04-12 14:52:38.782318”, “failed”: true, “item”: [{“branch”: “master”, “cache”: {“duration”: “30s”, “enabled”: false}, “env”: {“db\_name”: “medialog\_staging”, “db\_user”: “medialog\_user”, “disable\_wp\_cron”: true, “domain\_current\_site”: “dev.xxx.nl”, “wp\_env”: “staging”, “wp\_home”: “[https://dev.xxx.nl](https://dev.xxx.nl)”, “wp\_siteurl”: “[https://dev.xxx.nl/wp](https://dev.xxx.nl/wp)”}, “local\_path”: “…/medialog-multisite”, “multisite”: {“enabled”: true, “subdomains”: true}, “repo”: “[git@bitbucket.org](mailto:git@bitbucket.org):reconcept/medialog-multisite.git”, “ssl”: {“enabled”: true, “provider”: “letsencrypt”}}, “dev.xxx.nl”], “rc”: 52, “start”: “2016-04-12 14:52:38.713746”, “stderr”: “”, “stdout”: “000”, “stdout\_lines”: [“000”], “warnings”: }

---

## Post 4 by @jurgenv — 2016-04-12T14:57:03Z

Heck, the other solution suggested in that thread does work: reversing the order of the server.yml tasks!

---

## Post 5 by @MWDelaney — 2016-04-13T14:18:05Z

I also ran into this problem. The site is relatively young and unvisited so I just rebuilt my droplet and re-provisioned, but I imagine as LetsEncrypt catches on, more and more users will want to reprovision existing servers to add SSL --is this something Trellis could support in the future?

---

## Post 6 by @fullyint — 2016-04-16T01:02:39Z

> [@Let's Encrypt: Could not access the challenge file for the hosts/domain](https://discourse.roots.io/t/lets-encrypt-could-not-access-the-challenge-file-for-the-hosts-domain/6457/11):
>
> [roots/trellis#565](https://github.com/roots/trellis/pull/565/) enables Trellis to transition existing `http` sites to `https`. This update may resolve some issues that led to the error message `Could not access the challenge file`
> 
> **Existing servers.** If you try the Trellis update above on a server that has already been provisioned with the prior version of Trellis (i.e., on a server that already has an Nginx conf set up), you should first run:
> 
> ```
> ansible-playbook server.yml -e env=<environment> --tags wordpress
> ```
> 
> That sets up an Nginx conf that will help with the next step of running the `letsencrypt` role:
> 
> ```
> ansible-playbook server.yml -e env=<environment> --tags letsencrypt
> ```
> 
> **New servers.** Just to be clear, for fresh/new servers, you can just run the regular command once:
> 
> ```
> ansible-playbook server.yml -e env=<environment>
> ```

(20 characters for discourse)