Certificates

Instances are served over TLS by the shared odoo-nginx container. Certificates are obtained from Let's Encrypt through a certbot container, and fall back to self-signed when a trusted certificate cannot be issued.

Requesting

Remote or localagainst prod-1

# odoocli instance certificate request --instance acme

Before requesting, confirm DNS actually points at this host. A request that fails because of DNS looks identical to one that fails for any other reason:

Remote or localagainst prod-1

# odoocli instance config validate-dns --instance acme

Two things have to be true for a trusted certificate:

• Every host name on the instance resolves to this server.
• Inbound TCP 80 is reachable from the internet, because that is how the challenge is answered.

Listing and renewing

Remote or localagainst prod-1

# odoocli instance certificate list --instance acme

Remote or localagainst prod-1

# odoocli instance certificate renew --instance acme

Renewal is one of the operations the maintenance scheduler can run unattended. That is the normal arrangement: a certificate you renew by hand is a certificate that expires on a weekend.

Requires the Professional edition

Letting the maintenance scheduler run backups, restores, certificate renewals, PostgreSQL maintenance and image cleanup unattended. Starting any of them by hand needs only the edition that operation itself needs, and the housekeeping schedules that look after the server's own state are never restricted.

Available on Developer, Professional, Provider. Below that the operation is refused and nothing is changed.

The fallback is deliberate

If a trusted certificate cannot be obtained, the instance gets a self-signed one rather than none. A browser warning is a bad outcome; an instance that will not serve HTTPS at all is a worse one.

Not available on the Developer edition

Publicly trusted certificates. Allowed on Unregistered, Community, Professional, Provider, the unregistered state included.

Because the Developer edition always falls back, a Developer instance ends up on a self-signed certificate rather than on no certificate, which needs no special handling at the call site.

The management UI's own certificate

The Web UI on port 5220 serves HTTPS with a self-signed certificate issued by server install for the server's host name. It is not renewed by the scheduler: it is reissued at install time. Re-run server install when it approaches expiry.

Reach the UI by name rather than by address. A passkey's relying-party id must be a domain, and the certificate carries DNS names only.

Related

• Creating an instance
• Maintenance schedules