Hello everyone, I am trying to migrate few of my client's old servers to a new server (merging multiple into one, but the problem is not related to merging). The target server is not yet accessible to the internet and DNS records still point to the original servers, I am aware the certificate 'renewals' will fail while DNS records still point to the original server, however existing valid certificates will work within their validity period, as they are simply copied over to the target server during migration. Some of the server migrate perfectly with no SSL issue on the websites (say from server A), but few in particular have a strange issue. Some websites from this server (let's call it Server B) show (as a browser warning) expired certificates, while other websites from the same server B work fine when accessing from the target server. None of these websites from B when accessed from the original server have expired certificates, all are valid for 30+ days. We cannot change DNS before all the websites/databases/ftp/mail is working on the target, for obvious reasons, hence cannot check if just renewing the certificates will solve the problems. I have done the same before and never faced the SSL problem while testing target server before changing DNS. My question is what is causing such behavior, is it possible that the there is some different configuration on the original server for these websites, and thus ISPC cannot copy the right set of certificates to the target, or there is some problem on the target server which causes it serve stale certificates ? Additional Info : Let's Encrypt Logs on the target server show domain validation failed for the problematic websites, but I think it is due to failure in renewal process which is expected. The .vhost file on original server B and target server are identical as well the certificate file pointed to in the vhost files. Running the 'certbot certificates' command show valid for working websites, and invalid (expired) for websites which are not working, as expected. Any help/leads/links in debugging this will be helpful, Thanks
Well, this is supposedly true. I would rsync again all the relevant LE folders to ensure they are all in there and have the latest copies. When I said "relevant" I meant i would copy only archives, live and renewal folders. This because you have multiple sources, with each having their own LE account and the numbering for each servers domain / website certs is different as well. This in my mind may cause the target to have more that one account and the numbering for each domain / website certs may overlap each others, if you are rsync the LE folders as whole from each sources to the target. This could be one of the problems. The problem could be caused by many things one of which I can think is the symlink to the latest certs from live folders to archive folders are somehow broken, so rsync as I said above could help, I think. However, I am not sure what is the cause if you doing the same using ISPConfig copy or migration tool copy as I have not use any of them before. Their developers would be answering you for that if you are using them.
The same problem occurs if the server B is migrated to a clean cluster, I don't think this should be the problem. but this is done by ISPMigrate itself and it is not seen on other server (I have tested two other separate server, both works well).
Check Let's encrypt log to find out why LE refuses to renew them. Might be that some of the certs belong to a different LE account or something similar, this might happen e.g. when you move different server to one new system, as there is just one new account for all certs, some of the other cert configs may contain a wrong account. This is nothing that the migration tool can handle as its internal config from the LE client, the best solution is probably to deactivate le for that site, press save and activate it again when expired.
Because domain verification fails, as I said the DNS still points to the original server, the certificates are valid for another month from now and it the renewal is expected to fail. The issue is why the certificates when copied over to the target server are shown as expired (it says they expired on jan 21, 2022, whereas if I access the website on the original server the certificate is valid till December 20, 2022). If this was a standard error, this should have been the case with all the other websites on the same server or another server but that is not the case. The expired (again, when accessed on target, not original) certificates are only for a few websites. Is it possible that these websites have some different settings or a different path to store the certificates on the original, but for some reason ISPMigrate is not aware of it ? (I checked the SSL directive in these websites vhost and they point to /etc/letsencrypt, just as any other website.) How can this be debugged, should I manually rsync these certificates to make sure they are the same? What all folders need to be copied over ?
The Migration tool copied them over with rync, unless you have chosen to not copy SSL certs during migration via command-line flags. Check if the certs on the old and new server are really the same by looking into the SSL files. And in case yu did not migrate the sites very recently, it might be that the certs on the active server got renewed in the meantime.
I do not remember choosing to *not* do it, I also saw it waiting to copy LE certificates, which was marked OK during the migration process. I opened the ssl cert file pointed to by the vhost for a problematic site and eyeballed few characters at random locations and they are exactly the same. Can you list what all files should be checked? Negative, I have migrated the server multiple times for the last 3 days and got the same results.
Checking the certificate should be enough, as the web server would not even start in case the key does not match.
This is not possible if the browser said otherwise unless it still refers to the old caches in which case you should clear them before trying again.
Thanks for the help, the client have given a go ahead to ignore these sites and renew the certificates on the target server after the DNS records are updated. I will reopen this/new thread in case the problem still remain, although I highly doubt it.
