- Fix 'requesteed' -> 'requested' in errors/errors.go
- Fix 'paylod' -> 'payload' in docs/acme-divergences.md
These changes address typos identified by the linter.
Remove the remaining divergences from RFC8555 regarding what error types
we use in certain situations. Specifically:
- use "invalidContact" instead of "invalidEmail";
- use "unsupportedContact" for contact addresses that use a protocol
other than "mailto:"; and
- use "unsupportedIdentifier" for identifiers that specify a type other
than "dns".
Make minor, non-user-visible changes to how we structure the probs
package. Notably:
- Add new problem types for UnsupportedContact and
UnsupportedIdentifier, which are specified by RFC8555 and which we will
use in the future, but haven't been using historically.
- Sort the problem types and constructor functions to match the
(alphabetical) order given in RFC8555.
- Rename some of the constructor functions to better match their
underlying problem types (e.g. "TLSError" to just "TLS").
- Replace the redundant ProblemDetailsToStatusCode function with simply
always returning a 500 if we haven't properly set the problem's
HTTPStatus.
- Remove the ability to use either the V1 or V2 error namespace prefix;
always use the proper RFC namespace prefix.
Remove the `MandatoryPOSTasGET` flag from the WFE2.
Update the ACMEv2 divergence doc to note that neither staging nor
production use MandatoryPOSTasGET.
Fixes#6582.
@jsha suggested I re-implement a PR against Pebble regarding Authorization
reuse into Boulder (see https://github.com/letsencrypt/pebble/pull/325).
This is an initial attempt. I opted to handle this by creating a new file for
"Implementation Details" that are RFC conformant and are known to have
confused client developers.
This change reorganizes the document to have all changes
noted under their respective section headings, updates estimated
resolution dates on long-standing divergences, and updates all URLs
to reference the final RFC 8555 instead of various drafts.
In addition, it adds a note that we do not accept the (optional)
`notBefore` and `notAfter` fields of a `newOrder` request.
We can remove some divergences since in the V2 API:
* We use the correct error namespace.
* We use the correct `Content-Type` for Certificate requests.
* We use the correct `url` field in Challenge objects.
* We use the correct HTTP status code for Challenge POST requests.
* Remove the challenge whitelist
* Reduce the signature for ChallengesFor and ChallengeTypeEnabled
* Some unit tests in the VA were changed from testing TLS-SNI to testing the same behavior
in TLS-ALPN, when that behavior wasn't already tested. For instance timeouts during connect
are now tested.
Fixes#4109
This is primarily based on @rolandshoemaker's `readme-updates` branch and the closed PR: #3195
The README is restructured to be user-driven. Information that is strictly contributor focused (e.g. dep upgrades) is moved to CONTRIBUTING.md. The review feedback from #3195 from @jsha was all about text that we removed entirely in 29cdd78155
The README now links to the production deployment guide in the wiki and describes our general position on using Boulder.
The CONTRIBUTING.md guide links to the various docs/ pages and was updated.
The docs/acme-divergences page is updated for draft-15.
The DESIGN.md document is moved from the root of the repo into docs/. It has been updated to cover ACMEv2 and precertificates/SCT embedding.
Resolves https://github.com/letsencrypt/boulder/issues/3850
A frequent point of confusion is which ACME draft Boulder implements. Often people imagine (sensibly!) that there is one draft they can reference to understand Boulder.
This commit updates the divergences doc to clarify that it should be used to compare Boulder to whatever the most current ACME draft is and that Boulder doesn't implement a specific draft. This commit also adds a reference to what ACME v1 is and a link to the ACME v2 blog post.
Small references are also added to the "applications" concept from prev. drafts. Otherwise folks that land on older ACME drafts may wonder why the divergences doc doesn't mention "applications", a concept that was renamed to "orders" in subsequent drafts. We do document divergences for "orders" and attention should be directed there.
The IETF working group has published a [draft-06](https://tools.ietf.org/html/draft-ietf-acme-acme-07) and [draft-07 revision of ACME](https://tools.ietf.org/html/draft-ietf-acme-acme-07). This PR updates the Boulder `docs/acme-divergences.md` documentation for both drafts. Primarily this meant updating section numbers and links.
Notable updates:
* Added "index" directory Link divergence
* Removed divergence for "existing" field of authorizations - this was removed from the spec so it isn't a divergence anymore \o/
* Added divergence for the Boulder certificates endpoint not respecting client `Accept` headers and using the `application/pkix-cert` content type in responses vs `application/pem-certificate-chain`
* Added divergence for `unsupportedContact` and `accountDoesNotExist` errors.
* Added divergence for the `only-return-existing` field.
* Added divergence for retrying challenges
* Removed "meta" directory divergence since Boulder supports this now
Resolves#2825
Issue #2365 reported two places where we had divergences from ACME-04 in Boulder's implementation that were not reflected in the divergences doc. This PR documents:
1. That Boulder checks the `resource` field from the protected JWS header instead of the `url` field as described in Section 5.4.1
2. That Boulder uses a response with HTTP status code 409 (Conflict) when returning a Location header for an existing reg while Section 6.3 describes using HTTP status code 200 for this purpose.
This resolves#2365.
The current ACME specification allows certificates to be revoked by a account key for an account that holds valid authorizations for every name in the certificate to be revoked. This PR adds a branch to the existing wfe.RevokeCertificate method which checks if the account key holds the required authorizations if it isn't the key for the issuing account or the certificate key.
Fixes#2318.
Fixes#503.
Functionality is gated by the feature flag `AllowKeyRollover`. Since this functionality is only specified in ACME draft-03 and we mostly implement the draft-02 style this takes some liberties in the implementation, which are described in the updated divergences doc. The `key-change` resource is used to side-step draft-03 `url` requirement.
This PR adds a divergence to the acme-divergence doc for Section 6.6 "Certificate Revocation". Boulder does not currently support authorizing a revocation request using an arbitrary account key that is authorized for the same domains as in the certificate.
Shiloh Heurich