Hello, I love the Let's Encrypt idea, and it appears to be working on my site - but I don't understand how. I was wondering if we might summarize the steps? Install using 'The Perfect Server' In a Domain Config, put a checkbox beside: Let's Encrypt SSL In SSL tab, Create Certificate In SSL tab, Save Certificate That's it? No need to download certificate/bundle? No need to join letsencrypt.org or register your site? What happens after 3 months, which is the validity of the certificate my site is serving? THX, -J
Incredible! So to get a certificate, I just check the box!?!! Amazing +thanks! Is it still one certificate/site per IP?
It is amazing. The most frustrating work for me was renewing the paid for certificates each year. Even using the notes I made the previous year it was a half a days work of constant struggle. I was very happy for the stuff @ahrasis made. LE creates one certificate for the website and all it alias hosts, so it is not always exactly one to one. But almost always it is just tick the box and wait 2 minutes, then you have certificate for that website. Reading this forum, one way to get it not working is to first use certbot from the command line, this creates certificate files that confuse the ISPConfig generated LE stuff. I believe IP number plays no role in this, Let's Encrypt certificate does not "certify" the IP-number.
Not so long ago, there was a firm rule about certificates only being applied to one website (and sub-domains) per IP address. You could have unlimited HTTP per IP, but only one of them could be HTTPS. I don't think it was a certificate issue, so much as distinguishing host headers on the server side.
"Long ago" is pretty subjective; sharing one ip address for multiple sites has been supported for years. It was an issue at the ssl layer, the web server had no way to know what domain you were wanting to access, and hence what certificate it should present in the ssl conversation, so it simply used a single certificate per ip address, and any http hostnames not included in that certificate would get an error for a certificate name mismatch. SNI fixed that by allowing the client to indicate the hostname it wanted in the initial ssl connection, so the server could know which certificate to use in the ssl connection. ISPConfig has supported SNI for I think 8 years; one might almost say, "for a long time. "
I was correct in that the second site on the same IP to which I applied a Let's Encrypt certificate is resolving the certificate of the first site! #1. IP is 1.2.3.4 #2. I get a Let's Encrypt certificate for mysite.com on 1.2.3.4 and it works great! #3. I get a Let's Encrypt certificate for yoursite.com on 1.2.3.4 and it serves the certificate for my site.com In other words: one certificate per IP.
No, that's not the case anymore, see explanation from @Jesse Norell . This would only happen if you use a client without SNI support, but all browsers support SNI for ages and ISPConfig enables SNI by default for many years as well. So what you write is only true in case a client lacks SNI support, but such clients are basically not in use anymore. All other clients will show the correct site. If you get a wrong site with a recent browser, then there is a config issue on your system, e.g. the second site does not has an SSL cert or you made a typo in the domain name or the second site points to a wrong IP or not all sites use the IP, if you mix * and IP, a wrong site must be shown as well.
OK, then my server has a problem. More, as indicated in the FAQ, the Let's encrypt check-boxes are un-checked automatically. Only thing I can think of is site where Let's Encrypt works easily is native to this server, and site giving me trouble is migrated from much older ISPconfig. Code: 2019-09-26 05:58:18,399:DEBUG:certbot.main:certbot version: 0.23.0 2019-09-26 05:58:18,399:DEBUG:certbot.main:Arguments: ['-q'] 2019-09-26 05:58:18,399:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot) 2019-09-26 05:58:18,405:DEBUG:certbot.log:Root logging level set at 30 2019-09-26 05:58:18,405:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log 2019-09-26 05:58:18,410:DEBUG:certbot.plugins.selection:Requested authenticator <certbot.cli._Default object at 0x7f4450b3c240> and installer <certbot.cli._Default object at 0x7f4450b3c240> 2019-09-26 05:58:18,415:INFO:certbot.renewal:Cert not yet due for renewal 2019-09-26 05:58:18,415:DEBUG:certbot.renewal:no renewal failures Any ideas?
That debug output shows no errors. Verify ISPConfig settings for all website the IP Address is the same for every site. That is, either * for all sites or IP-number for all sites. Mixing the two creates the situation of displaying wrong website. Certbot version 0.23 seems old, on Debian Stretch I have 0.28.0-1~deb9u2. What OS is your host? Check DNS info is correct for the problem website. https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/
I did read the error Let's Encrypt Error FAQ - but here was the issue: I used to host all my websites internally on VMware - but due to aging hardware, decided to move to UpCloud for Linux Webservers. UpCloud wants you to use their DHCP-supplied DNS along with your public IP - promised it wouldn't change. What did change was the DNS, so I set to: 8.8.8.8 now everything works!
Note that for mail servers you should not use public dns servers, as you won't have as good of spam scanning, since many of the dns rbls have usage limits. In mail servers you should use a local caching, resolving name server (just use the already installed bind server if you also serve dns, otherwise install unbound).
