Why TLS certificates for Ceph RGW with cephadm need a plan up front
If you are exposing S3 endpoints over HTTPS through cephadm-managed RGW daemons, decide before cutover where your certificates come from, who issues and renews them, and how they reach every RGW host. The certificate is only as useful as the names it covers, so the decision has to start with the endpoint hostnames your applications use, not with the certificate file. Your options for issuing and loading the certificate are covered in the sections that follow.
The certificate has to cover three things. First, the endpoint hostnames that clients connect to, including any load balancer or ingress name fronting the gateways. Second, the bucket names that clients address through virtual-host style URLs, where the bucket name becomes part of the hostname, so a single hostname certificate will not match those requests. Third, client trust: every application, SDK, backup tool and internal CA bundle that talks to the endpoint must trust the issuing authority, or connections fail in ways that look like application bugs. Confirm with each application owner which URL style they use and which CA bundle they load.
Teams usually need this work before application cutover, when a client is first pointed at the HTTPS endpoint, and again during an audit of encryption in transit, when someone will ask for the certificate chain, its expiry and its renewal process. DeployOpen prepares and verifies the cephadm configuration, the naming plan and the client checks. It does not issue certificates; your certificate authority or an independent certification body does, and you should confirm the issuance and renewal process with them before the configuration is finalized.
Which certificate source fits your RGW endpoints
With cephadm-signed certificates, the orchestrator generates and signs the certificate for the RGW service, so the cluster holds both the private key and the signing material. This is the lowest-effort option for a lab or an internal cluster where every client can be configured to trust one internal authority. Renewal is handled by cephadm's certificate management, but the cluster must stay healthy enough to rotate certificates before they expire, and clients must be updated whenever the signing material changes.
- Key custody: The private key is created and stored inside the cluster, so anyone who can manage the orchestrator can reach the endpoint key.
- Renewal: Cephadm reissues certificates on its own schedule; confirm the renewal window and any expiry alerting for your release in the cephadm documentation.
- Client trust: Every S3 client, SDK and backup tool must trust the cluster's signing authority, which usually means distributing that authority to each host and application image.
- Operational trade-off: Setup is fast, but losing or replacing the signing material forces a trust update across all clients at once.
- Names in the certificate: Confirm which hostnames and subject alternative names the generated certificate includes before you rely on virtual-host bucket URLs.
Check the authority export procedure, expiry alerts and the exact name handling for your release before you use this option for client-facing endpoints.
Inline certificate material means the certificate chain and private key are supplied directly in the RGW service specification or in configuration that your team pastes or passes in. Your organization's certificate authority, or a public one, handles issuance, and the cluster receives the finished material. This suits teams that already run a certificate issuance process and want few moving parts. The main trade-off is that key material travels through files and specifications that more people can copy.
- Key custody: Your team handles the private key during issuance, and it then lives in cluster configuration, so restrict read access to the specification files and the configuration store.
- Renewal: Renewal is a manual or scripted step: issue a new certificate, update the specification and reapply it so the RGW daemons pick it up. Confirm the reload behavior for your release.
- Client trust: Clients trust your issuing authority, and if the endpoint name is public, a public authority can reduce trust distribution work.
- Operational trade-off: Nothing in the specification shows the expiry date, so expiry monitoring must come from outside the cluster.
- Chain completeness: Include intermediate certificates in the bundle. A missing intermediate is a common failure that only some clients expose.
Confirm the reload method, the accepted file formats and how the specification stores key material on your release before you write the renewal procedure.
Referenced certificates are stored in the cluster's configuration store under a name, and the RGW service points to that name instead of carrying the material in its specification. This separates the service definition from the secret, so you can rotate material without editing the specification. The cluster still holds the private key, so control shifts toward who can write to the store and how the store is backed up.
- Key custody: The key sits in the cluster's store, so the main risk is read and write access to that store rather than the specification file.
- Renewal: Replace the stored material, then confirm whether cephadm applies the change automatically or whether the affected daemons must be restarted on your release.
- Client trust: Clients trust whichever authority issued the stored chain, so the trust plan matches the one for inline material.
- Operational trade-off: Rotation and review are cleaner, but a wrong or stale reference can break endpoints in ways that appear only after a daemon restarts.
- Backup and recovery: Include the configuration store in your backup plan and test restoring it, because losing it can take the endpoint down.
Check the reference syntax, the store commands and the reload behavior in the Object Gateway documentation for your release, and rehearse a rotation in a non-production cluster first.
Configuration options and when each fits
This table compares the ways to supply TLS material to Ceph Object Gateway endpoints under cephadm. Read each row for who trusts the certificate, who renews it, how much work a rotation creates and where the option fits best. The main takeaway is that the frontend certificate field is deprecated, so confirm its status in the current RGW documentation before reusing it on any cluster.
| Option | Trust source | Renewal ownership and rotation effort | Best-fit environment |
|---|---|---|---|
| cephadm-signed | Certificate issued by a CA that cephadm manages inside the cluster. Clients must trust that CA. | Cephadm handles issuance and renewal. Rotation effort is low, but clients still need the CA bundle updated. Confirm renewal timing and alerts for your release. | Clusters without a corporate CA where the storage team owns endpoint trust end to end. |
| Inline certificate | Certificate and private key placed directly in the RGW service specification. Trust comes from the CA that signed it. | Your team renews outside Ceph, then edits the specification and reconfigures RGW daemons on each renewal. Effort is manual and repeats every renewal cycle. | Small deployments with a corporate CA and few renewals, where a simple change record is acceptable. |
| Referenced certificate | Certificate stored in the cluster configuration store under a named reference. Trust comes from the CA that signed it. | Your PKI or security team renews the certificate and updates the stored material. The specification stays unchanged. Confirm how RGW reloads the new material in your release. | Organizations with central PKI tooling that want renewals separated from service specifications. |
| Frontend certificate field (deprecated) | Certificate set through the older frontend SSL option on the RGW service. Trust comes from the CA that signed it. | Renewal and manual edits are owned by your team, similar to inline. Check current RGW documentation before reuse, since the field is deprecated. | Existing deployments only, with a planned move to a currently supported option. |
Planning wildcard SANs for virtual-host bucket names
Virtual-host style S3 requests carry the bucket name in the hostname, so the certificate has to match every bucket subdomain as well as the RGW endpoint itself. The decisions below connect DNS, certificate names and client configuration, and each one fails quietly if it is set in isolation.
Choose the endpoint base domain
Pick the domain that clients will call, such as the one that will sit under s3.example.com. Every bucket name then becomes a label under that base, so reports.s3.example.com depends on the wildcard *.s3.example.com. Keep the base domain short and dedicated to S3 so the wildcard does not overlap with web or API hostnames that already have their own certificates. Confirm the exact base with your DNS team before issuing anything.
Add both the base and wildcard names
The certificate needs the base name as a SAN and the single-level wildcard as a second SAN. The wildcard covers one label only, so *.s3.example.com matches a bucket but not a.b.s3.example.com. Missing either entry produces TLS errors that look like client bugs, so check the SAN list on the issued certificate instead of trusting the request.
Resolve dotted bucket names
Bucket names containing dots, such as logs.2024.archive, create extra labels that a single-level wildcard does not match, and a wildcard certificate cannot validate them. Decide whether your bucket naming policy forbids dots for buckets that clients will address virtually. Where dotted names are needed, plan path-style addressing for those clients or a separate certificate strategy, and test the exact names your applications create.
Map DNS records to each endpoint
The wildcard DNS record must point every bucket hostname at the address that serves RGW, usually a virtual IP managed by the ingress service. Confirm whether your resolver serves a wildcard record or per-bucket records, and whether internal and external clients resolve the same names. A certificate that matches the name is still rejected if DNS sends the request to a host with a different certificate.
Plan certificates for shared ingress
When several RGW endpoints, such as a public zone and an internal zone, sit behind one ingress, each hostname pattern must appear in the certificate that the ingress presents. Mixing endpoints on one certificate is possible but enlarges the SAN list and the blast radius of a key compromise. Decide early which endpoints share a certificate and which get their own, and confirm that the ingress can select certificates by name.
Confirm client addressing style
Before you issue the certificate, ask each application team whether its SDK and tooling use virtual-host or path-style addressing, and set the RGW configuration to match what those clients send. Some older tools default to path-style, which means the wildcard never gets exercised in testing. Record the addressing style per application so that the certificate, DNS and client settings are reviewed together.
How to set up RGW TLS under cephadm step by step
This sequence takes an RGW endpoint from plain HTTP or an unverified certificate to HTTPS that clients trust, with the certificate source, SANs and service specification confirmed before any daemon restarts.
Confirm the cephadm release and RGW service spec
Your team checks which Ceph release the cluster runs and which RGW service specification is currently applied. Run
ceph orch ls rgw --exporton a cephadm admin host and save the output as the baseline. Confirm the release is one of the actively maintained releases on the Ceph releases page, since older releases are not a safe target for new configuration. Done means you hold a saved copy of the spec, the release version, and a list of the RGW daemons and the hostnames clients use today.Choose the certificate source
The platform owner decides whether cephadm signs the certificate itself, whether your internal certificate authority issues it, or whether a commercial CA does. Record the trade-offs with the security team: cephadm-signed certificates are convenient for lab and internal use but are trusted only where your clients import the signing authority, while certificates from your own or a public CA are what most applications already trust. Ask the team to confirm whether the endpoint must be reachable from partner networks, since that decides whether a public chain is required. Done means the source is written down with its owner and renewal process.
Generate the key and certificate with the correct SANs
Create a private key and a certificate signing request, or request a certificate from your CA, with every name clients will use in the subject alternative names. Include the load balancer or service name, each RGW hostname, and a wildcard entry such as
*.s3.example.internalif you plan virtual-host style buckets, where the bucket name becomes part of the hostname. Confirm the wildcard covers only one label level, so nested bucket hostnames need their own review. Done means the certificate, its full chain and the key are on disk, andopenssl x509 -in cert.pem -noout -textlists every intended SAN.Apply the RGW service specification with the certificate
Update the RGW service specification so it references the certificate and key, either through the certificate material stored in the cephadm configuration or inline in the spec, depending on the release and your standards. Check the Cephadm documentation for the exact keys for your release, since they differ between versions, and do not rely on the deprecated frontend certificate field for new work. Apply the file with
ceph orch apply -i rgw-spec.yaml. Done meansceph orch ls rgw --exportshows the new spec with the TLS settings, and the command returns without a validation error.Redeploy the RGW daemons
Let cephadm roll the RGW daemons onto the new configuration, or restart them explicitly with
ceph orch restart rgw.<service-name>. Do this during a window your change process approves, and watch for daemons that fail to start, which usually points to an unreadable key, a mismatched key and certificate pair, or a missing intermediate. Checkceph orch ps --daemon-type rgwuntil every daemon reports running. Done means every RGW daemon is up on the HTTPS port, and the health status of the cluster has not degraded because of the change.Verify the chain and hostnames from a client
From a host outside the cluster, run
openssl s_client -connectagainst the endpoint and confirm the presented chain, the expiry date and that the served name matches the hostname you requested. Then test with an S3 client over HTTPS, such as the AWS CLI with--endpoint-url, listing buckets and writing a small test object. Repeat from a machine that does not trust your internal root to confirm the expected trust failure, if that is your design. Done means the handshake validates against your trust store, the S3 requests succeed, and the results are saved with the change record.Confirm application trust and plan renewal
Ask each application team to confirm that their SDK and runtime trust the chain, including any container images that ship their own CA bundle, since those often need the internal root added separately. Record the certificate expiry in your monitoring and assign an owner for renewal and for the redeploy step that follows each renewal. Confirm with your security team how the key is stored and who can read it. Done means each consuming application has a recorded trust check and the renewal calendar and monitoring alert exist.
Security and operational considerations for RGW certificates
Certificates for RGW are only as safe as the keys behind them and the clients that trust them. The cards below cover the decisions that carry over from issuing a certificate to running it: who can read keys, how expiry is caught, how rotation avoids outages, and how trust reaches applications.
Protect private keys and cephadm configuration
Anyone who can read the private key or the certificate spec stored in the cluster can impersonate the RGW endpoint. Check who holds cephadm admin access, who can run ceph orch commands that set certificates, and whether the Dashboard or automation accounts can read key material. Limit those permissions to the people who operate the storage, and record every change to the certificate configuration.
Monitor certificate expiry
An expired RGW certificate fails TLS handshakes for every S3 client at once, and the failure often looks like a network fault. Track the not-after date of each certificate in use, including any issued by an internal CA, and alert well before it lapses. Make sure the alert reaches the team that owns the storage service, not only the person who installed the certificate.
Rotate without client downtime
Replacing a certificate on a running gateway should not interrupt applications. Plan the rotation so the new certificate covers the same names as the old one, test it against a non-production endpoint first, and confirm that clients accept the new chain before the old certificate expires. Keep a documented rollback that restores the previous certificate material.
Distribute CA trust to applications
Clients that use a private CA must trust its root or intermediate certificate, and that trust is set in each application, SDK, container image or host trust store. Inventory the S3 clients, including backup tools and CI runners, and confirm how each one loads CA bundles. Plan for CA rollover so that trust is added before a new issuing certificate is deployed.
Separate RGW HTTPS from msgr2 encryption
HTTPS on the RGW endpoint protects traffic between S3 clients and the gateway. It does not encrypt traffic between Ceph daemons. The msgr2 secure mode, which listens on port 3300 and encrypts post-authentication traffic with AES-GCM, is configured separately. Confirm both controls in your design, and do not treat one as evidence of the other.
Questions teams ask before hiring help with RGW certificates
What drives the cost of TLS work for Ceph RGW endpoints?
The main drivers are the number of RGW endpoints and zones, whether a load balancer or ingress layer terminates TLS, how certificates are issued (cephadm-signed, an internal CA or a public CA), and how many client types must trust the chain. Each added endpoint, virtual-host bucket domain and client group adds testing and change control. Quotes should list each of these as separate line items, with the work split between one-time design and build and any recurring renewal support. A written scope lets you compare the quote against the endpoint inventory your team already has.
How long does a scoped RGW certificate deployment take?
Duration depends on the fixed scope agreed in writing before work starts. The biggest variables are how many endpoints and domain names are involved, whether a CA approval or change window sits on the critical path, and how many client applications must be retested after the certificate changes. Ask for the timeline as a sequence of milestones tied to those inputs, not as a single number. Engagements are fixed-scope, so the timeline should be confirmed in the same document as the deliverables.
What do we need to provide before the work starts?
Plan to provide the following before work begins:
- DNS control or a DNS administrator who can create the records for the RGW service name and wildcard names used by virtual-host buckets
- Access to the certificate authority, or a named approver for certificate requests
- Test clients for each application type, such as S3 SDKs, command-line tools and any browser-based access
- Change windows approved for restarting or reconfiguring RGW and any load balancer
Missing any of these usually extends the schedule more than the technical work does.
Can an internal team set up RGW TLS without outside help?
Yes, if the team already runs cephadm, understands how RGW listens on its frontend, and has a CA process that issues certificates for the names it needs. The harder parts are usually wildcard subject alternative names for virtual-host buckets, certificate placement in cephadm specifications, and testing every client after a change. Outside help makes most sense when several endpoints, a load balancer and an external CA must be coordinated, or when the team cannot spare people for testing and rollback planning. Your team can use the Ceph cephadm documentation as the starting reference.
Does DeployOpen issue the certificates for our RGW endpoints?
No. DeployOpen plans, configures and documents the certificate setup in your infrastructure, but certificates are issued by your own internal CA or a public certificate authority that you choose and control. DeployOpen does not act as a certificate authority, and it does not issue audit reports or attestations. The work can include preparing certificate requests, configuring RGW and any ingress with the issued material, and verifying each endpoint and client path against the agreed scope.
What changes if our RGW sits behind a load balancer?
A load balancer changes where TLS is terminated and which certificate clients see. If the load balancer terminates TLS, its certificate must cover every public name, and the connection from the balancer to RGW needs its own trust decision. If TLS passes through to RGW, the RGW certificate must cover every name that clients use. Confirm which layer owns each certificate before issuing anything, because a mismatch shows up as failed client handshakes that are hard to trace.
Which certificate option should we check first when using a deprecated frontend field?
Start by confirming whether your current RGW configuration sets certificate material in the deprecated frontend certificate field. If it does, plan a move to the supported cephadm-managed certificate settings as part of the scope, and test that RGW still serves the expected chain after the change. Check the current Ceph documentation for the release you run, since option names and behavior can differ between releases. Keep a record of the existing configuration so rollback is possible during the change window.
What a fixed-scope RGW TLS engagement covers
A fixed-scope engagement for RGW TLS starts with an endpoint inventory, not with a certificate request. We list every name and address that clients use to reach the Ceph Object Gateway, including internal and external S3 endpoints, any Swift endpoints, the Dashboard, and any load balancer or proxy that terminates TLS in front of RGW. For each endpoint we record which applications, SDKs and tools connect to it, which trust stores they use, and whether any of them pin certificates. The same review settles the certificate source decision: whether cephadm generates and manages the certificate, whether an inline certificate is supplied in the service specification, or whether a referenced certificate is stored in the cluster and rotated separately. Each option has different renewal and audit consequences, so the choice is written down with its owner before any configuration changes.
The next deliverables are the SAN plan and the cephadm configuration. The SAN plan lists every hostname that must appear in the certificate, including wildcard entries such as *.s3.example.internal where virtual-host style bucket addressing is used, and it records which names are deliberately left out. We then document the RGW service specification and the certificate settings that cephadm applies, and we flag the deprecated frontend certificate field so it is not carried forward from older configurations. Client verification follows: we test each endpoint from representative clients, confirm the chain validates against the trust stores in use, and check that virtual-host bucket requests resolve under the wildcard. The engagement closes with handover notes covering renewal steps, owners and the checks to repeat after a cephadm upgrade. DeployOpen does not issue certificates or audit reports. Your certificate authority issues the certificates, and independent auditors assess your controls. The scope, deliverables and timeline are agreed in writing before work begins, and your team should confirm the endpoint list and certificate authority details before the quote is finalized.
