Hi there:
Ubuntu 24.04.2 LTS running certbot 4.0.0, installed via snap:
$ certbot --version
certbot 4.0.0
I was interested in trying out the new shortlived profile, but when I try to use them against either the test or production LE servers, I get the following error:
Failed to renew certificate [hostname] with error: urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Error creating new order :: account ID [accountid] is not permitted to use certificate profile "shortlived"
To test, I'm running:
/usr/bin/certbot renew --preferred-profile shortlived --dns-cloudflare --dns-cloudflare-credentials [path-to-credentials] --test-cert --dry-run
But the results are identical without --test-cert and --dry-run. Without --preferred-profile the renewal succeeds.
Are these profiles not available yet? Or have I screwed something up?
Also, the documentation seems to indicate that failure of a --preferred-profile should result in certbot falling back to the default, but it seems to just be erroring out in this case.
it's not released to public yet: they hope it could released at end of 2025
wonder staging have this lock too?
3 Likes
Got it. Yes, the staging environment also throws the same error.
The Certbot 4.0.0 announcement makes it sound like it is usable today, which is what confused me (Certbot 4.0: Long Live Short-Lived Certs! | Electronic Frontier Foundation).
Thanks!
2 Likes
Yeah, that announcement is confusing. There is a bit of chicken-and-egg problem where clients and servers both need to add support, but each won't do much good without the other also supporting it.
I think the only shortlived certs they've made is for their own internal testing, and they even had a compliance incident involving some of them. I'm sure they'll open up testing in staging at some point, but I'm not aware of them having published any specific date or anything yet.
6 Likes
I believe it will only fallback if the --preferred-profile is not among the list of valid profiles "advertised" by the CA. It would allow you to renew a cert even if the CA drops the profile you previously specified.
Let's Encrypt currently advertises 3 profiles in the directory so I think that is why the error.
curl https://acme-staging-v02.api.letsencrypt.org/directory
{
"ET55Uw5EDOw": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",
"keyChange": "https://acme-staging-v02.api.letsencrypt.org/acme/key-change",
"meta": {
"caaIdentities": [
"letsencrypt.org"
],
"profiles": {
"classic": "https://letsencrypt.org/docs/profiles#classic",
"shortlived": "https://letsencrypt.org/docs/profiles#shortlived (not yet generally available)",
"tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver (not yet generally available)"
},
"termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.5-February-24-2025.pdf",
"website": "https://letsencrypt.org/docs/staging-environment/"
},
"newAccount": "https://acme-staging-v02.api.letsencrypt.org/acme/new-acct",
"newNonce": "https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce",
"newOrder": "https://acme-staging-v02.api.letsencrypt.org/acme/new-order",
"renewalInfo": "https://acme-staging-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo",
"revokeCert": "https://acme-staging-v02.api.letsencrypt.org/acme/revoke-cert"
From the Certbot docs:
--preferred-profile PREFERRED_PROFILE
Request the given profile name from the ACME server,
or fallback to default. If the given profile name
exists in the ACME directory, use it to request a a
certificate. Otherwise, fall back to requesting a
certificate without a profile (which means the CA will
use its default profile). This allows renewals to
succeed even if the CA deprecates and removes a given
profile. (default: None)
3 Likes
An ACME server should only advertise the profiles it genuinely supports, otherwise clients can get stuck trying to request profiles that don't really exist, and they can only intelligently avoid that by not requesting a profile if it doesn't appear in the directory. There is no profile specific mechanism for checking if an account has permission to request a specific profile, so you're left parsing the error to determine the cause.
The profiles are possibly advertised now to flush out any acme clients that might have had trouble parsing the directory, but that seems more like a job for staging than production.
Arguably you could fallback to not requesting a profile if the order fails repeatedly but that's not ideal.
I don't see that restriction in the draft spec for profiles. I only saw that ACME Clients "must" not request a profile that is not advertised. And, perhaps this aspect of profiles is better discussed in the Client Dev section 
Certbot's new profile options look designed to control how its own renew command behaves. Nothing more and nothing less.
When Certbot successfully gets a cert it creates a renewal config file. That config file contains all the options used including any profile setting. The --preferred profile allows Certbot renew to continue receiving a cert even if the CA drops support for the chosen profile (by dropping it from directory).
The burden falls on the user to specify a valid profile with the original cert request.
I personally would use --required and not the --preferred profile setting as if I bothered to choose one I want to know that's what I got. I stay informed, actively monitor my systems, and can react promptly to changes. But, I can appreciate some people may choose differently. I think anyone using a 6-day long cert (once available) should stay actively informed of changes and also have backup certs already in place in case of outages. But, I very much digress
1 Like
You're special Mike - many of the users I work with are not traditional server administrators, they often have a job doing something else and got lumbered with looking after their website(s). However the majority of them will never intentionally use profiles at all, so I guess it doesn't have to affect them and this can just be a thing for the power users.
2 Likes