Backport 1.14: Add notes around OCSP GET request issue (#25757)

Co-authored-by: Steve Clark <[email protected]>

website/content/api-docs/secret/pki.mdx

@@ -1705,6 +1705,10 @@ At this time there are certain limitations of the OCSP implementation at this pa
  1. Note that this API will not work with the Vault client as both request and responses are DER encoded, and
  1. Note that KMS based issuers which require PSS support are not supported either (such as PKCS#11 HSMs or GCP in certain scenarios).
 
+~> Note: The OCSP implementation for GET requests can lead to intermittent
+400 errors when an encoded OCSP request contains consecutive '/' characters.
+Until this is resolved it is recommended to use POST based OCSP requests.
+
 These are unauthenticated endpoints.
 
 | Method | Path                                                       | Response Format                                                                   | Source  |
@@ -3837,9 +3841,9 @@ the CRL.
    cross-cluster revocation request will be created.<br /><br />
    API calls to revoke a certificate with Proof of Possession (PoP) cannot
    be satisfied if the certificate is not available locally and will
-   not result in a cross-cluster revocation request. 
+   not result in a cross-cluster revocation request.
 
-- `unified_crl` `(bool: false)` - 
+- `unified_crl` `(bool: false)` -
   <EnterpriseAlert product="vault" inline /> Enables unified CRL and OCSP building. This
   synchronizes all revocations between clusters; a single, unified CRL will be
   built on the active node of the primary performance replication (PR)

website/content/docs/secrets/pki/considerations.mdx

@@ -33,7 +33,7 @@ generating the CA to use with this secrets engine.
    - [NotAfter Behavior on Leaf Certificates](#notafter-behavior-on-leaf-certificates)
    - [Cluster Performance and Quantity of Leaf Certificates](#cluster-performance-and-quantity-of-leaf-certificates)
  - [You must configure issuing/CRL/OCSP information _in advance_](#you-must-configure-issuingcrlocsp-information-_in-advance_)
- - [Distribution of CRLs and OCSP](#distribution-of-crls-ocsp)
+ - [Distribution of CRLs and OCSP](#distribution-of-crls-and-ocsp)
  - [Automate CRL Building and Tidying](#automate-crl-building-and-tidying)
  - [Spectrum of Revocation Support](#spectrum-of-revocation-support)
    - [What Are Cross-Cluster CRLs?](#what-are-cross-cluster-crls)
@@ -144,7 +144,7 @@ also be more expensive. Careful consideration of both issuer and issued key
 types can have meaningful impacts on performance of not only Vault, but
 systems using these certificates.
 
-### Cluster performance and key type
+### Cluster performance and key types
 
 The [benchmark-vault](https://github.com/hashicorp/vault-benchmark) project
 can be used to measure the performance of a Vault PKI instance. In general,
@@ -523,6 +523,10 @@ OCSP responses are signed by the issuing CA within Vault). This means both are
 fine to distribute over non-secure and non-authenticated channels, such as
 HTTP.
 
+~> Note: The OCSP implementation for GET requests can lead to intermittent
+400 errors when an encoded OCSP request contains consecutive '/' characters.
+Until this is resolved it is recommended to use POST based OCSP requests.
+
 ## Automate CRL building and tidying
 
 Since Vault 1.12, the PKI Secrets Engine supports automated CRL rebuilding

website/content/docs/upgrading/upgrade-to-1.12.x.mdx

@@ -183,7 +183,7 @@ Affects version 1.12.3. A fix will be released in 1.12.4.
 
 @include 'tokenization-rotation-persistence.mdx'
 
-@include 'ocsp-redirect.mdx'
+@include 'known-issues/ocsp-redirect.mdx'
 
 ### LDAP pagination issue
 
@@ -202,8 +202,8 @@ Affects Vault 1.12.6.
 
 ### Slow startup time when storing PKI certificates
 
-There was a regression introduced in 1.12.0 where Vault is slow to start because the 
-PKI secret engine performs a list operation on the stored certificates. If a large number 
+There was a regression introduced in 1.12.0 where Vault is slow to start because the
+PKI secret engine performs a list operation on the stored certificates. If a large number
 of certificates are stored this can cause long start times on active and standby nodes.
 
 There is currently no workaround for this other than limiting the number of certificates stored

website/content/docs/upgrading/upgrade-to-1.13.x.mdx

@@ -101,7 +101,7 @@ are unaffected.
 
 @include 'tokenization-rotation-persistence.mdx'
 
-@include 'ocsp-redirect.mdx'
+@include 'known-issues/ocsp-redirect.mdx'
 
 ### PKI revocation request forwarding
 

website/content/docs/upgrading/upgrade-to-1.14.x.mdx

@@ -64,3 +64,5 @@ is measuring cumulative time writing, and not the distribution of individual wri
 @include 'known-issues/expiration-metrics-fatal-error.mdx'
 
 @include 'known-issues/perf-secondary-many-mounts-deadlock.mdx'
+
+@include 'known-issues/ocsp-redirect.mdx'

website/content/partials/ocsp-redirect.mdx → website/content/partials/known-issues/ocsp-redirect.mdx

@@ -8,4 +8,4 @@ As a workaround, OCSP POST requests can be used which are unaffected.
 
 #### Impacted versions
 
-Affects all current versions of 1.12.x and 1.13.x
+Affects all current versions of 1.12.x, 1.13.x, 1.14.x, 1.15.x, 1.16.x