Disable automatic renewal of Lets encrypt

We have a server where we have been using our own ssl for years. For some time ispconfig has been doing this by overwriting our ssl with a lets encryt ssl without saying anything. If I overwrite it with ours, it will overwrite it again with lets encrypt after 3 months. But it only does this for one of our servers. How can I disable it so that it doesn't want to use Lets encrypt ssl at all costs?

 

I try get certificate, but nothing show:

~/.acme.sh/acme.sh --list
Main_Domain KeyLength SAN_Domains CA Created Renew

 

Not. There isnt cert under /etc/letsencrypt. Only one file there: ntpsec under renewal-hooks/deploy

 

What is in that file? I mean, something is doing something.
Who did the setup of the ssl? Are there any crons trying to get the files from a folder which uhm I don't know
is part of a multiserver ispconfig setup and is deploying certs?
And as you did not say, though I assume but must ask, Letsencrypt is disabled for that domain?
Does the domain have aliasdomains or subdomains which use LE?

 

ntpsec conatains the following code:

Code:

#!/bin/sh -eu
# vim: ai ts=4 sts=4 et sw=4

if [ -r /etc/default/ntpsec ]
then
    . /etc/default/ntpsec
fi

if [ -z "${NTPSEC_CERTBOT_CERT_NAME-}" ]
then
    exit 0
fi

# If the certificate being deployed is not the one for ntpd, exit.
found=0
for domain in $RENEWED_DOMAINS
do
    if [ "$domain" = "$NTPSEC_CERTBOT_CERT_NAME" ]
    then
        found=1
    fi
done
if [ "$found" = "0" ]
then
    exit 0
fi

# Copy the certificate (including chain) and key so ntpd can read them
# after dropping privileges.
install -m 644 /etc/letsencrypt/live/"$NTPSEC_CERTBOT_CERT_NAME"/fullchain.pem \
    /etc/ntpsec/cert-chain.pem
install -m 640 -g ntpsec \
    /etc/letsencrypt/live/"$NTPSEC_CERTBOT_CERT_NAME"/privkey.pem \
    /etc/ntpsec/key.pem

# Tell ntpd to reload the certificate and key.
killall -HUP ntpd 2>/dev/null || true

It is not a multi-server. As far as I know, we've never used a secret key on this domain. I just looked back at the tickets, and this problem first appeared on January 22 (so exactly 3 months ago like letsencrypt life time), and ispconfig was also updated to version 3.2.11p2 on that day. This problem did not occur before (and before that, ispconfig was updated several times). So something strange happened during the update.
We keep our own certs under /etc/certs, and here I overwrite them with letsencrypt, but strangely the name of our certs is kept (domain.crt, domain.key)

Root cronjob the following:

Code:

37 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null
* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
* * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done

 

One more thing. Today I did an ispconfig_update.sh --force to see maybe that solves the problem. Maybe it deleted the possible cert from /etc/letsencrypt?

 

Hmm eventually - and despite my tag on this forum I do not know much about internals - it shows in the logs if it removed / cleaned up things?
Possible lazy way to solve this would be to use auditctl -w /path/to/your/live.cer -p war -k recognizeablesearchstring_mycertinlogs

and watch for ausearch -f /path/to/your/live.cer


or wait for till to have some, hopefully donored, coffee

or fs_usage in a screen window maybe

just in case it is not ispconfig. but if it is, you'd know when and may be able to have a better entry point in the debug logs you have enabled on ispconfig by now? or just use the certs mtime ya ya

 

I thought that it activated/deactivated the operation of letsencrypt, because there is a question about whether to generate a new cert.

 

Unfortunately, auditd was not installed by default, so even though I installed it and set it to the files in the cert folder, I have to wait 3 months before it is overwritten again

 

yes, this was just something I could suggest. Not knowing how long it'd take for till to receive some coffee
Sometimes you'd well have to wait a few *g But hey, maybe someone learned something new for other use cases

 

Thank you both very much for your help. Now there will be a long wait, so this ticket can be closed.

 

you could see what happens if you chattr +- i a file, then auditctl it and check if overwriting it would be logged still, this I did not try.
at least you could prevent ispconfig ( or whatever ) from overwriting it.

 

I did chattr +i in January and still something managed to overwrite it. So it's very mysterious to me. Hopefully in 3 months I'll see what's bothering me like this.

 

oh nice, that is indeed a good info to know as there are some places where it could have been ispconfig.
And one could add some extensive debug code in 3 months to that :?

 

maybe those are better spots

 

Uhm, Unfortunately, I don't understand any of these.