I ran this command:
certbot-auto --apache --staging certonly
It produced this output:
Domain: www.nosotros.dk
Type: connection
Detail: Failed to connect to 212.112.134.44:443 for TLS-SNI-01
challenge
My operating system is (include version):
Fedora 21
My web server is (include version):
Apache 2.4
My hosting provider, if applicable, is:
N/A
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
Error from Apache:
[ssl:warn] [pid 502] AH01906: 086aeb551ced5f171224dc4227556c86.65d41ff1a378f90d4dcf3386ef2ac60f.acme.invalid:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
I don’t get this error when starting Apache with the certificate from CACert, so it must be coming from the temporary certificates generated by certbot.
How can I get certbot to generate a valid certificate?
The warning message from your apache error log (“server certificate is a CA certificate …”) does not appear to be related to the connectivity issues between Let’s Encrypt’s validation server and your web server. The warning is only that - a warning - and would not prevent the web server from starting.
I’m not entire certain, but based on your IPs reverse DNS, it looks like your site is hosted behind a residential internet connection. Some ISPs have been known to generally block common ports like 80 or 443 for incoming traffic as a matter of policy, either completely, or for traffic originating from certain countries/IP blocks. While I’m able to connect to your IP on port 443, it’s possible that the IP Let’s Encrypt is connecting from is part of that blacklist. The bad news is that these types of issues are hard or impossible to debug (especially from your end).
There are a couple of other things you could try. The first one is using the webroot plugin rather than the apache plugin, just to rule out that it is indeed an issue related to the apache plugin or your apache configuration in general (which I don’t think is the case, but who knows!). The webroot plugin works via port 80.
The second option would be using dns-01 validation, where you validate domain ownership by creating a TXT record. certbot support for dns-01 is fairly new, and I tend to recommend lego as an alternative client as it happens to support a large number of APIs from various DNS providers which allow you to automate solving the challenge. dns-01 does not require that your server is in any way accessible from the public internet, so this would be the preferable option if it is indeed some kind of ISP filtering.
@larsalthof, it’s probably a problem with your Apache configuration using the wrong file. You should most likely serve using fullchain.pem in Apache 2.4. If you still have trouble, could you show us the part of your Apache configuration that tells it which keys, certs, and chains to use?
As for filtering, I think it is unlikely but as you say, it will be a challenge to troubleshoot from my end. I am going to let that lie and enjoy my encrypted connection
Once I got verification to work, I did arrive at the conclusion that I need full chain.pem
That wasn’t the original problem, though, it happened during verification, and thus I wasn’t in control of the settings. I did manage to grab them, though:
<VirtualHost *:443>
ServerName f4b3acbef74d941c0fbafec3f462e2d2.aa61743c7a0eb2e6406a38bc61e5e4c4.acme.invalid
UseCanonicalName on
SSLStrictSNIVHostCheck on
LimitRequestBody 1048576
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /var/lib/letsencrypt/_GT5mCHGJvMF0ts4L01LYAn0nTLliNP8tWX_LNWQmo8.crt
SSLCertificateKeyFile /var/lib/letsencrypt/_GT5mCHGJvMF0ts4L01LYAn0nTLliNP8tWX_LNWQmo8.pem
DocumentRoot /var/lib/letsencrypt/tls_sni_01_page/