Checking the log (after having clearing some problems with renewals), I was surprised that there is no identification of which certificate is being considered, when.

Here is the beginning of the latest check (I have four certificates) but none of the entries indicate which certificate/domain(s) is being checked (nor can I tell which during the other three interactions).

Are there options for more verbose (or fewer “DEBUG” ) entries?

2019-09-08 08:00:03,332:DEBUG:certbot.main:certbot version: 0.38.0
2019-09-08 08:00:03,332:DEBUG:certbot.main:Arguments: [’-q’]
2019-09-08 08:00:03,332:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2019-09-08 08:00:03,357:DEBUG:certbot.log:Root logging level set at 30
2019-09-08 08:00:03,357:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2019-09-08 08:00:03,411:DEBUG:certbot.plugins.selection:Requested authenticator <certbot.cli._Default object at 0x7fead6bb3cd0> and installer <certbot.cli._Default object at 0x7fead6bb3cd0>
2019-09-08 08:00:03,411:DEBUG:certbot.cli:Var rsa_key_size=4096 (set by user).
2019-09-08 08:00:03,411:DEBUG:certbot.cli:Var server=https://acme-v02.api.letsencrypt.org/directory (set by user).
2019-09-08 08:00:03,411:DEBUG:certbot.cli:Var server=https://acme-v02.api.letsencrypt.org/directory (set by user).
2019-09-08 08:00:03,411:DEBUG:certbot.cli:Var account=set([‘server’]) (set by user).
2019-09-08 08:00:03,411:DEBUG:certbot.cli:Var renew_hook=/root/bin/certbot-renew (set by user).
2019-09-08 08:00:03,460:INFO:certbot.renewal:Cert not yet due for renewal
2019-09-08 08:00:03,462:DEBUG:certbot.plugins.selection:Requested authenticator apache and installer apache
2019-09-08 08:00:03,470:DEBUG:certbot.plugins.selection:Selecting plugin: * apache
Description: Apache Web Server plugin
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = certbot_apache.entrypoint:ENTRYPOINT
Initialized: <certbot_apache.override_centos.CentOSConfigurator object at 0x7fead1bdcfd0>
2019-09-08 08:00:03,471:DEBUG:certbot.plugins.storage:Plugin storage file /etc/letsencrypt/.pluginstorage.json was empty, no values loaded

certbot-auto 0.38.0
CentOS 7

1 Like

Hi @davnei,

You may want to check out the certbot certificates command. https://certbot.eff.org/docs/using.html#managing-certificates.

I assume the log you’ve posted is from /var/log/letsencrypt? https://certbot.eff.org/docs/using.html#log-rotation



Thank you for the advice, but the certificates command requires one to first know that there’s been a problem in the update cycle (automated through cron), to then log-in to the server, then to figure-out which certificate/domain(s) require attention - and doing it that way requires one to manually decide which domain (of ‘however many’ - although mine are few) by reading every certificate-date/time-left entry. It’s a work-around.

Meantime, the server produces a log on the server. (log rotation is irrelevant BTW as we are only interested in ‘the latest activity’!) Logs can be monitored centrally (ie no manual/specific log-in step required) and/or emailed for inspection (again, no need to log-in to the remote server). Log processing software directs an administrator’s attention and saves reading (boring) repetitive entries. Such works well if the log-entry is appropriately descriptive, but can only issue an ‘alert’ to spark manual investigation otherwise!

In the above example log (yes, from /var/log/letsencrypt), renewal was not necessary. Let’s say it was - and for multiple certs. Further, let’s say that one certificate failed to renew but another/others renewed happily, as one would expect. To which certificate/domain’s renewal process should I direct my attention?

Refer to something like Apache/httpd. If a problem occurs during server operation, the log will identify which virtual-host/file is involved. It always labels access to vhostA appropriately, and thus there is no confusion with analysis of vhostB - and no need for extra investigation to ascertain ‘which vhost?’.

Let’s Encrypt log entries fail to identify the applicable certificate/distinguish between all of the certs/domains that may be included in one automated and regular renewal check - despite such being fundamental to the philosophies and purposes of logging!

(or am I missing something?)
Further thoughts?
Regards =dn

FWIW, when Certbot does attempt to renew certificates, the logs are pretty clear about what’s going on.

Thank you @mnordhoff - that ‘the’ certificate was reviewed and is not yet due for renewal, I agree that the log is clear.

But…, using the log reproduced in the first post, please advise where it shows which certificate is being considered for renewal (as distinct from the three other certificates which were considered in-turn, immediately afterwards, and in the same run of certbot-auto)?
(yes, some of my certificates have different ‘anniversaries’ to the others)

Regards =dn

I think this would be a good suggestion to pose to the Certbot developers at https://github.com/certbot/certbot/issues.

Possibly it is a logging volume problem if Certbot is managing hundreds or thousands of certificates, but at least, it can be discussed.

1 Like

I don’t disagree with you, but why does it matter which certificate it is? Certbot checks every certificate. And nothing can normally go wrong, unless the files are corrupt or something.

1 Like

Yes, I think our thinking on this was that all renewal problems are always logged in detail, whereas decisions not to attempt renewal are much less interesting and hence are not logged. (They should usually align with the output of certbot certificates.) I’m sure we’d be happy to hear about a proposal to change this on the GitHub issues page as mentioned by @_az.

Note that there is also a recent proposal for a failure hook (to run a script specifically in response to each failed renewal), although this also hasn’t been implemented yet. It might turn out to cover some of the same use cases in practice.

Thank you all.
(elements of this post use Linux-based examples and thus require translation/generalisation to cover other OpSys)

Unfortunately, I do not have a GitHub (or any other Microsoft, Apple, …) ID. Otherwise I should follow @_az’s recommendation.

@schoen’s summary applies: in log analysis the principle is to manage by exception - we are really only interested in a log-entry when it reports ‘failure’. The exception to this is ‘statistics’, which I can only imagine would be (in this example) “4/4 Certificates are current”.

I can’t categorically state that when a Let’s Encrypt certificate is due for replacement and if the certbot-auto operation fails, what is (not) included in such a log-entry. It is apparent that the certificate name is not included in ‘no update needed’ situations (and it will be a while before I can view the log covering an ‘update-needed-and-worked-happily’ scenario).

Kudos to the authors, in that I have only experienced one ‘log-able’ error with the Let’sEncrypt routine/regime, and that was due to updating certbot before CentOS7 was ready - hence moving to certbot-auto. That problem was notified by a cron alert, and thus wouldn’t/didn’t get as far as the letsencrypt log!

Now, back to the ‘problem’ and proposing a solution:

i) I recommend that EVERY log entry include the name of the certificate to which it pertains, ie that the current “cerbot.cli” or “certbot.renewal” (becomes more specific); when possible/applicable. This will enable/ease log post-processing and administrative reporting.

ii) I recommend the inclusion of a switch in the (/etc/letsencrypt/)cli.ini configuration file to allow administrators to select a logging level, ie to be able to exclude DEBUG communications. This will reduce the volume of log-entries (a somewhat weak justification!), and improve readability for more mature installations. (cli.ini should be installed with the ‘maximum setting’ and alteration be a user-choice and require deliberate (SysAdmin) user-action).

NB recommendation (i) is likely a more appropriate solution (in this scenario) than, but may have the effect of reducing use-cases for the “failure hook” proposal.

Thanks for the good work and for effecting wider security across the web!

Submitted at


Many thanks @schoen.
Regards =dn

1 Like