mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
Merge branch 'main' into chore/contributing-docs-update
This commit is contained in:
Victor Santos
@@ -122,11 +122,13 @@ To successfully deploy an Infisical Gateway for use, follow these steps in order
|
||||
<Tab title="Linux Server (Production)">
|
||||
For production deployments on Linux servers, install the Gateway as a systemd service so that it runs securely in the background and automatically restarts on failure or system reboot:
|
||||
```bash
|
||||
sudo infisical gateway systemd install --token <your-machine-identity-token> --domain <your-infisical-domain> --name <gateway-name> --relay <relay-name>
|
||||
sudo infisical gateway systemd install --token <your-machine-identity-token> --domain <your-infisical-domain> --name <gateway-name>
|
||||
sudo systemctl start infisical-gateway
|
||||
```
|
||||
|
||||
|
||||
<Info>
|
||||
By default, the gateway connects to the most optimal relay. Use the `--relay` flag to manually specify a different relay server.
|
||||
</Info>
|
||||
|
||||
<Warning>
|
||||
The systemd install command requires a Linux operating system with root/sudo
|
||||
@@ -153,10 +155,13 @@ To successfully deploy an Infisical Gateway for use, follow these steps in order
|
||||
--from-literal=INFISICAL_AUTH_METHOD=universal-auth \
|
||||
--from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_ID=<client-id> \
|
||||
--from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET=<client-secret> \
|
||||
--from-literal=INFISICAL_RELAY_NAME=<relay-name> \
|
||||
--from-literal=INFISICAL_GATEWAY_NAME=<gateway-name>
|
||||
```
|
||||
|
||||
<Info>
|
||||
By default, the gateway connects to the most optimal relay. Use the `--from-literal=INFISICAL_RELAY_NAME=<relay-name>` flag to manually specify a different relay server.
|
||||
</Info>
|
||||
|
||||
#### Install the Gateway
|
||||
|
||||
```bash
|
||||
@@ -168,8 +173,12 @@ To successfully deploy an Infisical Gateway for use, follow these steps in order
|
||||
For development or testing environments:
|
||||
|
||||
```bash
|
||||
infisical gateway start --token <token> --relay=<relay-name> --name=<gateway-name>
|
||||
sudo infisical gateway start --token <token> --name=<gateway-name>
|
||||
```
|
||||
|
||||
<Info>
|
||||
By default, the gateway connects to the most optimal relay. Use the `--relay` flag to manually specify a different relay server.
|
||||
</Info>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "Certificates with ACME CA"
|
||||
title: "ACME-compatible 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/certificate-profiles/get-latest-active-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: "Microsoft AD CS"
|
||||
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,64 @@ 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 **Active Directory Certificate Services (AD CS)**
|
||||
- **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 **Active Directory
|
||||
Certificate Services (AD CS)** - **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 +92,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 +104,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 +121,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 +135,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 +173,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 +207,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
|
||||
50
docs/documentation/platform/pki/ca/external-ca.mdx
Normal file
50
docs/documentation/platform/pki/ca/external-ca.mdx
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "External CA"
|
||||
sidebarTitle: "External CA"
|
||||
description: "Learn how to connect External Certificate Authorities with Infisical."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
Infisical lets you integrate with External Certificate Authorities (CAs), allowing you to use existing PKI infrastructure or connect to public CAs to issue digital certificates for your end-entities.
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A1[External Public CA<br>e.g. Let's Encrypt, ZeroSSL, ...] --> Infisical
|
||||
A2[External Private CA<br>e.g. AWS Private CA, HashiCorp Vault PKI, ...] --> Infisical
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
As shown above, these CAs commonly fall under two categories:
|
||||
|
||||
- External Private CAs: CAs like AWS Private CA, HashiCorp Vault PKI, Azure ADCS, etc. that are privately owned and are used to issue certificates for internal services; these are often either cloud-hosted private CAs or on-prem / enterprise CAs.
|
||||
- External Public CAs: CAs like Let's Encrypt, DigiCert, GlobalSign, etc. that are publicly trusted and are used to issue certificates for public-facing services.
|
||||
|
||||
Note that Infisical can also act as an _ACME client_, allowing you to integrate upstream with any ACME-compatible CA to automate certificate issuance and renewal.
|
||||
|
||||
## Workflow
|
||||
|
||||
A typical workflow for integrating an External CA with Infisical consists of choosing the desired External CA type
|
||||
and specifying the configuration or connection details necessary to connect to the CA.
|
||||
|
||||
The specific steps and requirements vary depending on the External CA type you choose to integrate.
|
||||
|
||||
## Supported External CA Types
|
||||
|
||||
Infisical currently supports the following External CA types out of the box:
|
||||
|
||||
- [ACME CA](/documentation/platform/pki/ca/acme-ca): An ACME-compatible CA that supports the ACME protocol, such as Let's Encrypt, ZeroSSL, Buypass, Digicert, etc.
|
||||
- [Azure ADCS](/documentation/platform/pki/ca/azure-adcs): A Microsoft Active Directory Certificate Services (ADCS) that supports the ADCS protocol, such as AWS Private CA, Azure ADCS, etc.
|
||||
|
||||
If you don’t see a specific external CA listed here or need a dedicated integration guide, please reach out to sales@infisical.com and we’ll help you set up the integration for your external CA.
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Can I use both Private CAs and External CAs in the same project?">
|
||||
Yes. You can have both Private and External CAs in the same project.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
13
docs/documentation/platform/pki/ca/overview.mdx
Normal file
13
docs/documentation/platform/pki/ca/overview.mdx
Normal file
@@ -0,0 +1,13 @@
|
||||
---
|
||||
title: "Overview"
|
||||
sidebarTitle: "Overview"
|
||||
---
|
||||
|
||||
Before issuing and managing certificates with Infisical, you'll need to configure a Certificate Authority (CA).
|
||||
|
||||
This is the trusted entity that signs and validates the X.509 certificates used to secure your end-entities.
|
||||
|
||||
Infisical supports two categories of CAs:
|
||||
|
||||
- [Internal CA](/documentation/platform/pki/ca/private-ca): Internally operated root and intermediate CAs managed within Infisical. This is useful if you need complete control over your PKI and are issuing certificates for private networks, internal services, or managed devices.
|
||||
- [External CA](/documentation/platform/pki/ca/external-ca): Third-party public (e.g. Let's Encrypt, DigiCert) or private (e.g. AWS Private CA, HashiCorp Vault PKI, etc.) CAs that can be integrated with Infisical. This is useful if you want to leverage existing PKI infrastructure or issue publicly trusted certificates.
|
||||
@@ -1,13 +1,12 @@
|
||||
---
|
||||
title: "Private CA"
|
||||
sidebarTitle: "Private CA"
|
||||
title: "Internal CA"
|
||||
sidebarTitle: "Internal CA"
|
||||
description: "Learn how to create a Private CA hierarchy with Infisical."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
The first step to creating your Internal PKI is to create a Private Certificate Authority (CA) hierarchy that is a structure of entities
|
||||
used to issue digital certificates for your [subscribers](/documentation/platform/pki/subscribers).
|
||||
Infisical lets you build your Internal PKI through a Private Certificate Authority (CA) hierarchy, enabling you to issue and manage digital certificates for your end-entities.
|
||||
|
||||
<div align="center">
|
||||
|
||||
@@ -47,7 +46,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
<Step title="Creating a root CA">
|
||||
If you wish to use an external root CA, you can skip this step and head to step 2 to create an intermediate CA.
|
||||
|
||||
To create a root CA, head to your Project > Internal PKI > Certificate Authorities and press **Create CA**.
|
||||
To create a root CA, head to your Certificate Management Project > Certificate Authorities > Internal Certificate Authorities and press **Create CA**.
|
||||
|
||||
|
||||
|
||||
@@ -55,18 +54,17 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each field:
|
||||
Here's some guidance for each field:
|
||||
|
||||
- Valid Until: The date until which the CA is valid in the date time string format specified [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_time_string_format). For example, the following formats would be valid: `YYYY`, `YYYY-MM`, `YYYY-MM-DD`, `YYYY-MM-DDTHH:mm:ss.sssZ`.
|
||||
- Path Length: The maximum number of intermediate CAs that can be chained to this CA. A path of `-1` implies no limit; a path of `0` implies no intermediate CAs can be chained.
|
||||
- Key Algorithm: The type of public key algorithm and size, in bits, of the key pair that the CA creates when it issues a certificate. Supported key algorithms are `RSA 2048`, `RSA 4096`, `ECDSA P-256`, and `ECDSA P-384` with the default being `RSA 2048`.
|
||||
- Friendly Name: A friendly name for the CA; this is only for display and defaults to the subject of the CA if left empty.
|
||||
- Name: A slug-friendly name for the CA.
|
||||
- Organization (O): The organization name.
|
||||
- Country (C): The country code.
|
||||
- State or Province Name: The state or province.
|
||||
- Locality Name: The city or locality.
|
||||
- Common Name: The name of the CA.
|
||||
- Require Template for Certificate Issuance: Whether or not certificates for this CA can only be issued through certificate templates (recommended).
|
||||
|
||||
<Note>
|
||||
The Organization, Country, State or Province Name, Locality Name, and Common Name make up the **Distinguished Name (DN)** or **subject** of the CA.
|
||||
@@ -98,8 +96,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
|
||||
|
||||
|
||||
Great! You've successfully created a Private CA hierarchy with a root CA and an intermediate CA.
|
||||
Now check out the [Subscribers](/documentation/platform/pki/subscribers) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
Great! You've successfully created a Private CA hierarchy with a root CA and an intermediate CA. Now check out the [Certificates section](/documentation/platform/pki/certificates/overview) to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
|
||||
2.3b. If you have an external root CA, select **External CA** for the **Parent CA Type** field.
|
||||
|
||||
@@ -110,7 +107,7 @@ consisting of an (optional) root CA and an intermediate CA.
|
||||
Finally, press **Install** to import the certificate and certificate chain as part of the installation step for the intermediate CA
|
||||
|
||||
Great! You've successfully created a Private CA hierarchy with an intermediate CA chained to an external root CA.
|
||||
Now check out the [Subscribers](/documentation/platform/pki/subscribers) page to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
Now check out the [Certificates section](/documentation/platform/pki/certificates/overview) to learn more about how to issue X.509 certificates using the intermediate CA.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
@@ -5,82 +5,87 @@ description: "Learn how to configure an AWS Certificate Manager Certificate Sync
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- Set up and configure a [Certificate Authority](/documentation/platform/pki/overview)
|
||||
- Create an [AWS Connection](/integrations/app-connections/aws)
|
||||
|
||||
<Note>
|
||||
The AWS Certificate Manager Certificate Sync requires the following ACM permissions to be set on the IAM user/role
|
||||
for Infisical to sync certificates to AWS Certificate Manager: `acm:ListCertificates`, `acm:DescribeCertificate`, `acm:ImportCertificate`, `acm:DeleteCertificate`, and `acm:ListTagsForCertificate`.
|
||||
|
||||
These permissions allow Infisical to list, import, tag, and manage certificates in your AWS Certificate Manager service.
|
||||
These permissions allow Infisical to list, import, tag, and manage certificates in your AWS Certificate Manager service.
|
||||
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
Certificates synced to AWS Certificate Manager will be stored as imported certificates, preserving both the certificate and private key components.
|
||||
Certificates synced to AWS Certificate Manager will be stored as imported
|
||||
certificates, preserving both the certificate and private key components.
|
||||
</Note>
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to **Project** > **Integrations** and select the **Certificate Syncs** tab. Click on the **Add Sync** button.
|
||||
|
||||
1. Navigate to **Project** > **Integrations** > **Certificate Syncs** and press **Add Sync**.
|
||||
|
||||
|
||||
2. Select the **AWS Certificate Manager** option.
|
||||
|
||||
|
||||
|
||||
3. Configure the **Source** from where certificates should be retrieved, then click **Next**.
|
||||
|
||||
3. Configure the **Destination** to where certificates should be deployed, then click **Next**.
|
||||
|
||||
|
||||
- **PKI Subscriber**: The PKI subscriber to retrieve certificates from.
|
||||
- **AWS Connection**: The AWS Connection to authenticate with.
|
||||
- **AWS Region**: The AWS region where certificates should be stored.
|
||||
|
||||
4. Configure the **Destination** to where certificates should be deployed, then click **Next**.
|
||||
|
||||
4. Configure the **Sync Options** to specify how certificates should be synced, then click **Next**.
|
||||
|
||||
|
||||
- **AWS Connection**: The AWS Connection to authenticate with.
|
||||
- **AWS Region**: The AWS region where certificates should be stored.
|
||||
- **Enable Removal of Expired/Revoked Certificates**: If enabled, Infisical will remove certificates from the destination if they are no longer active in Infisical.
|
||||
- **Preserve ARN on Renewal**: If enabled, Infisical will sync renewed certificates to the destination under the same ARN as the original synced certificate instead of creating a new certificate with a new ARN.
|
||||
- **Certificate Name Schema** (Optional): Customize how certificate tags are generated in AWS Certificate Manager. Must include `{{certificateId}}` as a placeholder for the certificate ID to ensure proper certificate identification and management. If not specified, defaults to `Infisical-{{certificateId}}`.
|
||||
- **Auto-Sync Enabled**: If enabled, certificates will automatically be synced when changes occur. Disable to enforce manual syncing only.
|
||||
|
||||
5. Configure the **Sync Options** to specify how certificates should be synced, then click **Next**.
|
||||
|
||||
|
||||
- **Auto-Sync Enabled**: If enabled, certificates will automatically be synced from the source PKI subscriber when changes occur. Disable to enforce manual syncing only.
|
||||
- **Enable Certificate Removal**: If enabled, Infisical will remove expired certificates from the destination during sync operations. Disable this option if you intend to manage certificate cleanup manually.
|
||||
- **Certificate Name Schema** (Optional): Customize how certificate tags are generated in AWS Certificate Manager. Must include `{{certificateId}}` as a placeholder for the certificate ID to ensure proper certificate identification and management. If not specified, defaults to `Infisical-{{certificateId}}`.
|
||||
|
||||
<Tip>
|
||||
**AWS Certificate Manager Certificate Limits**: AWS Certificate Manager has limits on the number of certificates per account and region. Refer to AWS documentation for current limits. Deleted certificates count toward your quota until they are permanently purged by AWS (typically after 30 days).
|
||||
</Tip>
|
||||
|
||||
6. Configure the **Details** of your AWS Certificate Manager Certificate Sync, then click **Next**.
|
||||
|
||||
5. Configure the **Details** of your AWS Certificate Manager Certificate Sync, then click **Next**.
|
||||
|
||||
|
||||
- **Name**: The name of your sync. Must be slug-friendly.
|
||||
- **Description**: An optional description for your sync.
|
||||
|
||||
6. Select which certificates should be synced to AWS Certificate Manager.
|
||||
|
||||
|
||||
7. Review your AWS Certificate Manager Certificate Sync configuration, then click **Create Sync**.
|
||||
|
||||
|
||||
|
||||
8. If enabled, your AWS Certificate Manager Certificate Sync will begin syncing your certificates to the destination endpoint.
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create an **AWS Certificate Manager Certificate Sync**, make an API request to the [Create AWS Certificate Manager Certificate Sync](/api-reference/endpoints/pki/syncs/aws-certificate-manager/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
<Note>
|
||||
You can optionally specify `certificateIds` during sync creation to immediately add certificates to the sync.
|
||||
If not provided, you can add certificates later using the certificate management endpoints.
|
||||
</Note>
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/pki/syncs/aws-certificate-manager \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-acm-cert-sync",
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"description": "an example certificate sync",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"subscriberId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"destination": "aws-certificate-manager",
|
||||
"isAutoSyncEnabled": true,
|
||||
"certificateIds": [
|
||||
"550e8400-e29b-41d4-a716-446655440000",
|
||||
"660f1234-e29b-41d4-a716-446655440001"
|
||||
],
|
||||
"syncOptions": {
|
||||
"canRemoveCertificates": true,
|
||||
"preserveArnOnRenewal": true,
|
||||
"certificateNameSchema": "myapp-{{certificateId}}"
|
||||
},
|
||||
"destinationConfig": {
|
||||
@@ -104,10 +109,10 @@ description: "Learn how to configure an AWS Certificate Manager Certificate Sync
|
||||
},
|
||||
"syncOptions": {
|
||||
"canRemoveCertificates": true,
|
||||
"preserveArnOnRenewal": true,
|
||||
"certificateNameSchema": "myapp-{{certificateId}}"
|
||||
},
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"subscriberId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-01-01T00:00:00.000Z",
|
||||
"updatedAt": "2023-01-01T00:00:00.000Z"
|
||||
@@ -115,24 +120,27 @@ description: "Learn how to configure an AWS Certificate Manager Certificate Sync
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
|
||||
</Tabs>
|
||||
|
||||
## Certificate Management
|
||||
|
||||
Your AWS Certificate Manager Certificate Sync will:
|
||||
|
||||
- **Automatic Deployment**: Deploy new certificates issued by your PKI subscriber to AWS Certificate Manager
|
||||
- **Certificate Updates**: Update certificates in AWS Certificate Manager when renewals occur
|
||||
- **Expiration Handling**: Optionally remove expired certificates from AWS Certificate Manager (if enabled)
|
||||
- **Automatic Deployment**: Deploy certificates in Infisical to AWS Certificate Manager.
|
||||
- **Certificate Updates**: Update certificates in AWS Certificate Manager when renewals occur.
|
||||
- **Expiration Handling**: Optionally remove expired certificates from AWS Certificate Manager (if enabled).
|
||||
- **Tagging**: Automatically tag certificates with an InfisicalCertificate tag for easy identification and management
|
||||
|
||||
<Note>
|
||||
AWS Certificate Manager Certificate Syncs support both automatic and manual synchronization modes. When auto-sync is enabled, certificates are automatically deployed as they are issued or renewed.
|
||||
AWS Certificate Manager Certificate Syncs support both automatic and manual
|
||||
synchronization modes. When auto-sync is enabled, certificates are
|
||||
automatically deployed as they are issued or renewed.
|
||||
</Note>
|
||||
|
||||
## Manual Certificate Sync
|
||||
|
||||
You can manually trigger certificate synchronization from your PKI subscriber to AWS Certificate Manager using the sync certificates functionality. This is useful for:
|
||||
You can manually trigger certificate synchronization to AWS Certificate Manager using the sync certificates functionality. This is useful for:
|
||||
|
||||
- Initial setup when you have existing certificates to deploy
|
||||
- One-time sync of specific certificates
|
||||
@@ -142,5 +150,8 @@ You can manually trigger certificate synchronization from your PKI subscriber to
|
||||
To manually sync certificates, use the [Sync Certificates](/api-reference/endpoints/pki/syncs/aws-certificate-manager/sync-certificates) API endpoint or the manual sync option in the Infisical UI.
|
||||
|
||||
<Note>
|
||||
AWS Certificate Manager does not support importing certificates back into Infisical due to security limitations where private keys cannot be extracted from AWS Certificate Manager. Only certificates imported into ACM (not AWS-issued certificates) can be managed by the sync.
|
||||
</Note>
|
||||
AWS Certificate Manager does not support importing certificates back into
|
||||
Infisical due to security limitations where private keys cannot be extracted
|
||||
from AWS Certificate Manager. Only certificates imported into ACM (not
|
||||
AWS-issued certificates) can be managed by the sync.
|
||||
</Note>
|
||||
|
||||
@@ -5,47 +5,43 @@ description: "Learn how to configure an Azure Key Vault Certificate Sync for Inf
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- Set up and configure a [Certificate Authority](/documentation/platform/pki/overview)
|
||||
- Create an [Azure Key Vault Connection](/integrations/app-connections/azure-key-vault)
|
||||
- Ensure your network security policies allow incoming requests from Infisical to this certificate sync provider, if network restrictions apply.
|
||||
- Create an [Azure Key Vault Connection](/integrations/app-connections/azure-key-vault)
|
||||
- Ensure your network security policies allow incoming requests from Infisical to this certificate sync provider, if network restrictions apply.
|
||||
|
||||
<Note>
|
||||
The Azure Key Vault Certificate Sync requires the following certificate permissions to be set on the user / service principal
|
||||
for Infisical to sync certificates to Azure Key Vault: `certificates/list`, `certificates/get`, `certificates/import`, `certificates/delete`.
|
||||
|
||||
Any role with these permissions would work such as the **Key Vault Certificates Officer** role.
|
||||
Any role with these permissions would work such as the **Key Vault Certificates Officer** role.
|
||||
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
Certificates synced to Azure Key Vault will be stored as certificate objects, preserving both the certificate and private key components.
|
||||
Certificates synced to Azure Key Vault will be stored as certificate objects,
|
||||
preserving both the certificate and private key components.
|
||||
</Note>
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
1. Navigate to **Project** > **Integrations** and select the **Certificate Syncs** tab. Click on the **Add Sync** button.
|
||||
|
||||
1. Navigate to **Project** > **Integrations** > **Certificate Syncs** and press **Add Sync**.
|
||||
|
||||
|
||||
2. Select the **Azure Key Vault** option.
|
||||
|
||||
|
||||
|
||||
3. Configure the **Source** from where certificates should be retrieved, then click **Next**.
|
||||
|
||||
|
||||
- **PKI Subscriber**: The PKI subscriber to retrieve certificates from.
|
||||
|
||||
4. Configure the **Destination** to where certificates should be deployed, then click **Next**.
|
||||
|
||||
3. Configure the **Destination** to where certificates should be deployed, then click **Next**.
|
||||
|
||||
|
||||
- **Azure Connection**: The Azure Connection to authenticate with.
|
||||
- **Vault Base URL**: The URL of your Azure Key Vault.
|
||||
<p class="height:1px" />
|
||||
|
||||
5. Configure the **Sync Options** to specify how certificates should be synced, then click **Next**.
|
||||
|
||||
4. Configure the **Sync Options** to specify how certificates should be synced, then click **Next**.
|
||||
|
||||
|
||||
- **Auto-Sync Enabled**: If enabled, certificates will automatically be synced from the source PKI subscriber when changes occur. Disable to enforce manual syncing only.
|
||||
- **Enable Certificate Removal**: If enabled, Infisical will remove expired certificates from the destination during sync operations. Disable this option if you intend to manage certificate cleanup manually.
|
||||
- **Enable Removal of Expired/Revoked Certificates**: If enabled, Infisical will remove certificates from the destination if they are no longer active in Infisical.
|
||||
- **Enable Versioning on Renewal**: If enabled, Infisical will sync renewed certificates to the destination under a new version of the original synced certificate instead of creating a new certificate.
|
||||
- **Certificate Name Schema** (Optional): Customize how certificate names are generated in Azure Key Vault. Use `{{certificateId}}` as a placeholder for the certificate ID. If not specified, defaults to `Infisical-{{certificateId}}`.
|
||||
- **Auto-Sync Enabled**: If enabled, certificates will automatically be synced when changes occur. Disable to enforce manual syncing only.
|
||||
|
||||
<Tip>
|
||||
**Azure Key Vault Soft Delete**: When certificates are removed from Azure Key Vault, they are placed in a soft-deleted state rather than being permanently deleted. This means:
|
||||
@@ -53,38 +49,50 @@ description: "Learn how to configure an Azure Key Vault Certificate Sync for Inf
|
||||
- To resync removed certificates, you must either manually **purge** them from Azure Key Vault or **recover** them through the Azure portal/CLI
|
||||
</Tip>
|
||||
|
||||
6. Configure the **Details** of your Azure Key Vault Certificate Sync, then click **Next**.
|
||||
|
||||
5. Configure the **Details** of your Azure Key Vault Certificate Sync, then click **Next**.
|
||||
|
||||
|
||||
- **Name**: The name of your sync. Must be slug-friendly.
|
||||
- **Description**: An optional description for your sync.
|
||||
|
||||
6. Select which certificates should be synced to Azure Key Vault.
|
||||
|
||||
|
||||
7. Review your Azure Key Vault Certificate Sync configuration, then click **Create Sync**.
|
||||
|
||||
|
||||
|
||||
8. If enabled, your Azure Key Vault Certificate Sync will begin syncing your certificates to the destination endpoint.
|
||||
|
||||
|
||||
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To create an **Azure Key Vault Certificate Sync**, make an API request to the [Create Azure Key Vault Certificate Sync](/api-reference/endpoints/pki/syncs/azure-key-vault/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
<Note>
|
||||
You can optionally specify `certificateIds` during sync creation to immediately add certificates to the sync.
|
||||
If not provided, you can add certificates later using the certificate management endpoints.
|
||||
</Note>
|
||||
|
||||
```bash Request
|
||||
curl --request POST \
|
||||
--url https://app.infisical.com/api/v1/pki/syncs/azure-key-vault \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data '{
|
||||
"name": "my-key-vault-cert-sync",
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"description": "an example certificate sync",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"subscriberId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"destination": "azure-key-vault",
|
||||
"isAutoSyncEnabled": true,
|
||||
"certificateIds": [
|
||||
"550e8400-e29b-41d4-a716-446655440000",
|
||||
"660f1234-e29b-41d4-a716-446655440001"
|
||||
],
|
||||
"syncOptions": {
|
||||
"canRemoveCertificates": true,
|
||||
"enableVersioningOnRenewal": true,
|
||||
"certificateNameSchema": "myapp-{{certificateId}}"
|
||||
},
|
||||
"destinationConfig": {
|
||||
@@ -108,10 +116,10 @@ description: "Learn how to configure an Azure Key Vault Certificate Sync for Inf
|
||||
},
|
||||
"syncOptions": {
|
||||
"canRemoveCertificates": true,
|
||||
"enableVersioningOnRenewal": true,
|
||||
"certificateNameSchema": "myapp-{{certificateId}}"
|
||||
},
|
||||
"projectId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"subscriberId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"connectionId": "3c90c3cc-0d44-4b50-8888-8dd25736052a",
|
||||
"createdAt": "2023-01-01T00:00:00.000Z",
|
||||
"updatedAt": "2023-01-01T00:00:00.000Z"
|
||||
@@ -119,24 +127,27 @@ description: "Learn how to configure an Azure Key Vault Certificate Sync for Inf
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
|
||||
</Tabs>
|
||||
|
||||
## Certificate Management
|
||||
|
||||
Your Azure Key Vault Certificate Sync will:
|
||||
|
||||
- **Automatic Deployment**: Deploy new certificates issued by your PKI subscriber to Azure Key Vault
|
||||
- **Automatic Deployment**: Deploy certificates in Infisical to Azure Key Vault.
|
||||
- **Certificate Updates**: Update certificates in Azure Key Vault when renewals occur
|
||||
- **Expiration Handling**: Optionally remove expired certificates from Azure Key Vault (if enabled)
|
||||
- **Format Preservation**: Maintain certificate format and metadata during sync operations
|
||||
|
||||
<Note>
|
||||
Azure Key Vault Certificate Syncs support both automatic and manual synchronization modes. When auto-sync is enabled, certificates are automatically deployed as they are issued or renewed.
|
||||
Azure Key Vault Certificate Syncs support both automatic and manual
|
||||
synchronization modes. When auto-sync is enabled, certificates are
|
||||
automatically deployed as they are issued or renewed.
|
||||
</Note>
|
||||
|
||||
## Manual Certificate Sync
|
||||
|
||||
You can manually trigger certificate synchronization from your PKI subscriber to Azure Key Vault using the sync certificates functionality. This is useful for:
|
||||
You can manually trigger certificate synchronization to Azure Key Vault using the sync certificates functionality. This is useful for:
|
||||
|
||||
- Initial setup when you have existing certificates to deploy
|
||||
- One-time sync of specific certificates
|
||||
@@ -146,5 +157,7 @@ You can manually trigger certificate synchronization from your PKI subscriber to
|
||||
To manually sync certificates, use the [Sync Certificates](/api-reference/endpoints/pki/syncs/azure-key-vault/sync-certificates) API endpoint or the manual sync option in the Infisical UI.
|
||||
|
||||
<Note>
|
||||
Azure Key Vault does not support importing certificates back into Infisical due to security limitations where private keys cannot be extracted from Azure Key Vault.
|
||||
</Note>
|
||||
Azure Key Vault does not support importing certificates back into Infisical
|
||||
due to security limitations where private keys cannot be extracted from Azure
|
||||
Key Vault.
|
||||
</Note>
|
||||
|
||||
@@ -3,17 +3,19 @@ sidebarTitle: "Overview"
|
||||
description: "Learn how to sync certificates from Infisical PKI to third-party services."
|
||||
---
|
||||
|
||||
Certificate Syncs enable you to sync certificates from Infisical PKI to third-party services using [App Connections](/integrations/app-connections/overview).
|
||||
Certificate Syncs enable you to push certificates from Infisical to third-party services using [App Connections](/integrations/app-connections/overview).
|
||||
|
||||
<Note>
|
||||
Certificate Syncs are designed to automatically deploy certificates issued by your Certificate Authority to external services, ensuring your certificates are always up-to-date across your infrastructure.
|
||||
Certificate Syncs are designed to automatically deploy certificates issued by
|
||||
your Certificate Authority to external services, ensuring your certificates
|
||||
are always up-to-date across your infrastructure.
|
||||
</Note>
|
||||
|
||||
## Concept
|
||||
|
||||
Certificate Syncs are a project-level resource used to sync certificates, via an [App Connection](/integrations/app-connections/overview), from a particular PKI subscriber (source)
|
||||
to a third-party service (destination). When new certificates are issued or existing certificates are renewed, changes will automatically be propagated to the destination, ensuring
|
||||
your certificates are always current.
|
||||
Certificate Syncs are a project-level resource used to push certificates, via an [App Connection](/integrations/app-connections/overview), from Infisical
|
||||
to a third-party service (destination). When paired with [server-side auto-renewal](/documentation/platform/pki/certificates/certificates#server-driven-certificate-renewal), renewed certificates are automatically synced to the destination,
|
||||
ensuring your certificates stay current.
|
||||
|
||||
<br />
|
||||
|
||||
@@ -31,17 +33,15 @@ your certificates are always current.
|
||||
G[Certificate 1]
|
||||
H[Certificate 2]
|
||||
I[Certificate 3]
|
||||
J[PKI Subscriber]
|
||||
|
||||
B --> A
|
||||
C --> J
|
||||
D --> J
|
||||
E --> J
|
||||
C --> B
|
||||
D --> B
|
||||
E --> B
|
||||
A --> F
|
||||
F --> G
|
||||
F --> H
|
||||
F --> I
|
||||
J --> B
|
||||
|
||||
classDef default fill:#ffffff,stroke:#666,stroke-width:2px,rx:10px,color:black
|
||||
classDef connection fill:#FFF2B2,stroke:#E6C34A,stroke-width:2px,color:black,rx:15px
|
||||
@@ -61,39 +61,50 @@ your certificates are always current.
|
||||
|
||||
## Workflow
|
||||
|
||||
Configuring a Certificate Sync requires three components: a <strong>source</strong> PKI subscriber to retrieve certificates from,
|
||||
Configuring a Certificate Sync requires three components: The certificates that you'd like to push,
|
||||
a <strong>destination</strong> endpoint to deploy certificates to, and <strong>configuration options</strong> to determine how your certificates
|
||||
should be synced. Follow these steps to start syncing:
|
||||
|
||||
<Note>
|
||||
For step-by-step guides on syncing to a particular third-party service, refer to the Certificate Syncs section in the Navigation Bar.
|
||||
For step-by-step guides on syncing to a particular third-party service, refer
|
||||
to the Certificate Syncs section in the Navigation Bar.
|
||||
</Note>
|
||||
|
||||
1. <strong>Create App Connection:</strong> If you have not already done so, create an [App Connection](/integrations/app-connections/overview)
|
||||
via the UI or API for the third-party service you intend to sync certificates to.
|
||||
1. <strong>Create App Connection:</strong> If you have not already done so, create
|
||||
an [App Connection](/integrations/app-connections/overview) via the UI or API
|
||||
for the third-party service you intend to sync certificates to.
|
||||
|
||||
2. <strong>Create Certificate Sync:</strong> Configure a Certificate Sync in the desired project by specifying the following parameters via the UI or API:
|
||||
- <strong>Source:</strong> The PKI subscriber you wish to retrieve certificates from.
|
||||
- <strong>Destination:</strong> The App Connection to utilize and the destination endpoint to deploy certificates to. These can vary between services.
|
||||
- <strong>Options:</strong> Customize how certificates should be synced, including:
|
||||
- Whether certificates should be removed from the destination when they expire
|
||||
- Certificate naming schema to control how certificate names are generated in the destination
|
||||
2. <strong>Create Certificate Sync:</strong> Configure a Certificate Sync in the
|
||||
desired project by specifying the following parameters via the UI or API:
|
||||
|
||||
- <strong>Destination:</strong> The App Connection to utilize and the destination
|
||||
endpoint to deploy certificates to such as [AWS Certificate Manager](/documentation/platform/pki/certificate-syncs/aws-certificate-manager)
|
||||
or [Azure Key Vault](/documentation/platform/pki/certificate-syncs/azure-key-vault).
|
||||
- <strong>Certificates:</strong> The certificates you wish to push to the destination.
|
||||
- <strong>Options:</strong> Customize how certificates should be synced, including:
|
||||
- Whether certificates should be removed from the destination when they expire.
|
||||
- Certificate naming schema to control how certificate names are generated in
|
||||
the destination.
|
||||
|
||||
<Note>
|
||||
Only certificates managed by Infisical will be affected during sync operations. Certificates not created or
|
||||
managed by Infisical will remain untouched, and changes made to Infisical-managed certificates directly
|
||||
in the destination service may be overwritten by future syncs.
|
||||
Only certificates managed by Infisical will be affected during sync
|
||||
operations. Certificates not created or managed by Infisical will remain
|
||||
untouched, and changes made to Infisical-managed certificates directly in the
|
||||
destination service may be overwritten by future syncs.
|
||||
</Note>
|
||||
|
||||
<Info>
|
||||
Some third-party services do not support removing expired certificates automatically.
|
||||
Some third-party services do not support removing expired certificates
|
||||
automatically.
|
||||
</Info>
|
||||
|
||||
3. <strong>Utilize Sync:</strong> Any new certificates issued or renewals from the source PKI subscriber will now automatically be propagated to the destination endpoint.
|
||||
3. <strong>Utilize Sync:</strong> Selected certificates will now be pushed to the
|
||||
destination endpoint and automatically redeployed whenever they are renewed.
|
||||
|
||||
<Note>
|
||||
Infisical is continuously expanding its Certificate Sync third-party service support. If the service you need isn't available,
|
||||
contact us at team@infisical.com to make a request.
|
||||
Infisical is continuously expanding its Certificate Sync third-party service
|
||||
support. If the service you need isn't available, contact us at
|
||||
team@infisical.com to make a request.
|
||||
</Note>
|
||||
|
||||
## Certificate Naming
|
||||
@@ -111,32 +122,12 @@ You can customize certificate naming by providing a **Certificate Name Schema**
|
||||
- `{{certificateId}}` - The unique certificate identifier (required)
|
||||
|
||||
**Examples:**
|
||||
|
||||
- `myapp-{{certificateId}}` → `myapp-abc123def456`
|
||||
- `ssl/{{certificateId}}` → `ssl/abc123def456`
|
||||
|
||||
**Rules:**
|
||||
|
||||
- Must include exactly one `{{certificateId}}` placeholder
|
||||
- Only alphanumeric characters, dashes (-), underscores (_), and slashes (/) are allowed
|
||||
- Only alphanumeric characters, dashes (-), underscores (\_), and slashes (/) are allowed
|
||||
- Certificate names matching your schema will be managed by Infisical during sync operations
|
||||
|
||||
## Certificate Management
|
||||
|
||||
Certificate Syncs handle the full lifecycle of certificate management:
|
||||
|
||||
- **Automatic Deployment**: New certificates are automatically deployed to configured destinations
|
||||
- **Renewal Propagation**: Certificate renewals are seamlessly pushed to all connected services
|
||||
- **Expiration Handling**: Expired certificates can be automatically removed from destinations (service-dependent)
|
||||
- **Certificate Validation**: Certificates are validated before deployment to ensure integrity
|
||||
|
||||
<div align="center">
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Certificate Issued] -->|Deploy| B[Destination Service]
|
||||
C[Certificate Renewed] -->|Update| B
|
||||
D[Certificate Expired] -->|Remove| B
|
||||
style B fill:#F4FFE6,stroke:#96D600,stroke-width:2px,color:black,rx:15px
|
||||
style A fill:#E6F4FF,stroke:#0096D6,stroke-width:2px,color:black,rx:15px
|
||||
style C fill:#E6F4FF,stroke:#0096D6,stroke-width:2px,color:black,rx:15px
|
||||
style D fill:#FFE6E6,stroke:#D63F3F,stroke-width:2px,color:black,rx:15px
|
||||
```
|
||||
</div>
|
||||
164
docs/documentation/platform/pki/certificates/certificates.mdx
Normal file
164
docs/documentation/platform/pki/certificates/certificates.mdx
Normal file
@@ -0,0 +1,164 @@
|
||||
---
|
||||
title: "Certificates"
|
||||
sidebarTitle: "Certificates"
|
||||
---
|
||||
|
||||
<Note>
|
||||
PKI architecture is a complex topic and there are many ways to orchestrate
|
||||
certificate management including renewal operations. For specific guidance and
|
||||
access to enterprise features, we recommend reaching out to
|
||||
sales@infisical.com to schedule a demo.
|
||||
</Note>
|
||||
|
||||
## Concept
|
||||
|
||||
A certificate is the (X.509) leaf certificate issued for a certificate profile.
|
||||
|
||||
Once issued, a certificate is kept track of in the certificate inventory
|
||||
where you can manage various aspects of its lifecycle including deployment to cloud key stores, server-side auto-renewal behavior, revocation, and more.
|
||||
|
||||
## Guide to Issuing Certificates
|
||||
|
||||
To issue a certificate, you must first create a [certificate profile](/documentation/platform/pki/certificates/profiles) and a [certificate template](/documentation/platform/pki/certificates/templates) to go along with it.
|
||||
|
||||
The [enrollment method](/documentation/platform/pki/enrollment-methods/overview) configured on the certificate profile determines how a certificate is issued for it.
|
||||
Refer to the documentation for each enrollment method below to learn more about how to issue certificates using it.
|
||||
|
||||
- [API](/documentation/platform/pki/enrollment-methods/api): Issue a certificate over UI or by making an API request to Infisical.
|
||||
- [EST](/documentation/platform/pki/enrollment-methods/est): Issue a certificate over the EST protocol.
|
||||
|
||||
## Guide to Renewing Certificates
|
||||
|
||||
To [renew a certificate](/documentation/platform/pki/concepts/certificate-lifecycle#renewal), you can either request a new certificate from a certificate profile or have the platform
|
||||
automatically request a new one for you. Whether you pursue a client-driven or server-driven approach is totally dependent on the enrollment method configured on your certificate
|
||||
profile as well as your infrastructure use-case.
|
||||
|
||||
### Client-Driven Certificate Renewal
|
||||
|
||||
Client-driven certificate renewal is when renewal is initiated client-side by the end-entity consuming the certificate.
|
||||
This is the most common approach to certificate renewal and is suitable for most use-cases.
|
||||
|
||||
### Server-Driven Certificate Renewal
|
||||
|
||||
Server-driven certificate renewal is when renewal is initiated server-side by Infisical rather than by the end-entity consuming the certificate.
|
||||
When a certificate considered for auto-renewal meets a specified _renewal days before expiration_ threshold, Infisical reaches out to the issuing CA bound to the [certificate profile](/documentation/platform/pki/certificates/profiles) of the expiring certificate
|
||||
to request for a new one.
|
||||
The resulting renewed certificate is stored in the platform and made available to be fetched back or pushed downstream to end-entities or external systems such as cloud key stores.
|
||||
|
||||
Note that server-driven certificate renewal is only available for certificates issued via the [API enrollment method](/documentation/platform/pki/enrollment-methods/api) where key pairs are generated server-side.
|
||||
A certificate can be considered for auto-renewal at time of issuance if the **Enable Auto-Renewal By Default** option is selected on its [certificate profile](/documentation/platform/pki/certificates/profiles) or after issuance by toggling this option manually.
|
||||
|
||||
<Info>
|
||||
For server-driven certificate renewal workflows, you can programmatically fetch the latest active certificate bundle for a certificate profile using the [Get Latest Active Certificate Bundle](/api-reference/endpoints/certificate-profiles/get-latest-active-bundle) API endpoint.
|
||||
|
||||
This ensures you always retrieve the most current valid certificate, including any that have been automatically renewed, making it particularly useful for deployment pipelines and automation workflows where you don't want to track individual serial numbers.
|
||||
</Info>
|
||||
|
||||
The following examples demonstrate different approaches to certificate renewal:
|
||||
|
||||
- Using the ACME enrollment method, you may connect an ACME client like [certbot](https://certbot.eff.org/) to fetch back and renew certificates for Apache, Nginx, or other server. The ACME client will pursue a client-driven approach and submit certificate requests upon certificate expiration for you, saving renewed certificates back to the server's configuration.
|
||||
- Using the ACME enrollment method, you may use [cert-manager](https://cert-manager.io/) with Infisical to issue and renew certificates for Kubernetes workloads; cert-manager will pursue a client-driven approach and submit certificate requests upon certificate expiration for you, saving renewed certificates back to Kubernetes secrets.
|
||||
- Using the API enrollment method, you may push and auto-renew certificates to AWS and Azure using [certificate syncs](/documentation/platform/pki/certificate-syncs/overview). Certificates issued over the API enrollment method, where key pairs are generated server-side, are also eligible for server-side auto-renewal; once renewed, certificates are automatically pushed back to their sync destination.
|
||||
|
||||
## Guide to Revoking Certificates
|
||||
|
||||
In the following steps, we explore how to revoke a X.509 certificate and obtain a Certificate Revocation List (CRL) for a CA.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
<Steps>
|
||||
<Step title="Revoking a Certificate">
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Obtaining a CRL">
|
||||
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
|
||||
```
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
<Steps>
|
||||
<Step title="Revoking a certificate">
|
||||
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/certificate-authorities/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/pki/certificates/<cert-serial-number>/revoke' \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"revocationReason": "UNSPECIFIED"
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
message: "Successfully revoked certificate",
|
||||
serialNumber: "...",
|
||||
revokedAt: "..."
|
||||
}
|
||||
```
|
||||
</Step>
|
||||
<Step title="Obtaining a CRL">
|
||||
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/crls) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request GET 'https://app.infisical.com/api/v1/pki/ca/<ca-id>/crls' \
|
||||
--header 'Authorization: Bearer <access-token>'
|
||||
```
|
||||
|
||||
### 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
|
||||
```
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
15
docs/documentation/platform/pki/certificates/overview.mdx
Normal file
15
docs/documentation/platform/pki/certificates/overview.mdx
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
title: "Overview"
|
||||
sidebarTitle: "Overview"
|
||||
---
|
||||
|
||||
To issue a certificate with Infisical, you create a certificate profile and a certificate template to go along with it. You then issue a certificate against
|
||||
a specific profile depending on the enrollment method associated with it.
|
||||
|
||||
There are three components to understand:
|
||||
|
||||
- [Certificate Profile](/documentation/platform/pki/certificates/profiles): A configuration set specifying how certificates should be issued under that profile including the [issuing CA](/documentation/platform/pki/ca/overview), a certificate template, and the [enrollment method](/documentation/platform/pki/enrollment-methods/overview) (such as ACME, EST, API, etc.) used to enroll certificates.
|
||||
|
||||
- [Certificate Template](/documentation/platform/pki/certificates/templates): A policy structure specifying the permitted attributes for requested certificates including subject naming conventions, SAN fields, key usages, and extended key usages.
|
||||
|
||||
- [Certificate](/documentation/platform/pki/certificates/certificate): The actual X.509 certificate issued for a profile. Once issued, a certificate kept track of in the certificate inventory.
|
||||
28
docs/documentation/platform/pki/certificates/profiles.mdx
Normal file
28
docs/documentation/platform/pki/certificates/profiles.mdx
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Certificate Profiles"
|
||||
sidebarTitle: "Profiles"
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
A certificate profile is a configuration set specifying how leaf certificates should be issued for a group of end-entities including the [issuing CA](/documentation/platform/pki/ca/overview), a [certificate template](/documentation/platform/pki/certificates/templates), and the [enrollment method](/documentation/platform/pki/enrollment-methods/overview) (e.g. ACME, EST, API, etc.) used to enroll certificates.
|
||||
|
||||
You typically request certificates against a certificate profile through its associated enrollment method. Each method defines its own interaction flow which you can read more about in its respective documentation.
|
||||
|
||||
## Guide to Creating a Certificate Profile
|
||||
|
||||
To create a certificate profile, head to your Certificate Management Project > Certificates > Certificate Profiles and press **Create Profile**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each field:
|
||||
|
||||
- Name: A slug-friendly name for the profile such as `web-servers`.
|
||||
- Description: An optional description for the profile.
|
||||
- Issuing CA: The [issuing CA](/documentation/platform/pki/ca/overview) that should be used to issue certificates for the profile.
|
||||
- Certificate Template: The [certificate template](/documentation/platform/pki/certificates/templates) that should be used to validate certificate requests for the profile.
|
||||
- Enrollment Method: The enrollment method that should be used to enroll certificates for the profile such as ACME, EST, API, etc.
|
||||
|
||||
Depending on which enrollment method you choose, you may be presented with additional enrollment-specific configuration fields.
|
||||
30
docs/documentation/platform/pki/certificates/templates.mdx
Normal file
30
docs/documentation/platform/pki/certificates/templates.mdx
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Certificate Templates"
|
||||
sidebarTitle: "Templates"
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
A certificate template is a policy structure specifying permitted attributes for requested certificates. This includes constraints around subject naming conventions, SAN fields, key usages, and extended key usages.
|
||||
|
||||
Each certificate requested against a profile is validated against the template bound to that profile. If the request fails any criteria included in the template, the certificate is not issued. This helps administrators enforce uniformity and security standards across all issued certificates.
|
||||
|
||||
## Guide to Creating a Certificate Template
|
||||
|
||||
To create a certificate template, head to your Certificate Management Project > Certificates > Certificate Templates and press **Create Template**.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each field:
|
||||
|
||||
- Template Name: A slug-friendly name for the template such as `tls-server`.
|
||||
- Description: An optional description for the template.
|
||||
- Subject Attributes: A list of common names that can be included in the certificate subject. Each row accepts a fixed value or pattern such as `example.com` or `*.example.com` and whether it is allowed or denied.
|
||||
- Subject Alternative Names (SANs): A list of SANs that can appear in the certificate. Each row accepts a SAN type (e.g. DNS, IP, Email, URI), a fixed value or pattern such as `example.com` or `*.example.com`, and an allow or deny flag.
|
||||
- Allowed Signature Algorithms: The set of signature algorithms permitted to sign certificates under this template such as `SHA256-RSA`, `SHA512-RSA`, etc.
|
||||
- Allowed Key Algorithms: The set of public key algorithms permitted for certificate requests such as `RSA-2048`, `RSA-4096`, etc.
|
||||
- Key Usages: The cryptographic purposes of the certificate such as Digital Signature, Key Encipherment, etc.
|
||||
- Extended Key Usages: The higher-level intended uses of the certificate such as Server Authentication, Client Authentication, etc.
|
||||
- Certificate Validity: The maximum lifetime of certificates that can be requested for certificates validated against this template. You can specify both a duration and unit (days, months, or years).
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "Certificate Lifecycle"
|
||||
description: "Learn what is the certificate lifecycle and how it works."
|
||||
---
|
||||
|
||||
## Certificate Lifecycle
|
||||
|
||||
Typically, a certificate goes through a series of stages during its lifetime from creation to retirement. This is called the certificate lifecycle. The exact names of these stages may vary from vendor to vendor, but they typically include [discovery](/documentation/platform/pki/concepts/certificate-lifecycle#discovery), [enrollment](/documentation/platform/pki/concepts/certificate-lifecycle#enrollment), [deployment](/documentation/platform/pki/concepts/certificate-lifecycle#deployment), [renewal](/documentation/platform/pki/concepts/certificate-lifecycle#renewal), [revocation](/documentation/platform/pki/concepts/certificate-lifecycle#revocation), and [retirement](/documentation/platform/pki/concepts/certificate-lifecycle#retirement).
|
||||
|
||||
Note that not every stage is needed. For instance:
|
||||
|
||||
- You are not required to discover certificates in order to start issuing and managing them.
|
||||
- You may not need to revoke a certificate explicitly if it expires naturally and is replaced during routine renewal.
|
||||
|
||||
## Discovery
|
||||
|
||||
Certificate discovery is the process of identifying all active and inactive certificates across an environment, including those found on web servers, load balancers, services, and devices. A complete inventory prevents outages from forgotten certificates and creates the foundation for automation and monitoring.
|
||||
|
||||
## Enrollment (Request / Issuance)
|
||||
|
||||
Certificate enrollment is the process of requesting a certificate from a CA and can follow different approaches depending on the system or protocol in use.
|
||||
|
||||
Common approaches to certificate enrollment include:
|
||||
|
||||
- CSR-based enrollment: The client generates a key pair locally and submits a Certificate Signing Request (CSR) to a CA for certificate issuance.
|
||||
- CSR-less enrollment: The client requests a certificate directly from a CA which may handle key generation internally and return the key pair in the response.
|
||||
|
||||
Enrollment can be manually completed via API or fully automated using protocols like EST or ACME. The choice of enrollment method depends on security requirements, operational constraints, and integration context.
|
||||
|
||||
## Deployment
|
||||
|
||||
Certificate deployment involves installing the issued certificate on the appropriate systems and services, such as web servers, load balancers, or internal endpoints. It can also include distributing or [synchronizing certificates](/documentation/platform/pki/certificate-syncs/overview) to external systems like cloud key stores (e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) so they can be securely consumed by workloads running in the cloud.
|
||||
|
||||
Deployment can happen manually or through automated mechanisms such as configuration pipelines, agents, or webhook integrations.
|
||||
|
||||
## Renewal
|
||||
|
||||
Certificate renewal is the process of requesting a new certificate from a CA before it expires to maintain trust and availability; this process can involve reusing the same key pair or rotating to a new one.
|
||||
|
||||
The renewal process can be server-driven or client-driven:
|
||||
|
||||
- Server-driven: Infisical automatically renews the certificate on your behalf. The renewed certificate is stored in the platform and can be synchronized to external systems such as cloud key stores.
|
||||
- Client-driven: An external client, such as an agent or workload, initiates the renewal against Infisical. This is useful when key material needs to remain under client control or when rotation is tied to application-specific logic.
|
||||
|
||||
This flexibility allows certificates to be renewed in a way that aligns with different security, automation, and infrastructure models.
|
||||
|
||||
## Revocation
|
||||
|
||||
Certificate revocation is the process of invalidating a certificate to prevent it from being used. This is required when a certificate is compromised, misconfigured, or no longer needed. The CA signals this status to clients through CRLs or OCSP. A new certificate can be issued and deployed if needed.
|
||||
|
||||
## Retirement
|
||||
|
||||
Certificate retirement is the process of removing a certificate from the system. This is typically done when a certificate is no longer needed or has expired.
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "Certificate Management"
|
||||
description: "Learn what is certificate management and why it matters for building secure systems."
|
||||
---
|
||||
|
||||
## What is a Certificate?
|
||||
|
||||
A (digital) _certificate_ is a file that is tied to a cryptographic key pair and is used to verify the identity of a website, user, device, or service. It helps establish trust and secure, encrypted communication between systems.
|
||||
|
||||
For example, when you visit a website over HTTPS, your browser checks the TLS certificate deployed on the web server or load balancer to make sure it’s really the site it claims to be. If the certificate is valid, your browser establishes an encrypted connection with the server.
|
||||
|
||||
Certificates contain information about the subject (who it identifies), the public key, and a digital signature from the CA that issued the certificate. They also include additional fields such as key usages, validity periods, and extensions that define how and where the certificate can be used. When a certificate expires, the service presenting it is no longer trusted, and clients won't be able to establish a secure connection to the service.
|
||||
|
||||
## What is Certificate Management?
|
||||
|
||||
As infrastructure scales and systems become more distributed, certificates sprawl. Without proper visibility and automation in place, certificates scatter across IT infrastructure, creating blind spots that can lead to service outages when certificates aren't renewed in time.
|
||||
|
||||
To solve certificate sprawl and avoid outages, organizations rely on certificate management: the practice of centralizing and automating the certificate lifecycle from issuance through renewal and revocation.
|
||||
|
||||
A consistent approach makes it easier to keep certificates valid and trusted, reduce operational risk, and maintain secure communication across environments.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Certificate Enrollment via ACME"
|
||||
sidebarTitle: "ACME"
|
||||
---
|
||||
|
||||
<Info>
|
||||
ACME-based certificate enrollment is currently under development and will be included in a future release.
|
||||
</Info>
|
||||
179
docs/documentation/platform/pki/enrollment-methods/api.mdx
Normal file
179
docs/documentation/platform/pki/enrollment-methods/api.mdx
Normal file
@@ -0,0 +1,179 @@
|
||||
---
|
||||
title: "Certificate Enrollment via API"
|
||||
sidebarTitle: "API"
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
The API enrollment method allows you to issue certificates against a specific certificate profile over Web UI or by making an API request to Infisical.
|
||||
|
||||
## Guide to Certificate Enrollment via API
|
||||
|
||||
In the following steps, we explore how to issue a X.509 certificate using the API enrollment method.
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a certificate profile">
|
||||
Create a [certificate
|
||||
profile](/documentation/platform/pki/certificates/profiles) with **API**
|
||||
selected as the enrollment method.
|
||||
|
||||
Notice that the API enrollment method supports an option called **Enable Auto-Renewal By Default**.
|
||||
If selected, _eligible_ certificates are automatically considered for server-side auto-renewal based
|
||||
on a specified renewal days before expiration threshold at the time of issuance; for more information
|
||||
about server-side auto-renewal, refer to the documentation [here](/documentation/platform/pki/certificates/certificates#guide-to-renewing-certificates).
|
||||
|
||||
</Step>
|
||||
<Step title="Issue a certificate">
|
||||
To create a certificate, head to your Project > Certificates > Certificates and press **Issue**.
|
||||
|
||||
|
||||
|
||||
Here, select the certificate profile from step 1 that will be used to issue the certificate and fill out the rest of the details for the certificate to be issued.
|
||||
|
||||
|
||||
|
||||
</Step>
|
||||
<Step title="Download the certificate details">
|
||||
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**.
|
||||
|
||||
|
||||
|
||||
<Note>
|
||||
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.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
|
||||
<Steps>
|
||||
<Step title="Create a certificate profile">
|
||||
|
||||
To create a certificate [profile](/documentation/platform/pki/certificates/profiles), make an API request to the [Create Certificate Profile](/docs/api-reference/endpoints/certificate-profiles/create) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request POST 'https://app.infisical.com/api/v1/pki/certificate-profiles' \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"projectId": "<project-id>",
|
||||
"caId": "<ca-id>",
|
||||
"certificateTemplateId": "<certificate-template-id>",
|
||||
"slug": "my-api-profile",
|
||||
"description": "Certificate profile for API enrollment",
|
||||
"enrollmentType": "API",
|
||||
"apiConfig": {
|
||||
"autoRenew": true,
|
||||
"renewBeforeDays": 7
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"certificateProfile": {
|
||||
"id": "550e8400-e29b-41d4-a716-446655440000",
|
||||
"projectId": "65f0a4b0-c123-4567-8901-23456789abcd",
|
||||
"caId": "550e8400-e29b-41d4-a716-446655440000",
|
||||
"certificateTemplateId": "660f1234-e29b-41d4-a716-446655440001",
|
||||
"slug": "my-api-profile",
|
||||
"description": "Certificate profile for API enrollment",
|
||||
"enrollmentType": "API",
|
||||
"apiConfigId": "770g2345-e29b-41d4-a716-446655440002",
|
||||
"createdAt": "2023-01-19T09:44:36.267Z",
|
||||
"updatedAt": "2023-01-19T09:44:36.267Z"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</Step>
|
||||
<Step title="Issue a certificate">
|
||||
|
||||
To issue a certificate against the certificate profile, make an API request to the [Issue Certificate](/api-reference/endpoints/certificates/issue-certificate) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request POST 'https://app.infisical.com/api/v3/pki/certificates/issue-certificate' \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"profileId": "<certificate-profile-id>",
|
||||
"commonName": "service.acme.com",
|
||||
"ttl": "1y",
|
||||
"signatureAlgorithm": "RSA-SHA256",
|
||||
"keyAlgorithm": "RSA_2048",
|
||||
"keyUsages": ["digital_signature", "key_encipherment"],
|
||||
"extendedKeyUsages": ["server_auth"],
|
||||
"altNames": [
|
||||
{
|
||||
"type": "DNS",
|
||||
"value": "service.acme.com"
|
||||
},
|
||||
{
|
||||
"type": "DNS",
|
||||
"value": "www.service.acme.com"
|
||||
}
|
||||
]
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"certificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"certificateChain": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"issuingCaCertificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"privateKey": "-----BEGIN PRIVATE KEY-----\nMIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC...\n-----END PRIVATE KEY-----",
|
||||
"serialNumber": "123456789012345678",
|
||||
"certificateId": "880h3456-e29b-41d4-a716-446655440003"
|
||||
}
|
||||
```
|
||||
|
||||
<Note>
|
||||
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.
|
||||
</Note>
|
||||
|
||||
If you have an external private key, you can also issue a certificate by making an API request containing a pem-encoded CSR (Certificate Signing Request) to the [Sign Certificate](/api-reference/endpoints/certificates/sign-certificate) API endpoint.
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl --location --request POST 'https://app.infisical.com/api/v3/pki/certificates/sign-certificate' \
|
||||
--header 'Authorization: Bearer <access-token>' \
|
||||
--header 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"profileId": "<certificate-profile-id>",
|
||||
"csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgMBE9oaW8...\n-----END CERTIFICATE REQUEST-----",
|
||||
"ttl": "1y"
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"certificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"certificateChain": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"issuingCaCertificate": "-----BEGIN CERTIFICATE-----\nMIIEpDCCAowCCQD...\n-----END CERTIFICATE-----",
|
||||
"serialNumber": "123456789012345679",
|
||||
"certificateId": "990i4567-e29b-41d4-a716-446655440004"
|
||||
}
|
||||
```
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
</Tabs>
|
||||
71
docs/documentation/platform/pki/enrollment-methods/est.mdx
Normal file
71
docs/documentation/platform/pki/enrollment-methods/est.mdx
Normal file
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: "Certificate Enrollment via EST"
|
||||
sidebarTitle: "EST"
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
The API enrollment method allows you to issue and manage certificates against a specific certificate profile using the [EST protocol](https://en.wikipedia.org/wiki/Enrollment_over_Secure_Transport).
|
||||
This method is suitable for environments requiring strong authentication and encrypted communication, such as in IoT, enterprise networks, and secure web services.
|
||||
|
||||
Infisical's EST service is based on [RFC 7030](https://datatracker.ietf.org/doc/html/rfc7030) and implements the following endpoints:
|
||||
|
||||
- **cacerts** - provides the necessary CA chain for the client to validate certificates issued by the CA.
|
||||
- **simpleenroll** - allows an EST client to request a new certificate from Infisical's EST server
|
||||
- **simplereenroll** - similar to the /simpleenroll endpoint but is used for renewing an existing certificate.
|
||||
|
||||
These EST endpoints are exposed on port 8443 under the .well-known/est path
|
||||
and structured under `https://app.infisical.com:8443/.well-known/est/{profile_id}/...`
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Your client devices need to have a bootstrap/pre-installed certificate.
|
||||
- Your client devices must trust the server certificates used by Infisical's EST server. If the devices are new or lack existing trust configurations, you need to manually establish trust for the appropriate certificates.
|
||||
|
||||
<Note>
|
||||
For Infisical Cloud users, the devices must be configured to trust the [Amazon
|
||||
root CA certificates](https://www.amazontrust.com/repository).
|
||||
</Note>
|
||||
|
||||
## Guide to Certificate Enrollment via EST
|
||||
|
||||
In the following steps, we explore how to issue a X.509 certificate using the EST enrollment method.
|
||||
|
||||
<Steps>
|
||||
<Step title="Set up up a certificate profile">
|
||||
Create a [certificate
|
||||
profile](/documentation/platform/pki/certificates/profiles) with **EST**
|
||||
selected as the enrollment method and fill in EST-specific configuration.
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each EST-specific configuration field:
|
||||
|
||||
- Disable Bootstrap CA Validation: Enable this if your devices are not configured with a bootstrap certificate.
|
||||
- EST Passphrase: This is also used to authenticate your devices with Infisical's EST server. When configuring the clients, use the value defined here as the EST password.
|
||||
- CA Chain Certificate: This is the certificate chain used to validate your devices' manufacturing/pre-installed certificates. This will be used to authenticate your devices with Infisical's EST server.
|
||||
|
||||
</Step>
|
||||
<Step title="Obtain the EST label">
|
||||
Once the EST enrollment method configuration is complete, you can use the ID of the associated certificate profile
|
||||
`profile_id` as the EST label when enrolling EST clients with Infisical.
|
||||
|
||||
|
||||
|
||||
The complete URL structure of the supported EST endpoints may look like the following:
|
||||
|
||||
- https://app.infisical.com:8443/.well-known/est/{profile_id}/cacerts
|
||||
- https://app.infisical.com:8443/.well-known/est/{profile_id}/simpleenroll
|
||||
- https://app.infisical.com:8443/.well-known/est/{profile_id}/simplereenroll
|
||||
</Step>
|
||||
|
||||
<Step title="Configure EST clients">
|
||||
To use the EST passphrase in your clients, configure it as the EST password. The EST username can be set to any arbitrary value.
|
||||
Use the appropriate client certificates for invoking the EST endpoints.
|
||||
- For `simpleenroll`, use the bootstrapped/manufacturer client certificate.
|
||||
- For `simplereenroll`, use a valid EST-issued client certificate.
|
||||
When configuring the PKCS#12 objects for the client certificates, only include the leaf certificate and the private key.
|
||||
|
||||
</Step>
|
||||
|
||||
</Steps>
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "Overview"
|
||||
sidebarTitle: "Overview"
|
||||
---
|
||||
|
||||
Enrollment methods determine how certificates are issued and managed for a [certificate profile](/documentation/platform/pki/certificates/profiles).
|
||||
|
||||
Refer to the documentation for each enrollment method to learn more about how to enroll certificates using it.
|
||||
|
||||
- [API](/documentation/platform/pki/enrollment-methods/api): Enroll certificates via API.
|
||||
- [EST](/documentation/platform/pki/enrollment-methods/est): Enroll certificates via EST protocol.
|
||||
@@ -0,0 +1,8 @@
|
||||
---
|
||||
title: "Certificate Enrollment via SCEP"
|
||||
sidebarTitle: "SCEP"
|
||||
---
|
||||
|
||||
<Info>
|
||||
SCEP-based certificate enrollment is currently under development and will be included in a future release.
|
||||
</Info>
|
||||
@@ -1,192 +0,0 @@
|
||||
---
|
||||
title: "External CA"
|
||||
sidebarTitle: "External CA"
|
||||
description: "Learn how to connect External Certificate Authorities with Infisical."
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
In addition to creating a Private CA hierarchy, Infisical allows you to integrate with External Certificate Authorities (CAs) to issue digital certificates for your [subscribers](/documentation/platform/pki/subscribers). This integration enables you to leverage established certificate authority infrastructure while centralizing your certificate management within Infisical.
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
B[Infisical] -->|Manages Certificates| D[Subscribers]
|
||||
|
||||
A1[Public CAs<br>Let's Encrypt, ZeroSSL] -->|ACME Protocol| B
|
||||
A2[Enterprise CAs<br>Vault PKI, Step CA] -->|ACME Protocol| B
|
||||
A3[Cloud CAs<br>ACME-compatible services] -->|ACME Protocol| B
|
||||
|
||||
A4[Future: Enterprise CAs] -.->|EST/SCEP Protocols| B
|
||||
A5[Future: Cloud CAs] -.->|REST APIs| B
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
When you integrate an External CA with Infisical, you benefit from:
|
||||
|
||||
1. **Trust by Default**: Certificates issued by public CAs are trusted by default in browsers and operating systems.
|
||||
2. **Unified Management**: Manage all certificates—both internally and externally issued—from a single platform.
|
||||
3. **Automation**: Leverage Infisical's automation capabilities for certificate lifecycle management.
|
||||
4. **Compliance**: Meet requirements for publicly trusted certificates, especially for public-facing services.
|
||||
5. **Flexibility**: Choose the most appropriate CA for different use cases while maintaining consistent management.
|
||||
|
||||
## General Workflow
|
||||
|
||||
A typical workflow for integrating an External CA with Infisical consists of the following steps:
|
||||
|
||||
1. **Select External CA Type**: Choose the appropriate external CA based on your requirements and supported protocols.
|
||||
2. **Configure Prerequisites**: Set up any required credentials, connections, or configurations specific to your chosen CA type.
|
||||
3. **Register External CA**: Add the External CA configuration to your Infisical project.
|
||||
4. **Create Subscribers**: Set up subscribers that use the External CA as their issuing authority.
|
||||
5. **Manage Certificate Lifecycle**: Handle certificate issuance, renewal, and revocation through Infisical's unified interface.
|
||||
|
||||
The specific steps and requirements vary depending on the External CA type you choose to integrate.
|
||||
|
||||
## Supported Integration Methods
|
||||
|
||||
Infisical currently supports integration with External Certificate Authorities through the following protocol:
|
||||
|
||||
### ACME Protocol Integration
|
||||
|
||||
ACME (Automatic Certificate Management Environment) is a widely adopted protocol for automated certificate issuance and management. Infisical can integrate with any CA that supports the ACME protocol, including:
|
||||
|
||||
**Public Certificate Authorities:**
|
||||
- Let's Encrypt - Free, automated SSL/TLS certificates
|
||||
- ZeroSSL - Free and premium SSL certificates
|
||||
- Buypass - Norwegian CA with free ACME certificates
|
||||
|
||||
**Enterprise Certificate Authorities:**
|
||||
- HashiCorp Vault PKI - Enterprise secret management with ACME support
|
||||
- Step CA - Open-source certificate authority with ACME
|
||||
|
||||
**Cloud Certificate Authorities:**
|
||||
- Some managed certificate services that support ACME protocol
|
||||
|
||||
[Learn more about ACME integration →](/documentation/platform/pki/acme-ca)
|
||||
|
||||
## Use Cases
|
||||
|
||||
External CA integration is ideal for various scenarios:
|
||||
|
||||
### Public-Facing Services
|
||||
Use publicly trusted CAs for websites and services that need browser compatibility:
|
||||
- Web applications and APIs
|
||||
- Load balancers and CDNs
|
||||
- Public-facing microservices
|
||||
|
||||
### Compliance Requirements
|
||||
Meet specific compliance standards that require certificates from accredited CAs:
|
||||
- PCI DSS compliance
|
||||
- SOC 2 requirements
|
||||
- Industry-specific regulations
|
||||
|
||||
### Hybrid Infrastructure
|
||||
Combine internal and external CAs for different use cases:
|
||||
- Internal services with Private CAs
|
||||
- Public services with External CAs
|
||||
- Development vs. production environments
|
||||
|
||||
### Legacy System Integration
|
||||
Integrate with existing enterprise PKI infrastructure:
|
||||
- Windows Active Directory Certificate Services
|
||||
- Network device management
|
||||
- IoT device provisioning
|
||||
|
||||
## Benefits of Centralized Management
|
||||
|
||||
Managing External CAs through Infisical provides several advantages over direct CA management:
|
||||
|
||||
### Unified Certificate Inventory
|
||||
- Single dashboard for all certificates
|
||||
- Centralized expiration tracking
|
||||
- Cross-CA certificate analytics
|
||||
|
||||
### Automated Lifecycle Management
|
||||
- Automatic certificate reissuance before expiration
|
||||
- Proactive expiration alerts
|
||||
- Standardized certificate management processes
|
||||
|
||||
### Enhanced Security
|
||||
- Centralized access controls
|
||||
- Audit trails for all certificate operations
|
||||
- Policy enforcement across CAs
|
||||
|
||||
### Operational Efficiency
|
||||
- Reduced manual certificate management
|
||||
- Consistent deployment workflows
|
||||
- API-driven automation
|
||||
- Integration with existing tools
|
||||
|
||||
## Available Integration Guides
|
||||
|
||||
Get started with External CA integration:
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="ACME Protocol Integration" icon="certificate" href="/documentation/platform/pki/acme-ca">
|
||||
Set up automated certificate issuance with any ACME-compatible CA
|
||||
</Card>
|
||||
<Card title="API Integrations" icon="code" color="#gray">
|
||||
Custom CA integrations via REST APIs (Coming Soon)
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Which External CAs does Infisical currently support?">
|
||||
Currently, Infisical supports any Certificate Authority that implements the ACME protocol, including:
|
||||
|
||||
- **Public CAs**: Let's Encrypt, ZeroSSL, Buypass
|
||||
- **Enterprise CAs**: HashiCorp Vault PKI, Step CA
|
||||
- **Cloud CAs**: ACME-compatible managed services
|
||||
|
||||
Integration uses DNS-01 validation through Route53 or Cloudflare. Learn more about [supported DNS validation methods](/documentation/platform/pki/acme-ca#what-dns-validation-methods-are-supported).
|
||||
|
||||
Support for additional integration protocols (EST, SCEP, direct APIs) is planned for future releases.
|
||||
</Accordion>
|
||||
<Accordion title="Can I use both Private CAs and External CAs in the same project?">
|
||||
Yes. You can have both Private CAs (root and intermediate) and External CAs in the same project, allowing you flexibility in how you issue certificates for different use cases. This hybrid approach enables you to:
|
||||
|
||||
- Use Private CAs for internal services and applications
|
||||
- Use External CAs for public-facing services
|
||||
- Apply consistent management practices across all certificate types
|
||||
- Implement appropriate security controls based on certificate usage
|
||||
</Accordion>
|
||||
<Accordion title="What types of certificates can I issue through External CAs?">
|
||||
The types of certificates you can issue depend on the External CA provider and type:
|
||||
|
||||
- **Public CAs**: Typically support Domain Validation (DV) certificates, with some offering Organization Validation (OV)
|
||||
- **Enterprise CAs**: Support internal certificates, device certificates, and custom certificate types
|
||||
- **Cloud CAs**: Support various certificate types depending on the service
|
||||
|
||||
Certificate capabilities vary by provider and integration method.
|
||||
</Accordion>
|
||||
<Accordion title="How does certificate renewal work with External CAs?">
|
||||
Certificate reissuance is handled automatically by Infisical based on the CA type:
|
||||
|
||||
- **Public CAs**: Automatic reissuance using ACME protocol with the same certificate extensions before expiration
|
||||
- **Other CA types**: Certificate management methods depend on the specific integration (when available)
|
||||
|
||||
All certificate lifecycle events are tracked and managed through Infisical's unified interface, ensuring continuous certificate validity.
|
||||
</Accordion>
|
||||
<Accordion title="What authentication methods are supported for External CAs?">
|
||||
Authentication methods vary by CA type:
|
||||
|
||||
- **Public CAs**: ACME account registration with email and account keys
|
||||
- **Enterprise CAs**: Client certificates, username/password, or domain authentication (when available)
|
||||
- **Cloud CAs**: API keys, OAuth tokens, or service account authentication (when available)
|
||||
|
||||
Infisical securely stores and manages all authentication credentials.
|
||||
</Accordion>
|
||||
<Accordion title="Can I enforce policies on certificates from External CAs?">
|
||||
Yes, Infisical provides policy enforcement capabilities:
|
||||
|
||||
- Certificate template constraints
|
||||
- Monitoring and alerting policies
|
||||
- Access controls for certificate operations
|
||||
|
||||
These policies ensure consistent governance across both internal and external certificate sources.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
@@ -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.
|
||||
|
||||
@@ -4,10 +4,16 @@ sidebarTitle: "Overview"
|
||||
description: "Learn how to create a Private CA hierarchy and issue X.509 certificates."
|
||||
---
|
||||
|
||||
Infisical can be used to create and manage Certificate Authorities (CAs) and issue X.509 certificates. This allows you to manage PKI infrastructure and issue digital certificates for subscribers such as services, applications, and devices.
|
||||
Infisical can be used to create and manage Certificate Authorities (CAs) and issue digital X.509 certificates. This allows you to manage PKI infrastructure and issue certificates for end-entities such as load balancers, web servers, devices, and more.
|
||||
|
||||
Infisical's PKI offering is split into three components:
|
||||
It helps teams automate certificate management including enrollment and renewal, and adopt secure workflows to ensure certificates remain valid, trusted, and synchronized across infrastructure.
|
||||
|
||||
- [Certificate Authorities](/documentation/platform/pki/private-ca): Create and manage CAs, including root and intermediate CAs.
|
||||
- [Subscribers](/documentation/platform/pki/subscribers): Define and manage entities that will request X.509 certificates from CAs. This module provides a centralized view of all subscribers, enabling you to issue certificates and monitor their status.
|
||||
- [Certificates](/documentation/platform/pki/certificates): Track and monitor issued X.509 certificates, maintaining a comprehensive inventory of all active and expired certificates.
|
||||
Core capabilities include:
|
||||
|
||||
- [Private CA](/documentation/platform/pki/ca/private-ca): Create and manage your own private CA hierarchy including root and intermediate CAs.
|
||||
- [External CA integration](/documentation/platform/pki/ca/external-ca): Integrate with external public and private CAs including [Azure ADCS](/documentation/platform/pki/ca/azure-adcs) and [ACME-compatible CAs](/documentation/platform/pki/ca/acme-ca) like Let's Encrypt and DigiCert.
|
||||
- [Certificate Enrollment](/documentation/platform/pki/enrollment-methods/overview): Support enrollment methods including [API](/documentation/platform/pki/enrollment-methods/api), ACME, [EST](/documentation/platform/pki/enrollment-methods/est), and more to automate certificate issuance for services, devices, and workloads.
|
||||
- Certificate Inventory: Track and monitor issued X.509 certificates, maintaining a comprehensive inventory of all active and expired certificates.
|
||||
- Certificate Lifecycle Automation: Automate issuance, [renewal](/documentation/platform/pki/certificates/certificates#guide-to-renewing-certificates), and [revocation](/documentation/platform/pki/certificates/certificates#guide-to-revoking-certificates) with policy-based workflows, ensuring certificates remain valid, compliant, and up to date across your infrastructure.
|
||||
- [Certificate Syncs](/documentation/platform/pki/certificate-syncs/overview): Push certificates to cloud certificate managers like [AWS Certificate Manager](/documentation/platform/pki/certificate-syncs/aws-certificate-manager) and [Azure Key Vault](/documentation/platform/pki/certificate-syncs/azure-key-vault).
|
||||
- [Certificate Alerts](/documentation/platform/pki/alerting): Receive alerts and webhook events for certificate lifecycle changes such as certificate expiration.
|
||||
|
||||
@@ -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"
|
||||
---
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@ title: "Secrets Management"
|
||||
description: "Learn what is secrets management and why it matters for building secure systems."
|
||||
---
|
||||
|
||||
## What is Secret?
|
||||
## What is a Secret?
|
||||
|
||||
A _secret_ is a confidential value used by an application such as database credential, API key, or other configuration.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user