mirror of
https://github.com/awatertrevi/infisical.git
synced 2026-09-22 13:39:35 +00:00
Merge pull request #3583 from Infisical/feat/acme-and-external-ca
feat: acme and external CA for PKI
This commit is contained in:
Sheen
299
docs/documentation/platform/pki/acme-ca.mdx
Normal file
299
docs/documentation/platform/pki/acme-ca.mdx
Normal file
@@ -0,0 +1,299 @@
|
||||
---
|
||||
title: "Certificates with ACME CA"
|
||||
description: "Learn how to automatically provision and manage TLS certificates using ACME Certificate Authorities like Let's Encrypt with Infisical PKI"
|
||||
---
|
||||
|
||||
## Concept
|
||||
|
||||
The Infisical ACME integration allows you to connect with ACME (Automatic Certificate Management Environment) Certificate Authorities to automatically issue and manage publicly trusted TLS certificates for your [subscribers](/documentation/platform/pki/subscribers). This integration enables you to leverage established public CA infrastructure like Let's Encrypt while centralizing your certificate management within Infisical.
|
||||
|
||||
ACME is a protocol that automates the process of certificate issuance and renewal through domain validation challenges. The integration is perfect for obtaining trusted X.509 certificates for public-facing services and is capable of automatically renewing certificates as needed.
|
||||
|
||||
<div align="center">
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[ACME CA Provider<br>e.g., Let's Encrypt] <-->|ACME v2 Protocol| B[Infisical]
|
||||
B -->|Creates TXT Records<br>via Route53| C[DNS Validation]
|
||||
B -->|Manages Certificates| D[Subscribers]
|
||||
```
|
||||
|
||||
</div>
|
||||
|
||||
As part of the workflow, you configure DNS provider credentials, register an ACME CA provider with Infisical, and create subscribers to represent the certificates you wish to issue. Each issued certificate is automatically managed through its lifecycle, including renewal before expiration.
|
||||
|
||||
We recommend reading about [ACME protocol](https://tools.ietf.org/html/rfc8555) and [DNS-01 challenges](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) for a fuller understanding of the underlying technology.
|
||||
|
||||
## Workflow
|
||||
|
||||
A typical workflow for using Infisical with ACME Certificate Authorities consists of the following steps:
|
||||
|
||||
1. Setting up AWS Route53 credentials with appropriate DNS permissions.
|
||||
2. Creating an AWS connection in Infisical to store the Route53 credentials.
|
||||
3. Registering an ACME Certificate Authority (like Let's Encrypt) with Infisical.
|
||||
4. Creating subscribers that use the ACME CA as their issuing authority.
|
||||
5. Managing certificate lifecycle events such as issuance, renewal, and revocation through Infisical.
|
||||
|
||||
## Understanding ACME DNS-01 Challenge
|
||||
|
||||
The DNS-01 challenge is the method used by ACME CA providers to verify that you control a domain before issuing a certificate. Here's how Infisical handles this process:
|
||||
|
||||
1. **Challenge Request**: When you request a certificate, the ACME provider (like Let's Encrypt) issues a challenge token.
|
||||
|
||||
2. **DNS Record Creation**: Infisical creates a TXT record at `_acme-challenge.<YOUR_DOMAIN>` with a value derived from the challenge token.
|
||||
|
||||
3. **DNS Propagation**: The TXT record must propagate through the DNS system (usually takes a few minutes, depending on TTL settings).
|
||||
|
||||
4. **Validation**: The ACME provider checks for the existence of this TXT record to verify domain control.
|
||||
|
||||
5. **Cleanup**: After validation completes successfully, Infisical automatically removes the TXT record from your DNS.
|
||||
|
||||
This automated process eliminates the need for manual intervention in domain validation, streamlining certificate issuance.
|
||||
|
||||
## Guide
|
||||
|
||||
In the following steps, we explore how to set up ACME Certificate Authority integration with Infisical using Let's Encrypt as an example.
|
||||
|
||||
<Steps>
|
||||
<Step title="Set Up AWS Connection with Required Permissions">
|
||||
Before proceeding with the ACME CA registration, you need to set up an AWS connection with the appropriate permissions for DNS validation:
|
||||
|
||||
1. Navigate to your Organization Settings > App Connections and create a new AWS connection.
|
||||
|
||||
2. Ensure your AWS connection has the following minimum permissions for Route53 DNS validation:
|
||||
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": "route53:GetChange",
|
||||
"Resource": "arn:aws:route53:::change/*"
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": "route53:ListHostedZonesByName",
|
||||
"Resource": "*"
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"route53:ListResourceRecordSets"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:route53:::hostedzone/YOUR_HOSTED_ZONE_ID"
|
||||
]
|
||||
},
|
||||
{
|
||||
"Effect": "Allow",
|
||||
"Action": [
|
||||
"route53:ChangeResourceRecordSets"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:route53:::hostedzone/YOUR_HOSTED_ZONE_ID"
|
||||
],
|
||||
"Condition": {
|
||||
"ForAllValues:StringEquals": {
|
||||
"route53:ChangeResourceRecordSetsRecordTypes": [
|
||||
"TXT"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Replace `YOUR_HOSTED_ZONE_ID` with your actual Route53 hosted zone ID.
|
||||
|
||||
For detailed instructions on setting up an AWS connection, see the [AWS Connection](/integrations/app-connections/aws) documentation.
|
||||
</Step>
|
||||
<Step title="Register ACME Certificate Authority">
|
||||
<Tabs>
|
||||
<Tab title="Infisical UI">
|
||||
<Steps>
|
||||
<Step title="Create ACME CA">
|
||||
To register an ACME CA, head to your Project > Internal PKI > Certificate Authorities and press the **+** button in the External Certificate Authorities section.
|
||||
|
||||
|
||||
|
||||
Fill out the details for the ACME CA registration:
|
||||
|
||||
|
||||
|
||||
Here's guidance on each field:
|
||||
|
||||
- **Type**: Select "ACME" as the External CA type.
|
||||
- **Name**: Enter a name for the ACME CA (e.g., "lets-encrypt-production").
|
||||
- **DNS App Connection**: Select from available DNS app connections or configure a new one. This connection provides Infisical with the credentials needed to create and remove DNS records for ACME validation.
|
||||
- **Hosted Zone ID**: Enter your Route53 hosted zone ID (e.g., Z04044I124N1GOOMCOYX1) for the domain(s) you'll be requesting certificates for.
|
||||
- **Directory URL**: Enter the ACME v2 directory URL for your chosen CA provider (e.g., `https://acme-v02.api.letsencrypt.org/directory` for Let's Encrypt).
|
||||
- **Account Email**: Email address to associate with your ACME account. This email will receive important notifications about your certificates.
|
||||
- **Enable Direct Issuance**: Toggle on to allow direct certificate issuance without requiring subscribers.
|
||||
|
||||
Finally, press **Create** to register the ACME CA with Infisical.
|
||||
</Step>
|
||||
<Step title="Verify ACME CA Registration">
|
||||
Once registered, your ACME CA will appear in the External Certificate Authorities section.
|
||||
|
||||
|
||||
|
||||
From here, you can:
|
||||
|
||||
- View the status of the ACME CA registration
|
||||
- Edit the configuration settings
|
||||
- Disable or re-enable the ACME CA
|
||||
- Delete the ACME CA registration if no longer needed
|
||||
|
||||
You can now use this ACME CA to issue certificates for your subscribers.
|
||||
</Step>
|
||||
</Steps>
|
||||
</Tab>
|
||||
<Tab title="API">
|
||||
To register an ACME CA with Infisical using the API, make a request to the Create External CA endpoint:
|
||||
|
||||
### Sample request
|
||||
|
||||
```bash Request
|
||||
curl 'https://app.infisical.com/api/v1/pki/ca/acme' \
|
||||
-H 'Authorization: Bearer <your-access-token>' \
|
||||
-H 'Content-Type: application/json' \
|
||||
--data-raw '{
|
||||
"projectId": "0fccb6ee-1381-4ff1-8d5f-0cb93c6cc4d6",
|
||||
"name": "lets-encrypt-production",
|
||||
"type": "acme",
|
||||
"status": "active",
|
||||
"enableDirectIssuance": true,
|
||||
"configuration": {
|
||||
"dnsAppConnection": {
|
||||
"id": "1e5f8c0d-09d2-492c-9b28-469acd8e841b",
|
||||
"name": "acme-dns-test-connection"
|
||||
},
|
||||
"dnsProviderConfig": {
|
||||
"provider": "route53",
|
||||
"hostedZoneId": "Z040441124N1GOOMCQYX1"
|
||||
},
|
||||
"directoryUrl": "https://acme-v02.api.letsencrypt.org/directory",
|
||||
"accountEmail": "admin@example.com",
|
||||
"dnsAppConnectionId": "1e5f8c0d-09d2-492c-9b28-469acd8e841b"
|
||||
}
|
||||
}'
|
||||
```
|
||||
|
||||
### Sample response
|
||||
|
||||
```bash Response
|
||||
{
|
||||
"id": "c48b701e-a20c-4a9a-8119-68f54e5fbb05",
|
||||
"name": "lets-encrypt-production",
|
||||
"type": "acme",
|
||||
"status": "active",
|
||||
"projectId": "0fccb6ee-1381-4ff1-8d5f-0cb93c6cc4d6",
|
||||
"enableDirectIssuance": true,
|
||||
"configuration": {
|
||||
"accountEmail": "admin@example.com",
|
||||
"directoryUrl": "https://acme-v02.api.letsencrypt.org/directory",
|
||||
"dnsAppConnection": {
|
||||
"id": "1e5f8c0d-09d2-492c-9b28-469acd8e841b",
|
||||
"name": "acme-dns-test-connection"
|
||||
},
|
||||
"dnsAppConnectionId": "1e5f8c0d-09d2-492c-9b28-469acd8e841b",
|
||||
"dnsProviderConfig": {
|
||||
"provider": "route53",
|
||||
"hostedZoneId": "Z040441124N1GOOMCQYX1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
</Step>
|
||||
<Step title="Create Subscriber for ACME CA">
|
||||
Next, create a subscriber that uses your ACME CA for certificate issuance. Navigate to your Project > Subscribers and create a new subscriber.
|
||||
|
||||
Configure the subscriber with:
|
||||
- **Issuing CA**: Select your registered ACME CA
|
||||
- **Common Name**: The domain for which you want to issue certificates (e.g., `example.com`)
|
||||
- **Alternative Names**: Additional domains to include in the certificate
|
||||
|
||||
Check out the [Subscribers](/documentation/platform/pki/subscribers) page for detailed instructions on creating and managing subscribers.
|
||||
</Step>
|
||||
<Step title="Issue Certificate">
|
||||
Once your subscriber is configured, you can issue certificates either through the Infisical UI or programmatically via the API.
|
||||
|
||||
When you request a certificate:
|
||||
1. Infisical generates a key pair for the certificate
|
||||
2. Sends a Certificate Signing Request (CSR) to the ACME CA
|
||||
3. Receives a DNS-01 challenge from the ACME provider
|
||||
4. Creates a TXT record in Route53 to satisfy the challenge
|
||||
5. Notifies the ACME provider that the challenge is ready for validation
|
||||
6. Once validated, the ACME provider issues the certificate
|
||||
7. Infisical stores and manages the certificate for your subscriber
|
||||
|
||||
The certificate will be automatically renewed before expiration according to your subscriber configuration.
|
||||
</Step>
|
||||
<Step title="Use Certificate in Your Applications">
|
||||
The issued certificate and private key are now available through Infisical and can be:
|
||||
|
||||
- Downloaded directly from the Infisical UI
|
||||
- Retrieved via the Infisical API for programmatic access using the [latest certificate bundle endpoint](/api-reference/endpoints/pki/subscribers/get-latest-cert-bundle)
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Example: Let's Encrypt Integration
|
||||
|
||||
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.
|
||||
</Note>
|
||||
|
||||
## FAQ
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="What DNS validation methods are supported?">
|
||||
Currently, Infisical supports DNS-01 validation through AWS Route53. The DNS-01 challenge method is preferred for ACME integrations because it:
|
||||
|
||||
- Works with wildcard certificates
|
||||
- Doesn't require your servers to be publicly accessible
|
||||
- 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:
|
||||
|
||||
- Encourage automation of certificate management
|
||||
- Reduce the impact of compromised certificates
|
||||
- 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:
|
||||
|
||||
- Different providers for different domains or use cases
|
||||
- Staging and production environments for the same provider
|
||||
- Backup providers for redundancy
|
||||
|
||||
Each subscriber can be configured to use a specific ACME CA based on your requirements.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
192
docs/documentation/platform/pki/external-ca.mdx
Normal file
192
docs/documentation/platform/pki/external-ca.mdx
Normal file
@@ -0,0 +1,192 @@
|
||||
---
|
||||
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. 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>
|
||||
@@ -24,7 +24,7 @@ A[Issuing CA] --> C1[Certificate]
|
||||
|
||||
The typical workflow for managing subscribers consists of the following steps:
|
||||
|
||||
1. Creating a subscriber and defining which (issuing) CA will issue X.509 certificates for it as well as attributes to be included on the certificates including common name, subject alternative names, TLL, etc.
|
||||
1. Creating a subscriber and defining which (issuing) CA will issue X.509 certificates for it as well as attributes to be included on the certificates including common name, subject alternative names, TTL, etc. You can also optionally configure automatic certificate renewal.
|
||||
2. Requesting for a certificate against the subscriber with or without a certificate signing request (CSR).
|
||||
3. Managing certificate lifecycle events such as certificate renewal and revocation. As part of the certificate revocation flow,
|
||||
you can also query for a Certificate Revocation List [CRL](https://en.wikipedia.org/wiki/Certificate_revocation_list), a time-stamped, signed
|
||||
@@ -49,17 +49,32 @@ In the following steps, we explore how to issue a X.509 certificate for a subscr
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The **PKI Subscriber** modal is organized into two tabs:
|
||||
|
||||
### Configuration Tab
|
||||
|
||||
|
||||
|
||||
Here's some guidance on each field.
|
||||
This tab contains the core certificate attributes and settings:
|
||||
|
||||
- Subscriber Name: A slug-friendly name for the subscriber such as `web-service`.
|
||||
- Issuing CA: The Certificate Authority (CA) that will issue X.509 certificates for the subscriber.
|
||||
- Common Name (CN): The common name to be included on certificates to be issued to the subscriber.
|
||||
- Subject Alternative Names (SANs): A comma-delimited list of Subject Alternative Names (SANs) to be included on certificates; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- TTL: The lifetime of the certificate.
|
||||
- Key Usage: The key usage extension of the certificate.
|
||||
- Extended Key Usage: The extended key usage extension of the certificate.
|
||||
- **Subscriber Name**: A slug-friendly name for the subscriber such as `web-service`.
|
||||
- **Issuing CA**: The Certificate Authority (CA) that will issue X.509 certificates for the subscriber.
|
||||
- **Common Name (CN)**: The common name to be included on certificates to be issued to the subscriber.
|
||||
- **Subject Alternative Names (SANs)**: A comma-delimited list of Subject Alternative Names (SANs) to be included on certificates; these can be hostnames or email addresses like `app1.acme.com, app2.acme.com`.
|
||||
- **TTL**: The lifetime of the certificate.
|
||||
- **Key Usage**: The key usage extension of the certificate.
|
||||
- **Extended Key Usage**: The extended key usage extension of the certificate.
|
||||
|
||||
### Advanced Tab
|
||||
|
||||
|
||||
|
||||
This tab contains optional advanced features:
|
||||
|
||||
- **Certificate Auto Renewal**: Toggle to enable automatic certificate renewal for this subscriber.
|
||||
- **Renewal Before Expiry**: When auto renewal is enabled, specify how many days before certificate expiry the system should automatically issue a new certificate (e.g., 7 days).
|
||||
|
||||
<Note>
|
||||
It's possible to issue certificates for a subscriber with or without a certificate signing request (CSR).
|
||||
@@ -68,6 +83,10 @@ In the following steps, we explore how to issue a X.509 certificate for a subscr
|
||||
and a certificate is only issued if they comply.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
When Certificate Auto Renewal is enabled, the system will automatically issue new certificates before the current ones expire, ensuring continuous certificate availability without manual intervention.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Requesting a certificate">
|
||||
Once you have created a subscriber from step 1, you can issue a certificate for it.
|
||||
@@ -123,8 +142,13 @@ openssl verify -verbose -crl_check -crl_download -CAfile chain.pem cert.pem
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="What is the workflow for renewing a certificate?">
|
||||
To renew a certificate, you have to issue a new certificate for the same
|
||||
subscriber. The original certificate will continue to be valid through its
|
||||
original TTL unless explicitly revoked.
|
||||
To renew a certificate, you have two options:
|
||||
|
||||
**Manual Renewal**: Issue a new certificate for the same subscriber. The original certificate will continue to be valid through its original TTL unless explicitly revoked.
|
||||
|
||||
**Automatic Renewal**: If Certificate Auto Renewal is enabled for the subscriber, the system will automatically issue new certificates before the current ones expire based on the configured renewal period.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
<Accordion title="How does Certificate Auto Renewal work?">
|
||||
When Certificate Auto Renewal is enabled for a subscriber, the system monitors certificate expiration dates and automatically issues new certificates before they expire. You can configure how many days before expiry the renewal should occur (e.g., 7 days before expiration). This ensures continuous certificate availability without manual intervention.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
Reference in New Issue
Block a user