Internal CA

Build your Internal PKI through a Private Certificate Authority (CA) hierarchy. This allows you to issue and manage X.509 certificates for internal services without relying on external CAs.

This page is for product admins setting up PKI infrastructure. Teams issuing certificates should see Applications.

How it works

Create a Root CA — Or use an existing external root CA
Create Intermediate CA(s) — Chain them to your root CA
Create Certificate Profiles — Link CAs to policies for teams to use
Create Applications — Assign profiles to Applications for teams

You can execute this workflow via the UI or API. For API workflows, you may need to create CSRs and import certificates manually.

Create a CA hierarchy

Create a simple Private CA hierarchy with a root CA and intermediate CA.

Infisical UI
API

Create a root CA

If you have an existing external root CA, skip to step 2.Go to Certificate Manager → Certificate Authorities → Internal and click Create CA.Set the CA Type to Root and fill out details for the root CA:

Valid Until: The date until which the CA is valid in the date time string format specified here. 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.
Key Source: Where the CA’s signing key is generated and stored. Infisical (the default) generates and manages the key for you. HSM generates the key inside your own Hardware Security Module through an HSM Connector, and every signing operation the CA performs runs on the HSM. See HSM-backed Internal CAs below. AWS KMS creates the key in your AWS account, and every signing operation runs in AWS KMS.
HSM Connector: The HSM Connector Infisical uses to reach your HSM. Shown only when Key Source is HSM. With an HSM key source the algorithm choices stay limited to RSA 2048, RSA 4096, ECDSA P-256, and ECDSA P-384.
AWS Connection: The AWS connection used to create the key and sign with it. Shown only when Key Source is AWS KMS.
Region: The AWS region to create the key in. Shown only when Key Source is AWS KMS.
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.

The Organization, Country, State or Province Name, Locality Name, and Common Name make up the Distinguished Name (DN) or subject of the CA. At least one of these fields must be filled out.

Creating an intermediate CA

To create an intermediate CA, press Create CA again but this time specifying the CA Type to be Intermediate. Fill out the details for the intermediate CA.Next, press the Install CA Certificate option on the intermediate CA. You will be presented with the installation method selector. Choose how the signing certificate should be issued:

Infisical CA
Manual
External CA

Select Infisical CA and press Continue. This option chains the intermediate CA to a root or intermediate CA managed by Infisical.Set the Parent CA to the root CA created in step 1 and configure:

Parent CA: The parent CA to chain to (the root CA from step 1).
Valid Until: Must be within the validity period of the parent CA.
Path Length: Must be less than the parent CA’s path length.

Press Install to chain the intermediate CA to the root CA. This creates a CSR, signs it with the root CA, and imports the certificate.You’ve successfully created a Private CA hierarchy. Now check out the Applications section to learn more about issuing certificates.

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, make an API request to the Create CA API endpoint, specifying the type as root.

Sample request

Request

curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/ca/internal' \
  --header 'Authorization: Bearer <access-token>' \
  --header 'Content-Type: application/json' \
  --data-raw '{
      "type": "root",
      "commonName": "My Root CA"
  }'

Sample response

Response

{
  ca: {
    id: "<root-ca-id>",
    type: "root",
    commonName: "My Root CA",
    ...
  }
}

By default, Infisical creates a root CA with the RSA_2048 key algorithm, validity period of 10 years, with no restrictions on path length; you may override these defaults by specifying your own options when making the API request.

Creating an intermediate CA

To create an intermediate CA, make an API request to the Create CA API endpoint, specifying the type as intermediate.

Sample request

Request

curl --location --request POST ‘https://app.infisical.com/api/v1/cert-manager/ca/internal’ \
  --header ‘Authorization: Bearer <access-token>’ \
  --header ‘Content-Type: application/json’ \
  --data-raw ‘{
      "type": "intermediate",
      "commonName": "My Intermediate CA"
  }’

Sample response

Response

{
  "ca": {
    "id": "<intermediate-ca-id>",
    "type": "intermediate",
    "commonName": "My Intermediate CA"
  }
}

Next, install a certificate for the intermediate CA using one of the following methods:

Infisical CA
Manual
External CA

Get a CSR from the intermediate CA, sign it with the root CA, and import the certificate back.Get the CSR:

Request

curl --location --request GET ‘https://app.infisical.com/api/v1/cert-manager/ca/internal/<intermediate-ca-id>/csr’ \
  --header ‘Authorization: Bearer <access-token>’

Sign the intermediate certificate using the root CA:

Request

curl --location --request POST ‘https://app.infisical.com/api/v1/cert-manager/ca/internal/<root-ca-id>/sign-intermediate’ \
  --header ‘Authorization: Bearer <access-token>’ \
  --header ‘Content-Type: application/json’ \
  --data-raw ‘{
      "csr": "<csr>",
      "notAfter": "2029-06-12"
  }’

The notAfter value must be within the validity period of the root CA.

Import the signed certificate back to the intermediate CA:

Request

curl --location --request POST ‘https://app.infisical.com/api/v1/cert-manager/ca/internal/<intermediate-ca-id>/import-certificate’ \
  --header ‘Authorization: Bearer <access-token>’ \
  --header ‘Content-Type: application/json’ \
  --data-raw ‘{
      "certificate": "<certificate>",
      "certificateChain": "<certificate-chain>"
  }’

You’ve successfully created a Private CA hierarchy. Now check out the Applications page to learn more about issuing certificates.

Get the CSR from the intermediate CA and use it to generate a certificate from your external root CA.Get the CSR:

Request

curl --location --request GET ‘https://app.infisical.com/api/v1/cert-manager/ca/internal/<intermediate-ca-id>/csr’ \
  --header ‘Authorization: Bearer <access-token>’

Use this CSR with your external root CA to generate a signed certificate. Then import the certificate and chain back:

Request

curl --location --request POST ‘https://app.infisical.com/api/v1/cert-manager/ca/internal/<intermediate-ca-id>/import-certificate’ \
  --header ‘Authorization: Bearer <access-token>’ \
  --header ‘Content-Type: application/json’ \
  --data-raw ‘{
      "certificate": "<certificate-from-external-ca>",
      "certificateChain": "<external-root-ca-certificate>"
  }’

You’ve successfully chained an intermediate CA to an external root CA. Now check out the Applications page to learn more about issuing certificates.

HSM-backed internal CAs

By default, Infisical generates and manages the signing key for an Internal CA. You can instead keep the CA’s signing key inside your own Hardware Security Module. When Key Source is set to HSM, Infisical generates the keypair on the HSM through an HSM Connector and performs every signing operation the CA does on the HSM. That covers the self-signed root certificate, intermediate CSRs, the certificates the CA issues, and its CRLs. Both root and intermediate CAs can be HSM-backed. HSM-backed CAs support the RSA 2048, RSA 4096, ECDSA P-256, and ECDSA P-384 key algorithms.

Set up an HSM Connector before creating an HSM-backed CA. Creating one requires the Attach permission on HSM Connectors in addition to permission to create Certificate Authorities.

To create an HSM-backed CA over the API, set keySource to hsm and supply the hsmConnectorId in the request.

Request

curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/ca/internal' \
  --header 'Authorization: Bearer <access-token>' \
  --header 'Content-Type: application/json' \
  --data-raw '{
      "type": "root",
      "commonName": "My HSM Root CA",
      "keyAlgorithm": "ECDSA_P384",
      "keySource": "hsm",
      "hsmConnectorId": "<hsm-connector-id>"
  }'

AWS KMS-backed internal CAs

If your CA’s private key must stay in AWS and you don’t run your own HSM, set Key Source to AWS KMS. The CA’s signing key is then created in AWS KMS through an AWS connection, and the private key never leaves AWS KMS. AWS KMS signs everything the CA produces: the self-signed root certificate, intermediate CSRs, the certificates the CA issues, its CRLs, and its OCSP responses. Both root and intermediate CAs can be AWS KMS-backed. They support the RSA 2048, RSA 3072, RSA 4096, ECDSA P-256, ECDSA P-384, ECDSA P-521, ML-DSA-44, ML-DSA-65, and ML-DSA-87 key algorithms.

Prerequisites

An AWS connection available to Certificate Manager
An IAM policy on the connection’s IAM role or user that lets the connection create KMS keys and sign with them:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["kms:CreateKey", "kms:TagResource", "kms:CreateAlias"],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": ["kms:GetPublicKey", "kms:Sign", "kms:ScheduleKeyDeletion"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:ResourceTag/purpose": "certificate-authority" }
      }
    }
  ]
}

Each CA signing key is created with the author=infisical and purpose=certificate-authority tags, so the second statement only allows signing with and deleting keys created for CAs. Each key also gets an alias named after the CA, such as alias/infisical-ca-kms-root-ca-x7k2p, so you can find it in the AWS KMS console.

Create the CA

In the Create Internal CA wizard, set Key Source to AWS KMS, then choose the AWS Connection, the Region, and the Key Algorithm. The CA’s details page shows the key’s ARN once the CA is created. To create the CA over the API instead, call the endpoint to create an internal CA with keySource set to aws-kms, and include the appConnectionId and region:

Request

curl --location --request POST 'https://app.infisical.com/api/v1/cert-manager/ca/internal' \
  --header 'Authorization: Bearer <access-token>' \
  --header 'Content-Type: application/json' \
  --data-raw '{
      "name": "kms-root-ca",
      "status": "active",
      "configuration": {
        "type": "root",
        "commonName": "My AWS KMS Root CA",
        "keyAlgorithm": "EC_secp384r1",
        "keySource": "aws-kms",
        "appConnectionId": "<aws-connection-id>",
        "region": "us-east-1",
        "notAfter": "2036-01-01"
      }
  }'

The response returns the key’s ARN in configuration.externalKeyId.

Deleting an AWS KMS-backed CA

Deleting the CA schedules its key for deletion in AWS KMS with a 30-day waiting period. If you still need the key, cancel the deletion in AWS KMS within those 30 days, then enable the key again, because AWS KMS leaves a key disabled when you cancel its deletion.

FAQ

What key algorithms are supported?

Infisical supports RSA 2048, RSA 4096, ECDSA P-256, ECDSA P-384 key algorithms specified at the time of creating a CA.

Does Infisical support chaining an Intermediate CA to an external CA?

Yes. You can either manually obtain a CSR and import the signed certificate, or use an integrated external CA provider like Venafi TLS Protect Cloud or Microsoft ADCS to automate the signing process.

Can the CA signing key be kept in my own HSM?

Yes. Set Key Source to HSM when creating the CA and pick an HSM Connector. The keypair is generated on your HSM and every signing operation the CA performs runs there. Both root and intermediate CAs support this. Supported algorithms are RSA 2048, RSA 4096, ECDSA P-256, and ECDSA P-384. See HSM-backed Internal CAs.

Can the CA signing key be kept in AWS KMS?

Yes, including post-quantum ML-DSA keys. Set Key Source to AWS KMS and create the CA through an AWS connection.

What’s next?

CA renewal

Renew your CA certificates before they expire.

CRL distribution

Configure CRL mirrors for high availability.

OCSP

Answer certificate revocation checks in real time.

Post-quantum algorithms

Issue certificates with post-quantum signature algorithms.

Certificate Profiles

Link your CA to a policy and create reusable profiles.

Applications

Set up Applications to issue certificates.

HSM Connectors

Keep the CA signing key inside your own Hardware Security Module.

Get started

Certificate authorities

Managing certificates

Monitoring

Code signing

How it works

Create a CA hierarchy

Sample request

Sample response

Sample request

Sample response

HSM-backed internal CAs

AWS KMS-backed internal CAs

Prerequisites

Create the CA

Deleting an AWS KMS-backed CA

FAQ

What’s next?

CA renewal

CRL distribution

OCSP

Post-quantum algorithms

Certificate Profiles

Applications

HSM Connectors

​How it works

​Create a CA hierarchy

​Sample request

​Sample response

​Sample request

​Sample response

​HSM-backed internal CAs

​AWS KMS-backed internal CAs

​Prerequisites

​Create the CA

​Deleting an AWS KMS-backed CA

​FAQ

​What’s next?

CA renewal

CRL distribution

OCSP

Post-quantum algorithms

Certificate Profiles

Applications

HSM Connectors

How it works

Create a CA hierarchy

Sample request

Sample response

Sample request

Sample response

HSM-backed internal CAs

AWS KMS-backed internal CAs

Prerequisites

Create the CA

Deleting an AWS KMS-backed CA

FAQ

What’s next?