- Add a helper function that can accept the final API path along with
the pattern function for an ACME api definition and generate the
various flavors for the given API
* Move all ACME wrappers into a dedicated go file
- Make it easier to figure out where the various wrappers for
ACME exist by locating them inside a dedicated go file instead
of spread out across the various path_acme_xxx files.
* Add missing copyright headers to PKI files
* Enable creation of accounts
- Refactors many methods to take an acmeContext, which holds the
storageContext on it.
- Updates the core ACME Handlers to use *acmeContext, to avoid
copying structs.
- Makes JWK exported so the JSON parser can find it.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Finish ACME account creation
- This ensures a Kid is created when one doesn't exist
- Expands the parsed handler capabilities, to format the response and
set required headers.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
- Instead of using tests that just test the plugin storage/interface
layer, use a full Vault instance to validate that we can send/receive
the proper headers and responses back to a client.
- Found an issue with HEAD new-nounce api calls returning 500 errors.
- Add the /acme/ suffix to the baseUrl in the acme context so we don't
have to keep adding it a bit everywhere.
* Identify whether JWKs existed or were created, set KIDs
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Reclassify ErrAccountDoesNotExist as 400 per spec
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Add additional stub methods for ACME accounts
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Start adding ACME newAccount handlers
This handler supports two pieces of functionality:
1. Searching for whether an existing account already exists.
2. Creating a new account.
One side effect of our JWS parsing logic is that we needed a way to
differentiate between whether a JWK existed on disk from an account or
if it was specified in the request. This technically means we're
potentially responding to certain requests with positive results (e.g.,
key search based on kid) versus erring earlier like other
implementations do.
No account storage has been done as part of this commit.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
* Unify path fields handling, fix newAccount method
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
---------
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
