---
id: platform/tls
title: TLS certificates
description: Understand managed certificate issuance, ownership verification, renewal, and TLS troubleshooting on Bex.
keywords: [bex, tls, ssl, certificates, https, acme]
last_updated: 2026-09-23
---

Bex integrates certificate management with public routing. A configured
platform installation can issue and renew certificates for platform hostnames
and verified custom domains. Application owners do not upload a certificate
through the service API.

This depends on the instance's ingress and certificate infrastructure. Running
the operator alone does not automatically provision public DNS, an ACME issuer,
or a publicly reachable HTTPS endpoint.

## Custom-domain certificate lifecycle

1. Add the hostname to the web service or static site.
2. Create the returned ownership TXT and routing DNS records.
3. Verify ownership through the dashboard or service-scoped API.
4. Wait for certificate and serving status to become ready.
5. Test the hostname over HTTPS before directing application users to it.

Follow [Custom domains](./custom-domains.md) for the exact commands and DNS
record fields. Ownership verification and certificate readiness are different
states; a verified TXT claim does not mean a certificate has already been issued.

For a domain already added to your service, inspect its current state:

```bash
# Set the API origin, authorized token, and service id for your instance.
curl --fail-with-body \
  "$BEX_API_URL/v1/services/$SERVICE_ID/custom-domains/api.example.com" \
  -H "Authorization: Bearer $BEX_TOKEN"
```

`ownershipStatus` reports the claim, `verificationStatus` reports certificate
verification, and `serverStatus` reports whether the domain is active.

## Platform domains and renewal

Platform hostnames use the base domain configured by the instance operator;
`onbex.co` is not a universal domain for every self-hosted installation.
Subdomain policy can disable a service's platform hostname when custom domains
are configured.

Custom hosts use separate certificate resources so a validation failure for
one domain does not group all hosts into a single certificate request.
They still depend on shared ingress, issuer, and DNS infrastructure. Keep the
required DNS routing intact and monitor certificate state during domain moves.

The standard deployment uses cert-manager and its configured issuer. An
instance operator must ensure the issuer's challenge mechanism can reach or
validate the domain. Do not assume a custom proxy or DNS change is compatible
with that mechanism without checking the instance configuration.

## Troubleshoot HTTPS

| Symptom | Next check |
| --- | --- |
| Ownership stays pending | Exact TXT record name/value from the domain response and DNS propagation. |
| Ownership verified, certificate pending | Routing DNS, issuer readiness, challenge failures, and certificate-authority limits. |
| Browser reports a different hostname's certificate | Confirm DNS reaches this Bex instance and that this exact hostname has a ready certificate. |
| Certificate expired | Inspect renewal failures and recent DNS/ingress/issuer changes. |
| TLS succeeds but HTTP requests fail | Check application logs, readiness, and routing; the certificate does not prove application health. |

A private service has no public ingress certificate. This does not imply all
internal connections are encrypted: use the application's or datastore's TLS
configuration where required.

## Related guides

- [Custom domains](./custom-domains.md) — ownership and routing setup.
- [Private network](./private-network.md) — internal service connections.
- [Web services](./web-services.md) and [Static sites](./static-sites.md) — public workloads.