# Letsencrypt error on 'Generate the initial certificate'

**URL:** https://discourse.roots.io/t/letsencrypt-error-on-generate-the-initial-certificate/6299
**Category:** trellis
**Created:** 2016-03-26T22:55:49Z
**Posts:** 8

## Post 1 by @vdrnn — 2016-03-26T22:55:49Z

I’m trying add letsencrypt to my staging environment.

Here’s what I did:

```
ssl:
  enabled: true
```

```
env:
  wp_home: https://staging.mydomain.com
  wp_siteurl: https://staging.mydomain.com/wp
```

Then I run `vagrant provision` which runs through without error.  
Afterwards I run `ansible-playbook server.yml -e env=staging` where I get the following error:

```
TASK [letsencrypt : Generate the initial certificate] **************************
fatal: [46.101.238.145]: FAILED! => {"changed": false, "cmd": ["./renew-certs.py"], "delta": "0:00:04.450153", "end": "2016-03-26 22:35:19.067992", "failed": true, "rc": 1, "start":
 "2016-03-26 22:35:14.617839", "stderr": "", "stdout": "Generating certificate for staging.mydomain.com\nError while generating certificate for staging.mydomain.com\nParsing acc
ount key...\nParsing CSR...\nRegistering account...\nRegistered!\nVerifying staging.mydomain.com...\nstaging.mydomain.com verified!\nVerifying 46.101.238.145...\nTraceback (most
 recent call last):\n File \"/usr/local/letsencrypt/acme_tiny.py\", line 198, in <module>\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 104, in get_crt\n raise ValueE
rror(\"Error requesting challenges: {0} {1}\".format(code, result))\nValueError: Error requesting challenges: 400 {\"type\":\"urn:acme:error:malformed\",\"detail\":\"Error creating
new authz :: Issuance for IP addresses not supported\",\"status\":400}", "stdout_lines": ["Generating certificate for staging.mydomain.com", "Error while generating certificate fo
r staging.mydomain.com", "Parsing account key...", "Parsing CSR...", "Registering account...", "Registered!", "Verifying staging.mydomain.com...", "staging.mydomain.com verifi
ed!", "Verifying 46.101.238.145...", "Traceback (most recent call last):", " File \"/usr/local/letsencrypt/acme_tiny.py\", line 198, in <module>", " 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/let
sencrypt/acme_tiny.py\", line 104, in get_crt", " raise ValueError(\"Error requesting challenges: {0} {1}\".format(code, result))", "ValueError: Error requesting challenges: 400
{\"type\":\"urn:acme:error:malformed\",\"detail\":\"Error creating new authz :: Issuance for IP addresses not supported\",\"status\":400}"], "warnings": []}
```

I’m running a basic DO server with Ubuntu 14.04 which I also destroyed and loaded from scratch in order to eliminate any problems, but no luck.

My DNS entry for the staging subdomain looks like this `staging.mydomain.com. 1800 IN A xx.xxx.xxx.xxx`

---

## Post 2 by @fullyint — 2016-03-26T23:17:18Z

@vdrnn Given part of the error that says `Issuance for IP addresses not supported`, I suspect you may have an IP listed in [`site_hosts`](https://github.com/roots/trellis/blob/baffeb7684f74ef2aa39ac0c2e2d1bb2d71cc7fb/group_vars/staging/wordpress_sites.yml#L4). If so, you could remove the IP and try again. I don’t think we tested what would happen if IP was included because [IP was removed from `site_hosts`](https://github.com/roots/trellis/commit/3533d753b9b206834bec88438a9cbcbca59fac3e) about a year ago.

Once you remove the IP and reprovision (rerun `server.yml`), Nginx will not serve the site from the IP (only from the domain name). If you find yourself wanting the site served from the IP, see if this other thread has any helpful info for how to use the domain instead:

> [@err_empty_response](https://discourse.roots.io/t/err-empty-response/6225/4):
>
> Normally before I would put a site live, I want to have it running on an IP to test and show clients (after the local build). What would be your workflow to test a site live without having to use the actual domain?

---

## Post 3 by @vdrnn — 2016-03-27T08:38:07Z

Problem solved, thanks a lot for the quick reply @fullyint! :beers:

---

## Post 4 by @masoninthesis — 2016-04-06T20:11:12Z

Hey @fullyint,

I’m trying out letsencrypt for the first time. Ran into the error above ^ for the same reason. `site_hosts` was an IP address.

I tried your advice in the thread you linked for using a hostname instead of an IP. Adding `IP domain.com` to `etc/hosts`. If I read it correctly, you don’t need DNS setup to pull that off. It kind of tricks your computer?

After changing `site_hosts` and `trellis/hosts/staging` I get this error:

`TASK [letsencrypt : Test Acme Challenges] ************************************** failed: [sideshed.com] => (item=sideshed.com) => {"changed": false, "failed": true, "failed_hosts": ["sideshed.com", "www.sideshed.com"], "item": "sideshed.com", "rc": 1} ...ignoring`

`TASK [letsencrypt : Notify of challenge failures] ****************************** Could not access the challenge file for the hosts/domains: sideshed.com, www.sideshed.com. Let's Encrypt requires every domain/host be publicly accessible. Make sure that a valid DNS record exists for sideshed.com, www.sideshed.com and that they point to this server's IP. If you don't want these domains in your SSL certificate, then remove them from site_hosts. See https://roots.io/trellis/docs/ssl for more details.`

`failed: [sideshed.com] => (item=sideshed.com) => {"failed": true, "item": "sideshed.com"}`

Obviously it seems like it wants a DNS setup. Is that a bug or am I just misunderstanding the process you laid out?

---

## Post 5 by @ben — 2016-04-06T20:31:26Z

Let’s Encrypt relies on DNS working and pointing to your server in order to get a certificate.

```
Could not access the challenge file for the hosts/domains: sideshed.com,
www.sideshed.com. Let's Encrypt requires every domain/host be publicly
accessible. Make sure that a valid DNS record exists for sideshed.com,
www.sideshed.com and that they point to this server's IP.
```

---

## Post 6 by @fullyint — 2016-04-06T20:34:10Z

Edit. Oh, Ben beat me to it. I’ll go ahead and post what I had typed anyway.

To use Let’s Encrypt, you’ll need to use a domain that _does_ have DNS set up. Let’s Encrypt won’t issue a cert for an IP. Let’s Encrypt will only issue a cert after verifying it can access specific content on your site, a process which requires DNS.

In the original issue of this thread, the error was `"Verifying staging.mydomain.com...", "staging.mydomain.com verified!", "Verifying 46.101.238.145...", "Traceback...`. So, the user had both a domain and IP in `site_hosts`. With a real domain in the list – which presumably had DNS set up – it was fine to just remove the IP.

When I said…

> If you find yourself wanting the site served from the IP, see if [this other thread](https://discourse.roots.io/t/err-empty-response/6225/4) has any helpful info for how to use the domain instead

…that other thread was mostly suggesting how to “use the domain instead” of the IP, serving the staging site from a subdomain `staging.example.com`.

As an aside I mentioned modifying `/etc/hosts` but pointed out that doing so only affects the local machine’s ability to view a site at a domain name. It is insufficient as a way to make the Let’s Encrypt process work for a domain without DNS.

So, Let’s Encrypt won’t work for an IP/domain without DNS. If it turns out you’re really just after ssl and have some reason not to set up a domain with DNS, maybe it would work to make the edit in `/etc/hosts` then set the [`ssl.provider`](https://roots.io/trellis/docs/ssl/#self-signed) to `self-signed`. I haven’t tried this, nor have I taken time to think it through.

So, to be clear, I’d recommend just setting up a domain or subdomain with DNS, instead of modifying your `/etc/hosts`.

---

## Post 7 by @masoninthesis — 2016-04-06T21:21:20Z

Gotcha, that makes sense. That was the idea I was gathering from the error logs and Trellis docs.

I think the obvious solution for me right now is to keep SSL false on my staging (which I’d prefer to be an IP for the moment) and just enable it on production which will deploy to an fqdn.

Thanks for making that clear!

---

## Post 8 by @daadir — 2016-11-09T22:48:55Z

Can you please help me [and possibly others] understand the proper way to approach this with the productions environment?

I am moving an existing site to trellis, but wouldnt want to change DNS records before the site is fully up and ready. Meaning with a valid SSL cert.

My staging env was on a subdomain so i hadnt any issues [with an IP btw!], how should i approach the production server?