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

Help
1

My domain is: gldn.page

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

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 gldn.page
dns-01 challenge for gldn.page
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 UKservers.com

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

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 "https://api.cloudflare.com/client/v4/user/tokens/verify" -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.

2

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.

2 Likes
3

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 gldn.page,*.gldn.page

Result:
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 gldn.page
dns-01 challenge for gldn.page
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 https://dash.cloudflare.com/profile/api-tokens).

So it didn't like that for some reason

4

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 https://certbot.eff.org/ and use one of the currently recommended methods of installing Certbot to get an up to date version.

2 Likes
5

Thanks,
I have updated to 1.27.0

certbot certonly --dns-cloudflare --dns-cloudflare-credentials /root/.secrets/gldn.ini -d gldn.page,*.gldn.page
usage:
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
certificate.
certbot: error: unrecognized arguments: --dns-cloudflare-credentials /root/.secrets/gldn.ini
root@expressresponse:~#

hmmmm new error message !

Should I have this included? --apache

1 Like
6

Not 100% certain.
Check the User Guide:
User Guide — Certbot 1.27.0 documentation (eff-certbot.readthedocs.io)

1 Like
7

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 certbot.eff.org instructions?

3 Likes
8

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 gldn.page,*.gldn.page
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for gldn.page and *.gldn.page
Waiting 10 seconds for DNS changes to propagate

Certbot failed to authenticate some domains (authenticator: dns-cloudflare). The Certificate Authority reported these problems:
Domain: gldn.page
Type: dns
Detail: DNS problem: SERVFAIL looking up TXT for _acme-challenge.gldn.page - 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 ...

DNS
DNS1415×763 46.5 KB

1 Like
9

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

3 Likes
10

Thank you for your patience !!

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

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/gldn.page/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/gldn.page/privkey.pem
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: gldn.page
Serial Number: 4b579b3f93b2a64d80ec8c9cd2f71a918a1
Key Type: RSA
Domains: gldn.page *.gldn.page
Expiry Date: 2022-09-05 18:15:37+00:00 (VALID: 89 days)
Certificate Path: /etc/letsencrypt/live/gldn.page/fullchain.pem
Private Key Path: /etc/letsencrypt/live/gldn.page/privkey.pem

root@expressresponse:~#

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?

Hestia-001
Hestia-0011119×839 69.3 KB

11

Woohoo :partying_face:

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

2 Likes
12

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 drbrainybox.com it added ...

 SSLEngine on
    SSLVerifyClient none
    SSLCertificateFile /home/dave/conf/web/drbrainybox.com/ssl/drbrainybox.com.crt
    SSLCertificateKeyFile /home/dave/conf/web/drbrainybox.com/ssl/drbrainybox.com.key
    SSLCertificateChainFile /home/dave/conf/web/drbrainybox.com/ssl/drbrainybox.com.ca

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

Thanks

13

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

1 Like
14

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 ?

15

Correct.

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.

3 Likes
16

OK

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 igw.news,*.igw.news

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

17

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.

3 Likes
18

I tried both ...

certbot --dns-cloudflare --dns-cloudflare-credentials /root/.secret/igw.ini --dns-cloudflare-propagation-seconds 60 -d igw.news,*.igw.news
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

And

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

Conclusion
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
19

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 igw.news,*.igw.news
2 Likes
20

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

??

UPDATE
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 ??