Not sure if it’s related to the Firewall threads, I’m having a problem getting SSL certificates from LetsEncrypt. I can access the site fine. I’m not seeing the /srv/*/public/htdocs/.well-known/acme-challenge/ directory being created while it’s fetching the new certificate.
When running sudo sympl-ssl --verbose vps2-test.domain.tld
* Examining certificates for vps2-test.domain.tld
No valid certificate sets found.
Fetching a new certificate from LetsEncrypt.
!! Failed: execution expired
I don’t think this is related to the firewall issue, but instead it’s something you sometimes see on IPv6-only connections, as the old Ruby libraries which sympl-ssl uses don’t understand the situation.
There’s a helper wrapper script which should fix this (it adds an entry to /etc/hosts for the LE API), but it sounds like it may be misbehaving.
I’ll take a look ASAP.
Thanks, I’m not seeing anything about Lets Encrypt in the /etc/hosts.
What should happen is that it adds the entry and then removes it when it’s done - I should be able to get to the bottom of it pretty soon.
Thanks, the /etc/hosts file hasn’t changed since I setup the RPi (based on date modified).
I’ve not been able to replicate this fully, but have a theory.
@smsm1 Can you let me know the output of:
sympl-ip -a | grep -c '\.'
sudo ip route | grep -c default.*[0-9]\.
The wrapper script is looking for an IPv4 address on the server, and only updating /etc/hosts when it finds one. If you have another IPv4 address on the server, even if it’s not being used, it may wrongly think you’re not IPv6 only.
If that’s the case you probably won’t have a default route set, so checking for that should be a good alternative.
The output is:
1
sympl@vps2:/var/log$ sudo ip route | grep -c default.*[0-9]\.
[sudo] password for sympl:
1
sympl@vps2:/var/log$
The /etc/hosts file has the following IPv4 IPs, which I didn’t intentionally add, and if I remember right were there as part of the default install of the RPi OS:
10.74.1.37 rpi-1-9
10.74.1.38 rpi-1-9-gateway
127.0.0.1 localhost
Thanks!
I’ve managed to track the issue down, and map it out, and have logged an issue.
A fix is working it’s way though now, and should be available on testing for Stretch and Buster via a sympl update soon.
This has solved the issue and I’m now getting Applying IPv6 only workaround... at the start and Removed IPv6 only workaround at the end of running sudo sympl-ssl --verbose.
I’ve also had an issue with the following error: !! Failed: Error creating new registration :: email domain name does not end in a IANA suffix showing. The hostname command returns a .me.uk address which should be an IANA suffix.
Tracing through the code the Socket.gethostname is returning the correct hostname that I’m expecting for the host. However a few lines further on the line getaddrinfo = Socket.getaddrinfo(localhost, nil, nil, nil, Socket::SOCK_DGRAM, Socket::AI_CANONNAME | 0x0040), combined with the line further on to get the specific item in the array is returning rpi-1-9.
So 2 options, first is to manually specify the email in the config /srv/[domain]/config/ssl/letsencrypt/email, or as I have now done switch the order of the items /etc/hosts so that the hostname domain that I’m using with the FQDN IANA suffix is first which means that the above Socket.getaddrinfo uses the domain that I’m expecting. This second method also prevents issues for any future domains that are added.
The other thing that I’ve noticed is the www.* version of domains are checked even when there’s no DNS pointing to them. Should these be turned off in this scenario? Under Symbiosis with Bytemark the www. domain was automatically created and uploaded to the DNS even if you didn’t want it.
That’s coming from Let’s Encrypt, rather than being generated by sympl-ssl - it defaults to root@ the ‘default domain’, ie: the same domain which should be the result of hostname -a, but can end up getting confused in some situations - if that happens, add the relevant email address to config/ssl/letsencrypt/email and that will be used instead for the domain.
This will change when sympl-ssl is upgraded (including trying to retrieve certs for non-existent domains), as it’s getting a full refresh to use up-to-date functionality, so it won’t be a problem for too long.
I suspect the way I had setup the hostname of the machine was the underlying cause, as changing the order of the domains listed in /etc/hosts fixed the issue. The ruby code for determining the hostname seems to run twice looking for different info, which I won’t know enough about to fully understand.
Good to hear that’s it’s being revamped in the future.