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
- Add the hostname to the web service or static site.
- Create the returned ownership TXT and routing DNS records.
- Verify ownership through the dashboard or service-scoped API.
- Wait for certificate and serving status to become ready.
- Test the hostname over HTTPS before directing application users to it.
Follow Custom domains 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:
# 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 — ownership and routing setup.
- Private network — internal service connections.
- Web services and Static sites — public workloads.