Pour une instance ownCloud Server hébergée directement derrière un VirtualHost Apache, la procédure habituelle consiste à associer un nom de domaine public au serveur, à rendre le site HTTP accessible et à exécuter l'installateur Apache de Certbot pour ce nom d'hôte. Par exemple, si votre adresse ownCloud est `/homecloud.com/owncloud` cloud.example.com, Certbot peut demander un certificat Let's Encrypt et configurer Apache pour servir du HTTPS avec `/homecloud.com/owncloud` sudo certbot --apache -d cloud.example.com. Testez le site et le renouvellement automatique avant de l'utiliser.
Cette procédure concerne une installation de type ownCloud Classic 10.16 avec Apache sur Ubuntu, comme indiqué dans le guide Apache d'ownCloud. Si vous utilisez ownCloud Classic 11 dans un conteneur Docker, ownCloud précise que le protocole HTTPS doit être configuré sur le proxy web placé devant le conteneur. Si votre hébergeur ou votre proxy inverse gère déjà la terminaison TLS, configurez le certificat à ce niveau plutôt que d'essayer de l'installer dans le conteneur ownCloud.
Let's Encrypt vérifie que vous contrôlez le nom de domaine demandé avant de délivrer un certificat. Pour le défi HTTP-01, Let's Encrypt doit pouvoir récupérer un fichier temporaire sur votre serveur via HTTP public sur le port 80. Ce même nom d'hôte doit correspondre au point de terminaison public qui héberge votre site ownCloud. Le trafic HTTPS atteint ensuite le point de terminaison Apache sur le port 443.
cloud.example.com, et vous contrôlez ses enregistrements DNS.Si votre site est protégé par un proxy, un équilibreur de charge, un hébergeur de conteneurs ou un panneau de contrôle, identifiez le point d'arrêt du protocole TLS public avant d'exécuter Certbot. Un certificat installé sur une machine incorrecte ne sécurisera pas la connexion entre le navigateur et le serveur. Pour ownCloud Classic 11, l'architecture Docker prise en charge gère Apache au sein du conteneur et configure le protocole HTTPS au niveau du proxy web.
Utilisez un nom d'hôte ownCloud dédié lorsque cela est possible. ownCloud exige que chaque URL de navigateur utilisée pour se connecter soit répertoriée trusted_domainsdans son config/config.phpfichier de configuration. Si vous remplacez une adresse IP ou un autre nom d'hôte par ownCloud cloud.example.com, ajoutez le nouvel hôte à une entrée inutilisée du tableau des domaines de confiance avant de tester la nouvelle adresse. Veillez à ne pas écraser accidentellement une autre entrée.
Avant de demander un certificat, assurez-vous que le protocole HTTP simple atteint bien le site ownCloud. Sous Apache, le VirtualHost doit spécifier le nom d'hôte exact à l'aide d'une ServerNamedirective. Les instructions Apache d'ownCloud supposent une configuration VirtualHost et, sous Ubuntu, placent les définitions de site sous le /etc/apache2/sites-available/répertoire `/etc/owncloud`. Les chemins et les noms de service peuvent varier selon les distributions.
Sauvegardez la configuration active de votre VirtualHost Apache avant toute modification. Cela vous permettra de revenir en arrière si un programme d'installation automatisé sélectionne un site incorrect ou crée un hôte HTTPS conflictuel. Si plusieurs sites sont hébergés sur le même serveur, vérifiez que le certificat associé au nom d'hôte ownCloud est bien lié à celui du site par défaut.
Installez Certbot en suivant les instructions correspondant à votre système d'exploitation et à votre configuration Apache. La documentation officielle de Certbot recommande son paquet Snap pour de nombreuses distributions Linux, mais la disponibilité des paquets et les méthodes d'installation prises en charge dépendent de la distribution. Évitez de mélanger plusieurs installations de Certbot provenant du gestionnaire de paquets du système d'exploitation et de Snap ; la commande exécutée certbotdoit être celle dont vous souhaitez utiliser le plugin Apache.
Sur un hôte Ubuntu où Snap est installé et pris en charge, les instructions de Certbot indiquent le chemin d'installation suivant :
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbotSi Certbot est déjà installé, vérifiez la version utilisée par votre shell et son mode d'installation avant d'en ajouter une autre copie. Consultez le guide d'installation Apache de Certbot pour connaître les autres options d'installation prises en charge.
Demandez et installez le certificat pour votre nom d'hôte ownCloud :
sudo certbot --apache -d cloud.example.comRemplacez cloud.example.compar le nom d'hôte réel. Certbot effectuera la validation du domaine et, avec l'installateur Apache, mettra à jour Apache pour utiliser le certificat émis. Si vous souhaitez qu'un seul certificat couvre plusieurs noms, spécifiez chaque nom explicitement, par exemple : `<nom_hôte>` -d cloud.example.com -d files.example.com. Chaque nom listé doit pointer vers un point de terminaison accessible et réussir la validation.
Certbot peut vous demander si les requêtes HTTP doivent être redirigées vers HTTPS. Activer cette redirection est approprié une fois que l'hôte virtuel HTTPS est opérationnel. ownCloud recommande l'utilisation de HTTPS en production et une redirection permanente pour le trafic non chiffré. Si vous préférez gérer vous-même la configuration d'Apache, Certbot propose également un mode « certificat uniquement ». Consultez le guide Apache d'ownCloud pour connecter correctement les fichiers de certificat et l'hôte virtuel, puis testez la configuration avant de redémarrer Apache.
La méthode HTTP-01 utilise un chemin sur /.well-known/acme-challenge/le port 80. Si un routeur redirige le port 80 vers une autre machine, si un pare-feu le bloque ou si un autre proxy redirige ce chemin ailleurs, la validation peut échouer même si la page ownCloud se charge via HTTPS. Vérifiez le DNS public et la redirection de port, puis assurez-vous que le défi ACME atteint le même point de terminaison que celui où Certbot est exécuté.
Si votre fournisseur d'accès Internet ou votre politique réseau bloque le port 80, privilégiez la validation DNS-01. Celle-ci atteste du contrôle du domaine via un enregistrement TXT DNS et permet l'émission de certificats génériques. Toutefois, l'automatisation du renouvellement dépend de la disponibilité d'un plugin API compatible chez votre fournisseur DNS. Évitez d'utiliser des identifiants DNS généraux sur un serveur web lorsqu'il est possible d'utiliser des identifiants spécifiques ou un serveur de validation distinct. N'utilisez pas une procédure HTTP-01 uniquement pour un certificat générique.
Avant de fermer la fenêtre de maintenance, vérifiez que la configuration d'Apache est valide et que Certbot répertorie le nouveau certificat :
sudo apache2ctl configtest
sudo certbot certificatesSous Ubuntu, une vérification syntaxique Apache réussie indique que la configuration est valide. Ouvrez https://cloud.example.comun navigateur et connectez-vous. Vérifiez que le navigateur affiche un certificat valide pour le nom d'hôte exact, puis testez un client de téléchargement, d'envoi et de synchronisation de fichiers représentatif. Si vous avez activé une redirection, accédez à l'adresse HTTP et vérifiez qu'elle aboutit bien au même nom d'hôte HTTPS, sans boucle de redirection.
Si la page de connexion ownCloud signale un domaine non fiable, vérifiez trusted_domainsla configuration du serveur. Si le navigateur redirige vers un nom d'hôte incorrect ou si ownCloud génère des liens HTTP via un proxy inverse, examinez les en-têtes HTTPS et d'hôte transférés du proxy, ainsi que les paramètres de proxy d'ownCloud. Ces paramètres dépendent de la topologie du proxy ; ne copiez pas les configurations de proxy inverse dans une installation Apache directe sans raison valable.
Les certificats standard de Let's Encrypt ont une durée de vie limitée ; leur renouvellement doit donc être automatisé. Les installations de Certbot proposent généralement un minuteur systemd ou une tâche cron. Testez le renouvellement à l'avance avec :
sudo certbot renew --dry-runUne simulation à blanc vérifie le processus de renouvellement sans remplacer le certificat actif. En cas d'échec, consultez la sortie de Certbot et corrigez le problème DNS, de pare-feu, de routage des défis ou d'Apache signalé. Assurez-vous qu'une tâche planifiée ou un minuteur est en place dans les outils de service de votre système d'exploitation ; ne présumez pas que le renouvellement est actif simplement parce que le premier certificat a été émis. Maintenez le port 80 ouvert si votre renouvellement utilise HTTP-01, ou assurez-vous que votre automatisation DNS-01 peut toujours mettre à jour l'enregistrement TXT requis.
| Situation | Itinéraire recommandé |
|---|---|
| ownCloud Classic 10.16 sur Ubuntu avec Apache directement exposé | Utilisez l'installateur Apache de Certbot pour le nom d'hôte ownCloud. |
| ownCloud Classic 11 dans Docker | Configurez le protocole HTTPS sur le proxy web placé devant le conteneur. |
| Le panneau d'hébergement gère déjà les certificats. | Utilisez la procédure Let's Encrypt du panneau et vérifiez que le certificat est bien renouvelé. |
| Le port 80 ne peut pas atteindre le serveur web ou un caractère générique est requis. | Utilisez DNS-01 avec une méthode de renouvellement appropriée. |
| Apache possède plusieurs hôtes virtuels | Confirmez que Certbot a sélectionné l'hôte virtuel dont le nom de serveur correspond au nom d'hôte du certificat. |
N'activez pas HSTS includeSubDomainstant que chaque sous-domaine concerné n'est pas correctement servi via HTTPS ; un en-tête sur un nom d'hôte influence la façon dont les navigateurs traitent ses sous-domaines. Commencez par sécuriser le certificat, les redirections et le renouvellement. Consultez ensuite les recommandations de renforcement de la sécurité d'ownCloud concernant HSTS et les autres paramètres TLS adaptés à l'ensemble de votre architecture de domaine.
Documentation vérifiée le 6 octobre 2026. Les chemins d'accès aux fichiers et les commandes exacts ci-dessous supposent Ubuntu avec Apache et ownCloud Classic 10.16 ; Docker, le proxy inverse, le panneau d'hébergement, Nginx et les déploiements non-Ubuntu nécessitent des instructions pour leur point de terminaison TLS réel.
Références : ownCloud 10.16 : Configurer Apache avec Let's Encrypt ; ownCloud 11 : Guide HTTPS et proxy inverse ; ownCloud 10.16 : Domaines de confiance ; Certbot : Installation et renouvellement d'Apache ; Let's Encrypt : Types de défis ; Let's Encrypt : Garder le port 80 ouvert .
Comparez 10 outils de balayage ping pour une découverte rapide du réseau local, une analyse multiplateforme et la gestion des adresses IP. Découvrez ce qu'un balayage peut – et ne peut pas – vous révéler.
Comparez six outils de gestion de réseau pour la surveillance des performances, notamment la couverture SNMP, la cartographie, les alertes, les modèles de déploiement et les compromis en matière de coûts.
Comparez sept moniteurs de ping gratuits et open source, allant des suites réseau complètes aux sondes de latence ciblées, et choisissez celui qui convient le mieux à vos besoins en matière de disponibilité, de perte de paquets et d'historique.
Comparez les meilleurs analyseurs Wi-Fi pour Windows, iPhone et Android, incluant des outils pour la congestion des canaux, la couverture du signal, les cartes thermiques et le dépannage réseau.
Découvrez ce que signifie la QoS dans le domaine des réseaux, comment les marquages DSCP et les files d'attente de trafic priorisent la voix, la vidéo et les applications professionnelles, et ce que la QoS ne peut pas corriger.
Comparez les logiciels serveurs SFTP fiables pour Windows et Linux, notamment OpenSSH, Bitvise, SolarWinds et SFTPGo. Trouvez la solution idéale pour vos besoins en matière de sécurité et de transfert de fichiers.
Comparez sept outils de gestion d'adresses IP pour la découverte de sous-réseaux, la coordination DNS et DHCP, l'inventaire réseau et l'IPAM open source.
Mettez en place une surveillance réseau pratique avec une couverture claire des périphériques, des indicateurs de performance utiles, des alertes exploitables et une comparaison de SolarWinds NPM, PRTG et OpManager.
Comparez les outils d'analyse réseau pour la découverte rapide des périphériques, les analyses IP multiplateformes et la gestion des identités et des accès IP (IPAM) d'entreprise, avec des conseils pour adapter chaque option à votre réseau.
Utilisez l'option --traceroute de Nmap pour associer les sauts à un hôte autorisé, comprendre les résultats des sauts et du RTT, et résoudre les problèmes de réponses manquantes sans sur-analyse.
