When Let's Encrypt fails..

With pre-existing SSL rules, forcing the web going to SSL
especially when migrating (such as Apache Directives, htaccess etc)
Let's Encrypt will fail
Not being able to run SSL right, the procedure will not be activated
makes sense!?

Hope this can be useful for someone

Greetings to all

 

If you have problems with Let's Encrypt, there is FAQ:
https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/
I admit I did not understand what your message #1 was about.

 

means it works with a site clean of any SSL configuration
for e.g. not with migrated sites didn't use Let's Encrypt before

 

Nope. It works that way as well, provided, the LE certs are transferred properly too and the LE client remains the same on both servers.

 

in my last case:

• old ISP version
• old certificate purchased
• old apache directives to force use SSL
• migrated with the Migration Tool to the new ISPConfig
  • Let's Encrypt from certbot** to acme version

** certbot was not as service.. (not ISPConfig managed)
You understand.. I had to clean up something first
I was talking about truly desperate cases like mine

Absolutely NOT critical about ISPConfig, using for years, the GREAT Migration Tool started using now or Let's Encrypt..

Thanks to all, thank you so much for your time

 

Today, without errors (apparently, I see), Acme Let's Encrypt stopped to issue certificates
the SSL and Let'sEncrypt checkboxes remain flagged without any change under .acme.sh ssl folders, logs etc
I did an update (stable) + resync, but this time without success
... reading many times https://www.howtoforge.com/community/threads/lets-encrypt-error-faq.74179/

the only error I see is this BUT NOT RELATED
==> /var/log/apache2/error.log <==
[Sat Jul 31 17:32:57.194911 2021] [fcgid:emerg] [pid 12955] (22)Invalid argument: [client 212.43.110.236:47457] mod_fcgid: can't lock process table in pid 12955, referer: https://XXXXXXXXXXXXX:8080/index.php
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message
[Sat Jul 31 17:32:57.431313 2021] [ssl:warn] [pid 2392] AH01909: 127.0.0.1:8080:0 server certificate does NOT include an ID which matches the server name
[Sat Jul 31 17:32:57.432044 2021] [mpm_prefork:notice] [pid 2392] AH00163: Apache/2.4.38 (Debian) mod_fcgid/2.3.9 OpenSSL/1.1.1d mod_perl/2.0.10 Perl/v5.28.1 configured --resuming normal operations
[Sat Jul 31 17:32:57.432065 2021] [core:notice] [pid 2392] AH00094: Command line: '/usr/sbin/apache2'
[Sat Jul 31 17:32:57.432099 2021] [mpm_prefork:warn] [pid 2392] AH00167: long lost child came home! (pid 12950)

UPDATE:
suddenly, working again without further intervention
may be related to xfs quota management, just a suspect
UPDATE:
fixed xfs quota management with an updated od ISPConfig auto-re-configuring services on/yes

 

Looks like you some DNS issues.
"Could not reliably determine the server's fully qualified domain name, using 127.0.0.1. Set the 'ServerName' directive globally to suppress this message"
You might want to follow that advice.

 

I reopened this thread because I had an issue with the server certificate
I'm using "acme.sh" method and referring to ispserver.crt, ispserver.pem, etc. in /usr/local/ispconfig/interface/ssl/ but also to those related to the server (FQDN) under acme.sh

Updating to the latest version (currently ISPConfig 3.2.7 release) I immediately noticed my mistake in the host file:
127.0.0.1 localhost [myshortservername] [myfullservername]
instead of
127.0.0.1 localhost
[IPADDRESS] [myshortservername] [myfullservername]

What a bad Root! Ha!
First I fixed the Hosts file and the update procedure would have fixed everything
in fact it happened that some mail clients could no longer connect..

So I would say that the management and therefore configuration of the Fully Qualified Domain Name is one of the basic things for a good functioning of ISPConfig.

In any case I have created some scripts, OpenSSL based, to check all the certificates..

But my question now is:
how acme.sh works with certificates between ~.acme-sh and /usr/local/ispconfig/interface/ssl/
and .pem is updated like other certificates or not ?

Thanks to everyone and hope to be a little help for someone as well

 

So far that I know, acme.sh folder only retains LE certificates and their renewal info after they have been successfully obtained.

The certificates will then be installed to the intended folder which is the SSL folder for the relevant websites under ISPConfig including ISPConfig own SSL folder which is to be used for all its services within that server.

However, ispserver.pem is a combination of ISPConfig LE SSL key and full chain certificates and its renewal is ensured via a script that is set to run immediately after every renewal of its LE certificates.