Search the Community

AWS Transfer Family now provides you with the option to import and use a trading partner’s public, self-signed TLS certificate for sending Applicability Statement 2 (AS2) messages to their server over HTTPS. Additionally, you can now choose to encrypt messages sent to your partner’s server using the 3DES cipher. By default, AS2 connectors will encrypt messages with the AES128 cipher unless you select 3DES for purposes of backwards compatibility with your partner’s existing AS2 implementation. These capabilities add to AWS Transfer Family’s existing list of AS2 interoperability features and enable you to reliably connect with trading partners that require these specific security configurations. View the full article

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

Don’t be surprised if you have seen the Certificate Update in the Amazon Relational Database Service (Amazon RDS) console. If you use or plan to use Secure Sockets Layer (SSL) or Transport Layer Security (TLS) with certificate verification to connect to your database instances of Amazon RDS for MySQL, MariaDB, SQL Server, Oracle, PostgreSQL, and Amazon Aurora, it means you should rotate new certificate authority (CA) certificates in both your DB instances and application before the root certificate expires. Most SSL/TLS certificates (rds-ca-2019) for your DB instances will expire in 2024 after the certificate update in 2020. In December 2022, we released new CA certificates that are valid for 40 years (rds-ca-rsa2048-g1) and 100 years (rds-ca-rsa4096-g1 and rds-ca-ecc384-g1). So, if you rotate your CA certificates, you don’t need to do It again for a long time... View the full article

Great post about application authentication and authorization on AWS; https://blog.cloudcraft.co/application-authentication-and-authorization-on-aws/

AWS Certificate Manager (ACM) Private Certificate Authority (CA) now supports using S3 Block Public Access when storing certificate revocation links (CRL) in S3 buckets. View the full article

AWS Certificate Manager (ACM) Private Certificate Authority (CA) is now available in the AWS Europe (Milan) and AWS Africa (Cape Town) regions. This regional expansion extends the availability of ACM PrivateCA across the globe, increasing the number of regions to 22, including AWS GovCloud (US) Regions. View the full article

ACM for Nitro Enclaves is an enclave application that allows you to use public and private SSL/TLS certificates with your web applications and servers running on Amazon EC2 instances with AWS Nitro Enclaves. SSL/TLS certificates are used to secure network communications and establish the identity of websites over the Internet as well as resources on private networks. Nitro Enclaves is an EC2 capability that enables creation of isolated compute environments to protect and securely process highly sensitive data, such as SSL/TLS private keys. View the full article

As more organizations undergo digital transformation, evolve their IT infrastructure and migrate to public cloud, the role of digital certificates will grow—and grow a lot. Certificates and certificate authorities (CAs) play a key role in both modern IT models like DevOps and in the evolution of traditional enterprise IT. In August, we announced our Certificate Authority Service (CAS)—a highly scalable and available service that simplifies and automates the management and deployment of private CAs while meeting the needs of modern developers building and running modern systems and applications. Take a look at how easy it is to set up a CA in minutes! At launch, we showed how CAS allows DevOps security officers to focus on running the environment and offload time consuming and expensive infrastructure setup to the cloud. Moreover, as remote work continues to grow, it’s bringing a rapid increase in zero trust network access (example), and the need to issue an increasing number of certificates for many types of devices and systems outside the DevOps environment. The challenge that emerged is that the number of certificates and the rate of change both went up. It is incredibly hard to support a large WFH workforce from a traditional on-premise CA, assuming your organization even has the “premises” where it can be deployed. To be better ready for these new WFH related scenarios, we are introducing a new Enterprise tier that is optimized for machine and user identity. These use cases tend to favor longer lived certificates and require much more control over certificate lifecycle (e.g., ability to revoke a certificate when the user loses a device). This new tier complements the DevOps tier which is optimized for high throughput environments, and which tend to favor shorter lived certificates (e.g., for containers, micro-services, load balancers, etc.) at an exceptionally high QPS (number of certificates issued per second). Simply, put our goal with the new Enterprise tier is to make it easy to lift and shift your existing on-premises CA. Today CAS supports “bring your own root” to allow the existing CA root of trust to continue being the root of trust for CAS. This gives you full control over your root of trust while offloading scaling and availability management to the cloud. This also gives you freedom to move workload across clouds without having to re-issue your PKI, and vastly reduces the migration cost. Moreover, through our integration with widely deployed certificate lifecycle managers (e.g., Venafiand AppViewX), we have made the lift and shift of an existing CA to the cloud a breeze, so you can continue using the tooling that you are familiar with and simply move your CA to the cloud. CAS leverages FIPS 140-2 Level 3 validated HSMs to protect private key material. With the two tiers of CAS (Enterprise and DevOps), you can now address all your certificate needs (whether for your devops environments or for your corporate machine and user identity) in one place. This is great news for security engineers and CA admins in your environment as now they can use a single console to manage the certificates in the environment, create policies, audit, and react to security incidents. Visibility and expiration have always been the two biggest issues in PKI and with CAS and our partner solutions, you can solve these issues in one place. So whether you are at the beginning of your journey of using certificates and CAs, or have an existing CA that has reached its limit to address the surge in demand (either due to WFH or your new DevOps environment), CA Service can deliver a blend of performance, convenience, ease of deployment/operation with the security and trust benefits of Google Cloud. CAS is available in preview for all customers to try. Call to action: Review CAS video “Securing Applications with Private CAs and Certificates” at Google Cloud Security Talks Review “Introducing CAS: Securing applications with private CAs and certificates”for other CAS use cases such as support for DevOps environments. Try Certificate Authority Service for your organization. Related Article Introducing CAS: Securing applications with private CAs and certificates Certificate Authority Service (CAS) is a highly scalable and available service that simplifies and automates the management and deploymen... Read Article