Search the Community

Many organizations rely on X.509 public key infrastructure (PKI) certificates to protect their services and workloads. This standard supports a wide range of configurable fields and extensions, making it highly flexible and allowing for a high degree of customization. Many of these fields are relevant for a large number of use cases and are natively supported by HashiCorp Vault. However, due to the sheer number of fields defined in the X.509 standard, there were cases where a field was not implemented in Vault and could not be validated by Vault. To address these use cases, we have introduced support for Certificate Issuance External Policy Services (CIEPS) in Vault Enterprise 1.15. Issuing a PKI certificate Issuing a PKI certificate with Vault is simple. Once a certificate authority (CA) has been established and configured with a role, authenticated clients can submit certificate issuance or signing requests against that role. The role defines the allowed values in the certificate and compares the request against those values. If the values match, a certificate is issued or signed. If they do not match, the request is rejected. This workflow is suitable for all requests that include fields and extensions natively supported by Vault. In scenarios where customers require certificates to be issued with custom fields, Vault offers the option to use the sign-verbatim method, described in the next section. Challenges with sign-verbatim requests Issuing or signing a certificate with the sign-verbatim method allows the request to use arbitrary fields and extensions that are not supported with the role-based process outlined above. However, because Vault does not validate those custom fields, the use of sign-verbatim requires a different validation approach. HashiCorp Sentinel is a policy as code framework that allows the definition of fine-grained, logic-based policies. It can be used to provide additional validation for requests made to endpoints and entities in Vault. When defined for a particular endpoint, the Sentinel policy evaluates all requests to that endpoint and determines whether to allow or reject them based on the result of the policy check. With Sentinel, specific fields can be denied or required. When fields are defined as required in the Sentinel policy, the client has to know and specify all required fields in the request. Missing fields would lead to the request being denied, and resolving the issue requires clients to have knowledge of very specific PKI fields, which may not be easy to find. In addition, Sentinel operates on a deny/accept basis and lacks the ability to modify requests. Another possible approach when issuing or signing certificates verbatim would be to set up a validation service in front of Vault. With this approach, the client communicates with and authenticates to the validation service instead of directly to Vault. The validation service then validates incoming requests and forwards valid requests to the sign-verbatim endpoint. However, in order to do this, the validation service needs to authenticate to Vault, which introduces an additional authentication and authorization step. Clients who need to use this validation service and Vault for other use cases, such as role-based certificate request validation, would need to manage authentication information for both services. Similar to the Sentinel approach, a validation service running in front of Vault cannot modify certificate signing requests (CSR). Even if the request could be modified, it would happen outside of Vault which leaves the question of how those modifications could be audited. In addition, in order to remain compatible with Vault, the validation service would need to support the ACME protocol and any protocols that may be added to Vault in the future. Both approaches, sign-verbatim with Sentinel or with a validation service, are good for allowing and rejecting requests. However, they do not provide the ability to modify requests and lack auditability. As a result, the sign-verbatim solution is not user-friendly and is not popular among organizations that use Vault. Vault’s Certificate Issuance External Policy Service To address these challenges, we designed and implemented a new Vault Enterprise feature called CIEPS in HashiCorp Vault 1.15. CIEPS is part of the PKI secrets engine and offers a new mechanism that allows customers to use and validate any field specified in the x.509 standard. This enables a high degree of customizability to address less-common use cases. With CIEPS, customers can build a custom policy service that runs outside of Vault. In the service, custom issuance policies can be specified. A Vault operator can then configure the PKI secrets engine to refer to this custom policy service. This lets Vault handle communication with the service. When Vault receives a request that requires validation by the external policy service, it forwards the request to the custom policy service for validation and approval. The external policy service processes the request and, based on the defined policies, determines if the request should be approved or denied. When the request is approved, Vault updates select fields if necessary and then issues the certificate. If the request is denied, the policy service can specify a custom error message in its response to Vault. Vault includes the error message in its response to the original request, allowing a better user experience with customized error messages instead of generic, uninformative ones. Once everything has been set up, clients can authenticate to and request certificates from Vault. The interaction between Vault and the external policy service is not visible to the client. For the client, Vault's behavior remains unchanged and the certificate request workflow remains the same. The only difference is the API endpoint to which the request is sent in Vault. No additional authentication or authorization step is necessary. This lets the client interact only with Vault as the central platform, instead of having to target an additional service. The external policy service can also modify the original requests if necessary. Since it is directly integrated with Vault, all requests and responses are part of Vault’s audit logs, ensuring complete auditability of the issuance process. The benefits of using an external policy service with Vault include: Auditability: As Vault is handling the communication and requests to the service, all requests and responses between Vault and the external policy service are tracked in Vault’s audit logs. User experience: Clients interact only with Vault, the request workflow stays the same, and error messages are customizable. Certificate modification: The original request can be customized according to the defined policies. Flexibility: The external policy service uses a customer-defined external service for validation and is therefore more flexible than the role-based system. CIEPS in Vault PKI: Adding flexibility With CIEPS, organizations now have granular control and the ability to create flexible certificate structures that meet their PKI requirements, while having HashiCorp Vault validate and issue them. CIEPS allows for the use and validation of any field or extension specified in the x.509 standard, addressing use cases that are not supported natively and therefore were previously not possible in Vault. Additionally, the workflow for end users remains the same, ensuring a consistent user experience. Interested in learning more about the Certificate Issuance External Policy Service? Check out our hands-on tutorial, which includes an example service to get you started. To learn more about how HCP Vault and Vault Enterprise can help with your PKI requirements, contact HashiCorp sales. HashiCorp Vault PKI resources PKI design considerations: Read this technical guide on how to build modern PKI with HashiCorp Vault. What is public key infrastructure (PKI): See how PKI governs the provisioning of digital certificates to protect sensitive data, establish digital identities, and secure communications. What is ACME PKI? Learn about the ACME protocol for PKI, the common problems it solves, and why it should be part of your certificate management roadmap. PKI hosting: Cloud-based PKI vs. self managed: Discover the benefits and differences between hosting PKI workloads in the cloud versus on-premises. X.509 certificate management with Vault: A look at practical public key certificate management in HashiCorp Vault using dynamic secrets rotation. View the full article

Enterprises leverage Public key infrastructure (PKI) to encrypt, decrypt, and authenticate information between servers, digital identities, connected devices, and application services. PKI is used to establish secure communications to abate risks to data theft and protect proprietary information as organizations increase their reliance on the internet for critical operations. This post will explore how public key cryptography enables related keys to encrypt and decrypt information and guarantee the integrity of data transfers... View the full article

HashiCorp is pleased to announce the general availability of Vault 1.15. HashiCorp Vault provides secrets management, data encryption, identity management, and other workflow capabilities for applications on any infrastructure. Vault 1.15 focuses on Vault’s core secrets workflows as well as team workflows, integrations, and visibility. Key additions in this release include: Certificate Issuance External Policy Service (CIEPS) UI enhancements Azure SDK Workload Identity Federation (WIF) support Vault Secrets Operator (VSO) enhancements Vault Enterprise seal high availability (beta) Vault Enterprise secrets sync (beta) Event monitoring (beta) Let’s take a closer look... View the full article

Many organizations continue to use antiquated methods to manage and track certificates. Common methods include tracking certificates in spreadsheets, text documents, and ticketing solutions. These methods are not only time consuming, taking hours or days to provision or renew certificates, they can also lead to security and compliance issues. The lack of an alerting mechanism or management interface can lead to systems outages that are otherwise easily avoidable... View the full article

We are pleased to announce the general availability of HashiCorp Vault 1.11. Vault provides secrets management, data encryption, and identity management for any application on any infrastructure. Vault 1.11 focuses on improving Vault’s core workflows and making key features production-ready. In this release, Vault adds a new Kubernetes secrets engine to dynamically generate credentials, improves the KV (key-value) secrets engine’s usability, adds support for the PKI engine for non-disruptive rotation, enables bring your own key (BYOK) for Transit, and brings many other improvements. Key features and improvements include: Kubernetes secrets engine: A new secrets engine that can dynamically generate Kubernetes service account tokens, service accounts, role bindings, and roles. Integrated storage autopilot (for Vault Enterprise): Autopilot is now able to perform seamless automated upgrades and includes support for redundancy zones to improve cluster resiliency. Vault agent: Updated consul-template includes an opt-in pkiCert option to prevent consul-template from re-fetching PKI certificates on reload or restart. Transit secrets engine: The ability to import externally generated keys to support use cases where there is a need to bring in an existing key from a hardware security module (HSM) or other outside system. PKI secrets engine: Support for non-disruptive intermediate and root certificate rotation. This introduces /keys and /issuers endpoints to allow import, generation, and configuration of any number of keys or issuers within a PKI mount, giving operators the ability to rotate certificates in place without affecting existing client configurations. Also has support for CPS URL in custom policy identifiers when generating certificates using the PKI engine. Terraform provider for Vault: New documentation and feature enhancements in the Terraform provider to the PKI secrets engine, along with support for specifying a namespace within a resource or data source. Entropy Augmentation: Updated sys/tools/random and transit/random endpoints to support user defined random byte source from an HSM. Google Cloud auth method: A custom_endpoint option so that Google service endpoints used by the underlying client can be customized to support both public and private services. User interface updates (UI): UI support to configure login multi-factor authentication (MFA) using time-based one-time passwords (TOTP), Duo, Okta, and PingIdentity. Snowflake database secrets engine: Support to manage RSA key-pair credentials for dynamic and static Snowflake database users. Consul secrets engine: Support for templating policy on node_identities and service_identities to be set on the Consul token creation. KMIP secrets engine (for Vault Enterprise): Support for import, query, encryption, and decryption operations. (Please refer to the Supported KMIP Operations for a complete list.) Transform secrets engine (for Vault Enterprise): A convergent tokenization mode and a tokenization lookup feature. Vault usage metrics: Ability to export the unique client count aggregate for a selected billing period (in technical preview). UI interface updated with the ability to view changes to client counts month over month. This release also includes additional new features, workflow enhancements, general improvements, and bug fixes. The Vault 1.11 changelog and release notes list all the updates. Please visit the Vault HashiCorp Learn page for step-by-step tutorials demonstrating the new features… View the full article