But when it tests the domains, authorization procedure fails:
Installation succeeded.
Failed authorization procedure. fifty-fifty.me (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: Failed to connect to 149.202.47.62:443 for TLS-SNI-01 challenge, stairs.opendataquality.com (tls-sni-01): urn:acme:error:tls :: The server experienced a TLS error during domain verification :: Failed to connect to 149.202.47.62:443 for TLS-SNI-01 challenge
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: fifty-fifty.me
Type: tls
Detail: Failed to connect to 149.202.47.62:443 for TLS-SNI-01
challenge
Domain: stairs.opendataquality.com
Type: tls
Detail: Failed to connect to 149.202.47.62:443 for TLS-SNI-01
challenge
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
you have an up-to-date TLS configuration that allows the server to
communicate with the Certbot client.
Both sites are online, and ports 80 and 443 are open both ways on the server.
What could be the issue ?
+1, same here. I can add that even adding the switch “certonly” fails the same way - I had imagined that “certonly” would not do the validation?
The error type urn:acme:error:tls usually means that the CA server doesn't like your TLS configuration for some reason, for example because there's no matching cipher between the server and the client. SSL Labs shows a couple of issues with your cipher list, so the first thing I'd recommend is using Mozilla's SSL configuration generator to get a better cipher list (SSLCipherSuite) for your existing TLS configuration in apache. If that doesn't resolve your issue, I can see if I can get more error details out of a local boulder instance (that's the CA server software), though that'll take until tomorrow as I currently don't have access to my test instance.
The difference between certonly and --apache is basically that the former only provides you with a set of files (certificates and keys), while the latter also attempts to automatically configure apache to use those files. Domain Validation will always have to be performed, otherwise you could get a valid certificate for any domain on the internet. There are different types of validation (HTTP-01, e.g. with --webroot, TLS-SNI-01, e.g. with --apache or DNS-01, using one of the alternative clients), but you'll have to pass at least one of them one way or another.
My VPS provider came back to me saying that the CloudFlare DNS service rejected the TLS-SNI-01 requests.
I did not install this CloudFlare, does it come with certbot ?
I’ll try the Mozilla Security configuration tool. Are the paths to certificates in this example /etc/ssl/certs ?
SSLCertificateFile /path/to/signed_certificate_followed_by_intermediate_certs
SSLCertificateKeyFile /path/to/private/key
SSLCACertificateFile /path/to/all_ca_certs
No, that would be something you or your provider would set up. CloudFlare is a reverse proxy service. That being said, the IP address mentioned in your post (149.202.47.62) belongs to OVH (I assume your provider) and not CloudFlare, so their response doesn't seem to be accurate. (TLS-SNI-01 doesn't work with CloudFlare, so maybe that's what their support team is trained to say, even when someone's not actually using CloudFlare. )
You can leave all the paths as they are right now, since you're already using a self-signed certificate. The important bits are SSLProtocol and SSLCipherSuite.
I’m having more or less the same problem… What I’m not clear on is where the challenge is coming from. If it’s coming from outside, it should be working (I’ve verified this from an outside server). If the server is trying to check itself, it’s never going to work, because our stupid DSL modem doesn’t reflect requests for our external IP back into the LAN.
Does anyone know how that phase of the certbot process works? I can’t think that a local verification would make sense, since anyone could then modify the script to allow a certificate for any domain, but then why is this not passing the test?
The validation is performed via Let’s Encrypt’s validation server, correct.
Does your error message contain the string urn:acme:error:tls as well? This would indicate a TLS error, not a general connection error. This could be caused by, for example, a SSL/TLS protocol version or cipher suite that’s incompatible with Let’s Encrypt’s validation server, though judging by SSL Labs that doesn’t seem to be the case here.
If it’s a general network error, this could be hard to debug. The connectivity issues could be specific to the route between your server and Let’s Encrypt’s validation server (i.e. any network hop in between, from Let’s Encrypt’s ISP to yours). Maybe some kind of country blocklist or DDoS mitigation is interfering.
Almost included it, but didn't want to make the post too big to digest...
Failed authorization procedure. manor.hypertwins.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to 50.111.67.243:443 for TLS-SNI-01 challenge
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: manor.hypertwins.org
Type: connection
Detail: Failed to connect to 50.111.67.243:443 for TLS-SNI-01
challenge
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
That includes urn:acme:error:connection but not urn:acme:error:tls.
Some kind of routing or blocking issue would be consistent with the pattern. I was able to wget https://manor.hypertwins.org from an outside server, and the output showed that it was accessing port 443 (and complaining about my self-signed cert, but my understanding is that this shouldn't be a problem for certbot).
If it might just be a single blocked IP address, I could reboot my DSL modem and get another one to try (which of course would require updating the DNS record and waiting the requisite 4 hours for the change to propagate).
FIXED. The problem was a minor configuration warning, which I only saw when I looked at the Apache logs while trying to run certbot – but I found I could get the same error with “apache2ctl configtest”.
So basically: checked the config with “apache2ctl configtest”; fixed the warning message, then certbot worked.
(The specific warning I was getting was that the machine had no global ServerName, though each of the two virtual servers had one.)
)