ISPConfig Migration Toolkit from Debian 9 to Ubuntu 20.04 (autoinstall) and the certbot vs acme.sh

Discussion in 'Plugins/Modules/Addons' started by curiousadmin, Jun 28, 2021.

  1. curiousadmin

    curiousadmin Member HowtoForge Supporter

    Hello Community,
    I'm not 100% sure if this is the best place to ask but I assume people who designed the ISPConfig Migration Toolkit have access to this forum as well.

    Here is the thing - I have servers that were originally installed as Debian 8.4 then migrated to Debian 9 (full story here) and jpcyrenne actually recommended there the automatic migration Toolkit which I bought license for.

    In the very old The Perfect Server - Debian 8.4 Jessie (Apache2, BIND, Dovecot, ISPConfig 3.1) the certificates are actually issued using certbot which is in the Perfect Server Automated ISPConfig 3 Installation on Debian 10 and Ubuntu 20.04 available but not recommended (as they recommend acme.sh).

    I plan to do a clean data migration using the Toolkit from Debian 9 to Ubuntu 20.04 - Server1 (currently running upgraded Debian 9) the data to be migrated to Server2 (running Ubuntu 20.04 using the above mentioned autoinstall) and once it's finished, the Server1 will be wiped and installed clean with the Ubuntu 20.04 autoinstall again. Then the data will be migrated back using the Toolkit from Server2 (running Ubuntu 20.04) to Server1 (now newly running Ubuntu 20.04).

    The issue is the How To Migrate ISPConfig 2, ISPConfig 3.x, Confixx or Plesk to ISPConfig 3.1 (single server) explicitly says that "The old and new server must use the same Let's Encrypt client. If your old server uses certbot, then ensure that the new system is using certbot too and not acme.sh."

    My questions are following:
    Q1: Is there any reason why the acme.sh is recommended over the certbot? (really just curious)
    Q2: How to best deal with this certificate generation tool incompatibility?

    Like I said the old servers are running certbot the new servers will be probably running acme.sh (as it's recommended), can we somehow choose to not migrate the certificates and just let the Server1 [after the clean autoinstall now running Ubuntu 20.04] generate new certificates using the acme.sh? What's the best approach to this? Setup self-signed certificates on Server1 prior to the two data migrations? Would it then not migrate the certificates? Something else?

    I don't mind if there are invalid/self-signed certificates (as I do the two data migrations Server1->Server2->Server1) on the websites for couple of hours, I just want a clean setup that is less headache in the future to migrate using the Toolkit from Ubuntu 20.04 to Ubuntu 22.04 LTS.

    Thank you in advance.
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    Certbot has been proven to be less stable in the way that they always change the way it works, and how it#s installed, this means that there are already dozens of workarounds for various issues in certbot in ISPConfig. acme.sh on the other hand, is stable, easy to install and longtime stable, that's why we normally use it on new installs. There is one exception though, don't install acme.sh when you plan to migrate a system that uses certbot onto this server.

    Do not switch from certbot to acme.sh or from acme.sh to certbot. Always keep the client that you originally used.

    Btw. Moved your post to the ISPConfig addons forum.
     
  3. curiousadmin

    curiousadmin Member HowtoForge Supporter

    Hi till,

    Thank you for the quick followup. I really would like to have a long term, solid future proof solution. Is there really no way to switch from certbot to acme.sh while using the painless ISPConfig Migration Toolkit I already have license for?

    If I shifted the data manually (imapsync for emails, the FTP download/upload, manually re-created the users for the sites and the MySQL backup&restore) I could simply re-create the certificates by ticking the boxes in the ISPConfig web admin...
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    That's something that you can do with the Migration Tool as well of course. Use --skip-letsencrypt option to skip copying over the LE certs. It might just be that LE refuses to recreate all certs when you hit their max day or week limits.
     
  5. curiousadmin

    curiousadmin Member HowtoForge Supporter

    Ah that's a cool switch! I wasn't aware that it's actually available there, maybe can you please update the list of "Advanced options" at https://www.howtoforge.com/tutorial...-confixx-plesk-to-ispconfig-31-single-server/ ?

    As the old certificates are not going to be renewed under Debian 9 (it became incompatible) it might be a good selling point to know that this is taken care of as well :)

    I'm not worried about the LE - the limits seem rather generous: https://letsencrypt.org/docs/rate-limits/ and I don't have more than 20 domain names per IP/ISPConfig installation/VPS and basically no subdomains (except for the www)

    In the very worst case scenario I will enable the shared Cloudflare certificate by enabling the reverse proxy in the meantime, I assume this will work as a workaround.
     

Share This Page