Rédigé par Rédaction CyberSDF / 16 September 2026

Nextcloud en HTTPS : configurer Apache et Let’s Encrypt

Serveur en rack avec câble réseau et voyant vert

Pour sécuriser une instance Nextcloud, faites pointer un nom de domaine vers le serveur, rendez le port 80 accessible, puis utilisez Certbot avec le module Apache. Certbot obtient le certificat et peut configurer le vhost HTTPS. Vérifiez ensuite la redirection HTTP, la réponse HTTPS et le renouvellement. Si TLS se termine sur un proxy inverse, appliquez la configuration Nextcloud dédiée au lieu de copier le vhost direct.

Sommaire

Le résultat attendu avant de toucher à Apache
Préparer le domaine et l’accès HTTP
Déclarer Nextcloud dans le vhost Apache
Obtenir le certificat avec Certbot
Faire passer les requêtes HTTP sur HTTPS
Aligner le nom public dans Nextcloud
Cas technique : le certificat est installé sur un proxy inverse
Rendre CalDAV et CardDAV découvrables
Contrôler le certificat et son renouvellement
Dépanner selon le symptôme

Cette procédure vise une installation Nextcloud déjà servie par Apache sous Debian ou Ubuntu, avec un accès sudo et un nom de domaine que vous contrôlez.

Le résultat attendu avant de toucher à Apache

Une configuration saine donne quatre réponses faciles à reconnaître :

le domaine répond sur HTTP et cette requête rejoint ensuite la même adresse en HTTPS ;
le certificat présenté sur 443 correspond au nom de domaine et sa date d’expiration reste surveillée ;
Nextcloud accepte le nom public dans trusted_domains ;
les liens produits par Nextcloud et les clients WebDAV utilisent https://.

Le cadenas du navigateur ne suffit pas : il prouve une connexion TLS pour cette adresse, pas que les redirections, les liens générés et les clients CalDAV sont correctement alignés.

Préparer le domaine et l’accès HTTP

Créez un enregistrement DNS A vers l’adresse IPv4 du serveur. Si un enregistrement AAAA existe, il doit mener vers un serveur IPv6 qui sert le même vhost ; sinon retirez-le ou corrigez-le. Contrôlez la résolution et la réponse initiale avant de demander le certificat :

dig +short cloud.example.org A
dig +short cloud.example.org AAAA
curl --max-redirs 0 -I http://cloud.example.org/

Le port 80 doit être joignable depuis Internet, en plus du port 443. Le challenge HTTP-01 de Let’s Encrypt place un jeton sous /.well-known/acme-challenge/, puis le service de validation le récupère sur le port 80. Une ouverture du seul port 443 ne suffit pas à ce mode de validation. Le challenge DNS-01 convient à un certificat générique, mais demande une modification automatisée ou manuelle de la zone DNS.

Sauvegardez la configuration avant de modifier le vhost ou config.php. Adaptez le chemin à votre installation réelle, et gardez le répertoire de données hors de la racine Web, comme le recommande la documentation de durcissement Nextcloud :

sudo cp -a /var/www/nextcloud/config/config.php \
  /var/www/nextcloud/config/config.php.bak.$(date +%Y%m%d)

Déclarer Nextcloud dans le vhost Apache

Le vhost HTTP doit connaître le nom public et le répertoire qui contient Nextcloud. Remplacez /var/www/nextcloud par le chemin de votre installation. Le dossier de données ne doit pas être choisi comme DocumentRoot.

<VirtualHost *:80>
    ServerName cloud.example.org
    DocumentRoot /var/www/nextcloud

    <Directory /var/www/nextcloud/>
        Require all granted
        AllowOverride All
        Options FollowSymLinks MultiViews
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/nextcloud-error.log
    CustomLog ${APACHE_LOG_DIR}/nextcloud-access.log combined
</VirtualHost>

Activez les modules nécessaires, le vhost, puis refusez le rechargement si la syntaxe n’est pas valide :

sudo a2enmod rewrite headers env dir mime setenvif
sudo a2ensite nextcloud.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Le contrôle doit afficher Syntax OK. Si votre distribution fournit apachectl plutôt que apache2ctl, utilisez le nom installé par le paquet Apache.

Obtenir le certificat avec Certbot

Sur Debian ou Ubuntu, installez Certbot et son module Apache si ces paquets ne sont pas déjà présents :

sudo apt update
sudo apt install certbot python3-certbot-apache

Le module Apache peut à la fois demander le certificat et modifier la configuration du serveur. La documentation Certbot distingue cette opération de certonly, qui obtient le certificat sans l’installer dans le serveur Web :

sudo certbot --apache -d cloud.example.org

Répondez aux questions sur l’adresse de contact et la redirection HTTP quand elles apparaissent. Après la commande, relisez la configuration et rechargez Apache :

sudo apache2ctl configtest
sudo systemctl reload apache2

Si vous préférez garder la main sur le vhost SSL, utilisez le mode webroot. Le chemin donné à -w doit être exactement le DocumentRoot qui sert le domaine :

sudo certbot certonly --webroot \
  -w /var/www/nextcloud \
  -d cloud.example.org

Ajoutez alors un vhost sur 443 qui charge les fichiers créés sous /etc/letsencrypt/live/cloud.example.org/ :

<VirtualHost *:443>
    ServerName cloud.example.org
    DocumentRoot /var/www/nextcloud

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/cloud.example.org/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/cloud.example.org/privkey.pem

    <Directory /var/www/nextcloud/>
        Require all granted
        AllowOverride All
        Options FollowSymLinks MultiViews
    </Directory>
</VirtualHost>

Dans ce cas, activez aussi le module SSL avec sudo a2enmod ssl, vérifiez la syntaxe, puis rechargez Apache.

Faire passer les requêtes HTTP sur HTTPS

Une fois le certificat délivré, la requête HTTP doit répondre par une redirection vers le même nom en HTTPS. Si Certbot n’a pas posé cette règle, le vhost du port 80 peut être réduit à cette redirection :

<VirtualHost *:80>
    ServerName cloud.example.org
    RewriteEngine On
    RewriteRule ^/?(.*)$ https://cloud.example.org/$1 [R=301,L]
</VirtualHost>

Contrôlez les deux chemins sans suivre la redirection pendant le diagnostic :

curl --max-redirs 0 -I http://cloud.example.org/
curl -I https://cloud.example.org/

La première réponse doit annoncer une destination https://cloud.example.org/. La seconde peut être 200 ou une redirection applicative attendue, par exemple vers la connexion Nextcloud.

Dans le vhost 443, ajoutez HSTS seulement après avoir vérifié tous les sous-domaines et toutes les ressources qui doivent rester accessibles :

sudo a2enmod headers
Header always set Strict-Transport-Security "max-age=15552000"

Cette directive demande à un navigateur de ne plus revenir en HTTP pendant la durée indiquée. Une faute de certificat ou de sous-domaine devient alors plus difficile à corriger depuis ce navigateur.

Aligner le nom public dans Nextcloud

Nextcloud refuse un hôte absent de trusted_domains. Lisez d’abord la liste actuelle afin de choisir un index libre ; ne remplacez pas une adresse déjà utilisée :

sudo -u www-data php /var/www/nextcloud/occ config:system:get trusted_domains
sudo -u www-data php /var/www/nextcloud/occ config:system:set trusted_domains 1 --value=cloud.example.org

L’indice 1 est un exemple : utilisez l’indice disponible dans votre sortie. Fixez aussi l’URL de base utilisée par les commandes et les notifications générées côté serveur :

sudo -u www-data php /var/www/nextcloud/occ config:system:set \
  overwrite.cli.url --value=https://cloud.example.org

Avec Apache qui termine lui-même TLS, Nextcloud voit normalement la connexion HTTPS et overwriteprotocol n’est pas nécessaire. Vérifiez le domaine affiché dans l’interface d’administration et ouvrez une session dans une fenêtre privée pour repérer une ancienne URL HTTP.

Cas technique : le certificat est installé sur un proxy inverse

Si un autre serveur reçoit HTTPS puis transmet la requête à Apache, Nextcloud doit connaître l’adresse de ce proxy et le protocole présenté au visiteur. La documentation Nextcloud sur les reverse proxies recommande de déclarer explicitement les proxys de confiance :

'trusted_proxies' => [
    '10.0.0.10',
],
'overwriteprotocol' => 'https',
'overwritehost' => 'cloud.example.org',
'overwrite.cli.url' => 'https://cloud.example.org',

Remplacez 10.0.0.10 par l’adresse réelle du proxy, ou par les plages CIDR strictement nécessaires. Ne faites pas confiance à toutes les adresses : ces paramètres influencent l’adresse client et les liens générés. Le proxy doit transmettre le protocole et l’hôte d’origine ; une déclaration incorrecte de X-Forwarded-For peut permettre de falsifier l’adresse utilisée pour les contrôles d’accès.

Ne copiez pas cette variante dans une installation où Apache reçoit directement HTTPS. Dans ce cas, ajoutez uniquement le nom dans trusted_domains et contrôlez la sortie publique.

Rendre CalDAV et CardDAV découvrables

Les clients d’agenda et de contacts recherchent souvent les deux chemins .well-known. Pour Apache qui reçoit directement HTTPS, placez ces règles dans le vhost. Derrière un proxy inverse, placez-les sur le proxy, car Nextcloud recommande que ce serveur fasse la redirection :

RewriteEngine On
RewriteRule ^/\.well-known/carddav https://cloud.example.org/remote.php/dav/ [R=301,L]
RewriteRule ^/\.well-known/caldav https://cloud.example.org/remote.php/dav/ [R=301,L]

Vérifiez les destinations sans suivre la redirection :

curl --max-redirs 0 -I https://cloud.example.org/.well-known/carddav
curl --max-redirs 0 -I https://cloud.example.org/.well-known/caldav

Un code 301 ou 308 vers /remote.php/dav/ confirme que la découverte arrive au bon service. Si le serveur renvoie 404, contrôlez le contexte Apache de la règle et le module rewrite.

Contrôler le certificat et son renouvellement

Pour le domaine de votre installation, lisez le certificat présenté par le serveur et demandez à Certbot une simulation de renouvellement :

openssl s_client -connect cloud.example.org:443 \
  -servername cloud.example.org </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates
sudo certbot renew --dry-run

Le nom du sujet, l’émetteur et les dates doivent correspondre à l’hôte demandé. La simulation de renouvellement doit terminer sans erreur ; elle ne remplace pas la surveillance du service qui lance ensuite le renouvellement réel.

Contrôle reproductible du 16 septembre 2026 sur le domaine public nextcloud.com : la requête HTTPS a reçu HTTP 200 sans redirection, et le certificat exposé était émis par Let’s Encrypt sous l’autorité YE1, avec une validité du 9 septembre au 8 décembre 2026.

status=200 redirects=0 url=https://nextcloud.com/
subject=CN = nextcloud.com
issuer=C = US, O = Let's Encrypt, CN = YE1
notBefore=Sep  9 23:03:47 2026 GMT
notAfter=Dec  8 23:03:46 2026 GMT

La commande de contrôle est courte et reproductible ; exécutez-la sur votre propre nom, car le certificat et la réponse d’application appartiennent toujours au domaine interrogé.

Dépanner selon le symptôme

Le challenge HTTP-01 expire ou renvoie un délai d’attente : vérifiez les enregistrements A et AAAA, le pare-feu et l’accessibilité du port 80. Avec plusieurs serveurs, le fichier de challenge doit être disponible sur chacun.
Le navigateur alterne entre HTTP et HTTPS : vérifiez que le proxy transmet le protocole d’origine et que overwriteprotocol n’est utilisé que dans le cas du proxy inverse.
Nextcloud signale un domaine non approuvé : relisez trusted_domains et ajoutez le nom exact, sans chemin ni schéma.
Un client d’agenda ne trouve pas le serveur : contrôlez les deux règles .well-known et leur destination /remote.php/dav/.
Apache refuse de recharger : lancez sudo apache2ctl configtest, puis consultez sudo journalctl -u apache2 -n 50 --no-pager avant toute nouvelle modification.

Pour replacer les commandes Apache et les vérifications réseau dans l’administration du serveur, consultez les bases durables de Debian et les repères Linux et terminal. Pour choisir un service ou un logiciel selon ses formats, ses données et sa possibilité de sortie, utilisez la sélection de logiciels utiles.