Pebble didn't have badSignatureAlgorithm error, while RFC8555 section
6.2 mandates it.
jws parse time check for bad algorithm is needed because same as
jose.parsesigned refuese to parse without algolist(which is good thing)
so error already thrown at that time and we need to catch this type of
error there.
see related boulder PR
https://github.com/letsencrypt/boulder/pull/8091
---------
Co-authored-by: Aaron Gable <aaron@aarongable.com>
- Add subproblem support (rfc8555#section-6.7.1)
- Use subproblems when rejecting identifiers in newOrder
- Block "blocked-domain.example" in the default configuration
Adds a new config value, `BlockedDomains`, which is a list of strings
representing domains for which Pebble should not issue certificates.
Adding a blocked domain such as "example.com" prevents issuance
for all subdomains of that name (e.g. "foo.example.com") as well.
If an order is rejected due to one of its names matching this blocklist,
the request will return a `rejectedIdentifier` error. This mirrors the
functionality of Boulder's Policy Authority.
Also slightly refactors the frontend's order verification code to split
domain-specific (as opposed to generic or ip-specific) checks into
their own helper function.
Signed-off-by: JoshVanL <vleeuwenjoshua@gmail.com>
This PR adds basic support for External Account Binding (EAB) as defined in the
[ACME protocol](https://tools.ietf.org/html/rfc8555#section-7.3.4).
The pebble config takes an extra argument `requireExternalBinding` which will
require new account ACME request to contain the `externalAccountBinding` object
to be present. Pebble will then verify the contents of the object as per the
spec.
The Pebble config takes an optional object of `externalAccountBindings`
containing a string map to
KIDs to MAC symmetric keys. These are stored statically in memory.
An extra config example has been made to show both options available
(test/config/pebble-config-external-account-bindings.json).
This has been tested using https://github.com/go-acme/lego. The following
command will successfully create a new account with Pebble using one of the keys
defined in the example config.
```
lego --server https://localhost:14000/dir --domains foo.com --email \
joshua.vanleeuwen@jetstack.io --http --kid kid-1 --hmac \
zWNDZM6eQGHWpSRTPal5eIUYFTu7EajVIoguysqZ9wG44nMEtx3MUAsUDkMTQ12W --eab run
```
**The keys in the example config are public and should never be used in
production**
Adds an endpoint to the API to revoke certificates.
There are some caveats to consider:
1. It doesn't verify account ownership.
2. It doesn't verify the certificate issuer.
3. It validates the reason, but it doesn't do anything with it after.
Signed-off-by: David Calavera <david.calavera@gmail.com>
This commit updates the WFE `verifyPOST` function to enforce that POSTs
with JWS bodies include the correct Content-Type header. If the header
is missing, or incorrect, an HTTP 415 response with a malformed problem
is returned.
This commit implements https://github.com/ietf-wg-acme/acme/pull/342 - replacing proactive issuance and CSR as part of new-order with an explicit order finalization step that delivers the CSR.
This is largely a port of the work done to add order finalization to the WIP ACMEv2 support in Boulder:
https://github.com/letsencrypt/boulder/pull/3169
I haven't tested this end-to-end yet - There are likely bugs lurking :-)
The later ACME draft specifies that one can retrieve account information for a given public key by signing a JWS request to the new-account endpoint that contains "only-return-existing: true". In such a case if the server can't find an existing account it should *not* create one but instead return an error. This commit adds this behaviour to Pebble.
Recent drafts define an explicit "accountDoesNotExist" error type for cases where the account indicated by a request can't be located. This commit updates Pebble to return this error type where appropriate.
This commit adds a `verifyContacts` method to the WFE that checks a new account's contact array to validate the contacts use the `mailto:` protocol and are generally well-formed. This adds support for testing
the "invalidContact" and "unsupportedContact" error types from the latest ACME drafts.
This commit adds initial support for HTTP-01 challenge validation. No
other challenge types are implemented at this time.
The implementation is largely a pared down version of what Boulder does
presently. For simplicities sake there are a number of important
differences that make Pebble *absolutely* unappropriate for production
uses:
1) The validation is performed in the same goroutine as the WFE's HTTP
handler instead of in a separate go routine. It might be worth
revamping this in the near future.
2) There is no read limit on the HTTP request body and timeouts are
not as strict
3) The validity of both pending and valid authzs is hardcoded at 1h.
As compared to Boulder the Pebble challenge design chooses to use
a separate endpoint (e.g. `/chalZ/9999` for chal 9999) instead of
referring to challenges subindexed from authorizations (e.g.
`/authZ/9999/1` for the first challenge of authz 9999). I believe this
is still within compliance with the overall specification and will
further exercise clients to not expect Boulder's choices to be
universal. The pebble client is updated to allow specifying a URL
to POST in addition to a directory endpoint to allow POSTing these
separate non-directory defined challenge URLs.
This PR adds support for ACME-04 style `/new-reg`. Most notably it:
1. Enforces the ToS differently than prior drafts
2. Keeps registrations in a simple map structure identified by the SPKI hash
There's no `regPath` handler for updating/viewing registrations at this time.
orangepizza
alexzorin
Maartje Eyskens
Josh Van Leeuwen
Florian Wernli
Daniel McCarney
Felix Fontein
David Calavera
Daniel