I'm having a similar issue to that reported by others recently, but I understand the issue, so this is more of "OK, what next?". I have a new system with a floating public IP address. I have not asked the infrastructure provider (DreamHost) to create a PTR record for this IP to this host. The reason, ref my other recent threads, is that I'm installing this system to replace another ISPC server. After I get this new one fully installed, I'll use the Migration Toolkit to move all of the data and configs, then transfer the public IP from the production server to this new one. The production server does have a PTR record. Until I do that switch, the LE cert fails because the IP address reported from dig and other utilities isn't the clean FQDN. The acme.sh utility kindly switches to a self-signed cert in this case. And with this, it's possible to open the ISPC web UI. However, when setting up this server and a secondary as MX1 and MX2, we need to create websites for these servers, and of course the LE cert fails to generate there too. This affects the Rspamd UI as well. The simple answer is to get the hardware provider to issue a PTR record for these IPs and then change them later as required. I'm presenting this as a stumbling point in the Perfect Server process. How do we know we will have this problem? : Ping the server after all network configuration. If you get host.domain.tld back, it's OK. If you get something like ip-000-000-000-000.some.other.tld, then you need a PTR record and you should not start the ispc3-ai process. That's a suggestion for enhancement to Perfect Server doc. A suggestion for enhancement to the ispc3-ai.sh is to ping the FQDN, and if the return FQDN doesn't match the FQDN source FQDN, don't start the install. At this point, I have gone through this process three times, with a lot of reading and testing. I now have a system that is fully configured for Web, DNS, MX, and with all related utilities. If/When I get the PTR record, can I just do 'acme.sh --renew-all --force'? Should I run the auto installer again? When we rerun the auto installer do we need to use the exact same command, or in this case if we just run with or without interactive mode will it check everything that's already in place, and in this case maybe renew the cert? This is more of a documentation question: What do we do to recover when the install fails? I have a pre ispc3-ai.sh image backup and it'll be easy to restore from that. I just don't know what the installer is already capable of doing to recover from a situation like this. Related - is a PTR record required in this situation for the Migration Toolkit to work? I don't think so because I believe it's just using the SOAP interface and certs aren't checked. If so then again, the answer is simple - we gotta have that PTR record first. I just want to understand the product better. Thanks!
When Let's Encrypt issues the certificate, PTR record is not examined at all. If fact, the IP of the host does not matter, only that using FQDN as URL goes to that host. If you later change the IP of host and change name service info accordingly, certificate verifies OK. The issue must be something else. That will not work. Running auto installer a second time on the same host should fail. Autoinstaller must be run on minimal OS install.
What websites need to be created? The migration tool creates the websites that were on the old host on this new host.
If LE fails for a site, follow the Let's Encrypt error FAQ step-by-step to find out why. As the FAQ mentions at the end, if you cannot find the reason by following the FAQ, then post the debug output. Let's Encrypt error FAQ: https://forum.howtoforge.com/threads/lets-encrypt-error-faq.74179/ Regarding PTR: A PTR record is not relevant for Let's Encrypt at all, like @Taleman mentioned already. And to answer the question you raised in the title "Force new LE cert after ISPC install?" you do this for ISPconfig by running "ispconfig_update.sh --force" and choose to create a new SSL cert during update and you do this for a website by disabling LE checkbox, pressing save, enabling the checkbox again. But you likely know this already as you are a frequent reader here and this topic is covered regularly in the forum.
Hmm, thanks @Taleman. Now I think I know the issue. I build my VPS in DreamHost's DreamCompute cloud service with OpenStack. They provide preconfigured "minimal" images for new instances, which include ufw, openssh-server, and some other necessary tooling. When ufw is first started, it closes ports 80 and 443, so the LE inbound connection will fail during the ISPC install. If you're installing a true minimal instance onto a newly partitioned disk, you don't have ufw until it's installed by ISPC. Then the instructions tell us to change firewall settings in the ISPC web UI. So if LE is trying to connect in during the install, those ports are closed for us DH/DC users, not others. I'll try another ISPC install over a fresh base, but will check the port status and do "ufw allow" first. Another option would be to remove ufw during initial updates. I don't think there's much overlap in the image packages and ISPC. I can experiment with a new truly minimal server later, and compare "dpkg -l" lists. UFW might be a package they decided to include in their Ubuntu v22 image, not in v20, so this wasn't a problem before. That's today's theory anyway. I'll report back.
Update: I used "ufw allow 'Apache Full' " to allow ports 80 and 443. Then I ran "ispconfig_update.sh --force", only answering 'yes' to reconfigure the Firewall. This re-ran the LE process and the cert authorization process did complete. I restarted the system. I then disabled ufw from the console which seemed to be necessary to SSH in. From the ISPC web UI (port 8080) I created a new website as a test (ref mx1 note in last comment here). On setting SSL/LE, the cert generation was successful. The Rspamd WebUI on port 8081 is available and working as HTTPS. Recap: I anticipate "you should have started with a minimal config per the doc." This has never been a problem. The image from which we generate new instances doesn't contain much beyond absolute basics, like DigitalOcean, Linode, RackSpace, and other VPS providers. My steps above aren't elegant. The block on SSH was unexpected and ufw commands to list rules don't show SSH. I'd be happy to reinstall a new minimal server, with the default VPS image, clearly define the minimal required commands, and offer an addition to the minimal guide for others who might need to do the same. Will this be accepted? This was my first "--force" update. That's what I was looking for (title of this thread), but wasn't sure if it would offer a new cert. Thanks. I understand the question by @Taleman about why I'm creating the new website for MX/Rspamd. In this comment I documented my plan for a server migration: This is just a normal (Perfect Server / ISPConfig) installation. Duplicate the topology of the existing ISPConfig servers. Get this working like it's a new company. Get server snapshots. Use the Migration Tool to port configs and data from live to test. Migration must be to same topology. @ztk.me said "in general it is looking fine" - that was the only feedback I got on that, so that's how I moved forward. If the correct procedure is not "follow the Perfect Server instructions, then run the Migration Tool on the source server", I'm hoping someone will say what else is required. Thanks.
Thank you for the update and feedback. Reading this, I can't get rid of two thoughts, The Letsencrypt certificate, after beeing issued, is not bound to your server IP. It can be read and used as a "normal" TLS certificate on the new server as long it is valid. Also always a possibility, even though I am not aware it is implemented yet, one can use DNS validation method and request a certificate without the need to have a webserver available. The process is pretty easy actually. Maybe you were not aware of those options - next time you are My takeaway is, Maybe someone with some spare time could write a user friendly howto or add to existing migration instructions.
Migration tool can copy also certificates for websites, if SOURCE and TARGET use same Let's Encrypt Client. The copied certificates should work immediately on the TARGET system, until they expire after 30 to 90 days.
The problems described in that thread arose because the thread starter accidentally did not start with an empty system with full internet access; he began with a system where a firewall was installed as he was not aware of the changes his ISP made to the internet base images and they were now configured to block web access from outside on port 80 by default, preventing LE from issuing certs. DNS-based LE certs are not required here. So, nothing is missing in the migration or install guide. The install guide clearly says you must start with an empty base system. So, the steps for migration are already fully documented. 1) Install ISPConfig: https://www.howtoforge.com/ispconfig-autoinstall-debian-ubuntu/ What is important here is that you read and follow the complete guide. Do not leave parts out, and especially do not ignore system prerequisites! Also, read the Migration guide, which mentions migration specific prerequisites like matching LE clients. As @Taleman pointed out, the Migration Tool automatically migrates the LE certs when the same LE client is used on source and target server. 2) Run the Migration Tool: https://www.howtoforge.com/tutorial...-confixx-plesk-to-ispconfig-31-single-server/
For testing of a new installation the hostnames are different, so migration of certs for live hosts is great but not relevant here. Regarding update/--force : Code: Reconfigure Services? (yes,no,selected) [yes]: selected Reconfigure Firewall (y,n) [y]: Configuring Ubuntu Firewall Configuring Database Updating ISPConfig Certificate exists. Not creating a new one. <<<<<< Reconfigure Crontab? (yes,no) [yes]: no Regarding minimal system - understood - really - but not realistic given that every VPS provider offers a selection of images. @ztk.me suggested enhancements to instructions for Migration Toolkit. @till responded that the instructions for minimal install are adequate. These are different parts of the installation. Till is right about this installation not conforming to the minimum install - I accept that and will adapt. I also agree with Ztk that the information about Migration Tools is minimal and leaves too much to the imagination. Enhancements would be welcome.
