Skip to content
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

Closed
6 tasks done
cpu opened this issue Jan 7, 2019 · 7 comments
Closed
6 tasks done

Make current -strict behaviour default #192

cpu opened this issue Jan 7, 2019 · 7 comments

Comments

@cpu
Copy link
Contributor

cpu commented Jan 7, 2019

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:

  • GET requests to Order, Authz, Challenge and Certificate resources will fail. POST-as-GET will be required.
  • HEAD requests to new nonce will return status 200 not status 204.
  • POST requests will be required to have the correct Content-Type header: application/jose+json
  • Using a POST with an empty JWS body to fetch Account resources will fail. A POST-AS-GET request should be used instead.
  • POSTs to Challenge resources that contain a key authorization in the JWS body will fail. The JWS body should be the trivial JSON payload {}.
  • TLS-ALPN-01 challenge response certificates using the obsolete OID (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.
@cpu
Copy link
Contributor Author

cpu commented Jan 7, 2019

I think if we switch to semver (#146) this would be a natural point at which to bump major version numbers.

@jsha
Copy link
Contributor

jsha commented Feb 8, 2019

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.

@Klaus-Tockloth
Copy link

The current Certbot release (0.30.2) isn't working (for me) in strict mode (option -strict):

{
   "type": "urn:ietf:params:acme:error:malformed",
   "detail": "Challenge response body contained legacy KeyAuthorization field, POST body should be `{}`",
   "status": 400
}

@jsha
Copy link
Contributor

jsha commented Feb 8, 2019

Thanks for checking! I've told the Certbot team

@cpu
Copy link
Contributor Author

cpu commented Feb 15, 2019

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.

We're running slightly behind schedule on this and are going to delay the v2.0.0 release to next week (likely Feb 19th).

@cpu cpu closed this as completed in #203 Feb 19, 2019
@cpu
Copy link
Contributor Author

cpu commented Feb 19, 2019

Master now defaults to enforcing all of the behaviours previously gated by -strict 🎉 👨‍🏫

Later today after #207 is merged I will cut the release tag for 2.0.0.

@cpu
Copy link
Contributor Author

cpu commented Feb 19, 2019

Release 2.0.0 and updated docker images are both now available. Thanks everyone!

bmw pushed a commit to certbot/certbot that referenced this issue Feb 27, 2019
…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.
adferrand added a commit to adferrand/certbot that referenced this issue Apr 26, 2019
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants