Not sure how to correct this. ISPconfig 3.2. Going to the admin interface it is using a let's encrypt certificate. https://host.domain.com:8080 is secured with a proper certificate. However I had an issue where mail users were getting an invalid certificate warning. A suggestion on this forum was to add host.domain.com as a site in the sites tab with LE turned on. So i've had that for a while. if you visit https://host.domain.com you get an invalid certificate warning. So the admin panel is using the cert but visiting the server without :8080 you get a warning. Inspecting the certificate i can see it's a self signed cert from when I installed the server. All other sites on the server have a correct LE cert applied to them. The issue is the host and it's certs. What is the proper way to fix this so the admin panel and mail users are presented with a valid let's encrypt certificate? Should I delete the site i added for it, is that causing a problem?
that's in place. however on port 80, 443, 993, and 465,587, it's not presenting that cert. It's presenting the self signed from 4 years ago. I've double checked and those certs are there, dating from aug 29. on port 8080, it's using the correct cert.
Per the link: Note for ISPConfig 3.2: ISPConfig 3.2 is able to create a valid Let's Encrypt SSL certificate for the server hostname automatically during installation, which is used for the mail server as well. There is no need to manually create a Let's Encrypt SSL certificate as described here on ISPConfig 3.2 systems unless you need different domain names in the SSL certificate beside the server hostname. But on a 3.2 version with existing certs (/usr/local/ispconfig/interface/ssl/[certs here]) I get do not get a choice to generate certificates when running ispconfig_update.sh --force. If I remove the certs I do but then NGINX crashes during the letsencrypt verification process which causes a CONNECTION REFUSED error. Otherwise, it appears that letsencrypt is successfully verifying the certs before crashing. Nginx 1.18, Linux 11(bullseye) Ispconfig3.2.8p1 Objective: I'm not trying to provide certificates for multiple domains, just my mail.example.com server for email clients and DMARC. I've tried both certbot and the acmetool. I have to missing something obvious. Thanks for any help!
Then there must be incorrect copies/symlinks, software has not been restarted, or there is a different issue. Using both acme.sh and certbot indicates that you have made a mistake already: those 2 should never be used on the same server. Which one did you use before?
I've remove certbot, just tried it once in a silly last ditch effort. What can I look for or post for you to know what I might be missing with regards to symlinks?
Not sure if this was for me or for sleepingranch... I set up this server in 2019, I applied a fix similar to your link a year or two later. So I honesly can't remember. I do have a site defined for the hosting server's URL and LE checked for it. It's also generating certs. For some reason it's only using the correct cert on https://host.domain.com:8080 and not on https://host.domain.com I've check and all the symlinks are using the same cert list in /etc/letsencrypt/live
found my issue for port 80/443 it is pulling the cert from /etc/httpd/conf.d/ssl.conf which is pointing to the certs in /etc/ssl/certs/ I'll change this ssl.conf file to use the LE certs and see what happens. Postfix main.cf is pointing to the correct certs from LE, yet it still presents the old self signed certificate. Is there somewhere else postfix is getting configuration info that i need to update?
No, just take care to restart postfix. You might also want to check the docvecot.conf file if it points to the right SSL cert. The domain https://host.domain.com is likely the systems default vhost of the OS (Debian or Ubuntu). This is not managed by ISPConfig and therefore it uses the self-signed SSL cert that the OS created at install time. If you want to replace it, disable the default SSL vhost and create a website in ISPConfig instead or change the default vhost config file and point it to the SSL certs from ISPConfig.
Finally found the answer, thank you for suggesting the default conf file. My server is centos 7, the default conf i needed was in /etc/httpd/conf.d/ssl.conf. Didn't realize this was still in play with ISPConfig installed. Correcting the SSL certificate there also fixed email. But that's where I get confused. in the main.cf smtpd.key and smtpd.crt were both linked to the let's encrypt cert, dovecot conf file points to the postfix cert files. However postfix/dovecot was still presenting the self generated/self signed cert from 2019 until i fixed the ssl.conf for apache??
In your post you was responding to this, that you said (I quoted in full this time): Which I thought was referring to the server hostname, so, I was wondering because previously it was not advisable to create a website for it because with acme.sh install to the website, it will break the server LE SSL certs' sharing with all other services including the recreation of ispserver.pem. Has this thing changed in the recent update?
The default vhost of the system is not a website for the server hostname. It's just a catchall site without a server name set. So what I meant there is that he can change the path of the SSL cert in the default vhost to point to the cert in /usr/local/ispconfig/interface/ssl/ This has no influence on issuing the cert as the same cert id referenced by the ISPConfig and apps vhost as well and it makes no difference if 2 or 3 vhosts use the same cert.
I think he really means that as the server FQDN as he managed to access https://host.domain.com:8080 with proper LE SSL certs but not on https://host.domain.com, so that's why I wandered about it. I get it that if he doesn't mean it as the server FQDN, it will be correct to assume the way you did.
What I said applies to the server FQDN as well as the default vhost is what catches the server FQDN when you enter it and the fact that he gets a self-signed SSL cert indicates that it is indeed served through the default vhost as this is the only remaining vhost not managed by ISPConfig that uses a self-signed SSL cert.
