Could not access the challenge file for the hosts/domains: www.example.com

It would be great to avoid having to change the IP. There’s a bit of bureaucracy between us and the registrar.

To avoid that, I would delete any files in /etc/nginx/ssl/letsencrypt/ and /srv/www/letsencrypt, and any *.csr files in /var/lib/letsencrypt.

Then provision again (without any tags, so everything).

I’m running that now with -vvv and fingers crossed.

Same Error

Could not access the challenge file for the hosts/domains: www.example.com

Should the challenge file be trying to load over www?

    site_hosts:
      -
        canonical: example.com
        redirects:
          - www.example.com

Will probably provision a new server if this fails. For Ubuntu 20, should I use the master branch of Trellis? Maybe I should just stick with Ubuntu 18 for now.

I was able to restore the /etc/nginx/ssl/letsencrypt/example.com.key from a previous Snapshot.

Now getting a 200 on curl http://example.com/.well-known/acme-challenge/ping.txt -w "%{http_code}".

Going to try cycling ssl: false, ssl: true again.

Now getting:

non-zero return code
The required CSR file /var/lib/letsencrypt/csrs/phytrehab.com-3224635.csr
does not exist. This could happen if you changed site_hosts and have not yet
rerun the letsencrypt role. Create the CSR file by re-provisioning (running
the Trellis server.yml playbook) with `--tags letsencrypt`

The run:

ansible-playbook server.yml -e env=production --tags letsencrypt -vvv     

And back to this again:

Could not access the challenge file for the hosts/domains: www.example.com

Running curl without www succeeds, with www it fails (curl: (6) Could not resolve host).

When I run the wordpress tasks with ssl set to false, the browsers are still trying to load the site over https. Is that to be expected?

Interesting. Removed the www redirect from wordpress-sites.yml and got a lot further. on the letsencrypt tasks.

Failed at `non-zero return code
nginx: [emerg] "resolver" directive is duplicate in
/etc/nginx/h5bp/directive-only/ssl-stapling.conf:37
nginx: configuration file /etc/nginx/nginx.conf test failed.

Running it a second time seemed to succeed.

Then success with:

ansible-playbook server.yml -e env=production --tags wordpress -vvv

Sites not loading on front end, though. Trying to run letsencrypt tasks again with redirect reinstated.

Content of ssl-stapling.conf:

 23 ssl_stapling on;
 24 ssl_stapling_verify on;
 25 
 26 resolver
 27   # (1)
 28   1.1.1.1 1.0.0.1 [2606:4700:4700::1111] [2606:4700:4700::1001]
 29   # (2)
 30   8.8.8.8 8.8.4.4 [2001:4860:4860::8888] [2001:4860:4860::8844]
 31   # (3)
 32   # 216.146.35.35 216.146.36.36
 33   valid=60s;
 34 #trusted cert must be made up of your intermediate certificate followed by root certificate
 35 #ssl_trusted_certificate /path/to/ca.crt;
 36 
 37 resolver 8.8.8.8 8.8.4.4 216.146.35.35 216.146.36.36 valid=60s;
 38 resolver_timeout 2s;

Commenting out line 37 seems to have solved that issue.

So for others with same issue (or next time I have it), I guess I would say:

  1. Don’t delete /etc/nginx/ssl/letsencrypt/example.com.key!
  2. DO Server backups may well be worth paying for (I had a snapshot by luck)
  3. Set ssl to false, running wordpress tagged tasks, and possibly just letsencrypt tasks
  4. Now set ssl back to true
  5. Removing redirects from site hosts may also help, particularly if it’s one of the redirects that is coming up in the error output.

Thanks for the time and input @swalkinshaw and @strarsis.

1 Like

@swalkinshaw Where on the server do the letsencrypt_contact_emails end up? I see that they are referenced by the python script that runs the renewal.

Be wary when setting the letsencrypt_contact_emails variable:

1 Like

I’m having trouble finding that file on the server. Do you know where it gets generated?

The GItHub search indeed seems to have issues finding some files,
it is in the Trellis repository however, as a template:

Thanks. I had found that template file, (and also see it geerated at shared/source/trellis/roles/letsencrypt/templates/renew-certs.py) but was thinking it is supposed to turn into a hard-coded script with the literal emails in it. No?

You have to apply the Trellis ansible playbook on the server for provisioning.
During provisioning this python script file is indeed generated and put onto the server so it can be regularly invoked (cron) for renewing the certificates via Let’s Encrypt.

Thank you. That’s what I thought. But where on the server is it put?

Trellis should place it under /var/lib/letsencrypt/renew-certs.py.
Note: You need root (sudo as the Trellis admin user) in order to list the directories and the file itself.

2 Likes

@mZoo were you just curious where it ended up? Just wondering… because it shouldn’t really matter. Or did you think it was causing an issue?

Curious, but more importantly wanting to confirm that the file is where and what it is supposed to be:

--contact mailto:still_employed@mzoo.org mailto:my_buddy@colleague.com mailto:worried.manager@owner.com 

Does that look right? No separator (aside from the whitespace) necessary in the python file?

Update

(Fairly confident this is correct)

Seeing now that

In roles/letsencrypt/defaults/main.yml locations/paths are configured

acme_tiny_software_directory: /usr/local/letsencrypt
acme_tiny_data_directory: /var/lib/letsencrypt
acme_tiny_challenges_directory: "{{ www_root }}/letsencrypt"

In roles/letsencrypt/tasks/certificates.yml the script is generated

- name: Generate certificate renewal script
  template:
    src: renew-certs.py
    dest: "{{ acme_tiny_data_directory }}/renew-certs.py"
    mode: 0700
  tags: [wordpress, wordpress-setup, wordpress-setup-nginx, nginx-includes]

In roles/letsencrypt/tasks/main.yml cron job/file is generated

- name: Install cronjob for key generation
  cron:
    cron_file: letsencrypt-certificate-renewal
    name: letsencrypt certificate renewal
    user: root
    job: cd {{ acme_tiny_data_directory }} && ./renew-certs.py ; /usr/sbin/service nginx reload
    day: "{{ letsencrypt_cronjob_daysofmonth }}"
    hour: "4"
    minute: "30"
    state: present

@mZoo sorry I’m a bit lost at this point. What’s the status at this point? If it’s not working, what the behaviour that you’re seeing?

No need to be sorry, @swalkinshaw. All is great. I had wanted to clarify where the LetsEncrypt emails ended up (and have).

Is there a recommended way to test that the renewal script is successfully provisioned and configured?

This topic was automatically closed after 42 days. New replies are no longer allowed.