Updating Internal Domain SSL: PluginError('An authentication script must be provided

Required details are appended to this post.

I have a problem RENEWING a few INTERNAL ( based domain names, these are only used on our LAN and are really only useful to us.

Because they are INTERNAL ip addresses I had to use DNS challenge.

I created them about 3 months ago, they are now due for renewal, but I have problems renewing them. When I created them I followed the instructions to the dot and did not have any problems creating the TXT records, SSL certs etc.

ALL TXT record for the INTERNAL domains (_acme-challenge.*) are still in the ZONE file for the domain, they STILL contain the SAME value when I created them.

I have no problem INTERNALLY doing a “host jack.barrett.com.au”.
I can see the correct “_acme-challenge.jack” TXT record.

How can I update the SSL?
Do I need every time when I update the SSL change the TXT record _acme-challenge.jack?
Do I need to use a different approach CREATING the record?

Am I doing something wrong?


My domain is (INTERNAL DOMAIN!)

I ran this command (CRONTAB)
/usr/local/bin/certbot-auto renew --max-log-backups 25 --non-interactive --no-bootstrap --no-self-upgrade

It produced this output:

Processing /etc/letsencrypt/renewal/jack.barrett.com.au.conf

Cert is due for renewal, auto-renewing…
Non-interactive renewal: random delay of 235 seconds
Could not choose appropriate plugin: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError(‘An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.’,)

My web server is (include version):

The operating system my web server runs on is (include version):
CentOS 7.X

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):
yes, SSH, keybased

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

1 Like

In short, yes. The value of the TXT record will need to change for every renewal that requires a new challenge. New challenges (per unique name in a cert) are required after the previous challenge cache has expired. If I recall correctly, I believe the current cache time is 30 days.


Can this be automated?
Do I have to every couple of months update these SSL certs by hand?

1 Like

Yes. That’s the idea in --manual-auth-hook and --manual-cleanup-hook.

You would create a script that updates the TXT records, using whatever mechanism your nameservers provide.

For example, using nsupdate/RFC2136, or something else. (Though there’s a prebuilt Certbot plugin for that case).


Sorry, not made myself clear enough!

Can this be automated launching it via /etc/crontab or do I need to run this on the command line?


1 Like

Can what be automated?

If you can use one of the mechanisms available to automate it, it can be automated.

If you can’t – if you have to run certbot interactively and copy and paste TXT records into your DNS to renew your certificate – it’s not automated and can’t be placed in a cron job.

It looks like you run your own DNS servers, so you can likely set up the RFC 2136 plugin.

1 Like

Figured it - this should be made more obvious in the documentation in the guide for how to do “Pre and Post Validation Hooks”. The problem I was having it was asking me whether I accept logging of my ip-address - you can’t do that in a script.

There is the not so well know switch “–manual-public-logging-ok” which accepts the logging automagically so not need to press “y” - I did not know this existed as “certbot --help” does not give much information away.

So after half an hour of frantically searching the Internet - the trouble always is the search term - I finally found the answer in stackoverflow as some other poor sod had the same problem.

It happily running and updating from crontab now.

1 Like

You should also add -n/--non-interactive on any invocation of Certbot you make via cron. That way, it will avoid doing things like prompting for input, and instead immediately fail or choose a sensible default.

1 Like

I have, but the missing “–manual-public-logging-ok” will overrule that.
That was really my problem, not knowing about the switch and the internal overrule of the “-n” switch.


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