Apparent letsencrypt misconfig? Bug?

I was scanning my syslog for another issue, and came across an error sequence shown below. Digging in on it, I discovered the following:

  • In /etc/letsencrypt/renew, the file set appears rather strange:

-rw-r–r-- 1 root root 0 Feb 27 17:08
-rw-r–r-- 1 root root 637 Feb 27 17:20
-rw-r–r-- 1 root root 637 Mar 3 11:30
-rw-r–r-- 1 root root 637 Mar 3 11:35

As you can see, the primary file (without “-nnnn”) is empty!

  • As a result, certbot refuses to run.


  • What should this look like?
  • Is this a known bug or known outcome of some kind of user/setup error?
  • Any ideas for how to fix? (Obviously I can try putting one of the other files in place… but would prefer to help find and fix whatever the bug is :slight_smile: )

From syslog:

Apr 2 20:38:03 aster certbot[543]: Traceback (most recent call last):
Apr 2 20:38:03 aster certbot[543]: File “/usr/lib/python3/dist-packages/certbot/”, line 68, in _reconstitute
Apr 2 20:38:03 aster certbot[543]: renewal_candidate = storage.RenewableCert(full_path, config)
Apr 2 20:38:03 aster certbot[543]: File “/usr/lib/python3/dist-packages/certbot/”, line 444, in init
Apr 2 20:38:03 aster certbot[543]: “file reference”.format(self.configfile))
Apr 2 20:38:03 aster certbot[543]: certbot.errors.CertStorageError: renewal config file {} is missing a required file reference
Apr 2 20:38:03 aster certbot[543]: Renewal configuration file /etc/letsencrypt/renewal/ is broken. Skipping.
Apr 2 20:38:03 aster certbot[543]: 0 renew failure(s), 1 parse failure(s)
Apr 2 20:38:03 aster systemd[1]: certbot.service: Main process exited, code=exited, status=1/FAILURE
Apr 2 20:38:03 aster systemd[1]: certbot.service: Failed with result ‘exit-code’.
Apr 2 20:38:03 aster systemd[1]: Failed to start Certbot.

Operating system Debian Linux 10
Webmin version 1.990
Usermin version 1.834
Virtualmin version 6.17-3
Authentic theme version 19.85.1OS
All packages up-to-date 4/2/22

I don’t know where those numbered files are coming from on your system. There shouldn’t be a bunch of files there at all, as far as I know (your system looks different from any of mine, I honestly don’t know what is happening there).

@Joe well some of us like the folk here like to do stuff differently - however I can see he is coming from Debian - he does create issues for him self - already solved - so I would be quiet touchy to even reply… which you did… any modifications to any config files - user should pass them into forum posts regardless - otherwise is just hi - I do not know what happen = hi, log files?

you know what I am saying…

Ummm… is there an issue with using the Debian install of Virtualmin? Not sure what you are saying about “create issues for him self”???

I began with a 100% normal install. My primary adjustments were:

  • Disable local bind, since my DNS is handled elsewhere (pretty common)
  • Server is on a LAN whose pfSense router manages IP assignments (also common)
  • My primary use is eMail so I did a LOT of Postfix-related config. Not sure how that might relate to this :wink:

@Joe, my guess is, if anything… I had to run letsencrypt several times before I got everything working properly.

If we’re going to have the new release soon, maybe I’ll just do a mostly-clean setup then rather than try to upgrade what I have. (Still will have to migrate users, email stores, etc etc… :wink: )

I have also external DNS, but let Bind run, so for good example for the dns to set external.
Also DKim is working then , sofar ik know this isn’t working ( in default setting) VMIN if DNS on the box is off.

Don’t know for this on LAN, for outbound IP’s but if done right it should.
IS “” the maincert you use also for services as vmin and more?

I can’t help while no debian.
But those above if you are using for mail i think you better have also DKim working if possible.

I you have to run letsencrypt more times then some timings (dns, or even traffic / connection to your box) ! ( or hickups letsencrypt itself sometimes there are)
Is this with newly created virtualservers / domains ? Then the dns resolving time maybe…

(Oyea if you use (local) box or one that is with IPV6 also connected and no fixed IPV6 but DHCP it can takes some time before the IPV6 connections are there and you have one from a provider, here with al local Fiber provider this could take to 20 Minutes , so if your box is local and using internet provider then this could also be the problem for those delay, problems, often we get a other ipv6 on that line, we have a fixed on bussiness cable line)


  • is my cert for this server (that’s it’s name :slight_smile: )
  • DKIM, DMARC, SPF and more all work just fine
  • (FWIW, this is my 2nd oldest domain… it goes back to 1994. I have been doing email for a long time :smiley: )

I’ve answered part of my own question… still a little more research to do:

  • certbot creates new versions (-000N) whenever it detects any kind of difference during a renew, compared to the last time. Thus, any reconfiguration may cause this.
  • For now, apparently the only solution is to uninstall, wipe all certs, and reinstall.

I may do that eventually. For now digging further. My bent is to find root causes rather than bandaid over the issue. That way I can help others avoid getting burned by whatever caused this :wink:

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.