mirror of
https://github.com/Infisical/infisical.git
synced 2026-01-10 07:58:15 -05:00
continue pki docs restructuring
This commit is contained in:
Tuan Dang
@@ -728,30 +728,30 @@
|
||||
},
|
||||
"documentation/platform/pki/subscribers",
|
||||
"documentation/platform/pki/certificates",
|
||||
"documentation/platform/pki/acme-ca",
|
||||
"documentation/platform/pki/azure-adcs",
|
||||
"documentation/platform/pki/est",
|
||||
"documentation/platform/pki/alerting",
|
||||
{
|
||||
"group": "Integrations",
|
||||
"pages": [
|
||||
"documentation/platform/pki/pki-issuer",
|
||||
"documentation/platform/pki/integration-guides/gloo-mesh"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Certificate Syncs",
|
||||
"pages": [
|
||||
"documentation/platform/pki/certificate-syncs/overview",
|
||||
{
|
||||
"group": "Syncs",
|
||||
"pages": [
|
||||
"documentation/platform/pki/certificate-syncs/aws-certificate-manager",
|
||||
"documentation/platform/pki/certificate-syncs/azure-key-vault"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
"documentation/platform/pki/alerting"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Infrastructure Integrations",
|
||||
"pages": [
|
||||
"documentation/platform/pki/pki-issuer",
|
||||
"documentation/platform/pki/integration-guides/gloo-mesh"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Certificate Syncs",
|
||||
"pages": [
|
||||
"documentation/platform/pki/certificate-syncs/overview",
|
||||
"documentation/platform/pki/certificate-syncs/aws-certificate-manager",
|
||||
"documentation/platform/pki/certificate-syncs/azure-key-vault"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "CA Integrations",
|
||||
"pages": [
|
||||
"documentation/platform/pki/acme-ca",
|
||||
"documentation/platform/pki/azure-adcs"
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Certificates with ACME CA"
|
||||
title: "ACME CA"
|
||||
description: "Learn how to automatically provision and manage TLS certificates using ACME Certificate Authorities like Let's Encrypt with Infisical PKI"
|
||||
---
|
||||
|
||||
@@ -257,6 +257,7 @@ In the following steps, we explore how to set up ACME Certificate Authority inte
|
||||
- Downloaded directly from the Infisical UI
|
||||
- Retrieved via the Infisical API for programmatic access using the [latest certificate bundle endpoint](/api-reference/endpoints/pki/subscribers/get-latest-cert-bundle)
|
||||
</Step>
|
||||
|
||||
</Steps>
|
||||
|
||||
## Example: Let's Encrypt Integration
|
||||
@@ -264,19 +265,23 @@ In the following steps, we explore how to set up ACME Certificate Authority inte
|
||||
Let's Encrypt is a free, automated, and open Certificate Authority that provides domain-validated SSL/TLS certificates. Here's how the integration works with Infisical:
|
||||
|
||||
### Production Environment
|
||||
|
||||
- **Directory URL**: `https://acme-v02.api.letsencrypt.org/directory`
|
||||
- **Rate Limits**: 50 certificates per registered domain per week
|
||||
- **Certificate Validity**: 90 days with automatic renewal
|
||||
- **Trusted By**: All major browsers and operating systems
|
||||
|
||||
### Staging Environment (for testing)
|
||||
|
||||
- **Directory URL**: `https://acme-staging-v02.api.letsencrypt.org/directory`
|
||||
- **Rate Limits**: Much higher limits for testing
|
||||
- **Certificate Validity**: 90 days (not trusted by browsers)
|
||||
- **Use Case**: Testing your ACME integration without hitting production rate limits
|
||||
|
||||
<Note>
|
||||
Always test your ACME integration using Let's Encrypt's staging environment first. This allows you to verify your DNS configuration and certificate issuance process without consuming your production rate limits.
|
||||
Always test your ACME integration using Let's Encrypt's staging environment
|
||||
first. This allows you to verify your DNS configuration and certificate
|
||||
issuance process without consuming your production rate limits.
|
||||
</Note>
|
||||
|
||||
## Example: DigiCert Integration
|
||||
@@ -289,7 +294,9 @@ DigiCert is a leading commercial Certificate Authority providing a wide range of
|
||||
- **Trusted By**: All major browsers and operating systems.
|
||||
|
||||
<Note>
|
||||
When integrating with DigiCert ACME, ensure you have obtained the necessary External Account Binding (EAB) Key Identifier (KID) and HMAC Key from your DigiCert account.
|
||||
When integrating with DigiCert ACME, ensure you have obtained the necessary
|
||||
External Account Binding (EAB) Key Identifier (KID) and HMAC Key from your
|
||||
DigiCert account.
|
||||
</Note>
|
||||
|
||||
## FAQ
|
||||
@@ -303,11 +310,13 @@ DigiCert is a leading commercial Certificate Authority providing a wide range of
|
||||
- Can be fully automated without manual intervention
|
||||
|
||||
Support for additional DNS providers is planned for future releases.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Can I use wildcard certificates with ACME CAs?">
|
||||
Yes! ACME CAs like Let's Encrypt support wildcard certificates (e.g., `*.example.com`) when using DNS-01 validation. Simply specify the wildcard domain in your subscriber configuration.
|
||||
|
||||
Note that wildcard certificates still require DNS-01 validation - HTTP-01 validation cannot be used for wildcard certificates.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="How long are ACME certificates valid?">
|
||||
Most ACME providers issue certificates with 90-day validity periods. This shorter validity period is designed to:
|
||||
@@ -317,6 +326,7 @@ DigiCert is a leading commercial Certificate Authority providing a wide range of
|
||||
- Ensure systems stay up-to-date with certificate management practices
|
||||
|
||||
When configured, Infisical automatically handles certificate renewal for subscribers.
|
||||
|
||||
</Accordion>
|
||||
<Accordion title="Can I use multiple ACME providers?">
|
||||
Yes! You can register multiple ACME CAs in the same project:
|
||||
@@ -326,5 +336,6 @@ DigiCert is a leading commercial Certificate Authority providing a wide range of
|
||||
- Backup providers for redundancy
|
||||
|
||||
Each subscriber can be configured to use a specific ACME CA based on your requirements.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Certificates with Azure ADCS"
|
||||
title: "Azure ADCS"
|
||||
description: "Learn how to issue and manage certificates using Microsoft Active Directory Certificate Services (ADCS) with Infisical."
|
||||
---
|
||||
|
||||
@@ -10,7 +10,7 @@ Issue and manage certificates using Microsoft Active Directory Certificate Servi
|
||||
Before setting up ADCS integration, ensure you have:
|
||||
|
||||
- Microsoft Active Directory Certificate Services (ADCS) server running and accessible
|
||||
- Domain administrator account with certificate management permissions
|
||||
- Domain administrator account with certificate management permissions
|
||||
- ADCS web enrollment enabled on your server
|
||||
- Network connectivity from Infisical to the ADCS server
|
||||
- **IP whitelisting**: Your ADCS server must allow connections from Infisical's IP addresses
|
||||
@@ -24,67 +24,56 @@ This section walks you through the complete end-to-end process of setting up Azu
|
||||
|
||||
<Steps>
|
||||
<Step title="Navigate to External Certificate Authorities">
|
||||
In your Infisical project, go to your **Certificate Project** → **Certificate Authority** to access the external CAs page.
|
||||
|
||||
|
||||
In your Infisical project, go to your **Certificate Project** →
|
||||
**Certificate Authority** to access the external CAs page. 
|
||||
</Step>
|
||||
|
||||
<Step title="Create New Azure ADCS Certificate Service CA">
|
||||
Click **Create CA** and configure:
|
||||
- **Type**: Choose **Azure AD Certificate Service**
|
||||
- **Name**: Friendly name for this CA (e.g., "Production ADCS CA")
|
||||
- **App Connection**: Choose your ADCS connection from the dropdown
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Certificate Authority Created">
|
||||
Once created, your Azure ADCS Certificate Authority will appear in the list and be ready for use.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Navigate to Subscribers">
|
||||
Go to **Subscribers** to access the subscribers page.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Create New Subscriber">
|
||||
Click **Add Subscriber** and configure:
|
||||
- **Name**: Unique subscriber name (e.g., "web-server-certs")
|
||||
- **Certificate Authority**: Select your ADCS CA
|
||||
- **Common Name**: Certificate CN (e.g., "api.example.com")
|
||||
- **Certificate Template**: Select from dynamically loaded ADCS templates
|
||||
- **Subject Alternative Names**: DNS names, IP addresses, or email addresses
|
||||
- **TTL**: Certificate validity period (e.g., "1y" for 1 year)
|
||||
- **Additional Subject Fields**: Organization, OU, locality, state, country, email (if required by template)
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Subscriber Created">
|
||||
Your subscriber is now created and ready to issue certificates.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Issue New Certificate">
|
||||
Click into your subscriber and click **Order Certificate** to generate a new certificate using your ADCS template.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Certificate Created">
|
||||
Your certificate has been successfully issued by the ADCS server and is ready for use.
|
||||
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Create New Azure ADCS Certificate Service CA">
|
||||
Click **Create CA** and configure: - **Type**: Choose **Azure AD Certificate
|
||||
Service** - **Name**: Friendly name for this CA (e.g., "Production ADCS CA") -
|
||||
**App Connection**: Choose your ADCS connection from the dropdown 
|
||||
</Step>
|
||||
<Step title="Certificate Authority Created">
|
||||
Once created, your Azure ADCS Certificate Authority will appear in the list
|
||||
and be ready for use. 
|
||||
</Step>
|
||||
<Step title="Navigate to Subscribers">
|
||||
Go to **Subscribers** to access the subscribers page. 
|
||||
</Step>
|
||||
<Step title="Create New Subscriber">
|
||||
Click **Add Subscriber** and configure: - **Name**: Unique subscriber name
|
||||
(e.g., "web-server-certs") - **Certificate Authority**: Select your ADCS CA -
|
||||
**Common Name**: Certificate CN (e.g., "api.example.com") - **Certificate
|
||||
Template**: Select from dynamically loaded ADCS templates - **Subject
|
||||
Alternative Names**: DNS names, IP addresses, or email addresses - **TTL**:
|
||||
Certificate validity period (e.g., "1y" for 1 year) - **Additional Subject
|
||||
Fields**: Organization, OU, locality, state, country, email (if required by
|
||||
template) 
|
||||
</Step>
|
||||
<Step title="Subscriber Created">
|
||||
Your subscriber is now created and ready to issue certificates. 
|
||||
</Step>
|
||||
<Step title="Issue New Certificate">
|
||||
Click into your subscriber and click **Order Certificate** to generate a new
|
||||
certificate using your ADCS template. 
|
||||
</Step>
|
||||
<Step title="Certificate Created">
|
||||
Your certificate has been successfully issued by the ADCS server and is ready
|
||||
for use. 
|
||||
</Step>
|
||||
|
||||
<Step title="View Certificate Details">
|
||||
Navigate to **Certificates** to view detailed information about all issued certificates, including expiration dates, serial numbers, and certificate chains.
|
||||
|
||||
|
||||
Navigate to **Certificates** to view detailed information about all issued
|
||||
certificates, including expiration dates, serial numbers, and certificate
|
||||
chains. 
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
@@ -95,6 +84,7 @@ Infisical automatically retrieves available certificate templates from your ADCS
|
||||
### Common Template Types
|
||||
|
||||
ADCS templates you might see include:
|
||||
|
||||
- **Web Server**: For SSL/TLS certificates with server authentication
|
||||
- **Computer**: For machine authentication certificates
|
||||
- **User**: For client authentication certificates
|
||||
@@ -106,13 +96,16 @@ ADCS templates you might see include:
|
||||
### Template Requirements
|
||||
|
||||
Ensure your ADCS templates are configured with:
|
||||
|
||||
- **Enroll permissions** for your connection account
|
||||
- **Auto-enroll permissions** if using automated workflows
|
||||
- **Subject name requirements** matching your certificate requests
|
||||
- **Key usage extensions** appropriate for your use case
|
||||
|
||||
<Info>
|
||||
**Dynamic Template Discovery**: Infisical queries your ADCS server in real-time to populate available templates. Only templates you have permission to use will be displayed during certificate issuance.
|
||||
**Dynamic Template Discovery**: Infisical queries your ADCS server in
|
||||
real-time to populate available templates. Only templates you have permission
|
||||
to use will be displayed during certificate issuance.
|
||||
</Info>
|
||||
|
||||
## Certificate Issuance Limitations
|
||||
@@ -120,10 +113,13 @@ Ensure your ADCS templates are configured with:
|
||||
### Immediate Issuance Only
|
||||
|
||||
<Warning>
|
||||
**Manual Approval Not Supported**: Infisical currently supports only **immediate certificate issuance**. Certificates that require manual approval or are held by ADCS policies cannot be issued through Infisical yet.
|
||||
**Manual Approval Not Supported**: Infisical currently supports only
|
||||
**immediate certificate issuance**. Certificates that require manual approval
|
||||
or are held by ADCS policies cannot be issued through Infisical yet.
|
||||
</Warning>
|
||||
|
||||
For successful certificate issuance, ensure your ADCS templates and policies are configured to:
|
||||
|
||||
- **Auto-approve** certificate requests without manual intervention
|
||||
- **Not require** administrator approval for the templates you plan to use
|
||||
- **Allow** the connection account to request and receive certificates immediately
|
||||
@@ -131,19 +127,22 @@ For successful certificate issuance, ensure your ADCS templates and policies are
|
||||
### What Happens with Manual Approval
|
||||
|
||||
If a certificate request requires manual approval:
|
||||
|
||||
1. The request will be submitted to ADCS successfully
|
||||
2. Infisical will attempt to retrieve the certificate with exponential backoff (up to 5 retries over ~1 minute)
|
||||
3. If the certificate is not approved within this timeframe, the request will **fail**
|
||||
4. **No background polling**: Currently, Infisical does not check for certificates that might be approved hours or days later
|
||||
|
||||
<Info>
|
||||
**Future Enhancement**: Background polling for delayed certificate approvals is planned for future releases.
|
||||
**Future Enhancement**: Background polling for delayed certificate approvals
|
||||
is planned for future releases.
|
||||
</Info>
|
||||
|
||||
### Certificate Revocation
|
||||
|
||||
<Warning>
|
||||
Certificate revocation is **not supported** by the Azure ADCS connector due to security and complexity considerations.
|
||||
Certificate revocation is **not supported** by the Azure ADCS connector due to
|
||||
security and complexity considerations.
|
||||
</Warning>
|
||||
|
||||
## Advanced Configuration
|
||||
@@ -166,28 +165,33 @@ This allows Infisical to control certificate expiration dates directly.
|
||||
### Common Issues
|
||||
|
||||
**Certificate Request Denied**
|
||||
|
||||
- Verify ADCS template permissions for your connection account
|
||||
- Check template subject name requirements
|
||||
- Ensure template allows the requested key algorithm and size
|
||||
|
||||
**Revocation Service Unavailable**
|
||||
|
||||
- Verify IIS is running and the revocation endpoint is accessible
|
||||
- Check IIS application pool permissions
|
||||
- Test endpoint connectivity from Infisical
|
||||
|
||||
**Template Not Found**
|
||||
|
||||
- Verify template exists on ADCS server and is published
|
||||
- Check that your connection account has enrollment permissions for the template
|
||||
- Ensure the template is properly configured and available in the ADCS web enrollment interface
|
||||
- Templates are dynamically loaded - refresh the PKI Subscriber form if templates don't appear
|
||||
|
||||
**Certificate Request Pending/Timeout**
|
||||
|
||||
- Check if your ADCS template requires manual approval - Infisical only supports immediate issuance
|
||||
- Verify the certificate template is configured for auto-approval
|
||||
- Ensure your connection account has sufficient permissions to request certificates without approval
|
||||
- Review ADCS server policies that might be holding the certificate request
|
||||
|
||||
**Network Connectivity Issues**
|
||||
|
||||
- Verify your ADCS server's firewall allows connections from Infisical
|
||||
- For Infisical Cloud: Ensure Infisical's IP addresses are whitelisted (see [Networking Configuration](/documentation/setup/networking))
|
||||
- For self-hosted: Whitelist your Infisical server's IP address on the ADCS server
|
||||
@@ -195,11 +199,13 @@ This allows Infisical to control certificate expiration dates directly.
|
||||
- Check for any network security appliances blocking the connection
|
||||
|
||||
**Authentication Failures**
|
||||
|
||||
- Verify ADCS connection credentials
|
||||
- Check domain account permissions
|
||||
- Ensure network connectivity to ADCS server
|
||||
|
||||
**SSL/TLS Certificate Errors**
|
||||
|
||||
- For ADCS servers with self-signed or private certificates: disable "Reject Unauthorized" in the SSL tab of your Azure ADCS app connection, or provide the certificate in PEM format
|
||||
- Common SSL errors: `UNABLE_TO_VERIFY_LEAF_SIGNATURE`, `SELF_SIGNED_CERT_IN_CHAIN`, `CERT_HAS_EXPIRED`
|
||||
- The SSL configuration applies to all HTTPS communications between Infisical and your ADCS server
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Gloo Mesh Integration"
|
||||
title: "Gloo Mesh"
|
||||
description: "Learn how to automatically provision and manage Istio intermediate CA certificates for Gloo Mesh using Infisical PKI"
|
||||
---
|
||||
|
||||
@@ -7,8 +7,8 @@ This guide will provide a high level overview on how you can use Infisical PKI a
|
||||
|
||||
## Overview
|
||||
|
||||
In this setup, we will use Infisical PKI to generate and store your root CA and subordinate CAs that are used to generate Istio intermediate CAs for your Gloo Mesh workload clusters.
|
||||
To manage the lifecycle of Istio intermediate CA certificates, you'll also install [cert-manager](https://cert-manager.io/).
|
||||
In this setup, we will use Infisical PKI to generate and store your root CA and subordinate CAs that are used to generate Istio intermediate CAs for your Gloo Mesh workload clusters.
|
||||
To manage the lifecycle of Istio intermediate CA certificates, you'll also install [cert-manager](https://cert-manager.io/).
|
||||
Cert-manager is a Kubernetes controller that helps you automate the process of obtaining and renewing certificates from various PKI providers.
|
||||
|
||||
With this approach, you get the following benefits:
|
||||
@@ -18,10 +18,10 @@ With this approach, you get the following benefits:
|
||||
- Use cert-manager to automatically issue and renew Istio intermediate CA certificates from the same root, ensuring cross-cluster workload communication.
|
||||
- Increased auditability of private key infrastructure.
|
||||
|
||||
|
||||
## General Setup
|
||||
|
||||
The certificate provisioning workflow begins with setting up your PKI hierarchy in Infisical, where you create root and subordinate certificate authorities.
|
||||
When you deploy a `Certificate` CRD in your workload cluster, `cert-manager` uses the Infisical PKI Issuer controller to authenticate with Infisical using machine identity credentials and request an intermediate CA certificate.
|
||||
When you deploy a `Certificate` CRD in your workload cluster, `cert-manager` uses the Infisical PKI Issuer controller to authenticate with Infisical using machine identity credentials and request an intermediate CA certificate.
|
||||
Infisical verifies the request against your certificate templates and returns the signed certificate.
|
||||
From there, Istio's control plane will automatically use this intermediate CA to sign leaf certificates for workloads in the service mesh, enabling secure mTLS communication across your entire Gloo Mesh infrastructure.
|
||||
|
||||
@@ -35,5 +35,5 @@ For Gloo Mesh-specific configuration, ensure that:
|
||||
|
||||
## Using the certificates
|
||||
|
||||
Once the `cacerts` Kubernetes secret is created in the `istio-system` namespace, Istio automatically uses the custom CA certificate instead of the default self-signed certificate.
|
||||
When you deploy applications to your Gloo Mesh service mesh, the workloads will receive leaf certificates signed by your Infisical PKI intermediate CA, enabling secure mTLS communication across your entire mesh infrastructure.
|
||||
Once the `cacerts` Kubernetes secret is created in the `istio-system` namespace, Istio automatically uses the custom CA certificate instead of the default self-signed certificate.
|
||||
When you deploy applications to your Gloo Mesh service mesh, the workloads will receive leaf certificates signed by your Infisical PKI intermediate CA, enabling secure mTLS communication across your entire mesh infrastructure.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Cert Manager Issuer"
|
||||
title: "Kubernetes Issuer"
|
||||
description: "Learn how to automatically provision and manage TLS certificates in Kubernetes using Infisical PKI"
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user