mirror of
https://github.com/Infisical/infisical.git
synced 2026-01-10 07:58:15 -05:00
Merge pull request #4965 from Infisical/request-cert-guide
docs: add guides for requesting certificate via agent, api, and acme
This commit is contained in:
BlackMagiq
@@ -662,7 +662,16 @@
|
||||
"group": "Concepts",
|
||||
"pages": [
|
||||
"documentation/platform/pki/concepts/certificate-mgmt",
|
||||
"documentation/platform/pki/concepts/certificate-lifecycle"
|
||||
"documentation/platform/pki/concepts/certificate-lifecycle",
|
||||
"documentation/platform/pki/concepts/certificate-components"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Guides",
|
||||
"pages": [
|
||||
"documentation/platform/pki/guides/request-cert-agent",
|
||||
"documentation/platform/pki/guides/request-cert-api",
|
||||
"documentation/platform/pki/guides/request-cert-acme"
|
||||
]
|
||||
}
|
||||
]
|
||||
@@ -2482,7 +2491,7 @@
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Infisical PKI",
|
||||
"group": "Certificate Management",
|
||||
"pages": [
|
||||
{
|
||||
"group": "Certificate Authorities",
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: "Certificate Components"
|
||||
description: "Learn the main components for managing certificates with Infisical."
|
||||
---
|
||||
|
||||
## Core Components
|
||||
|
||||
The following resources define how certificates are issued, shaped, and governed in Infisical:
|
||||
|
||||
- [Certificate Authority (CA)](/documentation/platform/pki/ca/overview): The trusted entity that issues X.509 certificates. This can be an [Internal CA](/documentation/platform/pki/ca/private-ca) or an [External CA](/documentation/platform/pki/ca/external-ca) in Infisical.
|
||||
The former represents a fully managed CA hierarchy within Infisical, while the latter represents an external CA (e.g. [DigiCert](/documentation/platform/pki/ca/digicert), [Let's Encrypt](/documentation/platform/pki/ca/lets-encrypt), [Microsoft AD CS](/documentation/platform/pki/ca/azure-adcs), etc.) that can be integrated with Infisical.
|
||||
|
||||
- [Certificate Template](/documentation/platform/pki/certificates/templates): A policy structure specifying permitted attributes for requested certificates. This includes constraints around subject naming conventions, SAN fields, key usages, and extended key usages.
|
||||
|
||||
- [Certificate Profile](/documentation/platform/pki/certificates/profiles): A configuration set specifying how leaf certificates should be issued for a group of end-entities including the issuing CA, a certificate template, and the enrollment method (e.g. [ACME](/documentation/platform/pki/enrollment-methods/acme), [EST](/documentation/platform/pki/enrollment-methods/est), [API](/documentation/platform/pki/enrollment-methods/api), etc.) used to enroll certificates.
|
||||
|
||||
- [Certificate](/documentation/platform/pki/certificates/certificates): The actual X.509 certificate issued for a profile. Once created, it is tracked in Infisical’s certificate inventory for management, renewal, and lifecycle operations.
|
||||
|
||||
## Access Control
|
||||
|
||||
Access control defines who (or what) can manage certificate resources and who can issue certificates within a project. Without clear boundaries, [certificate authorities](/documentation/platform/pki/ca/overview) and issuance workflows can be misconfigured or misused.
|
||||
|
||||
To manage access to certificates, you assign role-based permissions at the project level. These permissions determine which certificate authorities, certificate templates, certificate profiles, and other related resources a user or machine identity can act on. For example,
|
||||
you may want to:
|
||||
|
||||
- Have specific teams(s) manage your internal CA hierarchy or external CA integration configuration and have separate team(s) configure certificate profiles for requested certificates.
|
||||
- Limit which teams can manage policies defined on certificate templates.
|
||||
- Have specific end-entities (e.g. servers, devices, users) request certificates from specific certificate profiles.
|
||||
|
||||
This model follows the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) so that each user or machine identity can manage or issue only the certificate resources it is responsible for and nothing more.
|
||||
@@ -9,7 +9,7 @@ A (digital) _certificate_ is a file that is tied to a cryptographic key pair and
|
||||
|
||||
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.
|
||||
Certificates contain information about the subject (who it identifies), the public key, and a digital signature from the Certificate Authority (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?
|
||||
|
||||
|
||||
@@ -6,7 +6,9 @@ sidebarTitle: "ACME"
|
||||
## Concept
|
||||
|
||||
The ACME enrollment method allows Infisical to act as an ACME server. It lets you request and manage certificates against a specific [certificate profile](/documentation/platform/pki/certificates/profiles) using the [ACME protocol](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment).
|
||||
This method is suitable for web servers, load balancers, and other general-purpose servers that can run an [ACME client](https://letsencrypt.org/docs/client-options/) for automated certificate management.
|
||||
|
||||
This method is suitable for web servers, load balancers, and other general-purpose servers that can run an [ACME client](https://letsencrypt.org/docs/client-options/) for automated certificate management;
|
||||
it can also be used with [cert-manager](https://cert-manager.io/) to issue and renew certificates for Kubernetes workloads through the [ACME issuer type](https://cert-manager.io/docs/configuration/acme/).
|
||||
|
||||
Infisical's ACME enrollment method is based on [RFC 8555](https://datatracker.ietf.org/doc/html/rfc8555/).
|
||||
|
||||
|
||||
@@ -149,9 +149,6 @@ Here, select the certificate profile from step 1 that will be used to issue the
|
||||
|
||||
<Note>
|
||||
Note: If the certificate is available to be issued immediately, the `certificate` field in the response will contain the certificate data. If issuance is delayed (for example, due to pending approval or additional processing), the `certificate` field will be `null` and you can use the `certificateRequestId` to poll for status or retrieve the certificate when it is ready using the [Get Certificate Request](/api-reference/endpoints/certificates/certificate-request) API endpoint.
|
||||
|
||||
Also be sure to store the `privateKey` as it is only returned once here at the time of certificate issuance. The `certificate` and `certificateChain` will remain accessible and can be retrieved at any time.
|
||||
|
||||
</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 same [Issue Certificate](/api-reference/endpoints/certificates/create-certificate) API endpoint.
|
||||
|
||||
108
docs/documentation/platform/pki/guides/request-cert-acme.mdx
Normal file
108
docs/documentation/platform/pki/guides/request-cert-acme.mdx
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: "Obtain a Certificate via ACME"
|
||||
---
|
||||
|
||||
import RequestCertSetup from "/snippets/documentation/platform/pki/guides/request-cert-setup.mdx";
|
||||
|
||||
The [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme) lets any [ACME client](https://letsencrypt.org/docs/client-options/) obtain TLS certificates from Infisical using the [ACME protocol](https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment).
|
||||
This includes ACME clients like [Certbot](https://certbot.eff.org/), [cert-manager](https://cert-manager.io/) in Kubernetes using the [ACME issuer type](https://cert-manager.io/docs/configuration/acme/), and more.
|
||||
|
||||
Infisical currently supports the [HTTP-01 challenge type](https://letsencrypt.org/docs/challenge-types/#http-01-challenge) for domain validation as part of the ACME enrollment method.
|
||||
|
||||
## Diagram
|
||||
|
||||
The following sequence diagram illustrates the certificate enrollment workflow for requesting a certificate via ACME from Infisical.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant ACME as ACME Client
|
||||
participant Infis as Infisical ACME Server
|
||||
participant Authz as HTTP-01 Challenge<br/>Validation Endpoint
|
||||
participant CA as CA<br/>(Internal or External)
|
||||
|
||||
Note over ACME: ACME Client discovers<br/>Infisical ACME Directory URL
|
||||
|
||||
ACME->>Infis: GET /directory
|
||||
Infis-->>ACME: Directory + nonce + endpoints
|
||||
|
||||
ACME->>Infis: HEAD /new-nonce
|
||||
Infis-->>ACME: Return nonce in Replay-Nonce header
|
||||
|
||||
ACME->>Infis: POST /new-account<br/>(contact, ToS agreed)
|
||||
Infis-->>ACME: Return account object
|
||||
|
||||
Note over ACME,Infis: Requesting a certificate
|
||||
|
||||
ACME->>Infis: POST /new-order<br/>(identifiers: DNS names)
|
||||
Infis-->>ACME: Return order<br/>with authorization URLs
|
||||
|
||||
loop For each authorization (one per DNS name)
|
||||
ACME->>Infis: POST /authorizations/:authzId
|
||||
Infis-->>ACME: Return HTTP-01 challenge<br/>(URL + token + keyAuth)
|
||||
|
||||
Note over ACME: Client must prove control<br/>over the domain via HTTP
|
||||
|
||||
ACME->>Authz: Provision challenge response<br/>at<br/>/.well-known/acme-challenge/<token>
|
||||
|
||||
ACME->>Infis: POST /authorizations/:authzId/challenges/:challengeId<br/>(trigger validation)
|
||||
|
||||
Infis->>Authz: HTTP GET /.well-known/acme-challenge/<token>
|
||||
Authz-->>Infis: Return keyAuth
|
||||
|
||||
Infis-->>ACME: Authorization = valid
|
||||
end
|
||||
|
||||
Note over Infis: All authorizations valid → ready to finalize
|
||||
|
||||
ACME->>ACME: Generate keypair locally<br/>and create CSR
|
||||
ACME->>Infis: POST /orders/:orderId/finalize<br/>(CSR)
|
||||
|
||||
Infis->>CA: Request certificate issuance<br/>(CSR)
|
||||
CA-->>Infis: Signed certificate (+ chain)
|
||||
|
||||
Infis-->>ACME: Return order with certificate URL<br/>(status: valid)
|
||||
|
||||
ACME->>Infis: POST /orders/:orderId/certificate
|
||||
Infis-->>ACME: Return certificate<br/>and certificate chain
|
||||
```
|
||||
|
||||
## Guide
|
||||
|
||||
In the following steps, we explore an end-to-end workflow for obtaining a certificate via ACME with Infisical.
|
||||
|
||||
<Steps>
|
||||
<RequestCertSetup />
|
||||
<Step title="Create a certificate profile">
|
||||
Next, follow the guide [here](/documentation/platform/pki/certificates/profiles#guide-to-creating-a-certificate-profile) to create a [certificate profile](/documentation/platform/pki/certificates/profiles)
|
||||
that will be referenced when requesting a certificate.
|
||||
|
||||
The certificate profile specifies which certificate template and issuing CA should be used to validate an incoming certificate request and issue a certificate;
|
||||
it also specifies the [enrollment method](/documentation/platform/pki/enrollment-methods/overview) for how certificates can be requested against this profile
|
||||
to begin with.
|
||||
|
||||
You should specify the certificate template from Step 2, the issuing CA from Step 1, and the **ACME** option in the **Enrollment Method** dropdown when creating the certificate profile.
|
||||
|
||||
</Step>
|
||||
<Step title="Request a certificate">
|
||||
Finally, follow the guide [here](/documentation/platform/pki/enrollment-methods/acme#guide-to-certificate-enrollment-via-acme) to request a certificate against the certificate profile
|
||||
using an [ACME client](https://letsencrypt.org/docs/client-options/).
|
||||
|
||||
The ACME client will connect to Infisical's ACME server at the **ACME Directory URL** and authenticate using the **EAB Key Identifier (KID)** and **EAB Secret** credentials as part of the ACME protocol.
|
||||
|
||||
The typical ACME workflow looks likes this:
|
||||
|
||||
- The ACME client creates (or reuses) an ACME account with Infisical using EAB credentials.
|
||||
- The ACME client creates an order for one or more DNS names.
|
||||
- For each DNS name, the ACME client receives an `HTTP-01` challenge and provisions the corresponding token response at `/.well-known/acme-challenge/<token>`.
|
||||
- Once all authorizations are valid, the ACME client finalizes the order by sending a CSR to Infisical.
|
||||
- Infisical issues the certificate from the issuing CA on the certificate profile and returns it (plus the chain) back to the ACME client.
|
||||
|
||||
ACME clients typically handle renewal by tracking certificate expiration and completing the lifecycle once again to request a new certificate.
|
||||
|
||||
<Note>
|
||||
We recommend reading more about the ACME protocol [here](https://letsencrypt.org/how-it-works/).
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: "Request a Certificate via the Infisical Agent"
|
||||
---
|
||||
|
||||
import RequestCertSetup from "/snippets/documentation/platform/pki/guides/request-cert-setup.mdx";
|
||||
|
||||
The [Infisical Agent](/integrations/platforms/certificate-agent) is an installable client daemon that can request TLS and other X.509 certificates from Infisical using the [API enrollment method](/documentation/platform/pki/enrollment-methods/api) configured on a [certificate profile](/documentation/platform/pki/certificates/profiles), persist it to a specified path on the filesystem, and automatically monitor and renew it before expiration.
|
||||
|
||||
Instead of [manually requesting](/documentation/platform/pki/guides/request-cert-api) and renewing a certificate via the [Issue Certificate](/api-reference/endpoints/certificates/create-certificate) API endpoint, you can install and launch the Infisical Agent to have it perform these steps for you automatically.
|
||||
|
||||
## Diagram
|
||||
|
||||
The following sequence diagram illustrates the certificate enrollment workflow for requesting a certificate using the Infisical Agent from Infisical.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant Agent as Infisical Agent
|
||||
participant Infis as Infisical
|
||||
participant CA as CA<br/>(Internal or External)
|
||||
|
||||
Agent->>Infis: Request certificate<br/>(profileId, conditional subject/SANs, ttl,<br/>key usages, conditional CSR, etc.)
|
||||
|
||||
Infis->>Infis: Look up certificate profile<br/>(by profileId)
|
||||
Infis->>Infis: Validate request<br/>against profile constraints<br/>(CN/SAN rules, key usages, max TTL, etc.)
|
||||
|
||||
alt Issuer Type = Self-Signed
|
||||
Infis->>Infis: Generate keypair<br/>and self-sign certificate
|
||||
else Issuer Type = Internal CA
|
||||
Infis->>CA: Request certificate issuance
|
||||
CA-->>Infis: Signed certificate<br/>(+ chain)
|
||||
end
|
||||
|
||||
Infis-->>Agent: Return certificate, certificate chain,<br/>(and private key if server-generated)
|
||||
|
||||
Note over Agent: Persist certificate and begin lifecycle monitoring
|
||||
|
||||
loop Periodic certificate status check
|
||||
Agent->>Agent: Check certificate expiration<br/>against renew-before-expiry threshold
|
||||
|
||||
alt Renewal not required
|
||||
Agent-->>Agent: Continue monitoring
|
||||
else Renewal required
|
||||
Agent->>Infis: Request new certificate<br/>(same profile and constraints)
|
||||
|
||||
Infis->>Infis: Validate renewal request<br/>against profile constraints
|
||||
|
||||
alt Issuer Type = Self-Signed
|
||||
Infis->>Infis: Generate keypair<br/>and self-sign certificate
|
||||
else Issuer Type = Internal CA
|
||||
Infis->>CA: Request certificate issuance
|
||||
CA-->>Infis: Signed certificate<br/>(+ chain)
|
||||
end
|
||||
|
||||
Infis-->>Agent: Return renewed certificate, certificate chain, and private key
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
## Guide
|
||||
|
||||
In the following steps, we explore an end-to-end workflow for requesting and continuously renewing a certificate using the Infisical Agent.
|
||||
|
||||
<Steps>
|
||||
<RequestCertSetup />
|
||||
<Step title="Create a certificate profile">
|
||||
Next, follow the guide [here](/documentation/platform/pki/certificates/profiles#guide-to-creating-a-certificate-profile) to create a [certificate profile](/documentation/platform/pki/certificates/profiles)
|
||||
that will be referenced when requesting a certificate.
|
||||
|
||||
The certificate profile specifies which certificate template and issuing CA should be used to validate an incoming certificate request and issue a certificate;
|
||||
it also specifies the [enrollment method](/documentation/platform/pki/enrollment-methods/overview) for how certificates can be requested against this profile
|
||||
to begin with.
|
||||
|
||||
You should specify the certificate template from Step 2, the issuing CA from Step 1, and the **API** option in the **Enrollment Method** dropdown when creating the certificate profile.
|
||||
|
||||
<Note>
|
||||
Note that if you're looking to issue self-signed certificates, you should select the **Self-Signed** option in the **Issuer Type** dropdown when creating the certificate profile.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Request a certificate">
|
||||
Next, [install the Infisical CLI](/cli/overview) on the target machine you wish to request the certificate on and follow the documentation [here](/integrations/platforms/certificate-agent#operating-the-agent) to set up the Infisical Agent on it.
|
||||
|
||||
As part of the setup, you must create an [agent configuration file](/integrations/platforms/certificate-agent#agent-configuration) that specifies how the agent should authenticate with Infisical using a [machine identity](/documentation/platform/identities/machine-identities), the certificate profile it should request against (from Step 3), what kind of certificate to request, where to persist the certificate, and how it should be managed in terms of auto-renewal.
|
||||
|
||||
Finally, start the agent with that configuration file so it can start requesting and continuously renewing the certificate on your behalf using the command below:
|
||||
|
||||
```bash
|
||||
infisical cert-manager agent --config /path/to/your/agent-config.yaml
|
||||
```
|
||||
|
||||
The certificate, certificate chain, and private key will be persisted to the filesystem at the paths specified in the `file-output` section of the agent configuration file.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
79
docs/documentation/platform/pki/guides/request-cert-api.mdx
Normal file
79
docs/documentation/platform/pki/guides/request-cert-api.mdx
Normal file
@@ -0,0 +1,79 @@
|
||||
---
|
||||
title: "Request a Certificate via API"
|
||||
---
|
||||
|
||||
import RequestCertSetup from "/snippets/documentation/platform/pki/guides/request-cert-setup.mdx";
|
||||
|
||||
The [API enrollment method](/documentation/platform/pki/enrollment-methods/api) lets you programmatically request TLS and other X.509 certificates from Infisical.
|
||||
|
||||
This is the most flexible way to request certificates from Infisical but requires you to implement certificate request and renewal logic on your own.
|
||||
For a more automated way to request certificates, we highly recommend you check out the guide for requesting certificates using the [Infisical Agent](/integrations/platforms/certificate-agent) [here](/documentation/platform/pki/guides/request-cert-agent).
|
||||
|
||||
## Diagram
|
||||
|
||||
The following sequence diagram illustrates the certificate issuance workflow for requesting a certificate via API from Infisical.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
participant Client as Client
|
||||
participant Infis as Infisical
|
||||
participant CA as CA<br/>(Internal or External)
|
||||
|
||||
Client->>Infis: POST /certificate<br/>(profileId, conditional subject/SANs, ttl,<br/>key usages, conditional CSR, etc.)
|
||||
|
||||
Infis->>Infis: Look up certificate profile<br/>(by profileId)
|
||||
Infis->>Infis: Validate request or CSR<br/>against profile constraints<br/>(CN/SAN rules, key usages, max TTL, etc.)
|
||||
|
||||
alt Issuer Type = Self-Signed
|
||||
Infis->>Infis: Generate keypair<br/>and self-sign certificate
|
||||
else Issuer Type = CA
|
||||
Infis->>CA: Request certificate issuance<br/>(CSR)
|
||||
CA-->>Infis: Signed certificate<br/>(+ chain)
|
||||
end
|
||||
|
||||
Infis-->>Client: Return certificate, certificate chain,<br/>issuing CA certificate, serial number,<br/>certificate ID<br/>(and private key if server-generated)<br /> OR certificate request ID if async
|
||||
```
|
||||
|
||||
## Guide
|
||||
|
||||
In the following steps, we explore an end-to-end workflow for requesting a certificate via API from Infisical.
|
||||
|
||||
<Steps>
|
||||
<RequestCertSetup />
|
||||
<Step title="Create a certificate profile">
|
||||
Next, follow the guide [here](/documentation/platform/pki/certificates/profiles#guide-to-creating-a-certificate-profile) to create a [certificate profile](/documentation/platform/pki/certificates/profiles)
|
||||
that will be referenced when requesting a certificate.
|
||||
|
||||
The certificate profile specifies which certificate template and issuing CA should be used to validate an incoming certificate request and issue a certificate;
|
||||
it also specifies the [enrollment method](/documentation/platform/pki/enrollment-methods/overview) for how certificates can be requested against this profile
|
||||
to begin with.
|
||||
|
||||
You should specify the certificate template from Step 2, the issuing CA from Step 1, and the **API** option in the **Enrollment Method** dropdown when creating the certificate profile.
|
||||
|
||||
<Note>
|
||||
Note that if you're looking to issue self-signed certificates, you should select the **Self-Signed** option in the **Issuer Type** dropdown when creating the certificate profile.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Request a certificate">
|
||||
Finally, follow the guide [here](/documentation/platform/pki/enrollment-methods/api#guide-to-certificate-enrollment-via-api) to request a certificate against the certificate profile
|
||||
over the Web UI or by making an API request the [Issue Certificate](/api-reference/endpoints/certificates/create-certificate) API endpoint with or without a certificate signing request (CSR).
|
||||
|
||||
To renew a certificate on the client-side, you have two options:
|
||||
|
||||
- Make a request to issue a new certificate against the same [Issue Certificate](/api-reference/endpoints/certificates/create-certificate) API endpoint.
|
||||
- Make a request to the [Renew Certificate](/api-reference/endpoints/certificates/renew) API endpoint with the ID of the certificate you wish to renew. Note that this endpoint only works if the original certificate was issued through the [Issue Certificate](/api-reference/endpoints/certificates/issue-certificate) API endpoint without a CSR.
|
||||
|
||||
<Note>
|
||||
We recommend reading the guide [here](/documentation/platform/pki/certificates/certificates#guide-to-renewing-certificates) to learn more about all the ways to renew a certificate
|
||||
with Infisical including [server-driven certificate renewal](/documentation/platform/pki/certificates/certificates#server-driven-certificate-renewal).
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
Note that depending on your environment and infrastructure use-case, you may wish to use a different [enrollment method](/documentation/platform/pki/enrollment-methods/overview) to request certificates.
|
||||
|
||||
For more automated certificate management, you may wish to request certificates using a client that can monitor expiring certificates and request renewals for you.
|
||||
For example, you can install the Infisical Agent on a VM and have it request and renew certificates for you or use an [ACME client](https://letsencrypt.org/docs/client-options/) paired with Infisical's [ACME enrollment method](/documentation/platform/pki/enrollment-methods/acme).
|
||||
@@ -0,0 +1,27 @@
|
||||
<Step title="Configure a Certificate Authority">
|
||||
Before you can issue any certificate, you must first configure a [Certificate Authority (CA)](/documentation/platform/pki/ca/overview).
|
||||
|
||||
The CA you configure will be used to issue the certificate back to your client; it can be either Internal or External:
|
||||
|
||||
- [Internal CA](/documentation/platform/pki/ca/private-ca): If you're building your own PKI and wish to issue certificates for internal use, you should
|
||||
follow the guide [here](/documentation/platform/pki/ca/private-ca#guide-to-creating-a-ca-hierarchy) to create at minimum a root CA and an intermediate/issuing CA
|
||||
within Infisical.
|
||||
|
||||
- [External CA](/documentation/platform/pki/ca/external-ca): If you have existing PKI infrastructure or wish to connect to a public CA (e.g. [Let's Encrypt](/documentation/platform/pki/ca/lets-encrypt), [DigiCert](/documentation/platform/pki/ca/digicert), etc.) to issue TLS certificates,
|
||||
you should follow the documentation [here](/documentation/platform/pki/ca/external-ca) to configure an External CA.
|
||||
|
||||
<Note>
|
||||
Note that if you're looking to issue self-signed certificates, you can skip this step and proceed to Step 3.
|
||||
</Note>
|
||||
|
||||
</Step>
|
||||
<Step title="Create a certificate template">
|
||||
Next, follow the guide [here](/documentation/platform/pki/certificates/templates#guide-to-creating-a-certificate-template) to create a [certificate template](/documentation/platform/pki/certificates/templates).
|
||||
|
||||
The certificate template will constrain what attributes may or may not be allowed in the request to issue a certificate.
|
||||
For example, you can specify that the requested common name must adhere to a specific format like `*.acme.com` and
|
||||
that the maximum TTL cannot exceed 1 year.
|
||||
|
||||
If you're looking to issue TLS server certificates, you should select the **TLS Server Certificate** option under the **Template Preset** dropdown.
|
||||
|
||||
</Step>
|
||||
Reference in New Issue
Block a user