migration tool error on couple of domains that were NOT on target server!

ack just noticed certbot has been axed???

 

Please follow LE FAQ as posting multiple times won't help readers here to help you.

Check whether you were using acme.sh or certbot before proceeding further.

Note that the latest way to install certbot, if you were using one, is by using snap.

Don't change to acme.sh if you were using certbot, unless you really know you are doing, but do upgrade certbot to use its latest version instead.

 

maybe the Server Migration Mode is still enable in the server-config

 

I can kill the newest one on the target server, but I think I probably need to recreate the ssl certs en masse? when I check ssl and letsencrypt on one of the domains on the target it will NOT create the ssl entry even after removing the newest account entry (referring to ns10). however this process DID work on the source server and it made new ssl for a domain on the source server, after deleting the older line on that server!
I'm using certbot always have I believe. though acme is there as well.
how to check which I'm using? where do I look under ispconfig?

 

definitely using certbot. on the older server (target of the migration) - certbot in /opt/eff.org/venv/bin:
certbot certificates
does list lots of certs which seem to be valid and work.
but one domain when I check SSL and Lets boxes and save, it does NOTHING - and the /var/log/letsencrypt/letsencrypt.log has now added lines at all after the certificate check above but nothing after I check and save the boxes!. so ispconfig is doing nothing when I check those boxes and save! seems its not invoking certbot at all. where to go from here?

 

You cannot have both on the same server. Since you migrated from certbot, maintain certbot in the target server as well and fully remove acme.sh

 

actually I dont think I have acme installed I just noted its part of the account name under /etc/letsencrypt/accounts!
acme-v01.api.letsencrypt.org is the account name

 

already checked the faq but point by point -
hat can I do if SSL certificate creation with Let’s Encrypt fails?
- Check that you have a Let’s Encrypt client installed. On servers installed before the release of ISPConfig 3.2, this is most likely certbot. On servers installed after the release, it's most likely acme.sh.
>>> was installed well before 3.2 cerbot it is...
- Check that the Let's encrypt client 'certbot' is updated (when using certbot).
>>> running /opt/eff.org/certbot/venv/bin/certbot certificates runs and produces a list of valid ssl certs. I dont see an option
to update it - is that not done each time certbot runs?
- Check that you run the latest ISPConfig version.
both running same version 3.2.5 (admittedly not updated to 3.2.6 yet).
- When your server is behind a NAT router so that the server itself can not reach the hosted domains, then enable the option "Skip Letsencrypt check" under System -> Server config -> server1.example.com -> Web.
>>> certbot should be able to reach the domains though the domains are entered on BOTH servers (migration) and both dns entries point to the source server (ns10). but its completely reachable.
I did in fact try checking the Skip option but did not lead to creation.
- Check that all domain names (incl. auto subdomain www etc), subdomains and aliasdomains really point to the right website and are working. Open one after another in your browser and test that.
>>> websites work. though again the website actually is hosted on the OTHER server. it exists on both servers, but dns entries are in agreement pointing to the source server (still. plan to change that).
NOW on the original server, the failing domain did NOT have ssl cert installed. I fixed that issue (noted above) by deleting the extra line in the /etc/letsencrypt/accounts entry and then creating the ssl on source server. I deleted the ns10 pointing account from the target server now as well. and I'm now trying to create the ssl on the TARGET server. should that not be possible? or must I rerun the migtool to have the ssl certs from source moved onto the target server? and if this should not work maybe doc might explain the need to run migtool to move the ssl and we cannot simply create ssl on the target server?
- If you still use Apache 2.2, then update your ispconfig to the latest version with the ispconfig_update.sh script to get an updated vhost template. After you did that, use Tools > resync to apply the new template to all sites or apply it to a single site by altering a value in the site settings and press save, before you try to activate Let’s Encrypt again. This is only necessary on apache 2.2 systems, newer apache 2.4 or nginx systems are not affected.
>>> both servers running 2.4. though the centos 7 server may have originally been running 2.2?
- If you updated from ISPConfig < 3.1 to ISPConfig > 3.1 and deselected the "Reconfigure services" option during update (which is selected by default), then Let’s Encrypt will fail as your server is missing the Let’s Encrypt configuration in the ispconfig apache configuration files. Redo the update and chose to reconfigure services in that case.
>>> n/a
- Check that 'Server Migration Mode' option under System > Server Config is not enabled, as migration mode disables the creation of new Let's encrypt certificates.
>>> its not.

so I'm a bit perplexed still.
running migration --syncjobs it says will save website,mail, and databases. will it sync the ssl certs? I'll find out

also after last round of check ssl/lets, save, wait for red dot to clear - check and boxes are now unchecked I did find this
in /var/log/letsencrypt/letsencrypt.log:
--snip--
2021-09-23 09:17:09,254EBUG:certbot._internal.main:certbot version: 1.9.0
2021-09-23 09:17:09,255EBUG:certbot._internal.main:Arguments: ['--domains', 'mazdaworld.net', '--domains', 'www.mazdaworld.net']
2021-09-23 09:17:09,255EBUG:certbot._internal.mainiscovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2021-09-23 09:17:09,324EBUG:certbot._internal.log:Root logging level set at 20
2021-09-23 09:17:09,324:INFO:certbot._internal.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
~
--snip--
so certbot seems to have run - just did not create anything for mazdaworld.net ON THE TARGET server. one possibility presents itself. is certbot checking mazdaworld.net ON THE SOURCE SERVER and seeing it already has a valid cert - and thus doing nothing????

sorry for being logwinded (or was that longwinded?) but I do love ispconfig and apprecate migtool. if this all turns out to be expected behaviour I'll find out after doing the --syncjobs if it does copy ssl cert over? and if it does NOT, maybe it should? I think if the website, mail and database has changed and should copy over, should not the ssl cert be considered part of the database? and how might that work anyway?

 

actually the NEW/TARGET server is actually the older server. I'm migrating backwards. It was surely originally 3.1 but its been updated.
OLD(source) server is 7 months old running centos 8 was always 3.2. both running apache 2.4.
you are saying that source 7-month-old server would have used acme.sh even though the old one was using certbot?
and must I change or can I assume certbot will continue to work on the older server?

hmm. my final plan was to change all dns entries on BOTH servers referencing ns10 (174.xxx) to reference ns9 (204.xxx). I believe you gave me the phpmyadmin instructions to do that all at one fell swoop? may need those again
which database do I need to alter? and what was that command again? and how to get all the dns entries to propogate the changes?

and after doing this so dns all point to the new/target/actually-the-older-server, LE will then work? or do I have to do something
to get certbot updated? it DOES seem to work.

my point about the ssl certs being considered part of the website is that migtool might point OUT that one site has ssl certs and the migrated site will not! might be useful information. and ssl does hang off the website path.
at least something that needs to be cleaned up later!

 

will check. and there is no .acme.sh so all is certbot. does it update itself automatically still? and do I need do anything additional to update it? and can I continue to use it or does it need to be replaced?

/etc/letsencrypt on both servers now just has one accounts line. not sure how the second got created, but thats obviously something should not have happened!

 

ok but I thought I read you can NOT have 2 accounts under /etc/letsencrypt? so this is guaranteed to cause problems? or did I misread?
and since I've already run migtool and deleted accounts from /etc/letsencrypt/accounts, now we assume I have some 'orphaned' domains that LE cannot renew since they may refer to the removed account?
Any way to get LE to forcibly recreate ALL certs ISPConfig knows of and attach them to the (one) existing account?
If not, might it make more sense not to copy over the SSL certs, but to have the target server recreate/renew/create ALL SSL certs after migration is complete? then no extra account and all should renew?
and what happens to the 'extra' certs we make, for postfix etc, or ISPCONFIG itself? those might need to be recreated if they have been overwritten by certs from the now dead account?