Re: Announcing Certificate Profile Selection

Issuance Policy
1

In the blog Announcing Certificate Profile Selection - Let's Encrypt (from Announcing Certificate Profile Selection), the following is mentioned:

An ACME client can supply a desired profile name in a new-order request:
(…)
If the new-order request is accepted, then the selected profile name will be reflected in the Order object when it is returned, and the resulting certificate after finalization will be issued with the selected profile. If the new-order request does not specify a profile, then the server will select one for it.

What error can users (and perhaps client developers) expect when a profile is used that isn't implemented by the ACME server?

5 Likes
2

The draft spec linked in the post I think answers:

  1. The client is just outright forbidden from not checking against the directory metadata: The client MUST NOT request a profile name that is not advertised in the server's Directory metadata object..
  2. If the client does so anyway, then If the server receives a newOrder request specifying a profile that it is not advertising, or specifying a profile which is incompatible with the rest of the contents of the request (e.g. a "tls-server-auth" profile alongside an identifier of type "email"), it MUST reject the request with a problem document of type "invalidProfile" (see Section 6.3).
6 Likes
3

Well, according to the blog, with regard to client implementation:

A simple implementation might allow the user to configure a static profile name and include that name in all new-order requests.

RFC compatibility is then up to the user I guess :stuck_out_tongue:

But indeed, I just read the draft too and saw the new invalidProfile ACME error. :slight_smile: Perhaps the blog might just mention that too.

3 Likes
4

Though from glancing at Boulder and Pebble code, it looks like they're just using "malformed" for now (though I may be missing something, it was a quick skim). Maybe they're waiting to see if the draft catches on more before committing to the new error message that clients may not yet be expecting.

4 Likes
5

Apart from the ACME implementation details, is there any guidance on the profiles themselves; which available profiles (currently "classic" vs "tlssever") are suitable for which TLS use cases?

classic should be broadly compatible, since it's what's LE has been offering all the time.
tlsserver looks like the "ideal" certificate, but also looks like it may introduce incompatibility with legacy clients - is anything known about such potential issues? Eg. clients insisting on a CN field, or things like that...
(if there weren't any compatibility risk, LE would be introducing these changes as defaults, rather than user-selectable profiles?)

Eg. on a personal mailserver, I probably wouldn't hesitate to choose "tlsserver" (and I can revert quickly if it breaks anything), but a generic website with a broad audience (say, Wikipedia...) will have to consider this more thoroughly. Is there any data available to base such decision on?

5 Likes
6

Another step toward short-lived certificates. Excellent. May 2025 be the year that we finally nail revocation's coffin closed (for most certs)!

4 Likes
7

The tlsserver certificates will work with all major browsers from the last decade or so. If you're thinking about using the cert for a general purpose website or webapp, selecting the tlsserver profile shouldn't have any risks for you.

If you're operating a server that IoT devices or other custom clients contact, that's where the risk lies. We're not simply updating the default (yet) to accommodate those use-cases. But those server operators generally know their clients' requirements.

4 Likes
8

Also with TLS-versions lower than 1.3? Because 1.3 is explicitly mentioned in the blog.

3 Likes
9

Funny you say that, I was thinking that I'd want to leave my mail server on "classic" for now just because email servers are notoriously out-of-date (I use dual ECDSA/RSA certs because some systems I get mail from still won't talk to ECDSA), but that my internal router configuration page (which only I use) could probably try out the new hotness (once in prod and clients have support).

I wouldn't be so sure, I suspect many server operators would have no idea if their clients care about CN or Key Encipherment fields… unless it's something other CAs already do.

2 Likes
10

In my experience, TLS clients don't care about CNs these days, but tools and scripts on servers handling certificates might. There's have been ACME clients that barf on certs without them, for example.

4 Likes
11

I was referring to MUA ports (IMAP, submission), not public MX, which indeed faces notoriously old TLS implementations...

3 Likes
12

TLS with the non-forward-secret RSA cipher suites, which are gone in 1.3, and these days not that widely used in TLS 1.2 either.

4 Likes
13

First, wow - someone fixed the URL on that page already!

I don't think it exists yet, or will for quite some time. There are 4 potential incompatibilities, and I haven't found any compatibility information for a single one - much less the intersection of all 4.

The lack of a CN and SKID should not be an issue - both have been recommended against for many years and I believe were long deprecated in RFCs; even though they are core elements, I don't expect things to break. The other two potential issues are less likely to cause issues, because most code I've ever seen checks to see if they are present.

I'd love to see a matrix of when browsers/libraries stopped looking at CNs - I think that is the most likely incompatibility. I think MTAs are actually the most likely to break regarding that - TLS is often slapped onto them, quite a bit behind, and (at least the last time I ran an Exim or Postfix server) they often liked single-domain certs.

4 Likes
14

Thanks @aarongable and @mcpherrinm, sounds safe then to switch to tlsserver profile for most use cases. :heart:

(shortlived profile is a story on its own, and is more about risk trade-off than compatibility)

5 Likes
15

I already saw the PR being comitted 1 minute before I checked the Github repo :rofl:

Ah OK, so it's about those cipher suites. Yes, good riddance, every used cipher suite today should be a forward-secret one. :slight_smile: Not that it matters very much with quantum computing though, although that still takes some time to fully develop :slight_smile:

2 Likes
16

Also do note that this is staging-only right now! Feedback is definitely appreciated as we line up to get the profiles ACME draft into an RFC, and finalize what profile we go to production with.

4 Likes
17

Is there any word on any popular clients working on support for profiles? I thought with ARI that Let's Encrypt staff worked toward submitting pull requests or other work to try to get the ball rolling there, with lego and maybe certbot? Anything like that on the horizon for profiles?

3 Likes
18

I have an initial commit I'm almost ready to push to ACMEz (used by CertMagic / Caddy). Haven't thoroughly tested it though.

4 Likes
19

Caddy, CertMagic, and ACMEz all have basic support for ACME profiles if you build from source.

Caddyfile example:

example.com {
	tls {
		issuer acme {
			ca https://acme-staging-v02.api.letsencrypt.org/directory
			profile tlsserver
		}
	}
}
6 Likes
21

Before the holidays, there are two open PRs for ARI, one from aarongable and the other from orangepizza.

Certbot has been undergoing a large push to remove PyOpenSSL from the stack and replace it with Cryptography. I know a lot of maintainers and contributors have been focused on that.

My initial feedback on this particular implementation:

I would like to see profiles identifiable from a unique value/hash. This could just be the "name" if the spec/server guaranteed the profile will not change, otherwise perhaps this could be a unique id, hash, or a serialized description.

The purpose of this is to enable clients to determine if a previously selected profile has changed, so they may act appropriately. I like how a URL is involved in the example.

Using the example:

        "profiles": {
            "tlsserver": "https://letsencrypt.org/2025/01/09/acme-profiles/"
        }

My concern is if "tlssever" might change in the future. As a subscriber I might opt-in to V1 of this - but if LetsEncrypt were to make any changes whatsoever, I might not be okay with the V2 profile and prefer reverting to "classic". In most situations I would want to at least review the new profile before continuing, to ensure it meets our organizations technical or compliance needs.

Signifying a change could happen many ways:

For example, a change in the payload:

        "profiles": {
            # "tlsserver": "https://letsencrypt.org/2025/01/09/acme-profiles/"
            "tlsserver": "https://letsencrypt.org/2025/01/10/acme-profiles/"
        }

Using version id:

        "profiles": {
            # "tlsserver": (1, "https://letsencrypt.org/docs/acme-profiles/#tlsserver")
            "tlsserver": (2, "https://letsencrypt.org/docs/acme-profiles/#tlsserver")
        }

As a subscriber, I would want my client to record whatever profile I accepted. If the profile were to change, I would want my client to give me the option between automatically using it OR alerting me to a potential change. As a subscriber, I would also want the ability to configure my client on how to properly fallback if a profile changes or is no longer offered.

The bulk of this work would be done by the client; the ACME server just needs to publish some sort of basic versioning info (or commit to never changing a profile).

My pie-in-the-sky request is still for an endpoint that offers a machine readable format of the profiles - so that a client could "read" from multiple acme servers and detect compatible alternatives.

4 Likes