Cerbot client authentication with EJBCA ACME server

My client wants to use Certbot with an EJBCA ACME server to automatically enroll and renew TLS certificates. I've followed the EJBCA guide (https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/protocols/acme) and successfully enrolled, renewed, and revoked the TLS certificates using standard Certbot 2.3.0 commands. But, my client has a hard requirement to enable client authentication for run these commands. While client authentication is supported by the EJBCA ACME server (see EJBCA guide above), I haven't been able to find any client authentication flags.

Are there any Certbot flags for client authentication? I couldn't find anything in this forum or Cerbot documenation (Welcome to the Certbot documentation! — Certbot 2.3.0 documentation). Chat GPT suggested this command and flags:

sudo certbot certonly --webroot -w /var/www/html -d example.com --client-cert /path/to/client/certificate.pem --client-key /path/to/client/private/key.pem

But, the --client-cert and -client-key flags didn't work in my tests. Chat GPT further said the flags were added in V.1.15.0. If anyone knows whether Certbot supports client authentication, I would appreciate it. Thanks.

1 Like

--eab-kid EAB_KID Key Identifier for External Account Binding (default:
--eab-hmac-key EAB_HMAC_KEY



All the [DV] certs LE provides are for client and server authentication.
But "client authentication" may mean different things to different people.
What exactly does your "client authentication" use mean to you?
[feel free to use third grade English (or lower - using simplified wording can sometimes do better)]

For instance, in your post you use the word "client" to means different things [in different context of course] - but this can be confusing to anyone not well versed in English OR when (lost in) translation.


If you mean to say that you need Certbot to authenticate to the ACME server via a TLS Client Certificate (a.k.a mutual TLS/mTLS), it is not possible. This would need to be a new feature in Certbot and we currently have no plans to implement it.


Thank you for the responses. My client wants web servers to present a certificate (with a Client Auth EKU) to the EJBCA ACME server for mutual authentication for the TLS connections. I'll talk with my client about submitting a feature request for it. If so, I'll submit a new post.

While EJBCA ACME server does support EAB_KID and EAB_HMAC_KEY, it only works for account registration. The EJBCA ACME server ignores these flags for certificate operations.

I can see your point about the many Client Auth meanings and will be more specific in the future. Once again, thank you everyone for your help.


ROFL :rofl:

Are we asking a novice AI now for help regarding software applications? Why not just check out the Certbot documentation at User Guide — Certbot 2.3.0 documentation where you can see no such options exist?


Hmm. That's interesting, I haven't heard of anyone using ACME in that way. I'm kind of surprised if they implemented it without having a client in mind that could use it; maybe even if certbot doesn't support it they know of other clients that make using it simple-ish?


Since I didn't find anything in the Certbot documentation, I tried Chat GPT as a last resort. Suprisingly, Chat GPT is fairly good at writing code and trouble shooting issues if you can structure the queries in a way it understands. I was surprised that it identified the --client-cert and --client-key flags to the Certbot 1.15.0 version so I thought that I would ask.

1 Like

Unfortunately, ChatGPT was incorrect, as ChatGPT itself confirms:

Does Certbot have the options "--client-cert" and "--client-key"?

No, Certbot does not have the options "--client-cert" and "--client-key".
Certbot is a command-line tool for managing SSL/TLS certificates, and it provides a range of options and flags for different operations. However, "--client-cert" and "--client-key" are not valid options in Certbot.


I would not trust ChatGPT above common sense like just looking in the documentation :wink:


Yet, experienced programmers consistently say the exact opposite.


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