when i look in , i can see that : root@web1:~# ls -alh /etc/letsencrypt/live/ drwxr-xr-x 2 root root 4.0K Sep 1 23:42 admin.domain.com drwxr-xr-x 2 root root 4.0K Sep 2 21:39 db1.domain.com drwxr-xr-x 2 root root 4.0K Sep 2 22:21 db1.domain.com-0001 drwxr-xr-x 2 root root 4.0K Sep 4 18:00 mail1.domain.com drwxr-xr-x 2 root root 4.0K Sep 4 23:27 mail1.domain.com-0001 -rw-r--r-- 1 root root 740 Sep 1 23:42 README root@web1:~# ls -alh /var/www/clients/client1/web39/ssl/mail1.domain.com-le.key lrwxrwxrwx 1 root root 58 Sep 5 22:00 /var/www/clients/client1/web39/ssl/mail1.domain.com-le.key -> /etc/letsencrypt/live/mail1.domain.com-0001/privkey.pem For vhost : mail1.domain.com. How certbot will manage this when renewing ? Note : web1 and mail1 are two separate server.(certbot is on web1), i 'm afraid of this way ispconfig genetrate cert. in order to use this cert for my mail server (dovecot, postfix, mailman)
Certbot knows the names and paths of certs that it creates as it chooses these names on its own, this means certbot knows how to renew its own certs. Certbot adds an ID to a cert when you add new domains to an existing certbot cert. ISPConfig is able to handle this default certbot behaviour correctly, so no need to panic. That's the way certbot works, it's not ispconfig specific in any way. If you are afraid in the way how certbot works, then don't use Let's encrypt and buy a SSL cert from any SSL cert vendor instead.
ok, with that . So on which cert dir can i "ln -s" in order to supply postfix (mail server) his cert ? (on web document root , like : /var/www/clients/client1/web33/ssl ? ) the aim is to export via nfs, /etc/letsencrypt to mail servers (3 mail servers) and then use this export in order to give postfix; dovacot mailman cert.
in the code of ispconfig how do you know/detrmine which cert to use ? db1.domain.com db1.domain.com-0001 ? Because in the /var/www/clients/client1/web33/ssl folder your symlink are pointing to the good cert ?
i found a good solution, i share it. (multi server setup) NOT WORKING => nfs and incron not friends at all. inotify not working with nfs. First export (nfs) /etc/lets/encrypt in ro, only for your server which need certificate (mail1, mail2 ....) Then mount /etc/letsencrypt on your target server (mail1,mail2 etc) then follow this tutorial : https://www.howtoforge.com/tutorial/securing-ispconfig-3-with-a-free-lets-encrypt-ssl-certificate/ install incron in order to detect letsencrypt cert renew ... so you can restart postfix, rspamd and dovecot services.
The use case for sharing /etc/letsencrypt is when you have multiple servers which are mirrored, and hence need access to the same set of certificates - I could have forgotten what you've mentioned setting up, but you don't have that, I don't believe, do you? Ie. your three servers all handle separate domains/users, they are not 3 mirrored servers sharing the same users, mirroring all mail data, etc? If they are not, then there is no need to share /etc/letsencrypt, and actually reason not to, as each server can only renew it's own certificates, so you will have eg. mail1 renewing it's mail1 certificate, but generating failed renewals for mail2 and mail3; mail2 will succeed with mail2 but fail mail1 and mail3, etc. (plus it's a simpler setup, less prone to errors).
thank you for,this long reply. but here ... onnly 3 public ip : we are doing our best with that. port ... 80,443,8080 goes to web server : web1,web2,web3), so only letsencrypt here ! 25,993,995,587 ... to mail servers : mail1,mail2, mail3. no need to expose db1,db2,db3 and ns1 and 2 , same pub ip of web1 and 2
with this "problem", of letsencrypt i question myself with the advice of Till : multiserver with dedicated task for each of them (web,mail,db,dns) as i do or only 3 servers with a all in one setup ... eventually two more for dns: that the big question ???
It depends on your setup and how big it is if that makes sense, but it might be an option: I use acme.sh instead of certbot (also supported by ispconfig, though migration is a pain) acme.sh is much more flexible and you can run additional certificates in parallel to the ones that are managed with ispconfig. You can easily add post-renew hooks to some certificates (like the mail ones) that then distribute the certs to the needed servers (I use that to also renew the TLSA records). In fact, when you have a big setup with many servers, I would only handle the www certs via ispconfig and have the mail servers get their own ones (for example via DNS challenge), instead of reusing the www certificates. It is no problem for letsencrypt to create different certificates for the same domain (as long as you do not violate the rate limits)
NFS is surely an acceptable solution to share the certs between servers as it seems secure last time I checked. However, as an alternative, one can always use standalone approach from any server provided port 80 is open and not use by other services like web server. But I would agree that DNS challenge is better if one doesn't want to open port 80 for the server at all. About renewal hook though, so far that I know, it should work the same in certbot and acme.sh and it is better if compared to incron as suggested in the tutorial. Good news is, some of these good features are already implemented in the latest ISPConfig 3.2, so each server can now secure its own Let's Encrypt SSL certs for all of its services during install or update (using web server or standalone plugin) and automatically renew them with the scripts that come with it.
what is working (multi server setup, same design with servers as in ispconfig manual.) : web servers ( 3 here) incron with scp (authent with key pairs), scp pushing cert letsencrypt to mail servers (3 here). on mail servers , incron doing the job of restarting postfix and dovecot when detecting in_modify with .cert and .key file (those scp have pushed on mail servers) note : on web servers incron trigered to (not mailx.domain.comof letsencrypt folder because it can -0001 ...) : /var/www/client/client1/mailx.domain.com/ssl/ folder.
