We break the clique, instead building these chains manually, ensuring
that the remaining chains do not change and only the modified certs
change. We then reset them (back to implicit chain building) and ensure
we get the same results as earlier.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

With the new issuer field (manual_chain), we can no longer err when a
name already exists: we might be updating the existing issuer (with the
same name), but changing its manual_chain field. Detect this error and
correctly handle it.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Using the issuance infrastructure, we generate new certificates (either
roots or intermediates), positing that this is roughly equivalent to
importing an external bundle (minus error handling during partial
imports). This allows us to incrementally construct complex chains,
creating reissuance cliques and cross-signing cycles.

By using ECDSA certificates, we avoid high signature verification and
key generation times.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This returns the CA Chain attribute of an issuer, showing its computed
chain based on other issuers in the database, when fetching a specific
issuer.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

With the one-entry-per-issuer approach, CA Chains become implicitly
constructed from the pool of issuers. This roughly matches the existing
expectations from /config/ca (wherein a chain could be provided) and
/intemediate/set-signed (where a chain may be provided). However, in
both of those cases, we simply accepted a chain. Here, we need to be
able to reconstruct the chain from parts on disk.

However, with potential rotation of roots, we need to be aware of
disparate chains. Simply concating together all issuers isn't
sufficient. Thus we need to be able to parse a certificate's Issuer and
Subject field and reconstruct valid (and potentially parallel)
parent<->child mappings.

This attempts to handle roots, intermediates, cross-signed
intermediates, cross-signed roots, and rotated keys (wherein one might
not have a valid signature due to changed key material with the same
subject).
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

 - Since the elements of the struct were not exported we serialized an empty
   migration log to disk and would re-run the migration

When importing complex chains, we should identify in which certificate
or key the failure occurred.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

 - Add a call to buildCRL if we created an issuer within pathImportIssuers
 - Augment existing FullCAChain to verify we have a proper CRL post set-signed api call
 - Remove a code block writing out "ca" storage entry that is no longer used.

 - Detail I missed from the RFC was to assign the Name field as "current" for migrated key and issuer.

 - Validate that generate/root calls are no longer idempotent, but the bundle importing
   does not generate new keys/issuers
 - As before make sure that the delete root api resets everything
 - Address a bug within the storage that we bombed when we had multiple different
   key types within storage.

 - Replace hardcoded "default" references with a constant to easily identify various usages.
 - Use the addIssuerRefField function instead of redefining the field in various locations.

The old DELETE /root code must now delete all keys and issuers for
backwards compatibility. We strongly suggest calling individual delete
methods (DELETE /key/:key_ref or DELETE /issuer/:issuer_ref) instead,
for finer control.

In the process, we detect whether the deleted key/issuers was set as the
default. This will allow us to warn (from the single key/deletion issuer
code) whether or not the default was deleted (while allowing the
operation to succeed).
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This makes two minor changes to the existing test suite:

 1. Importing partial bundles should now succeed, where they'd
    previously error.
 2. fetchCertBySerial no longer handles CA certificates.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

When the default issuer and key are missing (and haven't yet been
specified), we should clarify that error message.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

The existing bundle import code will satisfy the intermediate import;
use it instead of the old ca_bundle import logic. Additionally, update
/config/ca to use the new import code as well.

While testing, a panic was discovered:

> reflect.Value.SetMapIndex: value of type string is not assignable to type pki.keyId

This was caused by returning a map with type issuerId->keyId; instead
switch to returning string->string maps so the audit log can properly
HMAC them.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

 - Addresses some test failures due to an incorrect refactoring of a legacy api
   path /sign-verbatim within PKI

 - PR feedback, move setting up the default configuration references within
   the import methods instead of within the writeCaBundle method. This should
   now cover all use cases of us setting up the defaults properly.

 - Use the buildPath convention for the function name instead of common...

 - Add utility methods to fetch the issuer_name, issuer_ref, key_name and key_ref arguments from data fields.
 - Centralize the logic to clean up these inputs and apply various validations to all of them.

 - Update all new API endpoints to use the new agreed upon argument names.
   - issuer_ref & key_ref to refer to existing
   - issuer_name & key_name for new definitions
 - Update returned values to always user issuer_id and key_id

This updates the /sign and /issue endpoints, allowing them to take the
default issuer (if none is provided by a role) and adding
issuer-specific versions of them.

Note that at this point in time, the behavior isn't yet ideal (as
/sign/:role allows adding the ref=... parameter to override the default
issuer); a later change adding role-based issuer specification will fix
this incorrect behavior.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

After setting a default issuer, one should be able to use the old /ca,
/ca_chain, and /cert/{ca,ca_chain} endpoints to fetch the default issuer
(and its chain). Update the fetchCertBySerial helper to no longer
support fetching the ca and prefer fetchCAInfo for that instead (as
we've already updated that to support fetching the new issuer location).
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

Using the new updateDefaultIssuerId(...) from the storage migration PR
allows for easy implementation of configuring the default issuer. We
restrict callers from setting blank defaults and setting default to
default.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This endpoint allows existing issuers to be used to directly sign CSRs.
In the process, we've updated the existing /sign-verbatim endpoint to be
equivalent to a call to /issuer/:ref/sign-verbatim.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This endpoint allows existing issuers to be used to sign self-signed
certificates. In the process, we've updated the existing
/root/sign-self-issued endpoint to be equivalent to a call to
/issuer/default/sign-self-issued.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This endpoint allows existing issuers to be used to sign intermediate
CA certificates. In the process, we've updated the existing
/root/sign-intermediate endpoint to be equivalent to a call to
/issuer/default/sign-intermediate.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This adds the two core import code paths to the API:
/issuers/import/cert and /issuers/import/bundle. The former differs from
the latter in that the latter allows the import of keys. This allows
operators to restrict importing of keys to privileged roles, while
allowing more operators permission to import additional certificates
(not used for signing, but instead for path/chain building).
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This implements the fetch operations around issuers in the PKI Secrets
Engine. We implement the following operations:

 - LIST /issuers - returns a list of known issuers' IDs and names.
 - GET /issuer/:ref - returns a JSON blob with information about this
   issuer.
 - POST /issuer/:ref - allows configuring information about issuers,
   presently just its name.
 - DELETE /issuer/:ref - allows deleting the specified issuer.
 - GET /issuer/:ref/{der,pem} - returns a raw API response with just
   the DER (or PEM) of the issuer's certificate.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This allows fetchCAInfo to fetch a specified issuer, via a reference
parameter provided by the user. We pass that into the storage layer and
have it return a cert bundle for us. Finally, we need to validate that
it truly has the key desired.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

 - Hook into the backend::initialize function, calling the migration on a primary only.
 - Migrate an existing certificate bundle to the new issuers and key layout

This adds tests for importing keys and issuers into the new storage
layout, ensuring that identifiers are correctly inferred and linked.

Note that directly writing entries to storage (writeKey/writeissuer)
will take KeyID links from the parent entry and should not be used for
import; only existing entries should be updated with this info.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

importKey is generally preferable to the low-level writeKey for adding
new entries. This takes only the contents of the private key (as a
string -- so a PEM bundle or a managed key handle) and checks if it
already exists in the storage.

If it does, it returns the existing key instance.

Otherwise, we create a new one. In the process, we detect any issuers
using this key and link them back to the new key entry.

The same holds for importCert over importKey, with the note that keys
are not modified when importing certificates.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This refactors the parsing of PrivateKeys from PEM blobs into shared
methods (ParsePEMKey, ParseDERKey) that can be reused by the existing
Bundle parsing logic (ParsePEMBundle) or independently in the new
issuers/key-based PKI storage code.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

This adds a method to construct a certutil.CertBundle from the specified
issuer identifier, optionally loading its corresponding key for signing.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

The API context will usually have a user-specified reference to the key.
This is either the literal string "default" to select the default key,
an identifier of the key, or a slug name for the key. Here, we wish to
resolve this reference to an actual identifier that can be understood by
storage.

Also adds the missing Name field to keys.
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>

* Simple starting PKI storage api for CA rotation
* Add key and issuer storage apis
* Add listKeys and listIssuers storage implementations
* Add simple keys and issuers configuration storage api methods