I ran this command: certbot --apache -n --agree-tos --email my-email -d creathys.fr
It produced this output: Failed authorization procedure. creathys.fr (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge. Requested e3123a6a281f93655339cc1a381e9231.aad2b4541bf34773614c63adc996f0c7.acme.invalid from 145.239.157.64:443. Received 2 certificate(s), first certificate had names "creathys.fr"
My web server is (include version): Apache 2.4.18
The operating system my web server runs on is (include version): Ubuntu 16.04
My hosting provider, if applicable, is: OVH
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no
Please, could you tell me the meaning of this output : Failed authorization procedure. creathys.fr (tls-sni-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Incorrect validation certificate for tls-sni-01 challenge.
Is it due to domain resolving fails ?
My ISP is OVH. This provider obfuscates private information. So, if you search on whois.net for creathys.fr, no email is provided. Can this explain the error output ?
The system was looking for your server to provide a TLS certificate for e3123a6a281f93655339cc1a381e9231.aad2b4541bf34773614c63adc996f0c7.acme.invalid (which is a certificate that certbot would have generated), but your server didn't provide that cert.
This happens whenever Certbot fails to reconfigure the web server to pass the challenge. That can occur for various reasons, like running Certbot on a machine that's not really the machine that inbound connections are terminated by (e.g. behind a proxy, firewall, or CDN), running old versions of Certbot with an unusual Apache configuration (like multiple virtual hosts in the same file), or previously unknown bugs in Certbot's ability to understand your Apache configuration.
You can see what Certbot is doing by running with --debug-challenges and looking in your /etc/apache2 directory when it pauses for validation. Remember that the self-signed certificate that it creates is only temporary, for validation purposes, and is distinct from the certificate that will eventually be issued to you by Let’s Encrypt.
However, this is rarely as useful as checking other factors, like whether you’re running Certbot on the machine that actually receives the connection, whether you have multiple virtual hosts in a single configuration file, and whether you have any other web server or reverse proxy, as well as looking at the logs in /var/log/letsencrypt to understand what Certbot tried to do.