Caddy, un serveur web sécurisé comme sur des roulettes

Nicolas Furno |

Sécuriser la connexion d’un site web entre votre navigateur et le serveur web grâce à un certificat TLS et une adresse en https devient de plus en plus un impératif. Même si certains acteurs reprochent ce choix, il s’est imposé notamment face à la pression des navigateurs web qui pointent du doigt les sites non sécurisés, et aussi celle de Google qui donne l’avantage dans ses résultats de recherche aux sites qui le sont.

Un site web non sécurisé affiché dans Firefox.

Depuis la création de Let’s Encrypt, on peut obtenir l’indispensable certificat TLS gratuitement et automatiquement. Néanmoins, les principaux serveurs web fonctionnent toujours sur un ancien modèle, non sécurisé par défaut. Apache comme nginx, les deux poids-lourds dans ce domaine, nécessitent une configuration spécifique pour qu’un site s’affiche en https, ils se contentent toujours du http par défaut. Certbot, l’outil qui sert à obtenir le certificat TLS fourni par Let’s Encrypt, peut aussi se charger de réaliser la configuration à votre place, certes, mais il existe une solution beaucoup plus simple encore.

Caddy est un serveur web écrit en Go qui existe depuis plusieurs années et qui vient de sortir en version 2. Il a été conçu à l’ère du web sécurisé et il fonctionne ainsi par défaut et fourni du https, sauf si vous lui demandez explicitement de ne pas le faire. Vous n’avez absolument rien à faire : si votre nom de domaine pointe déjà sur votre serveur web, il se chargera tout seul d’obtenir un certificat Let’s Encrypt et de le renouveler ensuite sans intervention de votre part. Il se chargera aussi de rediriger toutes les requêtes vers l’adresse en https, là encore sans configuration spécifique.

Avec la version 2, le créateur de Caddy s’est lancé dans une réécriture complète du code source. La première version avait été pensée avant tout pour gérer des sites web, mais cette mise à jour lui permet de remplacer d’autres composants des serveurs web. On peut s’en servir comme load balancer, pour répartir la charge sur plusieurs serveurs, mais c’est toujours un serveur de fichiers statiques extrêmement rapide, avec même la possibilité de convertir automatiquement du Markdown pour des sites simples.

Si vous utilisiez Caddy 1, vous devrez convertir vos fichiers de configuration, puisqu’il y a plusieurs changements importants détaillés dans ce guide. Si vous n’avez jamais entendu parler de Caddy et que vous gérez votre propre serveur web, sachez qu’il est fourni sous la forme d’un exécutable prêt à emploi pour toutes les plateformes. Vous pouvez aussi l’installer via Docker ou en utilisant le gestionnaire de paquets de la majorité des distributions Linux, comme expliqué à cette adresse1.

Caddy 2 se configure principalement par le biais du « Caddyfile », un fichier de configuration qui repose sur une syntaxe assez légère. Au strict minimum, il doit contenir un nom de domaine et soit une commande file_server pour un site web statique, soit une commande reverse_proxy pour utiliser un autre service web. Comme avec nginx, PHP n’est pas intégré par défaut, mais vous pouvez installer php-fpm et la commande php_fastcgi fournie par Caddy pour gérer la majorité des CMS.

À titre d’exemple, voici une configuration complète pour mon blog qui tourne sous WordPress :

voiretmanger.fr {
	root * /var/www/voiretmanger.fr
	encode gzip
	file_server
	php_fastcgi unix//run/php/php7.4-fpm-caddy.sock

	log {
		output file /var/log/caddy/voiretmanger.fr.access.log
	}
}
La configuration pour un site statique est très simple avec Caddy 2.

La configuration par le biais de ce fichier est la plus proche de celle des autres serveurs web et elle nécessite un reload du service Caddy à chaque modification. La version 2 ajoute une autre méthode, plus complexe à mettre en œuvre, mais aussi beaucoup plus puissante, basée sur une API et des fichiers JSON. À ce stade du développement, la configuration par Caddyfile n’est pas aussi complète et certaines opérations complexes nécessitent encore de passer par l’API, mais Caddy est toujours en développement.

Comme ses concurrents, Caddy 2 est un projet entièrement open-source et vous trouverez l’intégralité de son code source sur GitHub. Si vous développez en Go, vous pouvez même y contribuer, notamment en créant des modules qui viennent enrichir les fonctions de base du serveur web. Il en existe déjà une bonne vingtaine, dans des domaines variés. De quoi créer un serveur WebDAV, récupérer automatiquement un site web depuis un dépôt Git (travail en cours), convertir une configuration nginx en configuration Caddy ou encore protéger un site web avec un mot de passe.

Parmi les autres nouveautés de la deuxième version, signalons la possibilité de sécuriser aussi les sites locaux, utilisés notamment pendant le développement. Vous pourrez ainsi afficher un site avec le nom de domaine https://localhost/, ce qui est pratique pour avoir un site de développement aussi proche possible que celui en production. Cette fonction repose sur des certificats TLS spécifiques qui devront être acceptés manuellement dans le navigateur web.

Caddy n’est pas aussi connu que ses illustres concurrents, mais c’est un projet stable et capable de gérer un trafic important sans problème. Je l’utilise pour tous mes projets personnels depuis des années, et nous l’utilisons aussi à MacG pour un certain nombre de sites et services annexes. Le site web LeKeynote.fr tourne grâce à Caddy depuis plus d’un an sans encombre et avec une configuration largement simplifiée.

Si vous avez des questions sur Caddy 2, les forums associés au projet sont très actifs et il y a de nombreuses personnes pour vous aider, dont le principal développeur du serveur web lui-même.


  1. Vous pouvez aussi l’installer sur macOS grâce au gestionnaire de paquets Homebrew et la commande brew install caddy.  ↩

avatar MacoGeek | 

On utilise aussi caddy dans ma boîte. Et on se prend un vrai gros traffic en million de pages vues. Ça n’a pas à rougir devant nginx ou Apache. On va voir si on passe la cette nouvelle version.

avatar Nicolas Furno | 

@MacoGeek

Il faut un petit temps d’adaptation, mais Caddy 2 est déjà nettement mieux pensé et fini, je trouve.

Intéressant comme retour sur les volumes en tout cas ! Je voulais utiliser Caddy depuis longtemps sur le Keynote et j’avais peur que ça ne tienne pas lors des pics liés aux conférences. Rétrospectivement, il n’y avait rien à craindre en effet, c’est du solide.

avatar C2SC3S | 

Encore les roulettes? C’est une obsession?

avatar iValFR | 

@C2SC3S

😂

avatar Scooby-Doo | 

@C2SC3S,

« Encore les roulettes ? C’est une obsession ? »

A priori, MacG est très fan des super roulettes du Mac Pro.

Du moment que Caddy 2 roule, tout va bien...

😉

avatar pakal | 

merci pour cette info très complète

avatar joelcro | 

Quelqu'un pourrait-il éclairer ma lanterne? J'ai un NAS (QNAP) avec un certificat let's encrypt. J'envoie pas mal de fichier et de dossier via la NAS. Lorsqu'un navigateur se connecte pour la première fois, il faut valider ce certificat et, pour des utilisateurs non avertis, les messages affichés par les navigateurs sont un peu abscons et anxiogènes. Du coup, retour de message paniqué des destinataires. Est-ce un comportement normal ou y-a-t-il un problème avec mon NAS ?
J'ai un peu cherché sur le net mais je n'ai rien trouvé de concluant.
Passer sur un certificat payant solutionnerait il ce comportement ?

avatar Nicolas Furno | 

@joelcro

Non, ce n’est pas normal. La configuration doit poser problème à mon avis, mais en tout cas, les certificats Let’s Encrypt sont acceptés par tous les navigateurs sans problème.

avatar joelcro | 

OK merci. Donc il faut que je fouille mieux.

avatar joelcro | 

aaaah mais ça y est je crois que j'ai compris. Il faut forcément que j'envoie les liens via le xxxx.myqnapcloud.com, pas via l'adresse IP puisque le certificat est rattaché à l'adresse Qnapcloud. Quelle quiche.

avatar Nicolas Furno | 

@joelcro

Ah ben oui, les certificats c’est toujours pour le nom de domaine. :-)

avatar joelcro | 

Encore une fois, le problème est situé devant le clavier 😁

avatar Felixba | 

Ca m’a l’air intéressant tout ça, malheureusement je n’ai rien compris 🤦‍♂️
Étant donné que mon Joomla saute dès qu’on dépasse les 200 visiteurs simultanés va falloir que je me documente sur Caddy.

avatar Nicolas Furno | 

@Felixba

Désolé si l'article n'est pas assez clair, j'ai essayé de tout expliquer, mais il faut quelques connaissances sur les serveurs web, en effet.

Et à mon avis, c'est plus Joomla que le serveur qui pose problème, Caddy n'y changera rien. Mais en tout cas, Caddy peut gérer bien plus que 200 utilisateurs connectés, bien bien plus.

avatar pilipe | 

Pour ma part j’utilise des caddies pour faire les courses, mais je suis hors sujet :-O

avatar scribe | 

Rien compris non plus. Mais il faut dire que je ne sais même pas précisément ce que désigne le terme « serveur » — à part au bistro…

avatar andr3 | 

Sympa le site voiretmanger.fr. Je ne connaissais pas ... maintenant oui 😊

avatar Monsieur Saucisse | 

Malin le module de récupération automatique d’un site web depuis un dépôt Git.

Je me demande si ça peut se combiner avec un générateur de sites statiques (genre Hugo ou Jekyll)...

avatar Nicolas Furno | 

@Monsieur Saucisse

Complètement ! Hugo comme Jekyll savent déjà surveiller un dossier pour générer une nouvelle copie du site.

avatar Monsieur Saucisse | 

@Nicolas Furno

En y regardant plus attentivement, je pense que quelque chose m’échappe.

Hugo et Jekyll ont besoin d’un service d’intégration continue (GitHub Actions par exemple) pour construire automatique le site à partir des sources.

Et si j’ai bien compris le fonctionnement du module, il se contente de faire un pull régulier sur un dépôt Git.

Or le site « construit » n’est pas stocké dans le dépôt, uniquement le source. Ou alors ça implique d’y stocker aussi le résultat de la construction, ce qui est beaucoup moins élégant je trouve.

avatar Nicolas Furno | 

@Monsieur Saucisse

Hugo (ou Jekyll) doit aussi être installé sur le serveur en effet, pour générer le site dans la foulée.

Après, en intégration continue, autant générer le site côté Git et le déployer avec un rsync ou autre, je pense.

avatar jackhal | 

Perso je continue d'utiliser Apache. J'ai essayé d'autres choses (NGINX, Varnish...) mais Apache se révèle être très performant.
Parfois, au lieu de changer pour la dernière techno en vue, il est préférable d'apprendre à configurer ce qu'on utilise déjà. Et bon, pour Apache, c'est sûr : la config par défaut permet un nombre incroyable de choses. Trop, et ça grève ses performances... mais une fois configuré, il tient la route face à la concurrence.
Pour l'anecdote, et vu où je poste ce message, le site d'Apple utilise Apache.

avatar Nicolas Furno | 

@jackhal

On utilise aussi Apache à MacG, mais pas tant par choix que par nécessité/simplicité (la force du fichier .htaccess, et les contraintes imposées par les CMS…).

Cela dit, Apache nécessite un gros travail pour avoir un bon résultat. Avec Caddy, c’est par défaut. Je ne dis pas que c’est mieux parce que c’est nouveau, mais c’est clairement mieux pour moi, parce qu’il nécessite beaucoup moins de travail. Et moins de connaissance, ne serait-que sur la partie TLS qu’il gère tout seul sans discuter.

avatar jackhal | 

"la force du fichier .htaccess"
Comme dirait Nginx quand on leur demande cette fonctionnalité : "If you need .htaccess, you’re probably doing it wrong." ^^ :
https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-ht...

Quand htaccess est laissé actif, c'est la première raison pour laquelle Apache perd nettement dans les benchs, qui se contentent généralement de demander quantité de fichiers statiques.

Bon après, tant que ça ne rame pas, c'est déjà ça. Mais j'évite tous les accès disques inutiles tout de même.

avatar Nicolas Furno | 

@jackhal

Ah ça, je suis le premier à vouloir le supprimer ! Mais quand on repose sur un (vieux) CMS, il n’y a parfois pas le choix.

Ça fait un moment que l’on veut utiliser nginx uniquement sur notre architecture serveur principale, mais on a encore des modules qui dépendent de ça, et ce serait trop compliqué de faire sans. Du coup, on garde les deux en parallèle…

Pages

CONNEXION UTILISATEUR