Hi Ahrasis I've been checking log daily basis and i thought that the certificate would renew only at 90 days...And I reveice emails from EEF about the expirying, other expired period i've done using certbot autorenew but many issues came up...So i've posted a question here, about months ago, and the answer was to do not use certbot once ISPConfig has a crontab that will renew it automatically. Well, anyway, many thanks to the reply to me with soo very good news about it. I will try what Jesse Norell has recommended to see if i can at least recover access to ISPConfig panel...
Jesse I've got the new version from git-stable "ISPConfig Version: 3.1dev" and the disabling and reenabling the Letsencrypt checkbox at ISPConfig->Website->Myhost.mydomain.com.br has recreated the certificate and finally the came up..... At first time that i've tried to use https://URL the login has never completed, but at second time, worked.....soo many Thanks for you Jesse once seems that the problem regarding certbot has solved... A final question...what should a i do to have 100% sure that ISPConfig scripts will automatically renew certificates 30 days previous to expire...?
If you now have ISPConfig version from GIT stable, you are OK. It was a bug in certbot that LE sometimes could not renew certificate. Check the e-mail address for LE is something you read daily, so you get informed if some problem pops up and LE can not renew.
For me ISPConfig cron job script is working just fine but the creation and renewal are done by other software i.e. certbot in this case and through Let's Encrypt. So nobody can ever be 100% sure that certbot (or any other LE clients) or Let's Encrypt servers will always work, so it is best for every server administrators to have high self-discipline in going through their emails and doing regular maintenance for their servers.
just one question: Do you think it would be possible keeping a self-signed certificate for "server.myserver.com", and one LE certificate "server.myserver.com" only for Postfix?. It would be problematic for the automatic LE renewal?
Possible since you can always define different certs for postfix and I don't think it would be problematic for the automatic LE renewal too, but that's just my thought.
Hello 3 questions : 1) If I understand well, despite the post date (Discussion in 'Tips/Tricks/Mods' started by ahrasis, Feb 14, 2017.) this tutorial is most recent than https://www.howtoforge.com/tutorial/securing-ispconfig-3-with-a-free-lets-encrypt-ssl-certificate/ (Published:Feb 13, 2018) ? 2) I have previously created symlinks for Dovecot, by following this thread (but it didn't work) : https://www.howtoforge.com/community/threads/letsencrypt-on-mail-server.73695/ Code: ln -s /etc/letsencrypt/live/mail.xxxx.com/fullchain.pem smtpd.cert ln -s /etc/letsencrypt/live/mail.xxxx.com/privkey.pem smtpd.key Does I need to remove these symlinks before start your tutorial, or Code: ln -sf /usr/local/ispconfig/interface/ssl/ispserver.crt smtpd.cert ln -sf /usr/local/ispconfig/interface/ssl/ispserver.key smtpd.key will automatically update the previous symlinks ? 3) Does your method allow Thunderbird & K-9 Mail for Android to recognize certificates as valid without having to add an exception? Thanks !
1. Yes but both are supposed to work anyway. 2. Yes, at least I think so. 3. Supposedly but I never try any of them.
Hi, Thanks for making this script iwas wating it develop for a long while but only used it after your last update on github afew days ago. But i have a problem after installing this script, i want to my control panal for the first time after installing the script, and i got the warning page on firefox that says Your connection is not secure, and give this option to add an exception, but i also see in the warning message that it says this IP uses an invalid security certificate! (because it is trying to use is a cert that is for one of my domains i have on my server). why is this cert trying to be used in the wrong place at the ispconfig login page, should your script not of created an cert for this? and what can i do to fix this issue? thanks
The latest update was to fix the additional incron command where there shouldn't be a space after the comma in between the commands. It sound like no LE SSL certs were created. I'd say - check your server hostname fqdn by running hostname -f command and if it is correct, re run the script again.
Hello When I go to https:// I get: SSL_ERROR_RX_RECORD_TOO_LONG And Firefox reports another SSL domain name than the hostname Here is the SSL vhost section: Code: # SSL Configuration SSLEngine On SSLProtocol All -SSLv3 #SSLCertificateFile /usr/local/ispconfig/interface/ssl/ispserver.crt SSLCertificateFile /etc/letsencrypt/live/xxxxxx.net/fullchain.pem #SSLCertificateKeyFile /usr/local/ispconfig/interface/ssl/ispserver.key SSLCertificateKeyFile /etc/letsencrypt/live/xxxxxx.net/privkey.pem #SSLCACertificateFile /usr/local/ispconfig/interface/ssl/ispserver.pem With this method is it also necessary to create a DNS zone in ispConfig for the server hostname ? I didn't get error messages during certificate generation. Any idea ?
I do not have any idea of your error(r) as we do not use dns-challenge to obtain LE SSL certs therefore it is not necessary to create a DNS zone in ISPConfig for the server hostname. We only need to have the server hostname fqdn to be accessible publicly via port 80 and 443 (the web server ports) so that cerbot can process the issuance of LE SSL certs. If you follow the original tutorial or use this LE4ISPC script, the result should be the same i.e. we will be using SSLCertificateFile /usr/local/ispconfig/interface/ssl/ispserver.crt instead of SSLCertificateFile /etc/letsencrypt/live/xxxxxx.net/fullchain.pem in the vhost since the former will be symlink to the later.
thank you for your reply. Then I guess there is a problem during certificate creation. The domain linked to the cert is the first LestEncrypt domain in alphabetical order, not the server hostname. When I check hostname -f, the result is OK Previously I clean up a former cert by deleting: /etc/letsencrypt/live/[hostname] /etc/letsencrypt/renewal/[hostname] /etc/letsencrypt/archive/[hostname] UPDATE : I found the problem, I have edited nano /etc/apache2/sites-available/ispconfig.vhost instead: /etc/apache2/sites-enabled/000-ispconfig.vhost Then in my case I would do: sed -i "s/#SSL/SSL/g" /etc/apache2/sites-enabled/000-ispconfig.vhost sed -i "s/SSLCACertificateFile/#SSLCACertificateFile/g" /etc/apache2/sites-enabled/000-ispconfig.vhost instead: sed -i "s/#SSL/SSL/g" /etc/apache2/sites-available/ispconfig.vhost sed -i "s/SSLCACertificateFile/#SSLCACertificateFile/g" /etc/apache2/sites-available/ispconfig.vhost Both have an SSL Configuration section It works but I doubt it's normal... It appears ispconfig.vhost is not symlinked to 000-ispconfig.vhost Finaly I deleted 000-ispconfig.vhost and created the symlink: ln -s /etc/apache2/sites-available/ispconfig.vhost /etc/apache2/sites-enabled/000-ispconfig.vhost
Dear @ahrasis, i have an issue at the usage of the certs at my mail server, when i use mail.domain.com instead of the IP: Code: Jul 25 19:35:23 server0101 postfix/smtps/smtpd[28126]: warning: TLS library problem: error:140940F5:SSL routines:ssl3_read_bytes:unexpected record:../ssl/record/rec_layer_s3.c:1696: Jul 25 19:35:28 server0101 postfix/smtps/smtpd[28117]: warning: TLS library problem: error:142090FC:SSL routines:tls_early_post_process_client_hello:unknown protocol:../ssl/statem/statem_srvr.c:1642: Jul 25 19:35:28 server0101 postfix/smtps/smtpd[28117]: warning: TLS library problem: error:1420918C:SSL routines:tls_early_post_process_client_hello:version too low:../ssl/statem/statem_srvr.c:1667: Jul 25 19:35:31 server0101 postfix/smtps/smtpd[28117]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2267: J I have tested my domains with mail accounts with this result: Code: [000.289] TLS is an option on this server [000.289] --> STARTTLS [000.375] <-- 220 2.0.0 Ready to start TLS [000.376] STARTTLS command works on this server [000.483] Connection converted to SSL SSLVersion in use: TLSv1_3 Cipher in use: TLS_AES_256_GCM_SHA384 Certificate 1 of 3 in chain: Cert VALIDATED: ok Cert Hostname DOES NOT VERIFY (mail.server.eu != server0101.domain.com | DNS:server0101.domain.com) So email is encrypted but the host is not verified thank you in advance
1. Run "hostname -f" on your mail server to verify the server hostname fqdn. 2. Check if Let's Encrypt SSL certs for it exists by running "ls -lat /etc/letsencrypt/*/$(hostname -f)*". 3. Check if proper symlinks have been created from its live directory to ispconfig at /usr/local/ispconfig/interface/ssl. 4. Check if proper symlinks have been created from there to /etc/postfix. 5. If all the above checked out fine, check your postfox, dovecot and roundcube settings. Note that using this script or following the tutorial for LE SSL certs are meant to cover 1-4 for a mail server. For 5, you'll need to check with other tutorials especially the perfect server tutorial.
I have followed your tutorial and all seems to run normally except for a "wrong server" error from Thunderbird when collecting mail from Dovecot. I am using an external DNS and created subdomains: pop3.domain.com and smtp.domain.com many years ago. How can I add these subdomains to the certificate?
I do not think external dns server caused the error but it is more likely the way your mail server is setup since the tutorial or script is designed to look only for hostname fqdn of your mail server and not just any other subdomains. I do not think you can simply add the subdomains to the existing or future LE SSL certs since they are created via website settings following the tutorial. However, if you create new certs manually you can include them.
[QUOTE="ahrasis, post: 391725, member: 76386" However, if you create new certs manually you can include them.[/QUOTE] Should I install certbot and use Code: certbot --expand -d domain.com, sub.domain.com
I do think to expand the existing LE SSL certs for your web server which was obtained using webroot, to other new domain (or subdomain), the new domain to be added must also have a web access. If it does, then it should work just fine.