Managing Certificates

Objective

Instance certificates centralize all private key / certificate pairs required by your platform. Once registered in one place, they can be reused by:

  • WebSocket Relays (TLS encryption and optionally mTLS),

  • Container Providers (authentication and secure transport to your clusters).

This centralization simplifies key rotation, avoids duplication, and reduces configuration errors.

Note

Only instance administrators can create, modify, or delete certificates.

Expected Formats

  • KEY: private key in PEM format (PKCS#1 or PKCS#8).

  • CERT: server certificate in PEM format (ideally the fullchain including the cert and intermediate chain).

  • CA (optional): authority certificate(s) in PEM format. Provide this only if you want to enable mutual authentication (mTLS) for clients.

Example PEM contents (simplified):

-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----

-----BEGIN CERTIFICATE-----
... (server certificate)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (intermediate chain)
-----END CERTIFICATE-----

# Optional CA for mTLS
-----BEGIN CERTIFICATE-----
... (Root/Intermediate CA)
-----END CERTIFICATE-----

Creating a Certificate

  1. Open Certificates → New Certificate.

  2. Enter a Name, then paste the KEY, CERT, and optionally CA contents.

  3. Click Create.

../../_static/images/instance/certificates/instance_certificates_create.png

Creating a certificate: name, private key, certificate (fullchain), and CA (for mTLS)

Listing and Opening a Certificate

The Certificates menu lists all available certificates. Click an item to open its details.

../../_static/images/instance/certificates/instance_certificates_list.png

List of instance certificates

Reusing a Certificate

From a certificate’s profile, two tabs show where it is used and allow you to verify its coverage:

  • Relays: WebSocket relays consuming this certificate (TLS / mTLS termination).

  • Container Providers: providers (Swarm, Kubernetes, …) using it to secure communications.

../../_static/images/instance/certificates/instance_certificates_profile_relays.png

“Relays” tab: WebSocket relays using the certificate


../../_static/images/instance/certificates/instance_certificates_profile_container_profiles.png

“Container Providers” tab: container providers linked to the certificate

Typical Use Cases

Standard TLS (WebSocket Relays)

  • KEY = relay’s private key.

  • CERT = server certificate (ideally fullchain).

  • CA = leave empty (no mTLS).

Mutual TLS (mTLS) for Clients

  • KEY = service’s private key.

  • CERT = server certificate (fullchain).

  • CA = CA that issued the client certificates. The relay will refuse connections that do not present a client certificate signed by this CA.

Container Providers (Swarm / Kubernetes)

  • Use a certificate to encrypt and/or authenticate exchanges between Reemo and your provider.

  • By selecting an existing certificate, you avoid pasting the same elements multiple times in each provider.

Rotation & Best Practices

  • Prepare the new KEY/CERT pair in advance (expiration date, new CA if required).

  • Edit the instance certificate and replace the PEM contents: all relays/providers pointing to it will benefit from the new cryptographic material without duplication.

  • Verify the chain (fullchain) and the order of certificates in CERT.

  • Keep the private key secure (strict access rights, secret management).

  • Test the connection after updating (clients, browser connections, agents, etc.).

Warning

Before deleting a certificate, unassign it from relays/providers using it to avoid downtime.

Troubleshooting

  • Browser shows an incomplete chain → use the fullchain (cert + intermediates) in CERT.

  • mTLS client rejected → check that the configured CA matches the issuer of the client certificate.

  • Format error → ensure BEGIN/END blocks are present and no extra characters are included.

  • Invalid domain name → the certificate’s CN/SAN must exactly match the FQDN used by clients.

Summary

  • Single repository for all key/certificate pairs at the instance level.

  • Direct reuse by WebSocket Relays and Container Providers.

  • Simplified rotation: update once, and all linked integrations follow.

  • Support for standard TLS and mutual authentication (mTLS) through the optional CA.