Swapping from acme to certbot (LAMP, Deb10, ISPC3)

Discussion in 'Installation/Configuration' started by axxies, Feb 21, 2022.

  1. axxies

    axxies Member

    Is it possible to swap out acme for certbot under ISPconfig3 ?
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    acme.sh is more stable, that's why all new ISPConfig systems use it. Why replace stable software with a less stable one?
     
  3. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    I'd say it's possible but the ISPConfig developers clearly prefers acme.sh over certbot as @till made that clear above and before.

    You may need to remove acme.sh and all its traces, install certbot via snap and then force update ISPConfig, creating LE certs for the server while updating and later on for the website(s) as well, if you have created any LE certs for it / them before.

    In my test that worked but it may be best for you to follow their advice on that i.e. simply maintain acme.sh for that ISPConfig server.
     
  4. axxies

    axxies Member

    Because we get the certificates issued with certbot, but not with acme.
    The problem I stated in another thread is still there and is not solved.
     
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    Then you should take a look into the log files and use the ISPConfig debug mode to find out which mistake you made while setting up your system that causes LE certs to fail. E.g. one reason can be that you left out the step to disable dash shell on Ubuntu and Debian systems, but this is shown by debug mode.
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

  7. axxies

    axxies Member


    We did follow that guide.

    This is the output of the acme.log

    Code:
    [Tue 22 Feb 2022 08:38:13 AM CET] Pending, The CA is processing your order, please just wait. (4/30)
    [Tue 22 Feb 2022 08:38:13 AM CET] sleep 2 secs to verify again
    [Tue 22 Feb 2022 08:38:15 AM CET] checking
    [Tue 22 Feb 2022 08:38:15 AM CET] url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/80961377500/ofx75w'
    [Tue 22 Feb 2022 08:38:15 AM CET] payload
    [Tue 22 Feb 2022 08:38:15 AM CET] POST
    [Tue 22 Feb 2022 08:38:15 AM CET] _post_url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/80961377500/ofx75w'
    [Tue 22 Feb 2022 08:38:15 AM CET] _CURL='curl --silent --dump-header /root/.acme.sh/http.header  -L  -g '
    [Tue 22 Feb 2022 08:38:16 AM CET] _ret='0'
    [Tue 22 Feb 2022 08:38:16 AM CET] code='200'
    »»»»»»»»     [Tue 22 Feb 2022 08:38:16 AM CET] crap.mydomain.com:Verify error:Fetching http://crap.mydomain.com/.well-known/acme-challenge/Iq7cVYS_TUnEdb1IUyTmwXeu8Zfd_fm-6P_TMd6RkY8: Timeout during connect (likely firewall problem)
    [Tue 22 Feb 2022 08:38:16 AM CET] pid
    [Tue 22 Feb 2022 08:38:16 AM CET] No need to restore nginx, skip.
    [Tue 22 Feb 2022 08:38:16 AM CET] _clearupdns
    [Tue 22 Feb 2022 08:38:16 AM CET] dns_entries
    [Tue 22 Feb 2022 08:38:16 AM CET] skip dns.
    [Tue 22 Feb 2022 08:38:16 AM CET] _on_issue_err
    [Tue 22 Feb 2022 08:38:16 AM CET] Please check log file for more details: /var/log/ispconfig/acme.log
    [Tue 22 Feb 2022 08:38:16 AM CET] url='https://acme-v02.api.letsencrypt.org/acme/chall-v3/80961377500/ofx75w'
    
    

    We disabled the firewall before that.
     
  8. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Looks like access from LE servers to that website does not work. Have you tried yourself in browser from outside your local LAN that same URL?
     
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    Like @Taleman mentioned, access from outside your network to the domain crap.mydomain.com on port 80 is blocked. Let's encrypt must be able to access the server to verify the SSL cert.
     
  10. axxies

    axxies Member

    I am able to reach ISPC3 there. Shouldn't that be good enough?
     
  11. axxies

    axxies Member

    How can it be blocked when UFW is disabled? (I have tried it with it enabled too and p80 opened)
     
  12. till

    till Super Moderator Staff Member ISPConfig Developer

    No. Let's encrypt (no matter if you use certbot or acme.sh) tries to connect from their servers (which are in the public internet) to your system on port 80 on the domain you try to get a cert for. if they can't reach the system on port 80, then issuing of the cert will fail. And it will fail in the exact same way for certbot too, both LE clients do exactly the same procedure.
     
  13. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    No, LE must be able to access that website and that file.
    Hard to say. Try in browser yourself to see what happens.
     
  14. till

    till Super Moderator Staff Member ISPConfig Developer

    At the time the cert request was issued, http://crap.mydomain.com/ could not be reached from the internet. This does not has to be a firewall on your system, it can also be a firewall in front of your system or a router in front of your system. Or the domain pointed to a wrong server at that time, might be the case as well.
     
  15. till

    till Super Moderator Staff Member ISPConfig Developer

    And just to mention it, you must test that from a system that is not in your network (the network of the server), might just be that you can access it but nobody else incl. LE can access it.
     
  16. axxies

    axxies Member

    It does seem to be closed. Strange.

    I tried to access the domain using lynx and it timed out. UFW is enabled again and p80 is opened.

    Any ideas
     
  17. axxies

    axxies Member

    The thing is that we have tried with certbot and with that a cert was issued.

    (long gone installation, we went nuts :) )
     
  18. till

    till Super Moderator Staff Member ISPConfig Developer

    Then it's likely that the domain pointed to a wrong system or a firewall was closed at the time you used acme.sh and this has changed at the time you started using certbot. As I mentioned already, certbot an acme.se do the exact same validation procedure. So there is no reason to switch to certbot as the issue was not acme.sh in your case.
     
  19. axxies

    axxies Member

    The problem is solved and you were right. This server has two IP addresses and the thing was that one of the was listening to p80, but the other IP was associated with the domain name.

    hahahaha! Embarrassing! :)

    Thank you!
     
    ahrasis and till like this.
  20. axxies

    axxies Member


    You liked it too fast. Actually it was I who cheered too fast. :)

    I was using my own DNS and that I got to work (still the thing with the IP), but when I go back to the org I am helping and their DNS (which also is ClouDNS.net, but a GeoDNS, they should have purchased a DDOS protected), then it doesn't work again. Grrr! So it has to do with the GeoDNS despite that the region is set to Default.

    Anyone who has some experience with that GeoDNS thingy?
    Could that cause this?
     

Share This Page