New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make current -strict
behaviour default
#192
Comments
I think if we switch to semver (#146) this would be a natural point at which to bump major version numbers. |
Let's go ahead and choose this flag day as February 15. We'll merge a PR to master making these behaviors the default, and bump to v2.0.0. Please post here if you expect this to cause big problems for you. |
The current Certbot release (0.30.2) isn't working (for me) in strict mode (option -strict):
|
Thanks for checking! I've told the Certbot team |
We're running slightly behind schedule on this and are going to delay the v2.0.0 release to next week (likely Feb 19th). |
Master now defaults to enforcing all of the behaviours previously gated by Later today after #207 is merged I will cut the release tag for |
Release 2.0.0 and updated docker images are both now available. Thanks everyone! |
…6758) Fixes #6755. POSTing the `keyAuthorization` in a JWS token when answering an ACME challenge, has been deprecated for some time now. Indeed, this is superfluous as the request is already authentified by the JWS signature. Boulder still accepts to see this field in the JWS token, and ignore it. Pebble in non strict mode also. But Pebble in strict mode refuses the request, to prepare complete removal of this field in ACME v2. Certbot still sends the `keyAuthorization` field. This PR removes it, and makes Certbot compliant with current ACME v2 protocol, and so Pebble in strict mode. See also [letsencrypt/pebble#192](letsencrypt/pebble#192) for implementation details server side. * New implementation, with a fallback. * Add deprecation on changelog * Update acme/acme/client.py Co-Authored-By: adferrand <adferrand@users.noreply.github.com> * Fix an instance parameter * Update changelog, extend coverage * Update comment * Add unit tests on keyAuthorization dump * Update acme/acme/client.py Co-Authored-By: adferrand <adferrand@users.noreply.github.com> * Restrict the magic of setting a variable in immutable object in one place. Make a soon to be removed method private.
…ertbot#6758) Fixes certbot#6755. POSTing the `keyAuthorization` in a JWS token when answering an ACME challenge, has been deprecated for some time now. Indeed, this is superfluous as the request is already authentified by the JWS signature. Boulder still accepts to see this field in the JWS token, and ignore it. Pebble in non strict mode also. But Pebble in strict mode refuses the request, to prepare complete removal of this field in ACME v2. Certbot still sends the `keyAuthorization` field. This PR removes it, and makes Certbot compliant with current ACME v2 protocol, and so Pebble in strict mode. See also [letsencrypt/pebble#192](letsencrypt/pebble#192) for implementation details server side. * New implementation, with a fallback. * Add deprecation on changelog * Update acme/acme/client.py Co-Authored-By: adferrand <adferrand@users.noreply.github.com> * Fix an instance parameter * Update changelog, extend coverage * Update comment * Add unit tests on keyAuthorization dump * Update acme/acme/client.py Co-Authored-By: adferrand <adferrand@users.noreply.github.com> * Restrict the magic of setting a variable in immutable object in one place. Make a soon to be removed method private. # Conflicts: # CHANGELOG.md
Pebble is carrying some breaking changes that more closely reflect the ACME specification but could break clients. To make Pebble less annoying to use in CI we gate these changes behind the
-strict
feature flag so that clients can make a choice about whether they'd like a stable(ish) ACME server for CI, or to find compatibility problems in their client before they become an issue with Let's Encrypt's production servers.At some point in the near future we should make a flag day to convert the
-strict
behaviours to default. Most of them have been present for some time and I think its reasonable to switch them to default soon.At present these are the
-strict
changes that would become default:application/jose+json
{}
.1.3.6.1.5.5.7.1.30.1
) will fail validation. The current OID should (1.3.6.1.5.5.7.1.31
) be used.The text was updated successfully, but these errors were encountered: