This API Token is valid and active BUT 6003 Invalid request headers. Please confirm that you have supplied valid Cloudflare API credentials

My domain is:

I ran this command:
certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/gldn.ini -d,*

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-cloudflare, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for
dns-01 challenge for
Cleaning up challenges
Error determining zone_id: 6003 Invalid request headers. Please confirm that you have supplied valid Cloudflare API credentials. (Did you copy your entire API key?)

My web server is (include version):
Apache/2.4.53 (Ubuntu)

Also running Nginx for reverse proxy

The operating system my web server runs on is (include version):
ubuntu 20.04

My hosting provider, if applicable, is:
dedicated by

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
HestiaCP but it doesn't do sub-domain LE certs so I am using command line

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

I have checked that the Cloudflare token is correct with the curl:

curl -X GET "" -H "Authorization: Bearer my-token-here" -H "Content-Type:application/json"

and I get back :

{"result":{"id":"3dfa37378f76e29afd63ca8474b696fe","status":"active"},"success":true,"errors":,"messages":[{"code":10000,"message":"This API Token is valid and active","type":null}]}root@expressresponse:/var/log/letsencrypt#

So I was disappointed that it didn't create the cert.

If you are using a scoped API token, then your gldn.ini should only contain dns_cloudflare_api_token.

Don't include dns_cloudflare_email or dns_cloudflare_api_key.


Thanks for reply.
I changed my ini file to:
dns_cloudflare_api_token = zltcUwQ4IxT5GIversome-letters-herepqRnd7

and ran the command:
certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/gldn.ini -d,*

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-cloudflare, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for
dns-01 challenge for
Cleaning up challenges
Missing properties in credentials configuration file /root/.secrets/gldn.ini:

  • Property "dns_cloudflare_email" not found (should be email address associated with Cloudflare account).
  • Property "dns_cloudflare_api_key" not found (should be API key for Cloudflare account, obtained from

So it didn't like that for some reason

Use of limited scope API tokens was introduced in Certbot 1.2.0. However:

You're using an ancient version of Certbot.

My advice is to go to and use one of the currently recommended methods of installing Certbot to get an up to date version.


I have updated to 1.27.0

certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/gldn.ini -d,*
certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...

Certbot can obtain and install HTTPS/TLS/SSL certificates. By default,
it will attempt to use a webserver both for obtaining and installing the
certbot: error: unrecognized arguments: --dns-cloudflare-credentials /root/.secrets/gldn.ini

hmmmm new error message !

Should I have this included? --apache

1 Like

Not 100% certain.
Check the User Guide:
User Guide β€” Certbot 1.27.0 documentation (

1 Like

Not in regard with your current error message, but it is possible to combine a DNS authenticator plugin with a webserver installer plugin, if you want. See the user guide listed above by Rudy, it contains a section about combining plugins.

Did you also install the appropriate DNS plugin using snap according to the instructions on the "wildcard" tab of the instructions?


Very good point!
I should have re-installed the plugin after updating the core.
Done it now - thanks.

New problem ...

root@expressresponse:~# certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secret/gldn.ini -d,*
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for and *
Waiting 10 seconds for DNS changes to propagate

Certbot failed to authenticate some domains (authenticator: dns-cloudflare). The Certificate Authority reported these problems:
Type: dns
Detail: DNS problem: SERVFAIL looking up TXT for - the domain's nameservers may be malfunctioning

Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-cloudflare. Ensure the above domains are hosted by this DNS provider, or try increasing --dns-cloudflare-propagation-seconds (currently 10 seconds).

These are my DNS entries ...

1 Like

Have you tried increasing --dns-cloudflare-propagation-seconds as stated?


Thank you for your patience !!

root@expressresponse:~# certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/gldn.ini --dns-cloudflare-propagation-seconds 60 -d,*
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for and *
Waiting 60 seconds for DNS changes to propagate

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/
Key is saved at:         /etc/letsencrypt/live/
This certificate expires on 2022-09-05.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

When I run:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Found the following certs:
Certificate Name:
Serial Number: 4b579b3f93b2a64d80ec8c9cd2f71a918a1
Key Type: RSA
Domains: *
Expiry Date: 2022-09-05 18:15:37+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/
Private Key Path: /etc/letsencrypt/live/


I do have other LE certs - which HestiaCP was able to get created.
( But HestaCP can't do the wildcards )
see image below.

Question ... is there any problem with creating them in these different ways?

Woohoo :partying_face:

What do you mean exactly with "in these different ways"?


I meant that the domains I am using wildcard certs for I have managed ( with your help) to get created using the command line.

The other domains you see in the image have had their certs generated by HestiaCP scripts.

HestiaCP updates the apache Virtual Host configs with the path for the LE Certs.

EG for it added ...

 SSLEngine on
    SSLVerifyClient none
    SSLCertificateFile /home/dave/conf/web/
    SSLCertificateKeyFile /home/dave/conf/web/
    SSLCertificateChainFile /home/dave/conf/web/

I guess that for the domain that I have just got the certs for, I need to update the Vitual host manually ? Is that correct ?


I'm not familiair with HestiaCP, so I wouldn't know. Maybe someone else knows this.

1 Like

Is that correct ?
I meant - the job of getting the certificate isn't done until the Virtual host in apache2 is updated.

And I guess I need to do that manually as I have checked and it is not changed.

Maybe (when I do the next domain) if I add that "-- apache" it will find the Virtual Host and update it ?


When using the certonly subcommand for Certbot, Certbot won't automatically do it for you, no.

However, please see my previous post about combining plugins:

Note that I don't have a clue if Certbot plays nicely with HestiaCP managed Apache configuration files: it might break things. Although manually modifying could also break things. Just make backups to be sure.



So for my next trick (ha ha )

On the next domain that needs a wildcard maybe I should take out the "certonly" and add "--apache"

Like this:

certbot  --dns-cloudflare --apache --dns-cloudflare-credentials /root/.secrets/igw.ini --dns-cloudflare-propagation-seconds 60 -d,*

Does this look like it may get the certificate issued and the Virtual Host updated?

Removing "certonly": yes. Just adding "--apache"? Not so sure.

You see, the --apache command would tell Certbot to use the Apache plugin as an installer as wel as an authenticator. I'm not sure if Certbot is smart enough to only use the installer part if a DNS plugin is also given as an option.

My advice is to specifically specify the authenticator and installer with their appropriate options. Please see the Certbot user guide linked by Rudy earlier and check the "combining plugins" part.


I tried both ...

certbot --dns-cloudflare --dns-cloudflare-credentials /root/.secret/igw.ini --dns-cloudflare-propagation-seconds 60 -d,*
Saving debug log to /var/log/letsencrypt/letsencrypt.log
With the dns-cloudflare plugin, you probably want to use the "certonly" command, eg:

certbot certonly --dns-cloudflare


certbot --dns-cloudflare --dns-cloudflare-credentials /root/.secret/igw.ini --apache --dns-cloudflare-propagation-seconds 60 -d,*
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Too many flags setting configurators/installers/authenticators 'apache' -> 'dns-cloudflare'

So , I'll use the version that worked and update the Virtual Hosts manually.

Thanks for your help.
And hope these questions and answers help others.

1 Like

I notice I'm a terrible teacher apparently, so I'll hand you a fish instead of learning you to fish yourself. (It seems "their appropriate options" wasn't clear enough even though referring to the combining plugins user guide section.)

From the Certbot user guide about combining plugins:

Sometimes you may want to specify a combination of distinct authenticator and installer plugins. To do so, specify the authenticator plugin with --authenticator or -a and the installer plugin with --installer or -i.

So my advice would be to try the following:

certbot --installer apache --authenticator dns-cloudflare --dns-cloudflare-credentials /root/.secret/igw.ini --dns-cloudflare-propagation-seconds 60 -d,*

Ahh, I see now, I can split the functionality.
That's great, apologies for not reading it all!

Before I try that, do you know if the standard path will be used
i.e. /etc/apache2/sites-available/my-domain

or will certbot find the path that HestiaCP has used - placing them under the user
i.e. /home/user/conf/web/my-domain


I have just realized that I would need to update both Nginx and Apache for HestiaCP to function properly. So I will be making changes to the HespiaCP templates.

UNLESS certbot can do that as well ??