LE (still) not renewing automatically in Webmin

as it says here

anyways, still no joy. still manually generating a new certificate the week before the existing one expires.

any specific help on where to look for the log(s) that might shed some light on whats going wrong would be great. been babysitting this thing for 2-1/2 years now. :frowning:

Are you using website or DNS validation? Does it work from within the Webmin UI when you manually request a certificate?

You might try changing the renewal frequency, as I’d guess that would trigger recreation of the scheduled job. I don’t know if this code uses a cron job or a Webmin scheduled job…might be worth poking around in those to see if there’s a job for this purpose and if it’s enabled.

as @Joe suggested try changing auto renewal to 2 months per domain & also check /etc/letsencrypt/renewal/domain.conf for any weird settings.

also, are there any auto-renewal tries in letsencrypt.log ? if so, post some log excerpt.

website validation.

manually requesting the certificate works every time.

long ago tried changing the renewal frequency.

/etc/letsencrypt/renewal/domain.conf for the affected domain looks nearly identical to the virtualmin domains that renew flawlessly. the only difference i saw was in the order of the things under [renewalparams].

letsencrypt.log is seriously verbose. it looks chock full of attempts to renew a certificate for a virtual host that was created and deleted months ago. i’d like to resolve this to cut down on the verbosity so i can better interpret the log.

any notions how i might go about that? why a virtual host that was deleted months ago is showing up in LE renewal logs?

A possible way to work around cron is to setup a systemd timer. I see where the cerbot-renew timer service can be enabled from Webmin/System/Bootup and Shutdown, but I don’t see a GUI way to fine-tune it, so you’ll need to use the command line and/or file manager.

That’s a different problem, maybe start a new topic?

1 Like

didnt help - no response.

still no help over there.

new topic set to expire soon.

after creating a new virtual server yesterday afternoon, i noticed dovecot and postfix both refusing connections. mail.err indicated a malformed /etc/dovecot/dovecot.conf. and indeed the file was half a mess. a } was missing and entries had run together. furthermore, entries for the virtual machines were not entirely consistent. besides local_name directives for domain.tld and www.domain.tld, most had directives for autoconfig.domain.tld and autodiscover.domain.tld, but not all. inside the local_name directives, all had ssl_cert and ssl_key, but some also had ssl_ca. and some of the ssl_cert’s pointed to /home/user/ssl.cert, while others read /home/user/ssl.combined.

wasnt sure if this could be related, so i thought i would include it since this has proven to be such a vexing issue that im seemingly no closer to a solution than i was when first reporting it back in october 2017.

while manually straightening out the files has got dovecot and postfix running again, im curious how the file should read in regards to the inconsistencies noted above? and is there an automated way to rebuild it?

Get rid of the ssl_ca lines. If a combined file exists, you can point to it, but it’s mostly harmless if it stays pointing to ssl.cert (just some older and mobile clients will give a cert warning).

There is a new bug in Dovecot which is fixed upstream and will be fixed as soon as we do a new release (I hope).

But, none of this is related to your original problem. Webmin LE is almost wholly independent of Virtualmin LE. I’ll ask Jamie if he has any ideas.

ca lines destroyed.

.cert>.combined for all virtual servers upon confirmation of said file’s existence. also added a pair of virtual servers upon not finding them in /etc/dovecot/dovecot.conf at all.

how about the autoconfig/discover discrepancies? should i normalize those across all virtual servers as well?

1 Like

of all the things at webmin>system>scheduled cron jobs, i only see one that jumps out as le-related. its set to run the following at midnight and noon of everyday.

test -x /usr/bin/certbot -a ! -d /run/systemd/system && perl -e ‘sleep int(rand(43200))’ && certbot -q renew

manually running it, either in webmin or at the terminal, produces no output there or in /var/log/letsencrypt/letsencrypt.log.

however, webmin>webmin>webmin configuration>webmin scheduled functions lists a function named “renew_letsencrypt_cert” that when manually ran via webmin produces this output in /var/log/letsencrypt/letsencrypt.log, though it does not end in a newly renewed certificate being installed. i noticed something squirrelly towards the end - the reference to “virtual-server-owner@virtual-server-domain.tld”. for what its worth, it happens to be the very last virtual server added to the system. i ran the function again a few minutes later to confirm it wasnt a coincidence.

is there anywhere else i should be “poking around” for webmin le renewal jobs?

There’s a quite long randomized sleep in there, so it won’t immediately do anything. Could take up to 12 hours. So, it’s supposed to run sort of randomly at some point during every 12 our period.

That is the job. The question is why it isn’t running or is being killed before it finishes waiting to run certbot. I don’t have good guesses.

Oh, and I guess this confirms Jamie moved the renewal and config process out to certbot entirely (that’s good, we used to handle a lot more of it when acme_tiny was the client everybody was using, and still does for the folks on CentOS 6), now it’s just scheduled via Webmin code.

So running certbot renew does or does not result in something in the log (and on the console if you leave off the -q)? I think it’ll just say no domains new renewal most days.

certbot renew loops through each virtual server domain and the webmin domain, stating Cert not yet due for renewal. and thats correct for all of them but the webmin domain, which is nearing a month overdue for renewal.


# renew_before_expiry = 30 days
version = 0.27.0
archive_dir = /etc/letsencrypt/archive/webmin-domain.tld
cert = /etc/letsencrypt/live/webmin-domain.tld/cert.pem
privkey = /etc/letsencrypt/live/webmin-domain.tld/privkey.pem
chain = /etc/letsencrypt/live/webmin-domain.tld/chain.pem
fullchain = /etc/letsencrypt/live/webmin-domain.tld/fullchain.pem

# Options used in the renewal process
account = [32 character alphanumeric]
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = webroot
manual_public_ip_logging_ok = True
rsa_key_size = 2048
webroot_path = /var/www/html,
webmin-domain.tld = /var/www/html
lamp1.webmin-domain.tld = /var/www/html
smtp.webmin-domain.tld = /var/www/html
ftp.webmin-domain.tld = /var/www/html
webmail.webmin-domain.tld = /var/www/html
mail.webmin-domain.tld = /var/www/html

since the current certificate for webmin-domain.tld is valid from 6/3/20 to 9/1/20, and with the above settings, it shouldve been eligible for renewal for about a month now. so why does certbot say otherwise?

It isn’t due for renewal. I think the default (which you’ll get if you remove 30 days, I think) is…30 days. And, we aren’t there yet. On roughly 8/1 it’d be eligible to renew.

i currently have it set to one month between automatic renewals in webmin>webmin>webmin configuration>ssl encryption>lets encrypt. shouldnt that mean renewal attempts shouldve begun a month later, around 7/3?

Then Webmin is doing something wrong, if what you posted above is your whole config. That option defaults to 30 days before expiry, so unless it is explicitly set otherwise (it’d be 60 days if you wanted it to renew after one month, which is overkill, but fine for testing) it’s not going to try to renew until ~8/1.