Changing ACME Server per site

Discussion in 'Feature Requests' started by Kenneth Hardy, Oct 20, 2021.

  1. Kenneth Hardy

    Kenneth Hardy New Member

    It would be great if optional (advanced) site specific options for letsencrypt could be added.

    Specifically I would love to be able to change the following two options for certbot per page:
    --server (
    --preferred-chain (

    This due to the default acme server and preferred chain not working on certain older Android devices since september 30:

    My "workaround" for those specific pages are to use another ACME server. Specifically buypass. The certbot command looks exactly the same, just needs to change --server setting from the default " or v02" to "".

    I had a look in /usr/local/ispconfig/server/lib/classes/ and this seems like a minor thing to change. Not sure how to implement i GUI, but the letsencrypt certbot file would probably just need a change to look for another thing in IF to set "$acme_version".

    If anyone else is interested in this I could try to write an implementation myself.
    Last edited: Oct 24, 2021
  2. Kenneth Hardy

    Kenneth Hardy New Member

    Last edited: Oct 24, 2021
  3. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    I think you definitely should contribute via ISPConfig git and ask for login access from the developers if you haven't got any yet.

    Just note that ISPConfig preferred LE client is and certbot is kept mainly to cover older servers and migration from them, so any proposal should cover both.
  4. Kenneth Hardy

    Kenneth Hardy New Member

    Thank you ahrasis. Will read through since I have not done that yet. Until now all my installations have been running certbot unfortunately. Will also ask for login access from developers. Would be great to contribute.
  5. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    No worries. Even if you are not familiar with, do contribute with whatever you can as much as you can.

    I myself am not familiar with but I contributed any way to the best of my knowledge, as the developers will always check all the contributed codes and give their feedback before finally merging the codes with or without changes.

    What I currently am doing is coding Let's Encrypt DNS challenge support for ISPConfig.

    For the time being I find that the dns secret access code for, while using export command, will be kept inside ISPConfig server which I think is unsafe for the clients as this can be easily accessed by ISPConfig server admins.

    Except for LE client certbot, I do not find any other way to create and keep this dns secret access code inside the clients' web site root folders for yet.

    I am still trying to figure it out though, but I am not really focus on resolving this as this is not my main priority and I don't think it is ISPConfig main priority either.

    For now, I think the best is opening this issue in github, but I my self personally am not sure whether this is an issue at the first place.
  6. Kenneth Hardy

    Kenneth Hardy New Member

    Maybe a dumb question but wouldn't everything be available for a ispconfig / server admin no matter where you try to "hide" it in the setup?

    Me myself would not see it as an issue in the first place. If was to host my website(s) with someone else I would need to trust that host in the first place. I think the same way for anywhere i host servers.
  7. Kenneth Hardy

    Kenneth Hardy New Member

    However, back to the main topic:
    I installed a new server according to the perfect server guide for Ubuntu 20.04. But i swapped out Apache for nginx and substituted some other things to my likings. So its more or less exactly the same as Perfect server 18.x with nginx.

    I missed to skip certbot installation, but this did not seem to cause me any problems at all since i installed it manually using snap. I have seen others in the forum getting great headache from trying to swap from certbot to For me it was pretty straight forward. I removed all existing certificated I could find and uninstalled certbot using "snap remove certbot".

    Thereafter I just ran " --force" which seems to have installed instead.

    So now I only need to find a way to fix two things on a per site basis:
    1) Choose which CA to use when enabling "Letsencrypt" under site settings.
    2) Also add the corresponding CAA entry in DNS-settings for that domain.

    After reading through the ""-script (which if very well written btw) it seems to be very simple to achieve at least number 1. I just need to find a way to do it directly in the ispconfig GUI and not only manually in filesystem.
  8. Kenneth Hardy

    Kenneth Hardy New Member

    Just writing down my thoughts here for convenience and if anyone has feedback.

    Another alternative (or a maybe more like a hack?) to doing the GUI changes could be to add a settings file for each site directly under /var/www/clients/client[0-9][0-9]/domain.tld/ssl/.settings. And just write another IF-statement in /usr/local/ispconfig/server/lib/classes/ to look for this file. If no file is present then it will simply not bother.

    Such a setting file could look something like:

    Which in turn just goes straight to the command issued by Example for buypass:

    From what I've gathered so far the crontab will remember this for next time it makes the renewal.
  9. Kenneth Hardy

    Kenneth Hardy New Member

    By trial and error I found that /root/ contains exactly the settings needed. Those settings are written once a certificate is issued. As a temporary fix/test I did change the "Le_NextRenewTime" to the past and also changed "Le_API" to BuyPass CA. This gave me a new certificate and proves that this should be a possibility.

    If I renew my certificated now, the ispconfig install will fetch (if expired) a certificate from letsencrypt CA whilst my test domain fetches it from buypass.

  10. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    It is true in a sense but there are duties imposed to every server admins by laws on data and privacy like GDRP and even in the common laws, therefore, it is safer to be kept in their own web site directory rather than in the server in general.

    The leak of such dns secret access code could be disastrous.

Share This Page