SSL & Sécurité

Oui, un certificat SSL Let's Encrypt gratuit est inclus avec l'hébergement web et renouvelé automatiquement. HTTPS est activé dès la mise en ligne.

Oui. Si vous avez besoin d'un certificat à validation étendue ou d'organisation, vous pouvez l'installer sur votre hébergement. Notre support vous accompagne.

La redirection automatique de HTTP vers HTTPS est activable en un clic depuis cPanel, pour servir tout votre site de manière sécurisée.

Notre infrastructure applique l'isolation des comptes, un pare-feu et des mises à jour régulières. Sur VPS, la sécurité de votre environnement reste sous votre responsabilité (nous pouvons vous conseiller).

Oui : chaque site est protégé par le réseau Cloudflare, qui absorbe les attaques DDoS à l'échelle mondiale — la même protection que les plus grands sites du web, incluse et sans surcoût.

Cloudflare est le réseau qui accélère et protège près de 20 % du web mondial. Nous y connectons votre domaine automatiquement et gratuitement : vous gagnez un CDN mondial (site plus rapide partout), une protection anti-DDoS, un DNS anycast résilient et le HTTPS — sans aucune manipulation de votre part.

Maintenez WordPress, ses thèmes et extensions à jour, utilisez des mots de passe forts, limitez les tentatives de connexion, activez le SSL et faites des sauvegardes régulières.

Contactez notre support sans attendre : nous vous accompagnons pour restaurer une sauvegarde saine et identifier la faille, afin d'éviter qu'elle ne se reproduise.

Les certificats Let's Encrypt sont valables 90 jours, ce qui impose un renouvellement automatique toutes les 60 jours environ. Sur nos hébergements, ce renouvellement est pris en charge automatiquement — vous n'avez rien à faire. Le CA/B Forum (l'organisme qui régit les autorités de certification) a voté une feuille de route pour raccourcir progressivement cette durée : d'abord 100 jours, puis 47 jours à l'horizon 2029. Un renouvellement plus fréquent renforce la sécurité car il limite la fenêtre d'exposition en cas de compromission de clé. Si vous utilisez un certificat sur un serveur non géré par nos soins, assurez-vous que votre outil d'automatisation (Certbot, acme.sh) est à jour pour gérer ces nouvelles durées.

Des clients ACME comme `certbot`, `acme.sh` ou Caddy permettent de renouveler vos certificats SSL automatiquement, sans intervention manuelle. Configurez un timer systemd ou un cron job pour lancer le renouvellement régulièrement — la plupart des clients le font nativement à l'installation. Cette automatisation devient urgente : le CA/B Forum prévoit de ramener les durées de validité à 47 jours d'ici 2029, ce qui rend tout renouvellement manuel structurellement ingérable.

Traefik intègre nativement un client ACME compatible Let's Encrypt. Il suffit de déclarer un resolver dans la section `certificatesResolvers` du fichier `traefik.yml` (ou en variable d'environnement), puis d'ajouter le label `traefik.http.routers.<service>.tls.certresolver=<nom>` à chaque conteneur Docker que vous souhaitez protéger. Traefik gère alors la négociation du challenge HTTP-01 ou DNS-01, l'émission du certificat et son renouvellement automatique avant expiration. Les certificats sont stockés dans un fichier JSON persistant (`acme.json`) que vous devez monter dans un volume pour éviter de les perdre au redémarrage du conteneur.

Oui. Des solutions open source comme Authentik ou Authelia, disponibles dans la Marketplace ServOrbit, permettent de centraliser l'authentification de toutes vos applications (Gitea, Nextcloud, Chatwoot…) via un seul portail SSO/OIDC. Vous gérez les utilisateurs, les droits et la double authentification depuis une interface unique, sans reconfigurer chaque application séparément. Un VPS Power (4 vCPU, 8 GB) est conseillé pour Authentik ; Authelia est plus léger.

Oui, l'hébergement mutualisé ServOrbit utilise CloudLinux, ce qui garantit une isolation forte entre les comptes. Chaque client s'exécute dans un environnement cloisonné appelé LVE (Linux Virtual Environment) : vos fichiers, processus et ressources CPU/RAM sont strictement séparés de ceux des autres clients hébergés sur le même serveur. Un site voisin mal configuré ou compromis ne peut donc ni accéder à vos données ni impacter vos performances de manière disproportionnée. Cette architecture est une protection supplémentaire par rapport à l'hébergement mutualisé classique sans CloudLinux.

Déployez Promtail sur chaque VPS à surveiller : il collecte les journaux système (auth.log, syslog, journald) et les envoie vers une instance Loki centralisée sur un second VPS ou un bucket objet compatible. Grafana se connecte à Loki comme source de données et vous permet de créer des alertes sur les tentatives de connexion échouées (sudo, SSH) ou les erreurs applicatives. Cette pile est légère (Loki + Grafana tiennent sur un VPS à 99 DH/mois) et évite d'exposer vos logs à un service tiers.

Oui. Cloudflare Tunnel (anciennement Argo Tunnel) établit une connexion sortante de votre VPS vers le réseau Cloudflare, ce qui permet d'exposer une application web avec HTTPS sans ouvrir aucun port entrant — idéal si votre VPS est derrière un pare-feu strict. Le démon `cloudflared` s'installe sur votre serveur et gère la connexion ; votre domaine doit être géré dans Cloudflare. Notre article de blog dédié détaille la configuration pas à pas.

Oui, vous pouvez générer et installer un certificat wildcard Let's Encrypt (gratuit) via Certbot avec le challenge DNS-01, qui couvre votre domaine principal et tous ses sous-domaines (*.exemple.com). Sur un serveur dédié ou VPS avec accès root, la démarche est entièrement libre : aucune restriction de notre côté. Vous pouvez également installer un certificat wildcard commercial (OV ou EV) obtenu auprès d'une autorité de certification de votre choix.

Deux vulnérabilités critiques de contournement de l'authentification à deux facteurs ont été découvertes dans Nextcloud en mai 2026 : CVE-2026-45690 (contournement via HTTP Basic Auth, CVSS 5.9) et CVE-2026-45691 (contournement via un token Bearer DAV, CVSS 5.9). Ces vulnérabilités permettent à un attaquant disposant d'un identifiant et d'un mot de passe de se connecter sans passer par le 2FA. **Étape 1 — Vérifier votre version** : connectez-vous à votre Nextcloud en administrateur, allez dans **Administration → Vue d'ensemble** et consultez la version affichée. **Versions corrigées** : Nextcloud 32.0.9 et 33.0.3. ⚠️ Nextcloud 34.0.2 contient une régression — ne pas l'utiliser. **Étape 2 — Mettre à jour si nécessaire** : depuis l'interface d'administration, allez dans **Administration → Vue d'ensemble → Vérifier les mises à jour** et appliquez la dernière mise à jour disponible. Pour une instance Docker, changez le tag d'image vers `nextcloud:32.0.9-apache` et relancez le conteneur. **Étape 3 — Vérifier l'application 2FA** : assurez-vous que l'application Two-Factor TOTP ou deux-facteurs SMS est activée dans **Administration → Sécurité** et qu'elle est obligatoire pour les comptes administrateurs.

‎Authelia est un proxy d'authentification léger (< 30 Mo de RAM) qui ajoute une couche 2FA et SSO OIDC devant vos applications via un reverse proxy (‎Traefik ou ‎nginx). Il ne gère pas d'annuaire utilisateur complet et ne parle pas ‎SAML 2.0. ‎Authentik est un ‎IAM (‎Identity and ‎Access ‎Management) complet : il couvre ‎OIDC, ‎SAML 2.0, ‎LDAP, ‎SCIM et le provisionnement automatique de comptes. Il nécessite un ‎VPS avec 4 ‎Go de ‎RAM minimum (4 conteneurs : ‎server, ‎worker, ‎PostgreSQL, ‎Redis). En pratique : ‎Authelia pour 2 à 6 applications internes à protéger avec 2FA, ‎Authentik si vous avez besoin de ‎SAML 2.0, de fédérer plus de cinq applications ou de provisionner des comptes automatiquement. Les deux sont disponibles sur la Marketplace ‎ServOrbit.

Les CVE post-authentification exploitent des failles accessibles une fois connecté : maintenez vos applications à jour dès la publication d'un correctif, restreignez l'accès à l'interface d'administration par IP ou via un reverse proxy avec authentification forte, et limitez les comptes administrateurs au strict nécessaire. Activer un WAF devant votre backoffice — via Cloudflare ou un proxy applicatif — permet de bloquer les patterns d'exploitation connus avant même qu'ils atteignent l'application.

Depuis la version 2026.4.1 des clients Bitwarden, certaines API de chiffrement plus anciennes ne sont plus acceptées par les nouvelles installations : un nouveau client applique des contrôles plus stricts que les sessions déjà ouvertes. Vérifiez que votre instance Vaultwarden est à jour (image `vaultwarden/server:latest` ou une version récente fixée) et que votre reverse proxy transmet correctement les en-têtes — en particulier `X-Real-IP` et `X-Forwarded-For`. Si le problème persiste, ouvrez un ticket depuis votre espace client en joignant la version de Vaultwarden (`docker inspect vaultwarden | grep -i version`) et le message d'erreur exact affiché par le client.

Placez un reverse proxy (Traefik ou nginx) devant votre instance Docmost et branchez Authelia ou Authentik comme middleware d'authentification : toute requête passe d'abord par la page de connexion du SSO avant d'atteindre l'application. Avec Traefik, ajoutez le middleware `forwardAuth` pointant vers l'endpoint de décision Authelia dans vos labels. Avec nginx, utilisez `auth_request` vers l'endpoint de vérification. Cette approche est particulièrement adaptée aux outils de documentation internes qui n'exposent pas d'authentification native robuste. Authentik est disponible via le marketplace ServOrbit et supporte OIDC, SAML 2.0 et les forward auth headers compatibles Traefik.

Avant la migration, exportez votre base SQLite (`kuma.db`) et posez-la en lieu sûr — c'est la seule source de vérité de vos moniteurs et alertes. La v2 change le schéma de base : démarrez le nouveau conteneur avec le même volume de données, Uptime Kuma exécutera les migrations automatiquement au premier lancement. Vérifiez ensuite que chaque moniteur est actif et que les canaux de notification répondent avant de supprimer l'ancienne instance. La v2 corrige la vulnérabilité CVE-2026-45618 (injection via les en-têtes HTTP) — la mise à jour est recommandée.

Un VPN en maillage (mesh) basé sur WireGuard, comme Netbird ou Tailscale, crée un réseau chiffré point à point entre vos VPS via des connexions sortantes uniquement — aucun port entrant n'est exposé sur l'adresse IP publique. Un nœud de coordination (relay STUN/TURN) résout les traversées NAT ; le trafic entre machines voyage directement en pair-à-pair une fois le tunnel établi. Cette approche convient aux clusters de bases de données, aux services internes et aux pipelines CI/CD qui ne doivent pas être accessibles depuis Internet.

CVE-2026-45672 est une vulnérabilité d'exécution de code à distance dans Open WebUI affectant les versions antérieures à 0.6.10 : un attaquant authentifié peut exécuter du code arbitraire sur le serveur via le pipeline de traitement de fichiers. Vérifiez votre version depuis l'interface d'administration (Réglages → À propos) ou avec `docker inspect ghcr.io/open-webui/open-webui:latest | grep 'version'`. Si vous êtes sous 0.6.10, mettez à jour immédiatement en tirant la nouvelle image : `docker compose pull && docker compose up -d`. En attendant, restreignez l'accès à votre interface par IP via votre reverse proxy. Consultez [email protected] pour une assistance à la mise à jour.

Le tag :latest écrase la clé de chiffrement des embeddings à chaque docker pull : perte IRRÉVERSIBLE des documents vectorisés. Toujours épingler une version fixe (ex. v1.8.x) dans docker-compose. Source : issue #5256 github.com/Mintplex-Labs/anything-llm.

Passbolt chiffre chaque entrée avec la clé GPG publique du destinataire. Ni le serveur ni l'administrateur ne peuvent lire les mots de passe sans la clé privée du titulaire. Le chiffrement s'effectue dans le navigateur via l'extension Passbolt.

Avant de mettre à jour Chatwoot, consultez le changelog officiel et la base NVD/CVE pour les vulnérabilités liées à la version cible ; la branche v4 a notamment corrigé des failles dans la gestion des tokens d'authentification. Sauvegardez intégralement votre base PostgreSQL et vos volumes avant toute mise à jour, puis testez sur un clone avant la production. En cas de doute sur l'exposition de votre instance, ouvrez un ticket depuis votre espace client ou contactez [email protected].

**Let's Encrypt (gratuit)** : - Certificats **DV (Domain Validation)** uniquement : prouve que vous contrôlez le domaine, pas l'identité de votre organisation - Valide 90 jours (renouvellement automatique via certbot) - Reconnu par tous les navigateurs modernes - Adapté à la grande majorité des sites web - Wildcard disponible (via DNS-01) : un seul certificat couvre `*.votre-domaine.com` **Certificats payants** : - **OV (Organization Validation)** : l'AC vérifie l'existence légale de votre entreprise — visible dans les détails du certificat - **EV (Extended Validation)** : vérification poussée, anciennement visible par la barre verte dans les navigateurs (cette indication a été retirée des navigateurs modernes en 2019) - Valides 1 à 2 ans - Peuvent inclure une garantie financière en cas de mauvaise émission **Pour 99 % des usages, Let's Encrypt est suffisant.** Les certificats EV/OV ont un intérêt pour des raisons de conformité interne, de contrats avec certains partenaires, ou pour des secteurs réglementés (banques, assurances) qui les exigent contractuellement.

Abonnez-vous aux releases GitHub de Gitea (github.com/go-gitea/gitea/releases) et activez les notifications pour les nouvelles versions. Chaque release précise si elle corrige des CVE et l'impact (CVSS). Sur un VPS ServOrbit, la mise à jour se fait via `docker compose pull && docker compose up -d` — prévoyez une sauvegarde avant toute mise à jour majeure.

Commencez par exporter un coffre chiffré depuis votre gestionnaire actuel, vérifiez son intégrité avant de supprimer l'original, puis déployez Vaultwarden ou Passbolt sur un VPS dédié en HTTPS avec certificat valide — les clients Bitwarden refusent les connexions non chiffrées. Activez l'authentification à deux facteurs sur tous les comptes dès le premier accès, planifiez la bascule hors des heures ouvrées et ne coupez l'accès à l'ancienne solution qu'une fois la nouvelle validée par chaque membre. Notre support peut vous aider pour la configuration TLS via [email protected].

Consultez `/var/log/auth.log` (Debian/Ubuntu) pour repérer les tentatives de connexion échouées (`Failed password`, `Invalid user`) et les connexions acceptées hors de vos plages horaires habituelles. La commande `last` liste les sessions SSH récentes avec horodatage et IP source. Pour une surveillance continue, `fail2ban` bloque automatiquement les IP qui accumulent des échecs, et vous pouvez configurer des alertes e-mail. En cas de connexion inconnue confirmée, coupez immédiatement la session avec `pkill -u <user>`, changez les clés SSH et ouvrez un ticket via votre espace client.

Pour un usage purement interne — équipe, projets internes, sans exposition du service à des tiers — la BSL et la SSPL n'imposent généralement pas de contrainte : ni l'une ni l'autre ne visent l'usage privé. La contrainte de la SSPL se déclenche si vous offrez le logiciel comme service à des utilisateurs externes (SaaS) ; la BSL interdit d'offrir un service commercial concurrent à l'éditeur. Si vos clients accèdent à l'outil, consultez un juriste avant de déployer. Abonnez-vous aux releases GitHub des projets concernés pour détecter les changements de licence à chaque version majeure.

Le défi DNS-01 permet d'obtenir un certificat wildcard (`*.mondomaine.ma`) sans exposer de port HTTP : Certbot crée un enregistrement TXT `_acme-challenge` dans votre zone DNS, puis Let's Encrypt le vérifie. Si votre domaine est géré via Cloudflare, le plugin `certbot-dns-cloudflare` automatise cette étape avec un token API à portée réduite (`Zone:DNS:Edit`). Ajoutez un cron ou un timer systemd pour lancer `certbot renew` et rechargez nginx automatiquement après renouvellement. Testez le renouvellement en avance avec `--dry-run` avant de le confier au planificateur.

Par défaut, PostgreSQL écoute sur le port 5432 ; si ce port est accessible depuis Internet, n'importe qui peut tenter de s'y connecter. Vérifiez votre exposition avec `ss -tlnp | grep 5432` (ou `netstat`) : si l'adresse d'écoute est `0.0.0.0` ou `::`, le service est joignable de l'extérieur. Pour le sécuriser : liez PostgreSQL à `127.0.0.1` dans `postgresql.conf` (`listen_addresses = 'localhost'`), bloquez le port avec votre pare-feu (`ufw deny 5432`), et n'autorisez l'accès distant que via un tunnel SSH ou un VPN. Si vous avez besoin d'aide pour durcir votre configuration, ouvrez un ticket depuis votre espace client.

Commencez par consulter les journaux de Certbot avec la commande journalctl -u certbot ou en lisant le fichier /var/log/letsencrypt/letsencrypt.log pour identifier la cause de l'échec. Si vous utilisez le challenge HTTP-01, vérifiez que le port 80 est accessible depuis l'extérieur et que votre configuration de serveur web sert correctement le répertoire .well-known/acme-challenge/. Si le port 80 est bloqué ou si vous avez besoin d'un certificat wildcard, basculez vers le challenge DNS-01 en utilisant le plugin DNS adapté à votre fournisseur. Pour forcer un renouvellement immédiat afin de tester la configuration, utilisez la commande certbot renew --force-renewal.

Un certificat SSL wildcard couvre un domaine et l'ensemble de ses sous-domaines de premier niveau, par exemple *.exemple.com. Let's Encrypt émet des certificats wildcard uniquement via le challenge DNS-01, qui nécessite de créer un enregistrement TXT dans votre zone DNS pour prouver la propriété du domaine. Pour automatiser ce processus, utilisez Certbot avec le plugin DNS correspondant à votre fournisseur DNS. ZeroSSL est une alternative à Let's Encrypt qui propose également des certificats wildcard gratuits via le challenge DNS-01 et dispose d'une interface web pour faciliter l'émission manuelle.

Lorsque votre domaine est proxifié par Cloudflare, le défi HTTP-01 de Certbot peut échouer car Cloudflare répond à la place de votre serveur. Utilisez plutôt le défi DNS-01 : installez le plugin `certbot-dns-cloudflare`, créez un token API Cloudflare avec la permission `Zone:DNS:Edit`, puis lancez `certbot renew --dns-cloudflare --dns-cloudflare-credentials ~/cloudflare.ini`. Le renouvellement s'effectue sans exposer de port et fonctionne même si votre serveur est inaccessible depuis Internet. Pensez à automatiser le renouvellement via un cron job `certbot renew` pour éviter toute expiration future.

Vous pouvez vérifier l'installation et la date d'expiration de votre certificat SSL directement depuis votre navigateur : cliquez sur le cadenas dans la barre d'adresse, puis sur « La connexion est sécurisée » pour afficher les détails du certificat (émetteur, domaine couvert, validité). Des outils en ligne comme SSL Labs (ssllabs.com/ssltest) ou check-host.net permettent également de réaliser une analyse approfondie (chaîne de certification, algorithmes, compatibilité). Si le certificat est géré automatiquement par ServOrbit (Let's Encrypt), le renouvellement est pris en charge sans intervention de votre part.

Cette CVE cible les instances Artifactory self-hosted qui exposent certains endpoints REST sans authentification. Vérifiez la version installée (Administration → System → General Configuration) et appliquez le patch indiqué dans les notes de version JFrog. En attendant, bloquez l'accès public au port d'administration (8081/8082) via le pare-feu de votre VPS ou serveur dédié ServOrbit, et désactivez l'accès anonyme dans les paramètres de sécurité Artifactory.

Oui, depuis Docker Compose v2.24, les secrets Docker sont nativement pris en charge sans Swarm. Vous déclarez un bloc secrets dans votre docker-compose.yml en référençant un fichier local : Docker monte le secret en tant que fichier temporaire dans /run/secrets/<nom> à l'intérieur du conteneur, sans l'exposer dans les variables d'environnement ni dans docker inspect. C'est la méthode recommandée pour protéger des clés d'API, des mots de passe de base de données ou des tokens sur un VPS root. Voir notre guide sur Docker Secrets en production pour les commandes exactes et les limites de chaque approche.

Trois approches sont possibles sur un VPS root : les Docker Secrets (fichiers montés en /run/secrets/, sans Swarm depuis Compose v2.24), .env.vault avec l'outil dotenvx qui chiffre le fichier .env et n'expose que la clé de déchiffrement DOTENV_KEY, et SOPS qui chiffre les valeurs d'un fichier YAML ou .env via une clé age ou AWS KMS. Dans tous les cas, le fichier .env en clair ne doit jamais être versionné dans Git. Voir notre guide Docker Secrets en production pour les commandes et les vraies limites de chaque méthode.