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:
- Don’t delete
/etc/nginx/ssl/letsencrypt/example.com.key
! - DO Server backups may well be worth paying for (I had a snapshot by luck)
- Set
ssl
to false, runningwordpress
tagged tasks, and possibly justletsencrypt
tasks - Now set
ssl
back to true - 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.
@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:
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.
@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.