SSL Certificates

Reemo encrypts all of its communications with TLS. SSL certificates serve two clearly distinct purposes: exposing the Portal to users, and securing the internal exchanges between the platform’s micro-services.

Understanding this separation helps you choose the right certification authority (CA) for each purpose, and reason about certificate renewal.

Two uses of certificates

  • Public exposure: the Traefik frontend terminates TLS on the browser side. This is the certificate users see when they open the Portal.

  • Internal communications: micro-services talk to each other over mTLS (mutual TLS), each presenting its own certificate. This relies on a dedicated internal PKI.

The user reaches Traefik over HTTPS with a public certificate; Portal, Signal, API and the database talk over mTLS with the internal PKI.

The two certificate uses: public HTTPS at Traefik, internal mTLS between services.

Public TLS termination

The Traefik frontend is the only component exposed to users. It carries the certificate(s) for the Portal URLs (for example the user portal and the admin portal) and then re-encrypts traffic toward the internal micro-services.

This certificate is usually issued by a public authority (trusted by browsers) or provided by the organization. It is independent from the internal PKI.

Internal PKI and mTLS

Micro-services do not trust each other by default: they authenticate mutually on every connection (mTLS). Each service presents a certificate signed by a dedicated internal CA (the Reemo CA), and verifies its peer’s certificate.

This model guarantees that only a service holding a valid certificate, issued by the internal CA, can join the platform — even if the network is compromised.

Important

It is recommended to use a different PKI for internal communications than the one used for Traefik: public exposure and the platform core do not share the same lifecycle or the same trust boundary.

Dedicated PKIs

Beyond the shared internal PKI, Reemo isolates certain exchanges behind dedicated PKIs. This is the case for communications with the secure gateways (workstations, appliance, credential portal, identity), which rely on their own certification authority — for example the Reemo Workstation CA for workstations.

A dedicated PKI narrows the trust boundary: compromising one of these domains does not expose the rest of the platform.

See also

Secure gateway architecture — How secure gateways communicate over mTLS with a dedicated PKI.

See also

SSL Certificates (installation) — Configuring Traefik certificates and the internal PKI in the reemo-infra role.