The problem is that LE has certificate limits of max. 100 domains per SSL cert, so your solution works only for small systems.
Yes, but than You can setup autodiscover with server hostname and one issued LE like on large shared hosting... so this is not solution for companies using ISP for thousands of websites/clients... of course U can always split servers to mail1.server.com mail2.server.com etc... it depends on how is your infrastructure designed.
Problem is that if even 1 domain has an DNS issue for what ever reason ALL the Letsencrypt certs on ISPconfig can fail to renew. Lets say you have +100 sites on the server and one of them fails to update because somebody failed to pay the Godday or what ever. It get really tiresome very quick finding out which site is the problem child and disabling it's Letsencypt Certs then regenerating the actual server cert then restarting Dovecot and Postfix after the actual email server cert deigns to upgrade again.
And don't forget the occasional switch from server1.domain.com to server1.domain.com-001 on Letsencrypt end. If you have linked to "wrong" cert on wrong folder you are going to have to remove server cert delete the "old" certs on all the folders so as not the regenerate the "wrong/new" certs.
On shared environment (lots of clients/domains on one server) the only way is to make one host SSL and force clients to use one HOST via autodiscover...
I noticed that if the sub/domain has no A record on IP (for example DNS cleared - client didn't pay)... it is auto-excluded... but the SSL is properly delivered with other sub/domains
This is done by ispconfig website ssl check function which does not pass the domain to certbot at all when the LE check is enabled and the domain does not point to the server. So this is not done by certbot nor letsencrypt, certbot would just fail for the whole ssl cert as @SamTzu explained.
Yes but this proves that the whole thing is working fine and there is no problem with expired domains... except large servers with more than 100 domains... for me it works perfectly.
The test if all domains have correct dns records is done by ispconfig when you add a domain to the site or when you remove a domain. Cert renewals are done by certbot itself and it will not test this, so if you don't add or remove a domain at least every 3 months and you lose the dns record for a single domain, then certbot will try to renew the cert and fail and the cert will expire.
Well, it uses several methods that nginx deems 'converted from apache'. Check out these here. Either way, I tried to use nginx the way ispcf thinks it is best done, but again, it reminded me too much of trying to do it the way apache does it, I didn't really fancy the deep vhost paths for example. I had a lot of vhosts migrating when I tried using ISPconfig for the first time, and they all had scripts and databases that had vhost paths in them. It was harder to change those around in ispconfig than to change nginx config by myself.
Hello @c3n, Your solution fits perfectly in my Ispconfig environment, probably 2 stupid questions: make proper DNS records for mail.my-domain.com pointing to 1392.server.com and make another DNS records for smtp, pop3, imap subdomains pointing to server You mean pointing directly with a type A record , or should I use a CNAME? It sound silly but since all my clients DNS zones are hosted on external providers, I would like to be sure before fiddling with them in production. Actually I've a wildcard on the main server for domains and email, and it works great. For various reason I'd like to give to my clients also the ability to have a custom mail.domain.com when configuring their email clients, and without certificates warnings (you know what I'm talking about: the classic call or email: "should I click yes? Is it safe?). Another thing is when I create a dns record in client side, like mail.domain.com, and the customer uses it to configure his mail client, they get the warning because it resolves to mail.mymainhost.com, so I think a different ip on the server, for every customer domain, is mandatory, if I want to go down with the custom mail domain road, is it correct? I know this is not ideally an ISPconfig related question, but more on DNS side, but a little clarification could help a lot of us running in to this issue Many thanks in andvance, also thanks to ISPconfig devs for this great software, I just bought the manual to give my support since I really appreciate this project
For the purposes involved (issuing a letsencrypt certificate and client email programs contacting the mail server), either A or CNAME should work. As always, test your new config on a test domain... It depends. Letsencrypt allows for 100 names in a certificate, so if you don't have very many domains on the server you could get away with using a single ip address, which used a single certificate with all the domain names (and mail.x, etc. names) included. If you need more certificates being served, you would currently have to have one ip address for each certificate and configure postfix (and dovecot) for that. In theory you may be able to find an smtp proxy which both handles starttls and supports sni, though I don't see a specific one right offhand in a little searching. Both nginx and haproxy might be candidates, but I didn't see the exact configuration setup you're wanting right off. (https://docs.nginx.com/nginx/admin-guide/mail-proxy/mail-proxy/) Postfix recently added SNI support, so that will be the long term solution, eg. one certificate per email domain, with a handful of hostnames in it, using a single ip address.
Wonderful, I wasn't aware about that, it was my main issue. Thank you very much for your clarifications @Jesse Norell
Realware I answered You on priv. Sorry for delay. @ ISPCONFIG community. I think that postfix hardened settings (tutorial from howtoforge) and also SSL / Letsencrypt for main servers (dovecot/postfix) should be built-in option while installing ISPCONFIG or to configure after installing on server settings in ISPCONFIG panel. For me the main problem with mail is that backup for mail is made on 0:00 hour not as setuped for web on server setup. Why is this a problem? Well. I got several dedicated servers with VPS. All of them got cascade backup scripts with mounted NFS so I can setup backups to avoid IO latency. It is working fine. But when servers starting backup email it is disaster. In my opinion there should be separated card for backup settings for ispconfig admin - one option for SERVER is good solution. OF course there is also issue with this that most of admins setup script to backup on 0:00 so there is too much traffic in datacenter.
I would strongly disagree with these statements. First of all, the auto-renewal of 1 cert with, for example, 100 domains (plus wildcard subdomains) via cloudflare happens at least a month ahead of validity expiring. So you'll be in time noticing which domain is failing. In fact, if you run the command through a script like: Code: #!/bin/sh certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --rsa-key-size 4096 --dns-cloudflare --dns-cloudflare-credentials ~/.config/cf-api-xs --dns-cloudflare-propagation-seconds 30 \ -d domain1.org,*.domain1.org,domain2.org,*.domain2.org\ domain1.net,*.domain1.net,domain2.net,*.domain2.net\ domain1.de,*.domain1.de,domain2.de,*.domain2.de\ systemctl reload postfix dovecot nginx It gives you a clear warning which domain is failing. You can have that sent to your admin-mail when running this as a cron-job. I've been doing it like this for ages. The only disadvantage I can think of is that users want to have their domain privacy, or they don't want to be connected to other domain names, but honestly, I have never had complaints from users about this, ever. So the cert is also used for other domain names, it is even favorable as long as all domains are not abusive domains, or spamdomains, or botnets, or malware, or ransomware domains. One could even argue that it shows/proves reputation validity for email. (Assuming you're a good administrator, of course..)
