3. Certificates

The basic building block of Web PKI.

A Certificate in CertKit represents the desired state of a TLS certificate. You define the domains (SAN list), the key algorithm, lifetime, and the ACME issuer, and we handle the issuance, renewal, and deployment.

Adding a certificate

Add certificate form
The Add Certificate form with Advanced fields expanded.

You can add up to 10 SANs. The Advanced section contains settings that affect how the certificate is issued and renewed.

Key Algorithm

We default to EC256, which is recommended for most modern environments. For older software or other reasons you might want something different:

Reason Choice
Policy requires a larger curve EC384
Legacy hardware/load balancer only supports RSA RSA2048
Compliance requires 4096-bit RSA RSA4096

Issuer

Defaults to Let’s Encrypt. Any additional configured issuers appear in the dropdown. The choice of issuer determines which Profiles and Challenge Types are available.

Profile

Pick a profile based on your desired certificate lifetime:

  • Default (90-day lifetime) — Standard ACME certificate.
  • Future Proofed (45-day lifetime) — Uses Let’s Encrypt tlsserver profile to issue 45 day certs. If you use these you’ll be ready when 47 day certs drop.
  • Short-Lived (6-day) — Use this to test your automation or if your security policy requires frequent rotations.

Challenge Type

Right now we recomment using DNS-01 as a challenge type. But we do support others.

  • DNS-01 - Uses a CNAME at _acme-challenge.<domain>.
  • DNS-PERSIST (Coming Soon) - Set one TXT record at _acme-persist.<domain> once. This removes DNS from the renewal path entirely. Still being ratified in standards committees.
  • HTTP-01 - Used for single SAN certs. We support this challenge type but don’t recommend it unless you need it for a specific reason. Requires port 80 be open and redirected to CertKit.

Multi-domain certificates

A multi-domain certificate only renews if every SAN validates. If one SAN fails, the entire renewal stalls. For unrelated services, we recommend using separate certificates.

Deployment options

Once we start issuing certificates, you need to deploy them. We recommend using the CertKit agent but there are a number of flexible options depending on your needs.

Option When to use it
CertKit Agent The recommended path. Provides automated deployment and status reporting. See Agents.
Download Manually For one-off use where automation isn’t possible.
S3-Compatible API Useful for integrating with tools like Terraform or config management that already support S3. See the Certificate Explorer.

If your Collection uses a Keystore, private key material is restricted and cannot be downloaded manually.

Removing a Certificate

When you remove a certificate from CertKit, the certificate is not revoked, we simply remove the reference to it from our system. Any systems still using it will continue to function. Effectively you’re breaking the “certificate lineage” by letting it expire naturally.