Does certbot have any plans to implement this feature? I think we'll probably sit this one out until the dust settles and a certbot implementation would be a strong indicator of readiness.
1 Like
The Profiles Extension lacks clarity regarding the behavior when a newOrder request is received without specifying a particular profile. This raises concerns about backward compatibility, particularly if the selected profile differs from the traditional classic profile. Could the Let's Encrypt team confirm whether, in such cases, the classic profile will be selected by default?
If the server is advertizing profiles and receives a newOrder request
which does not identify a specific profile, it is RECOMMENDED that
the server select a profile and associate it with the new Order
object.
{
"status": "valid",
"expires": "2025-01-01T12:00:00Z",
"profile": "profile1",
"identifiers": [{"type": "dns", "value": "example.org"}],
"authorizations": ["https://example.com/acme/authz/PAniVnsZcis"],
"finalize": "https://example.com/acme/order/TOlocE8rfgo/finalize",
}
2 Likes
Not sure if the draft lacks anything: it clearly recommends what the CA should do, but does not mandate it. E.g., a CA could choose one of the profiles or could refuse such an order, making it mandatory to select one. As I read the draft, it's up to the CA to decide what to do when a profile is missing from the newOrder.
That said, I am missing any statement from the CA Let's Encrypt with regard to the default profile or how they'd handle requests without a profile. I assume it will be the classic profile, but assumptions are the … of all …, so it would be nice of LE to confirm or deny this.
2 Likes
I would expect the draft to connect to real life use-cases and at least mention backward compatibility and migration considerations for the CA to evaluate. Would be good if LE confirm this.
I've implemented profile selection in uacme (Add support for certificate profiles · ndilieto/uacme@4cd4f10 · GitHub)
If a profile is selected by the user, uacme no longer sets the KeyUsage extension in the CSR. But I noticed while testing on staging that if the CSR includes a KeyUsage extension, the server still accepts the CSR, even though it changes the contents of it in the final certificate (see diff below). Is this intended behaviour?
X509v3 Key Usage: critical
- Digital Signature, Key Encipherment
+ Digital Signature
X509v3 Extended Key Usage:
- TLS Web Server Authentication, TLS Web Client Authentication
+ TLS Web Server Authentication
2 Likes
@ndilieto Let's Encrypt only cherry-picks the parts of a CSR it requires and as far as I know, this also counts for key usages.
4 Likes
You're best just to drop the key usage requests in the CSR, if your private key was ECDSA instead of RSA it would be rejected (by at least some CAs).
1 Like
@mcpherrinm Can you post a reference regarding this deadline? Is it CAB mandated?
I looked at the certificates of a bunch of major websites, and most have both server & client EKU, except for Google and Apple, which run their own CA's.
Are you saying all public CA's must split their hierarchies in the (near) future? On root level, or only on intermediates level?
3 Likes
@webprofusion:
That only applies to the Key Encipherment usage, because ECDSA algorithm isn't designed to encrypt data, only sign data. The Digital Signature Usage is still required and allowed.
And in fact uacme removes the Key Encipherment usage for EC keys uacme/crypto.c at f3794cdd90a2be2aac92e2c7f6230c92ad10b7ce · ndilieto/uacme · GitHub
1 Like
The Chrome root program intends to start phasing out support for the client EKU in their program. A timeline will be in the next version of their root program requirements, which should be out soon. The exact details are still being sorted out, and they've been asking CAs for feedback.
5 Likes
I'm not sure it is required. Let's Encrypt only honor the SAN and (currently) Must-Staple part of the CSR and decide the usage extensions on their own, maybe it matters for some other types of CA. We used to have similar key usage inclusion logic based on key type, but got rid of it as it only resulted in potential finalize failures.
4 Likes
At first, the classic profile will be selected by default. This is subject to change, and we will announce changes just as we have announced profile changes in the past.
For example, the shortlived profile will be based on the tlsserver profile, not the classic profile, so short-lived certs will have the same features as the new profile. Similarly, certs with IP Address SANs will all be short-lived, and therefore will also share features with the tlsserver profile.
In the future, we may make the tlsserver profile the default. We do not have concrete plans or timelines to do so, but it is certainly a possibility.
6 Likes
Yes -- Let's Encrypt wholly ignores the contents of the KeyUsage field of the CSR. Ignoring as much as possible of the CSR keeps our code simple.
8 Likes
Isn't this a violation of 7.4 RFC8555?
The CSR encodes the client's requests with regard to the content of
the certificate to be issued. The CSR MUST indicate the exact same
set of requested identifiers as the initial newOrder request.
Identifiers of type "dns" MUST appear either in the commonName
portion of the requested subject name or in an extensionRequest
attribute [RFC2985] requesting a subjectAltName extension, or both.
(These identifiers may appear in any sort order.) Specifications
that define new identifier types must specify where in the
certificate signing request these identifiers can appear.
A request to finalize an order will result in an error if the CA is
unwilling to issue a certificate corresponding to the submitted CSR.
For example:
o If the CSR and order identifiers differ
o If the account is not authorized for the identifiers indicated in
the CSR
o If the CSR requests extensions that the CA is not willing to include
2 Likes
@ndilieto I believe aspects like that are referred to as a divergence rather than violation: boulder/docs/acme-divergences.md at main · letsencrypt/boulder · GitHub
Let's Encrypt will also ignore Country etc if you include them in the CSR, and they have always done that, but it would be worth adding that in the above linked doc, or elsewhere in the LE docs, and/or propose Errata to RFC 8555 so its MAY rather than the non-RFC requirement term will
4 Likes
It's a good question, but no, not by my reading. The section you quoted does two things:
- It says that the identifiers MUST match. We enforce this.
- It provides examples of times that an ACME Server might reject a finalize request. These are not normative requirements (indicate by a MUST or SHALL), nor even suggestions (indicated by a SHOULD), they're illustrative examples. We choose to be liberal in what we accept and strict in what we produce.
3 Likes
What are you going to do in the futur when CSR arrives with the must stapple option request? Will you reject the CSR, or simply issue a certificate without the must stapple option?
1 Like
From the Ending OCSP Support in 2025 - Let's Encrypt blog:
As of January 30, 2025, issuance requests that include the OCSP Must Staple extension will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension.
As of May 7, all issuance requests that include the OCSP Must Staple extension will fail, including renewals. Please change your ACME client configuration to not request the extension.
Thus a 'hard fail' it seems.
3 Likes
Yes, it is hard fail, not very much liberal. But I prefer this way, users should be aware of the change, instead of silently failing somewhere later at the usage of the certificate.
2 Likes
I INCORRECTLY believe they also ignore the date information (notBefore/notAfter) and recode it to their preference
1 Like