Request: clientAuth EKU and R10/R11 issuing CA for monara.ch (bLink / SIX Group onboarding)

Help
1

My domain is: monara.ch

I ran this command:

openssl genrsa -out monara-rsa.key 2048
openssl req -new -key monara-rsa.key -out monara-rsa.csr -subj "/CN=monara.ch" -addext "extendedKeyUsage=clientAuth,serverAuth"
sudo certbot certonly --manual --preferred-challenges dns --csr monara-rsa.csr --cert-name monara-rsa-client

It produced this output: The certificate was issued successfully and saved to /Users/sascha/0001_chain.pem. However, when I inspect the issued certificate:

openssl x509 -in 0001_chain.pem -noout -text | grep -A1 "Extended Key Usage"

I see only:

X509v3 Extended Key Usage:
    TLS Web Server Authentication

The TLS Web Client Authentication EKU that I included in the CSR was stripped from the issued certificate. The cert was also issued under intermediate R12.

My web server is (include version): No traditional web server. The application runs as a frontend on Lovable with a Supabase backend. The certificate is needed for mutual TLS client authentication against an external API (SIX Group's bLink open banking platform), not for serving HTTPS traffic.

The operating system my web server runs on is (include version): macOS (running certbot locally on macOS to generate the certificate; LibreSSL 3.3.6)

My hosting provider, if applicable, is: Lovable (frontend) and Supabase (backend). Domain registered with Infomaniak.

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

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

The version of my client is: certbot 5.1.0 (installed via Homebrew)

Additional context:

I need this certificate to satisfy the requirements of SIX Group's bLink open banking platform, which I am onboarding to. According to bLink's official TLS Certificates documentation (TLS Certificates | bLink Docs), my client certificate must meet all of these requirements:

  1. RSA key, 3072 bits or longer
  2. Signature algorithm: sha224/256/384/512 with RSA
  3. Extended Key Usage: Client Authentication (id-kp-clientAuth)
  4. For Let's Encrypt specifically: issued under intermediate R10 or R11 (R12, R13, R14 are explicitly not on bLink's accepted list)

bLink's support team has confirmed in writing that "Let's Encrypt will be perfect, just make sure to generate one with Client Authentication. They are not including this anymore in their certificates by default, however on request they are still issuing them."

My questions:

  1. What is the correct procedure to request a Let's Encrypt certificate that includes the clientAuth EKU? Is there an account-level setting, a specific ACME profile, or do I need to submit a request through a specific channel?
  2. Is it possible to request issuance under intermediate R10 or R11 specifically (rather than R12)?
  3. Are 3072-bit RSA keys supported by Let's Encrypt for the leaf certificate?
  4. Can the issued certificate include keyUsage = digitalSignature in addition to the EKU?

Thank you very much for your help — bLink onboarding is otherwise complete, the certificate is the only blocker.

Best regards, Sascha

2

We are in the final stages of removing support for the client with EKU. To get a certificate with the client auth EKU, you need to request it from the correct profile.

You can read more about that here: Ending TLS Client Authentication Certificate Support in 2026 - Let's Encrypt

6 Likes
3

No, those intermediates are retired. See: Chains of Trust - Let's Encrypt

They have not been used to issue new certs since last August. See: Switching issuance to new intermediates

7 Likes
4

Sounds like the bLink support team aren't up to date.

Also, usually a private CA is used for client authentication.

5 Likes
5

I would like to add that Let's Encrypt intentionally randomized which intermediate leaf certificates get issued from to discourage intermediate pinning, or systems relying on leaf certificated being issued from a specific intermediate.

bLink also seems unaware that Let's Encrypt always keeps backup intermediates which are in stand-by to take place of the active intermediates in events like compromises of the active intermediates. Because of this, LE specifically states they might start issuing from the backup intermediates with little to no notice.

bLink failing to update their website for almost a year tp reflect the changes in LE's issuance hierarchy is another example of why enforcing specific intermediates be used is a bad idea. Their policies should only include requirements users are able to affect (like the roots, key types and EKUs).

The Google Chrome root program made changes that forbids CA's issuing publicly trusted certs for both server and client authentication if they want to continue to be trusted by Google Chrome. This policy affects all CAs, and no CA on their list will be able to offer certs that are both server and client auth after July 2026. As mentioned above, private CAs are much better suited for client authentication.

For now, the best you can do is running certbot with the --key-type rsa --rsa-key-size 3072 --required-profile tlsclient

It will not use the intermediates specified in their docs, but their docs are asking for a hierarchy that's long been retired, and this will be the closest you can get. The last day you will be able to request a client auth certificate from Let's Encrypt will be July 7th 2026, and it will remain valid until October 6th 2026. Beyond that date, neither LE, or any other CA on their list will provide publicly trusted certs with the ClientAuth EKU.

I would recommend making their support aware of this forum thread, since it includes links to all the resources they might need to understand the situation.

Hope this helps.

3 Likes
6

Those docs show Let's Encrypt certs only being valid for their test system. And, the problems with that are well explained by others in this thread.

But, Let's Encrypt is not a valid issuer for their production system anyway. And, a number of the Certificate Authorities bLink describes for production (and test) do provide certs with a client EKU. Those other CA have multiple "roots" and for their roots that are not in the Chrome trust store they can mix server and client uses in the same cert. They may also offer certs with only the client EKU. You will need to work with bLink and those other CA to ensure you get a compatible cert.

5 Likes