.png)
Bonjour à tous,
+ ++ +
Comme le dit si bien le titre, non le blog n'est pas mort.
+ +Bon, il est pas non plus hyper vivant je me fais pas d'illusions...
+ + +J'ai malheureusement (à ma grande honte) disposé et débloqué très peu de temps pour m'en occuper.
+ +Du coup, il y a plusieurs brouillons dans les tuyaux, pas mal d'idées, des articles pas finis, ...
+ ++ +
J'ai conscience que c'est un peu frustrant, et je vois régulièrement des commentaires qui montrent que le blog est toujours lu.
+ +En attendant d'avoir le temps de faire plus (j'y compte bien, sisi !), je vous annonce la mise en place d'une page "Contact".
+ +Disponible en haut du blog parmi les sections (Articles, Présentation, ...), cela vous permettra de m'envoyer directement un courriel si vous souhaitez discuter d'un article, poser une question, avancer de votre côté sur un quelconque problème levé par un article, etc.
+ ++ +
L'idée étant principalement que le système de commentaire est assez vite limité pour les échanges vraiment constructifs et les questions qui y sont parfois posées sont compliquées à répondre dans un si petit espace.
+ +Un courriel permettra d'initier un vrai dialogue ! ;)
+ +N'hésitez donc pas à me contacter sur ce formulaire de contact (avec une adresse valable si vous souhaitez que je vous réponde \o/ ) et je reviendrai vers vous avec grand plaisir !
+ +A très bientôt à tous, merci pour votre soutien et vos différents commentaires sur mes articles !
+ +Victor
diff --git a/content/Système/cluster-proxmox-distant-1.4-concept.md b/content/Système/cluster-proxmox-distant-1.4-concept.md index e9fbe04..d22eabd 100644 --- a/content/Système/cluster-proxmox-distant-1.4-concept.md +++ b/content/Système/cluster-proxmox-distant-1.4-concept.md @@ -1,5 +1,5 @@ -Title: Cluster Proxmox distant (1/4) -subtitle: ; le concept +Title: Le concept du cluster +subtitle: ; cluster Proxmox distant (1/4) Date: 2013-01-16 19:00 Modified: 2013-01-16 19:00 Category: Système diff --git a/content/Système/cluster-proxmox-distant-2.4-construction-cluster.md b/content/Système/cluster-proxmox-distant-2.4-construction-cluster.md index 8ede0e5..c871cc0 100644 --- a/content/Système/cluster-proxmox-distant-2.4-construction-cluster.md +++ b/content/Système/cluster-proxmox-distant-2.4-construction-cluster.md @@ -1,5 +1,5 @@ -Title: Cluster Proxmox distant (2/4) -subtitle: ; construction du cluster (openvpn) +Title: Construction du cluster (openvpn) +subtitle: ; cluster Proxmox distant (2/4) Date: 2013-02-02 13:35 Modified: 2013-02-02 13:35 Tags: proxmox, debian, iptables, linux, sécurité, tunnel, cluster, haute disponibilité @@ -32,7 +32,7 @@ Status: published
Les fichiers up.sh et down.sh sont différents pour les clients. Comme le serveur principal possède déjà up.sh et down.sh, on les nomme upclient.sh et downclient.sh pour qu'ils ne se marchent pas dessus (quelle imagination ! 
)
Les fichiers up.sh et down.sh sont différents pour les clients. Comme le serveur principal possède déjà up.sh et down.sh, on les nomme upclient.sh et downclient.sh pour qu'ils ne se marchent pas dessus (quelle imagination ! \o/)
Donc, upclient.sh :
diff --git a/content/Système/configurer-reverse-proxy-apache.md b/content/Système/configurer-reverse-proxy-apache.md index 46bcfaa..95fcf9b 100644 --- a/content/Système/configurer-reverse-proxy-apache.md +++ b/content/Système/configurer-reverse-proxy-apache.md @@ -34,7 +34,7 @@ Status: publishedOn y arrive. ;-)
-EDIT décembre 2015 : j'ai écris un nouvel article pour utiliser haproxy en tant que reverse-proxy, logiciel plus léger et plus adapté qu'apache à cet usage.
+EDIT décembre 2015 : j'ai écris un nouvel article pour utiliser haproxy en tant que reverse-proxy, logiciel plus léger et plus adapté qu'apache à cet usage.
Or donc, si vous avez plusieurs serveurs web mais une seule connexion Internet, alors vous avez sans doute déjà eu cette problématique.
diff --git a/content/Système/configurer-reverse-proxy-haproxy.md b/content/Système/configurer-reverse-proxy-haproxy.md new file mode 100644 index 0000000..3b3959c --- /dev/null +++ b/content/Système/configurer-reverse-proxy-haproxy.md @@ -0,0 +1,354 @@ +Title: Configurer un reverse proxy avec haproxy +subtitle: (HTTP/HTTPS) +Date: 2015-12-11 09:16 +Modified: 2015-12-11 09:16 +Tags: haute disponibilité, hébergement, reverse proxy, nom de domaine, debian, linux, haproxy +keywords: haute disponibilité, hébergement, reverse proxy, nom de domaine, debian, linux, haproxy +Slug: configurer-reverse-proxy-haproxy +Authors: Victor +Status: published + +[TOC] + +## Ou : utilisons un logiciel dont c'est le taf de proxyfier :-) + +(Oui, j'assume le verbe proxyfier, na)
+ +Il y a quelques temps, j'avais fait un article pour configurer apache en mode reverse proxy.
+ +Je vous invite à le relire rapidement (au moins le chapô ;-) ) pour savoir de quoi l'on parle avec le terme reverse proxy.
+ +Bien que ça fonctionne très bien, il existe des logiciels dédiés à la mise en place d'un reverse proxy, à mettre devant le serveur web.
+ +Le logiciel auquel nous allons nous intéresser aujourd'hui est haproxy et est justement dédié à cet usage.
+ +À noter que nous allons l'utiliser ici en tant que proxy HTTP/HTTPS, mais que haproxy peut servir de proxy pour n'importe quoi, du serveur de messagerie à un serveur mysql, et globalement à tout ce qui utilise TCP.
+ +## Pourquoi que donc ? + +Avoir un reverse proxy devant son serveur web présente plusieurs avantages.
+ +Une fois n'est pas coutume, attaquons le concret :)
+ +## Pré-requis + +Pour que cela fonctionne, il vous faut au minimum un serveur web fonctionnel. Il peut être sous apache, nginx, ou même IIS pourquoi pas.
+ +C'est vers lui que nous redirigerons les requêtes.
+ +Il vous faut également un serveur où installer haproxy.
+ +Dans cet exemple, nous prendrons un serveur dédié à cet usage. Cependant, il est aussi possible d'installer haproxy SUR le serveur hébergeant le serveur web (s'il est sous Linux). Ce n'est pas le sujet ici :-)
+ ++ +
Nous allons donc partir sur un serveur web, et un serveur "passerelle" qui possédera l'adresse publique de votre site, et sur lequel nous installerons haproxy.
+ +Dans notre exemple, ce serveur passerelle sera sous debian 8.
+ +Soit vous avez des serveurs physiques, soit vous les virtualisez.
+ +Si vous vous auto-hébergez, vous ne pourrez pas utiliser votre adresse publique sur votre serveur passerelle. Dans ce cas, mettez en place une redirection de port vers votre serveur passerelle sur votre machinbox (ou routeur). Les ports 80 et 443 suffiront :-)
+ +## Terminologie + +Haproxy utilise des termes assez classiques dans sa configuration, mais que nous allons tout de même revoir ici afin de bien savoir de quoi l'on parle dans la suite.
+ +On commence par installer haproxy. Il est de base dans debian (depuis la version 6)
+ +Si vous voulez faire de l'https, il vous faudra la version au moins 1.5 de haproxy. (disponible dans les backports debian 7 ou nativement sous debian 8)
+ +Si vous voulez plus de détails sur les versions à installer, rendez vous sur http://haproxy.debian.net/
+ ++aptitude update +aptitude install haproxy+ +### Global et default + +
Les 2 sections global et default permettent de définir des variables qui seront appliquées à tout le reste de la configuration (sauf redéfinition plus précise dans un sous bloc).
+ +Les paramètres définit à l'installation sont corrects, vous pouvez donc laisser ces sections ainsi pour l'instant.
+ +### Où configurer + +Le fichier de configuration de haproxy est placé dans /etc/haproxy/haproxy.cfg. Néanmoins, pour que cela soit plus pratique à configurer, vous pouvez écrire vos configurations personnalisées dans un fichier /etc/haproxy/haproxy.local, cela évitera d'avoir à modifier le fichier par défaut.
+ +### Configuration du frontend + +Nous allons voir ici une configuration de frontend basique. Il est possible de faire des choses très compliquées, mais on va rester simple pour l'instant :-)
+ ++frontend http-in + bind IP_PUBLIQUE:80 + mode http + option httplog + acl your_acl hdr(host) votresiteweb.tld + use_backend backend1 if your_acl ++ +
Attention, l'indentation est importante !
+ +Tous les paramètres du bloc doivent être décalés en dessous pour que haproxy voit que ces paramètres font parti du bloc. En général, une tabulation ou X espaces, selon les préférences.
+ +Vous définissez :
+ +Et voila, en 5 lignes, vous avez configuré un premier frontend pour rediriger votresiteweb.tld vers un backend (qu'il reste à écrire)
+ +On voit déjà que la syntaxe est très simple par rapport à apache (plus de ProxyPass avec des paramètres pas toujours clairs).
+ +On a ici une configuration très simpliste. Je présenterai quelques options montrant la puissance d'haproxy à la fin de cet article.
+ +### Configuration du backend + +Maintenant que notre frontend est prêt à recevoir les requêtes publiques, il faut créer le backend qui sera à même de savoir où envoyer ces requêtes.
+ +
+backend backend1
+ mode http
+ option httpchk
+ option forwardfor except 127.0.0.1
+ http-request add-header X-Forwarded-Proto https if { ssl_fc }
+ server web-server1 IP_SERVEUR_WEB:80 maxconn 32
+
+
+De la même manière que pour le frontend, attention à l'indentation pour que les paramètres soient décalés en dessous du mot clef backend
+ +Ici vous définissez :
+ +A partir de là, c'est tout bon. Vous avez une configuration, certes basique, qui vous permettra de recevoir des requêtes pour votre site, et les transmettre vers votre serveur web :-)
+ +Bien sûr, redémarrez haproxy pour appliquer la configuration.
+ ++systemctl restart haproxy+ +## Un peu plus loin : https + +### frontend + +
Jusqu'ici, le frontend était uniquement http, pas de certificat.
+ +Mettre en place un frontend https est tout ce qu'il y a de plus simple. On va tout simplement créer un deuxième frontend, cette fois bindé sur le port 443
+ ++frontend https-in + bind IP_PUBLIQUE:443 ssl crt /etc/haproxy/cert/ no-sslv3 + mode http + option httplog + acl your_acl hdr(host) votresiteweb.tld + use_backend backend1 if your_acl ++ +
On voit quelques différences par rapport à la configuration définie plus haut.
+ ++cat domain.tld.crt domain.tld.key > domain.tld.pem+ +
Toutes les autres options sont les même que pour le frontend HTTP (acl, use_backend, ...)
+ +### Note sur le dossier des certificats + +haproxy gère de manière très efficace les certificats. Vous pouvez les mettre en vrac dans le répertoire, haproxy les parse au démarrage et utilise les certificat de la manière la plus précise possible.
+ +Si par exemple vous possédez un certificat wildcard (*.domain.tld) et un certificat plus précis (sous.domain.tld)
+ +Comme c'est le frontend qui gère la partie HTTPS, vous pouvez utiliser exactement les même backend pour le frontend http et le frontend https. Rien à faire à ce niveau là donc, tout est déjà bon dans la configuration.
+ +Redémarrez haproxy, et votre site est prêt à fonctionner en HTTPS !
+ +## Encore plus loin : options sympathiques + +Cette liste n'est clairement pas exhaustive, haproxy disposant d'une foison incroyable de possibilités. Je ne liste ici que celles qui me semblent les plus utiles de manière générales (en gros, celles que j'utilise moi :-D )
+ +Pour une liste complète, je vous invite à vous référer à la documentation haproxy qui est vraiment très claire et détaillée avec tous les exemples nécessaires à la compréhension.
+ +### Plusieurs sites dans un frontend + +Comme vous ne pouvez créer qu'un seul frontend écoutant sur le port 80 (ou 443) sur une adresse IP, il va falloir utiliser le même frontend pour gérer plusieurs sites.
+ +Cela se fait très simplement, en utilisant plusieurs acl dans le frontend, par exemple :
+ ++acl site1 hdr(host) site1.tld +acl sous-domaine hdr(host) sousdomain.site1.tld +acl toto-site2 hdr(host) toto.site2.tld ++ +
Vous pouvez ensuite utiliser un ou plusieurs backend selon les acl :
+ ++use_backend backend1 if site1 or sous-domaine or toto-site2+ +
Ou encore :
+ ++use_backend backend1 if site1 or sous-domaine +use_backend backend2 if toto-site2+ +### Test de domaine dans un frontend + +
Dans mes exemples, j'ai à chaque fois utilisé hdr(host) dans mes acl, qui permet de chercher le contenu exact de la variable HOST de la requête HTTP.
+ +Néanmoins, il est possible de faire plus général, comme par exemple créer des acl en se basant sur la fin du HOST, le début, voir chercher si HOST contient telle ou telle chaîne de caractère.
+ +Cela peut permettre de créer une acl qui gérera tout ce qui se termine par site.tdl, tout ce qui contient www., etc
+ ++acl test1 hdr_beg(host) www. #On match ce qui commence par www. +acl test2 hdr_end(host) domain.tld #On match tout ce qui termine par domain.tld +acl test3 hdr_reg(host) REGEX #On match tout ce qui correspond à l'expression régulière REGEX ++ +
Vous êtes ensuite libre d'utiliser ces acl dans les backend que vous voulez.
+ +### Backend par défaut, aussi nommé la poubelle + +Une fonctionnalité que je trouve assez intéressante est de prévoir un backend par défaut qui servira de poubelle. Toutes les visites arrivant sur votre serveur et qui ne matchent pas une acl peuvent être considérées comme de la poubelle, voire comme une attaque potentielle, et donc autant ne pas les rediriger vers un site par défaut (comme le fait par exemple de base le vhost apache default)
+ +Pour cela, il suffit d'ajouter dans le frontend le mot clef default_backend qui permet de définir un backend qui sera utilisé pour les requêtes n'ayant matché aucune acl dans le frontend, et de créer un backend qui renverra par exemple une erreur 403 "accès interdit" :
+ ++frontend http-in + [...] + default_backend poubelle + +backend poubelle + mode http + http-request deny ++ +### Répartition de charge avec un backend + +
Si vous définissez plusieurs lignes de server dans un backend, alors haproxy va automatiquement répartir (via le protocole round robin) les requêtes entrantes de manière équitables entre les serveurs.
+ +Mais il est également possible de définir des poids pour ces serveurs, si par exemple l'un d'eux est plus puissant, plus à même de recevoir des requêtes
+ ++backend backend1 + [...] + server server1 ip1:80 weight 1 + server server2 ip2:80 weight 2 ++ +
Ici server2 encaissera 2 fois plus de requêtes que server1
+ +Vous pouvez utiliser le mot clef backup :
+ ++backend backend1 + [...] + server server1 ip1:80 + server server2 ip2:80 backup ++ +
Ici, server1 recevra toutes les requêtes, mais si haproxy détecte qu'il n'est plus accessible, alors il enverra automatiquement toutes les requêtes vers server2
+ +Il est possible aussi de combiner ces 2 techniques, faire de la répartition de charge entre plusieurs serveurs tout en ayant d'autres disponibles en backup.
+ +### Forcer l'https + +Il est possible de dire à haproxy, dans votre frontend sur le port 80, que tel site doit absolument utiliser l'HTTPS. Auquel cas, si haproxy reçoit une requête en HTTP, alors il redirigera immédiatement le visiteur vers exactement la même requête mais en HTTPS :
+ +
+frontend http-in
+ [...]
+ # On a plusieurs acl
+ acl site1 hdr(host) site1.tld
+ acl sous-domaine hdr(host) sousdomaine.site1.tld
+ acl toto-site2 hdr(host) toto.site2.tld
+
+ redirect scheme https code 301 if !{ ssl_fc } site1.tld or sous-domaine
+ use_backend backend2 if toto-site2
+
+
+Ici, on va forcer via un code 301 (redirection permanente) la redirection vers l'HTTPS (on détecte que le protocole ssl n'est pas utilisé) pour les accès sur site1.tld et sousdomaine.site1.tld, mais on reste en HTTP et on utilise backend2 si la visite est sur toto.site2.tld
+ +### Réécrire des en-têtes dans le backend + +On a vu un exemple de réécriture d'en tête dans la partie sur les backend avec le xForwarFor.
+ +Il est possible dans un backend d'écrire tous les en têtes que vous voulez.
+ +Par exemple, si le frontend devant le backend est en https, vous pouvez ajouter un en-tête qui indiquera au serveur web derrière qu'il y a eu traitement https, ce même si le serveur web ne voit jamais le certificat puisque c'est haproxy qui s'en occupe :
+ +
+backend backend1
+ [...]
+ http-request add-header X-Forwarded-Proto https if { ssl_fc }
+
+
+Vous pouvez ainsi écrire (ou réécrire) n'importe quel en-tête.
+ +Par exemple pour réécrire l'en tête serveur :
+ ++backend backend1 + [...] + rspidel ^server #On commence par effacer l'en tête serveur déjà présent + rspadd Server:\ Vous\ utilisez\ mon\ super\ serveur\ ! #On rajoute un nouvel en-tete Server (attention à bien protéger les espaces par des \) ++ +
+ +
Voila pour ce tour d'horizon (pas si) rapide sur haproxy !
+ +J'espère que cela vous permettra de vous familiariser avec ce logiciel, qui n'a été ici qu'à peine effleuré :-)
+ +Comme toujours, n'hésitez pas à poser vos questions dans les commentaires !
diff --git a/content/Système/use-letsencrypt-haproxy.md b/content/Système/use-letsencrypt-haproxy.md new file mode 100644 index 0000000..8ddbb14 --- /dev/null +++ b/content/Système/use-letsencrypt-haproxy.md @@ -0,0 +1,256 @@ +Title: Use Haproxy with Let's Encrypt +Date: 2015-12-18 09:33 +Modified: 2015-12-18 09:33 +Tags: haproxy, hébergement, reverse proxy, sécurité, système +keywords: haproxy, hébergement, reverse proxy, sécurité, système +Slug: utiliser-letsencrypt-haproxy +Authors: Victor +Status: published +lang: en + +[TOC] + +## First: what are we talking about? + +Note : Ceci est la version anglaise de l'article, pour la version française, voir ici.
+ +### Haproxy : + +Haproxy is a proxy software. It has many use, but here we will use its capacity to reverse proxying HTTP and HTTPS.
+ +For this post, we will consider you have a working Haproxy server and a working configuration.
+ +### Let's Encrypt : + +Let's Encrypt is an open source project sponsored by Mozilla foundation and Cisco.
+ +Idea is to create an free certificate authority in order to create SSL certificate and doing so, allowing to most people possible to use HTTPS and secure websites.
+ +Regarding usual cost of SSL certificate, this a very interesting project!
+ +In addition to that, Let's Encrypt is really easy to use, mainly thank to an API allowing to create certificate very easily.
+ +We will use this API in this post through Let's Encrypt official python client.
+ +EDIT : 04/04/16 : add note about case when you use redirect HTTP to HTTPS in your HTTP haproxy frontend
+ +EDIT : 09/16/16 : Update with new binary + add git repository with some scritps to automate LE management
+ +## Concept + +Let's Encrypt offers many option to create and validate certificate via its client.
+ +If your Haproxy is localised on the same server than your web server, you can use the --webroot option, which allow Let's Encrypt to store a special file directly in the root directory of your website, in order to allow Let's Encrypt server to request the file and validate that you are the real owner of the domain.
+ +If you want to use this option, you can read this blog post about using webroot and haproxy, including using a dedicated apache webserver for validation.
+ +For this post, we will use instead the --standalone option, which launch a mini-webserver. This webserver will be used for the validation process, as Let's Encrypt server will request it directly. Usually, this option has a big disadvantage: as the webserver bind on 80 network port, the real webserver needs to be temporally shutdown during the validation process.
+ +In other word, your website(s) will be unavailable during all the process.
+ +But we are going to use an option to change the default port, in coordination with haproxy frontend/backend capabilities, to allow validation without any downtime :-)
+ +-- Many thanks to coolaj86 as his post give me this idea to use haproxy and Let's Encrypt together ;-) --
+ +## Get Let's Encrypt client + +As LE is now officially released, a new official binary is available, more advanced and more easy to use than the previous letsencrypt-auto
+ +All information are available on the certbot official website, but here are quick instructions how to use it.
+ +cd /root/
mkdir letsencrypt
cd letsencrypt
wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
+You can next directly use the binary to get your new certificate (at least, once you have configured as this blog article describes it :-p)
./certbot-auto certonly --domains blog.victor-hery.com --renew-by-default --http-01-port 63443 --agree-tos
To avoid any downtime, we will use your existing frontend.
+ +Let's Encrypt will request the IP address which resolve your website, so if you have many frontends or many IPs, you need to configure each frontend according to your needs.
+ +Main idea is : during the process, Let's Encrypt request the base website URL, following by /.well-known/acme-challenge/a_unique_id.
+ +So we are going to configure a haproxy ACL which match this path to redirect it to a specific backend!
+ ++frontend http-in + acl app_letsencrypt path_beg /.well-known/acme-challenge/ + [...] + use_backend bk-letsencrypt if app_letsencrypt ++ +
Doing so, all Let's Encrypt requests will be redirected to the bk-letsencrypt backend.
+ +Warning : if you are using redirect from HTTP to HTTPS for your website, haproxy will also redirect Let's Encrypt request to your HTTPS frontend.
+ +You will then need to add the acl and use_backend lines to your HTTPS frontend as well, or let's encrypt will get 404 not found answer.
+ +### Backend + +About the backend, we are going to configure it to redirect request to the server launched by Let's Encrypt client.
+ ++backend bk-letsencrypt + log global + mode http + server srv_letsencrypt 127.0.0.1:63443 ++ +
The local server will not always be up, only when the client is running. Rest of the time, haproxy will return a 503 error if someone try to get an URL matching the ACL.
+ +Of course, you need to reload haproxy after doing these modifications.
+ ++systemctl reload haproxy.service+ +## Configure and use of Let's Encrypt + +#### Configuration : + +
To simplify the command line usage, we use a configuration file for Let's Encrypt client.
+ +By default, the client uses the file /etc/letsencrypt/cli.ini. So this is the file we are going to edit.
+ ++rsa-key-size = 4096 +email = your_admin_email +authenticator = standalone +standalone-supported-challenges = http-01 ++ +
Using HTTP for the verification process is safe, as only the verification request will be send in clear, and it has no secret inside.
+ +### Generate the certificate + +The command line to use to generate your certificate is the following:
+ ++/root/letsencrypt/certbot-auto certonly --domains yourdomain.tld --renew-by-default --http-01-port 63443 --agree-tos+ +
Certificates are created in a directory called /etc/letsencrypt/live/yourdomain.tld/ by the client during the generation process.
+ +You will find multiple files inside:
+ +In order to use with haproxy, you need to concatenate fullchain.pem and privkey.pem, and store it where haproxy read its certificates.
+ ++cat fullchain.pem privkey.pem > domain.tld.pem+ +
For example for the following HTTPS frontend:
+ ++frontend https-in + bind IP:443 ssl crt /etc/haproxy/cert/ ++ +
Here we need to store the domain.tld.pem file in /etc/haproxy/cert/
+ +Once your certificate is stored in the right place, reload haproxy for it to re-read certificate, and everything should be OK.
+ +Of course do not forget to configure an HTTPS frontend with correct ACL for your website in haproxy!
+ +Usually, simply copy/paste of your HTTP frontend changing port to 443 (and adding ssl and crt option) will do the job.
+ +## Limitations + +### Renew the certificate + +Even from the end of beta time, LE has taken decision to provide certificate for 90 days duration max. It allow them to avoid abuse usage and to make the project alive by forcing regular renew.
+ +Note that unlilke the beta client, certbot-auto is capable to use all your available certificates (thanks to the directory/etc/letsencrypt/renewal/) to allow automatic renewal .
+ +So remember to configure a cron job on your server to renew certificate:
+ ++crontab -e ++ +
+#renew certificate +30 01 01,10,20,30 * * /root/letsencrypt/certbot-auto renew+ +
This cron task will launch the renew command each 10 days to be sure your certificates will stay valids.
+ +Do not forget that you still need to create the .pem from fullchain.pem and .key to give it to haproxy. See below for some automation about this task!
+ +### Rate limit of certificate by domain + +Because of its free use Let's Encrypt use a rate-limit sysytem to avoid generation of too many certificate for the same domain.
+ +You will get an error if you try to generate too quickly or too often certificates for the same domain
+ +Be careful: the limitation take into account subdomain as well! All certificates finishing with domain.tld will be count.
+ +### iNS : + +For the moment, Let's Encrypt does not allow certificate for international Domain Name.
+ +This is impossible to generate a certificate for a domain or subdomain containing accent or special characters.
+ +For example, impossible to generate certificate for https://blog.héry.com unfortunately.
+ +There is currently a boulder on Let's Encrypt github, but it is still no available. If you are willing to help or need the function, does not hesitate to join :-)
+ +## Bonus: some scripts + +In order to make the process easier, I have written some scripts to allo generation and renewal of certificate, and haproxy interactions, easier.
+ +They are available in my git repository, so you can easily clone them in your server:
+ +git clone https://git.lecygnenoir.info/LecygneNoir/letsencrypt-haproxy.git
README simply describes how to use them, it pretty simple.
+ +create-certificate allow you to create a certificate for the domain you pass to the script, then it creates the .pem for haproxy, store it in the given directory and reload haproxy.
+ +renew-certificates only renew all certificates that need to be renewed, creates as well haproxy pem files, en reload haproxy. You can use renew-certificate in our cron task as explained before if you want.
+ +Do not forget to check path in scripts, mainly where to store certificates for haproxy, and path to certbot binary
+ +And voila, with all of that, you should be able to create all certificates you need, and use them directly in haproxy, without any downtime! So, welcome in the HTTPS world :-)
diff --git a/content/Système/utiliser-letsencrypt-haproxy.md b/content/Système/utiliser-letsencrypt-haproxy.md new file mode 100644 index 0000000..d37b8e2 --- /dev/null +++ b/content/Système/utiliser-letsencrypt-haproxy.md @@ -0,0 +1,256 @@ +Title: Utiliser Let's Encrypt avec Haproxy +Date: 2015-12-18 09:33 +Modified: 2015-12-18 09:33 +Tags: haproxy, hébergement, reverse proxy, sécurité, système +keywords: haproxy, hébergement, reverse proxy, sécurité, système +Slug: utiliser-letsencrypt-haproxy +Authors: Victor +Status: published +lang: fr + +[TOC] + +## De quoi parle-t-on donc ? + +Note: This is the French version of the post. English version here.
+ +### Haproxy : + +Haproxy est un logiciel de proxy. Il peut servir à beaucoup de chose, ici nous l'utiliserons pour de l'https et de l'http. Je vous invite à lire mon article à ce sujet si vous voulez en savoir plus.
+ +Dans cet article, nous considérerons que vous avez un serveur avec Haproxy fonctionnel pour les tests.
+ +### Let's Encrypt : + +Let's Encrypt est un projet soutenu entre autre par la fondation Mozilla et Cisco.
+ +L'idée est de mettre en place une autorité de certification gratuite pour créer des certificats SSL et permettre au plus grand nombre de personne de sécuriser leurs sites web.
+ +Au regard du prix habituel d'un certificat, c'est un projet vraiment très intéressant !
+ +D'autant plus qu'il est vraiment axé sur la facilité d'utilisation, avec notamment une API permettant de créer des certificats de manière simple.
+ +Nous nous appuierons ici sur cette API, à travers un client créé par Let's Encrypt.
+ +EDIT : 04/04/16 : ajout d'une note si vous utilisez des redirect de l'http vers l'https, pour permettre le renouvellement auto de letsencrypt
+ +EDIT : 16/09/16 : Mise à jour avec les nouveaux binaires suite à la sortie de bêta de LE + amélioration et versionning des Scripts
+ + +## Concept + +Let's Encrypt propose plusieurs options via le client pour télécharger et valider un certificat SSL.
+ +Si votre haproxy est sur le même serveur que le serveur web, vous pouvez utiliser l'option --webroot, qui permet de placer un fichier à la racine de votre site, que le site letsencrypt ira vérifier pour valider que vous possédez bien le site web. Si vous souhaitez utiliser cette technique, cet article de blog explique très bien comment le faire interagir en utilisant un serveur apache dédié.
+ +Dans cet article, nous utiliserons l'option --standalone qui permet de lancer un mini serveur web, qui contiendra le fichier de vérification et qui sera utilisé par le site letsencrypt. Cette option présente à première vue l'inconvénient de devoir utiliser le port 80 ou 443 pour lancer le serveur web, ce qui demande evidemment de faire sauter le serveur web principal, et donc de couper les sites pendant la vérification.
+ +Mais nous allons utiliser une option du client qui permet d'utiliser un autre port que ceux par défaut, allié aux capacité frontend/backend de haproxy, pour effectuer la vérification sans aucune coupure de vos sites :-)
+ +Merci à coolaj86 dont l'article m'a donné cette idée d'utiliser haproxy et Let's Encrypt ensembles ;-)
+ +-- Many thanks to coolaj86 as his post give me this idea to use haproxy and Let's Encrypt together ;-) --
+ ++ +## Récupérer le client Let's Encrypt + +
Maintenent que LE est officiellement sorti un binaire plus carré est disponible, et beaucoup plus simple à installer que le précédent letsencrypt-auto.
+ +Toutes les info sont présente sur le site officiel de certbot, mais voici les instructions rapides pour l'installer.
+ +cd /root/
mkdir letsencrypt
cd letsencrypt
wget https://dl.eff.org/certbot-auto
chmod a+x certbot-auto
+Vous pouvez ensuite directement utiliser le binaire pour activer vos certificats
./certbot-auto certonly --domains blog.victor-hery.com --renew-by-default --http-01-port 63443 --agree-tos
Pour éviter toute coupure, nous allons utiliser votre (vos) frontend existant.
+ +La requête de Let's Encrypt se fera sur l'adresse IP à laquelle répond le site web pour lequel vous générez le certificat, donc si vous avez plusieurs frontend ou plusieurs IP, il faudra configurer chaque frontend selon vos besoins.
+ +L'idée est la suivante : lors de sa requête, Let's Encrypt interrogera l'url du site, suivi simplement de /.well-known/acme-challenge/un-id_unique.
+ +Nous allons donc configurer une acl qui cherchera cette chaine pour la rediriger vers un backend spécifique !
+ ++frontend http-in + acl app_letsencrypt path_beg /.well-known/acme-challenge/ + [...] + use_backend bk-letsencrypt if app_letsencrypt ++ +
Ainsi, toutes les requêtes de vérification de Let's Encrypt seront redirigées vers le backend bk-letsencrypt.
+ +Attention : Si vous redirigez de manière forcée vos sites en HTTP vers l'HTTPS, alors haproxy va rediriger aussi les requêtes let's encrypt vers votre frontend HTTS.
+ +Il faut alors ajouter l'acl et le use_backend bk-letsencrypt dans votre frontend https !
+ +### Backend + +Concernant le backend, nous allons le configurer pour rediriger les requêtes vers le serveur qui sera lancé en local par le client Let's Encrypt.
+ ++backend bk-letsencrypt + log global + mode http + server srv_letsencrypt 127.0.0.1:63443 ++ +
Ce serveur ne tournera pas en permanence, uniquement lorsque le client Let's Encrypt est en attente de vérification, en temps normal haproxy renverra donc une erreur 503 si quelqu'un tente d'accéder à une URL qui correspond à l'acl du frontend.
+ +Bien sûr, rechargez haproxy après ces modifications.
+ ++systemctl reload haproxy.service+ +## Configurer et utiliser Let's Encrypt + +### Configuration : + +
Pour simplifier la ligne de commande et faciliter l'automatisation, nous allons directement configurer un fichier pour Let's Encrypt.
+ +Let's Encrypt utilise par défaut le fichier /etc/letsencrypt/cli.ini. Nous allons donc taper dedans directement.
+ ++rsa-key-size = 4096 +email = your_admin_email +authenticator = standalone +standalone-supported-challenges = http-01 ++ +
Utiliser http pour la vérification ne pose pas de problème, car seule la requête de validation passe en clair, et elle n'a rien de secrète.
+ +### Génération du certificat + +La ligne de commande à utiliser pour générer votre certificat est la suivante :
+ ++/root/letsencrypt/certbot-auto certonly --domains yourdomain.tld --renew-by-default --http-01-port 63443 --agree-tos+ +
Les certificats sont mis en place dans le répertoire /etc/letsencrypt/live/yourdomain.tld/ par le client lors de la génération.
+ +Vous y trouverez plusieurs fichiers :
+ +Pour haproxy, vous devez concaténer fullchain.pem et privkey.pem dans un seul fichier, et le placer là ou votre haproxy lit ses certificats.
+ ++cat fullchain.pem privkey.pem > domain.tld.pem+ +
Un exemple :
+ ++frontend https-in + bind IP:443 ssl crt /etc/haproxy/cert/ ++ +
Ici, nous devons mettre notre fichier.pem dans le répertoire /etc/haproxy/cert/
+ +Une fois le certificat placé là, rechargez haproxy pour qu'il le lise, et ça y est tout sera Ok.
+ +N'oubliez pas que pour que votre site fonctionne en HTTPS, il faudra un frontend https dans haproxy, avec les acl qui vont bien.
+ +En général, un copier/coller de votre frontend HTTP classique en changeant le port vers 443 fait l'affaire.
+ +## Limitations + +### Renouveler le certificat + +Même sorti de bêta, LE a pris la décision de ne fournir des certificat valides que 3 mois (90 jours), ce afin d'éviter les abus et faire "vivre" le certificat.
+ +Notez que contrairement au binaire de bêta, certbot-auto peut scanner vos certificats disponibles (via le répertoire /etc/letsencrypt/renewal/) pour les renouveller automatiquement.
+ +Pensez donc à configurer une tache cron sur votre serveur pour renouveler le certificat régulièrement
+ ++crontab -e +#renew certificate +30 01 01,10,20,30 * * /root/letsencrypt/certbot-auto renew+ +
Cette tâche permettra de lancer la commande tous les 10 jours, afin d'être sur d'avoir des certificats à jour.
+ +N'oubliez pas qu'il faudra quand même aller récupérer le fullchain.pem et le .key pour aller les mettre dans haproxy. Voyez plus bas pour un peu d'automatisation sur cette tâche !
+ +### Nombre de certificat par domaine + +A cause de sa gratuité, Let's Encrypt dispose d'un système évitant de générer trop violemment des certificats pour le même domaine.
+ +Vous aurez donc une erreur si vous tentez de générer trop vite ou trop souvent des certificats avec le même domaine.
+ +Attention, c'est valable également pour les sous-domaine ! La limitation prend en compte tout ce qui se termine par domain.tld.
+ +### iDN : + +Actuellement Let's Encrypt ne gère pas les noms de domaines internationaux.
+ +Il est donc impossible de générer un certificat pour un domaine ou un sous-domaine contenant des accents ou des caractères spéciaux.
+ +Impossible par exemple de générer pour l'instant un certificat pour blog.héry.com malheureusement.
+ +Une requête existe actuellement à ce sujet sur le github de Let's Encrypt, mais plusieurs mois après le passage en stable, ce n'est toujours pas prêt malheureusement. Affaire à suivre (et à aider dans la mesure de ses moyens ;-) )
+ +## Bonus : des scripts + +Histoire de faciliter la génération et la mise en place sur haproxy, j'ai écris quelques petits scripts maison permettant de générer le certificat et le placer dans le bon répertoire, ainsi que gérer proprement le renouvellement.
+ +Ceux-ci sont disponibles sur mon dépôt git, vous pouvez donc directement les cloner sur votre serveur :
+ +git clone https://git.lecygnenoir.info/LecygneNoir/letsencrypt-haproxy.git
Le README décrit rapidement comment utiliser les scripts, c'est globalement assez simple.
+ +create_certificate permet de créer un certificat pour le domaine passé en paramètre, génère le .pem pour haproxy, le place dans l'arborescence haproxy et reload haproxy.
+ +renew-certificates se contente de renouveler tous les certificats, de générer les fichiers pour haproxy et de reload ce dernier. Vous pouvez utiliser renew-certificates dans une tâche cron comme indiqué plus haut.
+ +Vérifiez les chemins dans les scripts, notamment où placer les certificats et le chemin vers le binaire certbot
+ ++ +
Voila, avec tout ça vous devriez pouvoir générer autant de certificat que vous le souhaitez, et les utiliser directement dans haproxy, alors bienvenue dans le monde de l'HTTPS !
diff --git a/content/comments/configurer-reverse-proxy-haproxy/0.md b/content/comments/configurer-reverse-proxy-haproxy/0.md new file mode 100644 index 0000000..4e497da --- /dev/null +++ b/content/comments/configurer-reverse-proxy-haproxy/0.md @@ -0,0 +1,14 @@ +email: 13.37@gmx.com +date: 2016-01-07T10:32+01:00 +author: HaproxyTCP +website: + +Bonjour, + +Super article, a quand une version aussi bien pour du TCP ? +J'ai un Nas synology chez moi et j'aimerais bien que le logiciel "CloudStation" puisse passer a travers "cloud.mondomaine.fr" par exemple.. sauf que ce sont des requêtes TCP et malgré mes nombreux essais je n'arrive pas a faire quelque chose de propre. + +Je pense que ce type de tuto pourrait en intéresse plein d'autre.. (notamment si tu explique comment faire passer de l'openvpn/mysql etc.) + + +Merci et bonne journée :) diff --git a/content/comments/configurer-reverse-proxy-haproxy/1.md b/content/comments/configurer-reverse-proxy-haproxy/1.md new file mode 100644 index 0000000..d30ef2e --- /dev/null +++ b/content/comments/configurer-reverse-proxy-haproxy/1.md @@ -0,0 +1,12 @@ +email: +date: 2016-04-12T09:45+01:00 +author: Aurélien +website: + +Bonjour Victor, + +Ce message, juste pour te remercier ! :) +Un excellent tuto avec des cas concrets. +Merci à toi. + +Bonne journée diff --git a/content/comments/configurer-reverse-proxy-haproxy/2.md b/content/comments/configurer-reverse-proxy-haproxy/2.md new file mode 100644 index 0000000..304e31e --- /dev/null +++ b/content/comments/configurer-reverse-proxy-haproxy/2.md @@ -0,0 +1,6 @@ +email: fscemama@effitek.fr +date: 2016-07-19T15:40+01:00 +author: Fabrice Scemama +website: + +Super boulot. Bien rédigé, bien structuré, complet et intelligent. Merci! diff --git a/content/comments/configurer-reverse-proxy-haproxy/3.md b/content/comments/configurer-reverse-proxy-haproxy/3.md new file mode 100644 index 0000000..ec2acdb --- /dev/null +++ b/content/comments/configurer-reverse-proxy-haproxy/3.md @@ -0,0 +1,9 @@ +email: salemioche@gmail.com +date: 2016-07-21T10:26+01:00 +author: Nicolas +website: + +Le load balancing en se passant des acl, c'est top aussi :) + +tout seul : +use_backend backend1 diff --git a/content/comments/configurer-reverse-proxy-haproxy/4.md b/content/comments/configurer-reverse-proxy-haproxy/4.md new file mode 100644 index 0000000..7044d96 --- /dev/null +++ b/content/comments/configurer-reverse-proxy-haproxy/4.md @@ -0,0 +1,16 @@ +email: courriel+blog@victor-hery.com +date: 2016-07-21T10:34+01:00 +author: Victor +website: https://blog.victor-hery.com/ +replyto: 3md + +Bonjour Nicolas, + +Effectivement, s'il n'y a qu'un seul site derrière le proxy, le use_backend sans acl est beaucoup plus direct :) + +J'avoue aussi préférer les ACL car cela permet de cibler le site qui est visité : même avec un seul site, une ACL dessus permet de renvoyer les visiteurs qui viennent voir le site vers le bon backend + +Alors que le visiteur qui attaque directement l'adresse IP (ou qui a été mettre un nom de domaine différent dans son fichier etc/hosts) est redirigé vers le default_backend puisqu'il ne matche pas l'acl. +Cela permet de faire en sorte que ce soit haproxy qui gère ce backend (par exemple, en renvoyant une simple page html "pas de sites ici" plutôt que donner ce rôle au serveur web (qui va alors charger son vhost par défaut, attention à bien l'avoir configuré !) + +C'est ce dont je parle dans la partie "backend par défaut, aussi nommé backend poubelle", mais ça n'a effectivement rien d'obligatoire