Certificates

Overview

Certificates are TLS certificates you manage at the account level, independent of any single load balancer - the same model AWS uses for ACM. You upload a certificate (or issue one from Let's Encrypt) once, and it lives in your account's certificate store. From there you attach it to as many load balancer listeners as you like, on as many load balancers as you like.

The certificate store replaces the older per-load-balancer certificate flow, where each load balancer kept its own separate set of certificates and a listener could only ever carry one. That model made it impossible to serve two unrelated domains, each with its own certificate, from the same :443 port. The account-level store fixes this directly: a listener now holds an ordered list of certificates - one default, plus any number of additional certificates served by SNI (Server Name Indication, the mechanism a browser uses to tell a server which hostname it's asking for before the TLS handshake completes).

Concepts

Term	Plain English
Certificate store	The account-level list of every certificate you own, independent of which load balancer(s) use it.
Default certificate	The certificate a listener serves when the client doesn't send SNI, or when its SNI hostname doesn't match any attached certificate. Always the first certificate in a listener's list.
Additional (SNI) certificate	Any certificate attached to a listener after the default. Served only when the client's SNI hostname matches that certificate's domain or SAN entries.
SAN (Subject Alternative Name)	Extra hostnames a single certificate is valid for, beyond its primary domain (a "multi-domain" certificate).
CA chain	The intermediate certificate(s) that link your certificate back to a trusted root. Required for most certificate authorities other than Let's Encrypt.
Fingerprint	A SHA-256 hash of the certificate, used to detect when the same certificate has been uploaded more than once.
Let's Encrypt	A free certificate authority. The platform can request and auto-renew certificates from it through a load balancer you choose.
Managed by	Whether a certificate was created by you (user) or minted automatically by the Kubernetes load balancer bridge (kubernetes) for a cluster's services. Kubernetes-managed certificates are read-only in the store.
Usage	A record of which load balancer listener(s) currently reference a certificate. A certificate with at least one usage cannot be deleted.

Uploading a certificate

1. Go to Networking > Certificates and click Add Certificate.
2. Choose the Upload Certificate tab.
3. Provide:
   • Name. A label for your own reference.
   • Certificate. The PEM-encoded leaf certificate.
   • Private Key. The PEM-encoded private key for that certificate.
   • CA Chain (optional). Any intermediate certificates your certificate authority issued alongside the leaf.
4. Submit.

The upload is validated before it is stored:

• The private key must match the certificate - if they're not a pair, the upload is rejected.
• If a CA chain is supplied, every block in it must parse, and the chain must actually sign the leaf certificate - an unrelated or incomplete chain is rejected rather than silently accepted.
• An already-expired certificate is rejected outright.

The platform reads the domain, SAN list and expiry date straight out of the certificate you upload, so there's nothing further to fill in.

Each account has a certificate quota (max_certificates, 20 by default) set by your admin. Uploading past the quota is refused; ask your admin to raise it if you need more.

Requesting a Let's Encrypt certificate

1. Go to Networking > Certificates and click Add Certificate.
2. Choose the Let's Encrypt tab.
3. Enter the domain(s) you want the certificate for, and pick which of your load balancers should answer the ACME (Let's Encrypt) HTTP-01 challenge. That load balancer must have a public IP and a port-80 listener; the platform creates a system-managed port-80 block for the challenge automatically if one doesn't already exist.
4. Submit.

If DNS already points at the chosen load balancer, issuance usually completes within a minute or two. If not, the certificate sits in Pending DNS and the platform rechecks periodically for up to 24 hours - point your DNS record at the load balancer and it will pick up on the next check.

Let's Encrypt certificates are valid for 90 days and renew automatically starting 30 days before expiry, reusing the same load balancer you originally chose. If that load balancer is later deleted, the certificate is marked renewal blocked instead of failing renewal silently - pick a different load balancer to resume automatic renewal (currently done by re-requesting the certificate).

Attaching certificates to a load balancer listener

On a load balancer's port configuration (protocol HTTPS), the certificate field is a multi-select of your account's certificates rather than a single dropdown:

1. Open the load balancer and edit (or create) an HTTPS configuration block.
2. In the Certificates field, select one or more certificates from your account's store.
3. The first certificate you select is the listener's default; any others are served by SNI based on the client's requested hostname.
4. Reorder or remove certificates as needed; save the block.

A listener needs at least one certificate to serve HTTPS. Certificates on a cluster-managed (Kubernetes) load balancer cannot be attached or detached from the panel - those listeners are managed by the cluster's load balancer bridge.

Certificate IDs in automation

Every certificate has a stable ID (a UUID), shown - and copyable with one click - in both the user and admin certificate lists. You'll want this ID whenever you're managing certificates outside the panel:

• OpenTofu. The iaas_certificate resource represents an account certificate, and the certificate_ids attribute on iaas_lb_frontend takes an ordered list of these IDs (first = default, rest = SNI) to attach them to a listener declaratively.
• MCP (AI tooling). The MCP server exposes list_certificates, upload_certificate and request_letsencrypt_certificate tools that return and accept the same ID. Deleting a certificate is a destructive operation and is intentionally not exposed as an MCP tool - remove a certificate from the panel or the API instead.
• Kubernetes. Certificates minted by the Kubernetes load balancer bridge for a cluster's control-plane load balancer or a LoadBalancer-type Service appear in your certificate store tagged managed_by: kubernetes, so you can correlate what a cluster provisioned with a specific store entry by matching IDs (for example against the cluster's SSL-certificates API).

note

The old iaas_lb_certificate OpenTofu resource is removed as of provider v0.3.0 in favor of iaas_certificate plus certificate_ids on iaas_lb_frontend. Update any Terraform/OpenTofu configuration that referenced iaas_lb_certificate before upgrading.

Certificate expiry notifications and alerts

• Email notifications. An uploaded certificate approaching expiry sends an email to the account owner so renewal doesn't come as a surprise. Let's Encrypt certificates renew themselves and don't need this reminder.
• Certificate alert rules. Monitoring has a dedicated certificate resource type with days_until_expiry and status metrics, so you can be paged (via any configured notification channel) ahead of expiry rather than finding out when the listener starts failing TLS handshakes. From the Certificates list, the Alert when expiring action opens the alert rule form pre-filled for that certificate - see Monitoring for how alert rules and notification channels work generally.

Deleting a certificate

A certificate in use by one or more listeners cannot be deleted - the delete action is refused with the exact list of load balancers and ports using it, so you know what to detach first. Once it has no usages, delete removes it permanently.

Admin view

Admins see a read-only Certificates tab on a user's account page, listing every certificate the account owns (including Kubernetes-managed ones) along with usage counts. Admins cannot upload or delete certificates on a customer's behalf in this release - that stays a self-service action for the account owner.

Team permissions

Certificates are gated by three permissions a team owner can grant to subusers under Team Management:

Permission	Grants
certificates.view	List certificates and see their usages.
certificates.manage	Upload certificates and request Let's Encrypt certificates.
certificates.delete	Delete certificates that are not in use.

Troubleshooting

Upload is rejected with a key/certificate mismatch error The private key you provided doesn't correspond to the certificate. Re-export both from the same source and confirm you haven't pasted a key from a different certificate or a previous renewal.

Upload is rejected because the chain doesn't sign the certificate The CA chain block(s) you supplied don't form a valid trust path to your certificate. Use the intermediate bundle your certificate authority provides for that specific certificate, not a generic or unrelated chain.

Let's Encrypt certificate is stuck in "Pending DNS" Confirm your domain's A/AAAA (or CNAME) record actually points at the load balancer you chose. The platform rechecks on its own schedule - there's no need to re-request.

Let's Encrypt certificate shows "renewal blocked" The load balancer originally used to issue this certificate no longer exists. Request a new certificate (or re-issue) through a load balancer that still exists to restore automatic renewal.

Delete is refused The certificate is still attached to at least one listener - the error message lists exactly which load balancer(s) and port(s). Detach it from those listeners (or attach a replacement certificate first) and try again.

FAQ

Can I attach the same certificate to more than one load balancer? Yes. A certificate is owned by the account, not by a load balancer, so it can be attached to any number of listeners across any number of your load balancers.

What happens to certificates I created before this release? They were automatically migrated into the account-level store and continue to work on the load balancers they were already attached to. Their expiry, fingerprint and domain metadata is backfilled the first time this release runs, so the Certificates page and expiry alerts see them correctly.

Can I still manage certificates from inside a load balancer's own page? A load balancer's page shows the certificates currently used by its listeners with a link back to the Certificates store, but certificate upload and Let's Encrypt requests now happen from the Certificates page itself.