diff --git a/docs/api-reference/endpoints/certificates/certificate-request.mdx b/docs/api-reference/endpoints/certificates/certificate-request.mdx
new file mode 100644
index 0000000000..fcf601f5ed
--- /dev/null
+++ b/docs/api-reference/endpoints/certificates/certificate-request.mdx
@@ -0,0 +1,4 @@
+---
+title: "Get Certificate Request"
+openapi: "GET /api/v1/cert-manager/certificates/certificate-requests/{requestId}"
+---
diff --git a/docs/docs.json b/docs/docs.json
index e3b7296872..aafd32c356 100644
--- a/docs/docs.json
+++ b/docs/docs.json
@@ -2521,6 +2521,7 @@
"pages": [
"api-reference/endpoints/certificates/list",
"api-reference/endpoints/certificates/read",
+ "api-reference/endpoints/certificates/certificate-request",
"api-reference/endpoints/certificates/create-certificate",
"api-reference/endpoints/certificates/renew",
"api-reference/endpoints/certificates/update-config",
diff --git a/docs/documentation/platform/pki/certificates.mdx b/docs/documentation/platform/pki/certificates.mdx
deleted file mode 100644
index 0dec4826bd..0000000000
--- a/docs/documentation/platform/pki/certificates.mdx
+++ /dev/null
@@ -1,412 +0,0 @@
----
-title: "Certificates"
-sidebarTitle: "Certificates"
-description: "Learn how to issue X.509 certificates with Infisical."
----
-
-## Concept
-
-Assuming that you've created a Private CA hierarchy with a root CA and an intermediate CA, you can now issue/revoke X.509 certificates using the intermediate CA.
-
-
-
-```mermaid
-graph TD
- A[Root CA]
- A --> B[Intermediate CA]
- A --> C[Intermediate CA]
- B --> D[Leaf Certificate]
- C --> E[Leaf Certificate]
-```
-
-
-
-## Workflow
-
-The typical workflow for managing certificates consists of the following steps:
-
-1. Issuing a certificate under an intermediate CA with details like name and validity period. As part of certificate issuance, you can either issue a certificate directly from a CA or do it via a certificate template.
-2. Managing certificate lifecycle events such as certificate renewal and revocation. As part of the certificate revocation flow,
- you can also query for a Certificate Revocation List [CRL](https://en.wikipedia.org/wiki/Certificate_revocation_list), a time-stamped, signed
- data structure issued by a CA containing a list of revoked certificates to check if a certificate has been revoked.
-
-
- Note that this workflow can be executed via the Infisical UI or manually such
- as via API.
-
-
-## Guide to Issuing Certificates
-
-In the following steps, we explore how to issue a X.509 certificate under a CA.
-
-
-
-
-
-
- A certificate template is a set of policies for certificates issued under that template; each template is bound to a specific CA and can also be bound to a certificate collection for alerting such that any certificate issued under the template is automatically added to the collection.
-
- With certificate templates, you can specify, for example, that issued certificates must have a common name (CN) adhering to a specific format like `.*.acme.com` or perhaps that the max TTL cannot be more than 1 year.
-
- Head to your Project > Certificate Authorities > Your Issuing CA and create a certificate template.
-
- 
-
- Here's some guidance on each field:
-
- - Template Name: A name for the certificate template.
- - Issuing CA: The Certificate Authority (CA) that will issue certificates based on this template.
- - Certificate Collection (Optional): The certificate collection that certificates should be added to when issued under the template.
- - Common Name (CN): A regular expression used to validate the common name in certificate requests.
- - Alternative Names (SANs): A regular expression used to validate subject alternative names in certificate requests.
- - TTL: The maximum Time-to-Live (TTL) for certificates issued using this template.
- - Key Usage: The key usage constraint or default value for certificates issued using this template.
- - Extended Key Usage: The extended key usage constraint or default value for certificates issued using this template.
-
-
- To create a certificate, head to your Project > Internal PKI > Certificates and press **Issue** under the Certificates section.
-
- 
-
- Here, set the **Certificate Template** to the template from step 1 and fill out the rest of the details for the certificate to be issued.
-
- 
-
- Here's some guidance on each field:
-
- - Friendly Name: A friendly name for the certificate; this is only for display and defaults to the common name of the certificate if left empty.
- - Common Name (CN): The common name for the certificate like `service.acme.com`.
- - Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) for the certificate; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
- - TTL: The lifetime of the certificate in seconds.
- - Key Usage: The key usage extension of the certificate.
- - Extended Key Usage: The extended key usage extension of the certificate.
-
-
- Note that Infisical PKI supports issuing certificates without certificate templates as well. If this is desired, then you can set the **Certificate Template** field to **None**
- and specify the **Issuing CA** and optional **Certificate Collection** fields; the rest of the fields for the issued certificate remain the same.
-
- That said, we recommend using certificate templates to enforce policies and attach expiration monitoring on issued certificates.
-
-
-
-
- Once you have created the certificate from step 1, you'll be presented with the certificate details including the **Certificate Body**, **Certificate Chain**, and **Private Key**.
-
- 
-
-
- Make sure to download and store the **Private Key** in a secure location as it will only be displayed once at the time of certificate issuance.
- The **Certificate Body** and **Certificate Chain** will remain accessible and can be copied at any time.
-
-
-
-
-
-
-
-
- A certificate template is a set of policies for certificates issued under that template; each template is bound to a specific CA and can also be bound to a certificate collection for alerting such that any certificate issued under the template is automatically added to the collection.
-
- With certificate templates, you can specify, for example, that issued certificates must have a common name (CN) adhering to a specific format like .*.acme.com or perhaps that the max TTL cannot be more than 1 year.
-
- To create a certificate template, make an API request to the [Create Certificate Template](/api-reference/endpoints/certificate-templates-v2/create) API endpoint, specifying the issuing CA.
-
- ### Sample request
-
- ```bash Request
- curl --request POST \
- --url https://us.infisical.com/api/v2/certificate-templates \
- --header 'Content-Type: application/json' \
- --data '{
- "projectId": "",
- "name": "",
- "description": "",
- "subject": [
- {
- "type": "common_name",
- "allowed": [
- "*.infisical.com"
- ]
- }
- ],
- "sans": [
- {
- "type": "dns_name",
- "allowed": [
- "*.sample.com"
- ]
- }
- ],
- "keyUsages": {
- "allowed": [
- "digital_signature"
- ]
- },
- "extendedKeyUsages": {
- "allowed": [
- "client_auth"
- ]
- },
- "algorithms": {
- "signature": [
- "SHA256-RSA"
- ],
- "keyAlgorithm": [
- "RSA-2048"
- ]
- },
- "validity": {
- "max": "365d"
- }
- }'
- ```
-
- ### Sample response
-
- ```bash Response
- {
- "certificateTemplate": {
- "id": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
- "projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
- "name": "",
- "description": "",
- "subject": [
- {
- "type": "common_name",
- "allowed": [
- "*.infisical.com"
- ]
- }
- ],
- "sans": [
- {
- "type": "dns_name",
- "allowed": [
- "*.sample.com"
- ]
- }
- ],
- "keyUsages": {
- "allowed": [
- "digital_signature"
- ]
- },
- "extendedKeyUsages": {
- "allowed": [
- "client_auth"
- ]
- },
- "algorithms": {
- "signature": [
- "SHA256-RSA"
- ],
- "keyAlgorithm": [
- "RSA-2048"
- ]
- },
- "validity": {
- "max": "365d"
- },
- "createdAt": "2023-11-07T05:31:56Z",
- "updatedAt": "2023-11-07T05:31:56Z"
- }
- }
- ```
-
-
-
- To create a certificate under the certificate template, make an API request to the [Issue Certificate](/api-reference/endpoints/certificates/create-certificate) API endpoint,
- specifying the issuing CA.
-
- ### Sample request
-
- ```bash Request
- curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates' \
- --header 'Content-Type: application/json' \
- --data-raw '{
- "profileId": "",
- "attributes": {
- "commonName": "service.acme.com",
- "ttl": "1y",
- "signatureAlgorithm": "RSA-SHA256",
- "keyAlgorithm": "RSA_2048"
- }
- }'
- ```
-
- ### Sample response
-
- ```bash Response
- {
- "certificate": {
- "certificate": "...",
- "certificateChain": "...",
- "issuingCaCertificate": "...",
- "privateKey": "...",
- "serialNumber": "...",
- "certificateId": "..."
- },
- "certificateRequestId": "..."
- }
- ```
-
-
- Note that Infisical PKI supports issuing certificates without certificate templates as well. If this is desired, then you can set the **Certificate Template** field to **None**
- and specify the **Issuing CA** and optional **Certificate Collection** fields; the rest of the fields for the issued certificate remain the same.
-
- That said, we recommend using certificate templates to enforce policies and attach expiration monitoring on issued certificates.
-
-
-
- Make sure to store the `privateKey` as it is only returned once here at the time of certificate issuance. The `certificate` and `certificateChain` will remain accessible and can be retrieved at any time.
-
-
- If you have an external private key, you can also create a certificate by making an API request containing a pem-encoded CSR (Certificate Signing Request) to the same [Issue Certificate](/api-reference/endpoints/certificates/create-certificate) API endpoint.
-
- ### Sample request
-
- ```bash Request
- curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates' \
- --header 'Content-Type: application/json' \
- --data-raw '{
- "profileId": "",
- "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBE9oaW8...\n-----END CERTIFICATE REQUEST-----",
- "attributes": {
- "ttl": "1y"
- }
- }'
- ```
-
- ### Sample response
-
- ```bash Response
- {
- "certificate": {
- "certificate": "...",
- "certificateChain": "...",
- "issuingCaCertificate": "...",
- "serialNumber": "...",
- "certificateId": "..."
- },
- "certificateRequestId": "..."
- }
- ```
-
-
-
-
-
-
-## Guide to Revoking Certificates
-
-In the following steps, we explore how to revoke a X.509 certificate under a CA and obtain a Certificate Revocation List (CRL) for a CA.
-
-
-
-
-
- Assuming that you've issued a certificate under a CA, you can revoke it by
- selecting the **Revoke Certificate** option for it and specifying the reason
- for revocation.
-
- 
-
- 
-
-
-
- In order to check the revocation status of a certificate, you can check it
- against the CRL of a CA by heading to its Issuing CA and downloading the CRL.
-
- 
-
- To verify a certificate against the
- downloaded CRL with OpenSSL, you can use the following command:
-
-```bash
-openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
-```
-
-Note that you can also obtain the CRL from the certificate itself by
-referencing the CRL distribution point extension on the certificate.
-
-To check a certificate against the CRL distribution point specified within it with OpenSSL, you can use the following command:
-
-```bash
-openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
-```
-
-
-
-
-
-
-
- Assuming that you've issued a certificate under a CA, you can revoke it by making an API request to the [Revoke Certificate](/api-reference/endpoints/certificates/revoke) API endpoint,
- specifying the serial number of the certificate and the reason for revocation.
-
- ### Sample request
-
- ```bash Request
- curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/certificates//revoke' \
- --header 'Authorization: Bearer ' \
- --header 'Content-Type: application/json' \
- --data-raw '{
- "revocationReason": "UNSPECIFIED"
- }'
- ```
-
- ### Sample response
-
- ```bash Response
- {
- message: "Successfully revoked certificate",
- serialNumber: "...",
- revokedAt: "..."
- }
- ```
-
-
- In order to check the revocation status of a certificate, you can check it against the CRL of the issuing CA.
- To obtain the CRLs of the CA, make an API request to the [List CRLs](/api-reference/endpoints/certificate-authorities/crl) API endpoint.
-
- ### Sample request
-
- ```bash Request
- curl --location --request GET 'https://app.infisical.com/api/v1/cert-manager/ca/internal//crls' \
- --header 'Authorization: Bearer '
- ```
-
- ### Sample response
-
- ```bash Response
- [
- {
- id: "...",
- crl: "..."
- },
- ...
- ]
- ```
-
- To verify a certificate against the CRL with OpenSSL, you can use the following command:
-
- ```bash
- openssl verify -crl_check -CAfile chain.pem -CRLfile crl.pem cert.pem
- ```
-
-
-
-
-
-
-## FAQ
-
-
-
- To renew a certificate, you have to issue a new certificate from the same CA
- with the same common name as the old certificate. The original certificate
- will continue to be valid through its original TTL unless explicitly
- revoked.
-
-
diff --git a/docs/documentation/platform/pki/enrollment-methods/api.mdx b/docs/documentation/platform/pki/enrollment-methods/api.mdx
index 713fbc0ec6..a6a9d04dac 100644
--- a/docs/documentation/platform/pki/enrollment-methods/api.mdx
+++ b/docs/documentation/platform/pki/enrollment-methods/api.mdx
@@ -148,7 +148,7 @@ Here, select the certificate profile from step 1 that will be used to issue the
```
- Note: If the certificate is available to be issued immediately, the `certificate` field in the response will contain the certificate data. If issuance is delayed (for example, due to pending approval or additional processing), the `certificate` field will be `null` and you can use the `certificateRequestId` to poll for status or retrieve the certificate when it is ready.
+ Note: If the certificate is available to be issued immediately, the `certificate` field in the response will contain the certificate data. If issuance is delayed (for example, due to pending approval or additional processing), the `certificate` field will be `null` and you can use the `certificateRequestId` to poll for status or retrieve the certificate when it is ready using the [Get Certificate Request](/api-reference/endpoints/certificates/certificate-request) API endpoint.
Also be sure to store the `privateKey` as it is only returned once here at the time of certificate issuance. The `certificate` and `certificateChain` will remain accessible and can be retrieved at any time.
diff --git a/docs/integrations/platforms/certificate-agent.mdx b/docs/integrations/platforms/certificate-agent.mdx
index 439d0c889e..90bddeacb2 100644
--- a/docs/integrations/platforms/certificate-agent.mdx
+++ b/docs/integrations/platforms/certificate-agent.mdx
@@ -221,8 +221,6 @@ certificates:
lifecycle:
renew-before-expiry: "30d"
status-check-interval: "6h"
- max-failure-retries: 3
- failure-retry-interval: "1h"
# Configure where to store the issued certificate and its associated private key and certificate chain
file-output: