Daniel Nashed's Blog

Free ACME CAs, BSI RSA Requirements and Having a Plan B

Disclaimer: The Blog post content is not well formatted, because I gave up after 30 minutes with the Domino Blog template.
The text copied from somewhere else and reformatted at least does not work.
I can't spend more time on this today. This is breaking my nerves.

----


A customer raised a concern about the RSA-2048 intermediate CA used by Let's Encrypt.

There is nothing wrong with RSA-2048 from a current public WebPKI/browser perspective.
However, the German BSI TR-02102-2 recommends a minimum RSA key length of 3000 bits for certificate-signing keys. In practice, this means using RSA-3072 or larger.

BSI TR-02102-2 – TLS recommendations:

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRich tlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile

This prompted me to test several free ACME providers with RSA-4096 certificates and look at the complete certificate chain, not just the server certificate.

ACME CA results

Let's Encrypt

- Free ACME: Yes
- Wildcard: Yes
- RSA CA chain: includes RSA-2048
- BSI RSA >=3000: No

Google Trust Services

- Free ACME: Yes
- Wildcard: Yes
- RSA CA chain: includes RSA-2048
- BSI RSA >=3000: No

ZeroSSL

- Free ACME: Yes
- Wildcard: Yes
- RSA CA chain: RSA-3072 / 4096 throughout
- BSI RSA >=3000: Yes

Actalis

Free ACME: Yes
- Wildcard: No (Not free at least)
- RSA CA chain: RSA-4096 throughout*
- BSI RSA >=3000: Yes

*Based on the certificate chain returned in my test.

Let's Encrypt

Let's Encrypt's current Generation Y RSA hierarchy uses RSA-2048 issuing intermediates.

With an RSA-4096 server certificate, the chain looks like this:

• RSA-4096  Server certificate
• RSA-2048  Let's Encrypt YR1
• RSA-4096  Root YR
• RSA-4096  ISRG Root X1
   
  

The important part is YR1. Even though the server certificate itself uses RSA-4096, the certificate chain contains an RSA-2048 issuing CA.

Therefore, increasing the RSA key size of the server certificate doesn't solve the BSI requirement.

Let's Encrypt could address this by introducing new RSA-3072 or RSA-4096 issuing intermediates and moving RSA issuance to them.
The current YR1/YR2/YR3 intermediates use RSA-2048 keys, so this would require new intermediate CA keys and certificates.

Let's Encrypt certificate hierarchy:

https://letsencrypt.org/certificates/

Google Trust Services

Google Trust Services also provides free ACME certificates including wildcard certificates.

I tested an RSA-4096 wildcard certificate. The resulting chain was:

• RSA-4096  Server certificate
• RSA-2048  Google Trust Services WR1
• RSA-4096  GTS Root R1
• RSA-2048  GlobalSign Root CA

Again, the relevant issuing CA, WR1, uses RSA-2048.

Google Trust Services therefore doesn't solve this particular requirement when using its current RSA certificate hierarchy.

Google Trust Services certificate repository:

https://pki.goog/repository/

ZeroSSL – RSA with wildcard support

ZeroSSL is the interesting result when RSA certificates are required.

ZeroSSL supports free ACME wildcard certificates, and the complete RSA certification path returned in my test uses at least RSA-3072:

• RSA-4096  Server certificate
• RSA-3072  ZeroSSL RSA DV SSL CA 2
• RSA-4096  Sectigo Public Server Authentication Root R46
• RSA-4096  USERTrust RSA Certification Authority
   
  

There is therefore no RSA-2048 certificate anywhere in this certification path.

This makes ZeroSSL a good option when RSA, wildcard certificates and the BSI RSA key-length recommendation are all requirements.

ZeroSSL ACME documentation:

https://zerossl.com/documentation/acme/

Actalis – a European alternative

Actalis is another interesting ACME provider, particularly for European customers. Actalis is based in Italy and provides free ACME certificates.
In my test, the complete RSA chain used RSA-4096, so it also meets the BSI RSA key-length recommendation.

The important limitation is that Actalis currently doesn't provide wildcard certificates through its free ACME service.
It is nevertheless an interesting European alternative for environments where wildcard certificates aren't required.

Actalis ACME:

https://www.actalis.com/acme-certificates.aspx

What about ECDSA?

There is another straightforward option: use ECDSA instead of RSA.

Let's Encrypt's current ECDSA hierarchy avoids the RSA-2048 issue. If all clients and applications in your environment support ECDSA certificates, this is a good option.

This gives us a fairly simple practical result:

• ECDSA + wildcard → Let's Encrypt
• RSA ≥3072 throughout + wildcard → ZeroSSL
• European CA without wildcard → Actalis

Have a Plan B

There is another lesson from this exercise which might be even more important than the RSA key sizes:

Don't depend on a single ACME CA.

When using a free public ACME service, a customer typically doesn't have an individual contract or SLA with that CA. Availability, policies, certificate hierarchies, rate limits or service conditions can change.
ACME is a standard protocol, so there is little reason to make certificate infrastructure unnecessarily dependent on one provider.

For example, even if Let's Encrypt is your normal CA, having a ZeroSSL ACME account configured and tested gives you an alternative. The reverse applies when ZeroSSL is your primary provider.

The important point is to test the alternative before you actually need it.

Domino CertMgr makes this easy

HCL Domino CertMgr supports the ACME providers discussed here and makes it easy to configure multiple ACME accounts centrally in certstore.nsf.
Certificate requests aren't tied to Let's Encrypt. Different ACME providers can be configured and used depending on the requirements of a particular certificate.

That makes a multi-provider strategy straightforward:

• ECDSA → Let's Encrypt
• RSA → ZeroSSL
• Plan B → Configure and test both
   
  

Actalis can additionally be useful as a European alternative where wildcard certificates aren't required.
Having more than one ACME provider configured and tested avoids unnecessary dependency on a single free service with which the customer might not have any contractual relationship.

For production certificate automation, having a working Plan B is a good idea regardless of which CA is the primary provider.

• Comments [0]