Gérer ses certificats

Objectif

Les certificats d’instance centralisent toutes les paires clé privée / certificat dont votre plateforme a besoin. Une fois enregistrés à un seul endroit, ils peuvent être réutilisés par :

  • les Relais WebSocket (chiffrement TLS et éventuellement mTLS),

  • les Container Providers (authentification et transport sécurisé vers vos clusters).

Cette centralisation simplifie la rotation des clés, évite les duplications et réduit les erreurs de configuration.

Note

Seuls les administrateurs d’instance peuvent créer, modifier ou supprimer des certificats.

Formats attendus

  • KEY : clé privée au format PEM (PKCS#1 ou PKCS#8).

  • CERT : certificat serveur au format PEM (idéalement le fullchain incluant le cert et la chaîne intermédiaire).

  • CA (optionnel) : certificat(s) d’autorité au format PEM. Renseignez-le uniquement si vous souhaitez activer une authentification mutuelle (mTLS) côté clients.

Exemples de contenus PEM (simplifiés) :

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

-----BEGIN CERTIFICATE-----
... (certificat serveur)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
... (chaîne intermédiaire)
-----END CERTIFICATE-----

# CA optionnelle pour mTLS
-----BEGIN CERTIFICATE-----
... (Root/Intermediate CA)
-----END CERTIFICATE-----

Créer un certificat

  1. Ouvrez Certificates → New Certificate.

  2. Renseignez Name, puis collez les contenus KEY, CERT et éventuellement CA.

  3. Cliquez Create.

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

Création d’un certificat : nom, clé privée, certificat (fullchain) et CA (pour mTLS)

Lister et ouvrir un certificat

Le menu Certificates liste tous les certificats disponibles. Cliquez sur un élément pour ouvrir sa fiche.

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

Liste des certificats d’instance

Réutiliser un certificat

Depuis la fiche d’un certificat, deux onglets listent où il est utilisé et vous permettent de vérifier la couverture :

  • Relays : relais WebSocket qui consomment ce certificat (terminaison TLS / mTLS).

  • Container Providers : providers (Swarm, Kubernetes, …) qui l’emploient pour sécuriser les communications.

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

Onglet « Relays » : relais WebSocket utilisant le certificat


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

Onglet « Container Providers » : providers de conteneurs liés au certificat

Cas d’usage typiques

TLS standard (relais WebSocket)

  • KEY = clé privée du relais.

  • CERT = certificat serveur (idéalement fullchain).

  • CA = laissez vide (pas de mTLS).

Mutual TLS (mTLS) côté clients

  • KEY = clé privée du service.

  • CERT = certificat serveur (fullchain).

  • CA = CA qui a émis les certificats clients autorisés. Le relais refusera les connexions qui ne présentent pas un certificat client signé par cette CA.

Container Providers (Swarm / Kubernetes)

  • Utilisez un certificat pour chiffrer et/ou authentifier les échanges entre Reemo et votre provider.

  • En sélectionnant un certificat existant, vous évitez de recoller plusieurs fois les mêmes éléments dans chaque provider.

Rotation & bonnes pratiques

  • Préparez à l’avance le nouveau couple KEY/CERT (date d’expiration, nouvelle CA si besoin).

  • Éditez le certificat d’instance et remplacez les contenus PEM : tous les relais/providers qui y pointent profiteront du nouveau matériel cryptographique sans duplication.

  • Vérifiez la chaîne (fullchain) et l’ordre des certificats dans CERT.

  • Conservez la clé privée en sécurité (droits d’accès stricts, secrets management).

  • Testez la connexion après mise à jour (clients, connexions browser, agents, etc.).

Warning

Avant de supprimer un certificat, désassociez-le des relais/providers qui l’utilisent pour éviter toute indisponibilité.

Dépannage

  • Le navigateur indique une chaîne incomplète → utilisez le fullchain (cert + intermédiaires) dans CERT.

  • Le client mTLS est refusé → vérifiez que la CA configurée correspond bien à l’émetteur du certificat client.

  • Erreur de format → assurez-vous que les blocs BEGIN/END sont présents et qu’il n’y a pas de caractères additionnels.

  • Nom de domaine invalide → le CN/SAN du certificat doit correspondre exactement au FQDN utilisé par les clients.

Résumé

  • Un seul référentiel pour toutes vos paires clé/certificat au niveau instance.

  • Réutilisation directe par les Relais WebSocket et les Container Providers.

  • Rotation simplifiée : modifiez le certificat une fois, et toutes les intégrations liées suivent.

  • Support du TLS standard et de l’authentification mutuelle (mTLS) via la CA optionnelle.