I ran this command: kelvintr@kokochap-server:~$ sudo certbot certonly --dns-cloudflare --dns-cloudflare-credentials ./credentials.ini -d blamethe.network -d www.blamethe.network
It produced this output: Missing properties in credentials configuration file ./credentials.ini:
Property “dns_cloudflare_email” not found (should be email address associated with Cloudflare account).*
The operating system my web server runs on is (include version): Ubuntu 18.04
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):
No, direct CLI access.
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): Certbot 0.31.0
I want to use the zone API key for Cloudflare to give Certbot access to make requests to the Cloudflare API for the increased control and security. I provided the key in the credentials.ini file by writing “dns_cloudflare_api_token = api key here” as indicated by the official documentation (found here), but I receive an error that it’s explicitly looking for the email and global API key. I’ve tried adding the certbot repository to apt and running sudo apt update and sudo apt upgrade to no avail, as it says it’s up to date.
Any assistance for this issue would be absolutely appreciated! Thank you in advance for your time.
I think it is reading the credentials file, but there is something wrong with either the contents or the processing of it, perhaps even at Cloudflares end.
@kelvintechie Could you post the redacted contents of your credentials.ini? And could you perhaps verify the version of python3-certbot-dns-cloudflare? (This can be different from the version of certbot.) It probaby is version 0.23.0. And if I read the code correctly, that version of the plugin didn’t yet support token keys, but only global keys unfortunately. It seems you’ll need version 1.2.0 to use token keys in stead of the global API key.
Hey there! Thanks for your help, everyone! I’m happy to report that using certbot run instead of certbot certonly and pointing to the absolute path of the file did end up working!
It’s weird. It accepted my command and ran, but I checked the package version in apt and it says that python3-certbot-dns-cloudflare is using version 0.23.0, but it accepted credentials2.ini which was using the dns_cloudflare_api_token parameter.
If you do a diff on the credentials.ini & credentials2.ini file it may help explain. It’s picky and you have to make sure you use the global API key & your registered email address. I haven’t had an issue with setting the creds for cloudflare.
Well, I don’t need to do a diff on the two files, they’re one and two lines respectively. Using a global API key/email address definitely works, but it’s not the recommended way because it provides instant access at a global level to all zones on the CF account, hence why Cloudflare introduced API tokens. What I’m trying to figure out is why a version that claims to not support API tokens has authenticated with them successfully when it was not working previously.
Right, but if you’re hosting multiple domains on a single server, then you want to use the global key anyway. It’s also possible that Cloudflare changed its access policies since then, so individual tokens will now work with the API calls from previous versions of Certbot.
Even so, an old version of certbot without knowledge of such token variables, shouldn't be able to use those variables when used in the credentials file. It can't use a variable if it doesn't know how to use it.
But the call wouldn’t change, just what cloudflare accepts as the token. If it now allows for individual tolens to be used along with the global, then the variable wouldn’t need to change. You’re just sending the token over. It’s cloudflare accepting the individual tokens as well as the global one.
The interface is different – when using API tokens, you don’t specify the account email address. Older software could have treated the email address as required; if so, it would have to be modified.
In theory perhaps, but in this case, only the TOKEN variable was given in the credential files. And certbot only knows how to handle the token variable in the credential file since version 1.2.0. Therefore, no key nor token should have been sent to Cloudflare. If the INI uses variable A and certbot expects variable B, it could naver have sent variable A, because certbot didn't look for that, because it didn't know its existence.
Again, the variable name doesn’t change, just the value. If Cloudflare will accept the individual token as well as the global token, then it will validate on cloudflare. API calls don’t specify a token type, just pass the token through for validation on Cloudflare.
@ZetaRevan You don’t understand me. I’m talking about the inner workings of CERTBOT. It’s plain and simple: if a user uses a variable the program doesn’t know, the program won’t work! This is as simple as I can explain it. If you don’t, sorry… But I won’t be posting anything further about this topic.
I completely understand you and couldn’t agree more. What’s weird then is that it accepted the token-based API even though the version claims that it doesn’t support it. In a previous execution of the command, I did give it an e-mail and global API key, so maybe it cached the global API key and used it (despite me giving it a different file and the fact that it shouldn’t be doing that for security purposes)?
I could test it by revoking/changing my global API key and seeing if a dry run of a renewal works, but it’s too much effort for too little benefit, since it works now and it’s not that much of a security risk for my single-domain Cloudflare account. I’m just trying to follow security best practice.
The variable name does change. The token-based API key is provided using dns_cloudflare_api_token and the global API key is provided with dns_cloudflare_api_key (along w/ dns_cloudflare_email_address). As I’ve mentioned in other replies, it works now but it’s still weird that an older version of Certbot accepts the api_token variable even though it shouldn’t. My hypothesis is that perhaps Certbot is caching in some way the old credentials I gave it (as in a previous run, I did provide it my global API key and email address), but that would pose a security risk and it’s hard to think that the developers of Certbot would allow such caching of credentials in memory.
The first time I ran it with the API token, it gave me an error saying that it was expecting e-mail and global API key, indicating that it’s not expecting the API token. I ran it once with the global API key, revoked it, and ran it again using a different credentials file (this time, with the API token) and it worked the second time I tried giving it an API token. That’s confusing though, since what I’m gathering from the contents of this thread is that it shouldn’t have.
Sorry to cause such a debate in the community! I really appreciate the help, everyone!
