import d'article depuis Pluxml + traductions

content/Discussions/le-blog-nest-pas-mort.md

@@ -0,0 +1,41 @@
+Title: Non le blog n'est pas mort :)
+Date: 2015-07-12 09:17
+Modified: 2015-07-12 09:17
+Tags:
+keywords:
+Slug: le-blog-nest-pas-mort
+Authors: Victor
+Status: published
+
+<p>Bonjour à tous,</p>
+
+<p>&nbsp;</p>
+
+<p>Comme le dit si bien le titre, non le blog n'est pas mort.</p>
+
+<p>Bon, il est pas non plus hyper vivant je me fais pas d'illusions...</p>
+
+
+<p>J'ai malheureusement (à ma grande honte) disposé et débloqué très peu de temps pour m'en occuper.</p>
+
+<p>Du coup, il y a plusieurs brouillons dans les tuyaux, pas mal d'idées, des articles pas finis, ...</p>
+
+<p>&nbsp;</p>
+
+<p>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.</p>
+
+<p>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".</p>
+
+<p>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.</p>
+
+<p>&nbsp;</p>
+
+<p>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.</p>
+
+<p>Un courriel permettra d'initier un vrai dialogue ! ;)</p>
+
+<p>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 !</p>
+
+<p>A très bientôt à tous, merci pour votre soutien et vos différents commentaires sur mes articles !</p>
+
+<p>Victor</p>

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

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
 
 <p><img alt="" src="/images/schemaHA(1).png" style="width: 612px; height: 353px;" /></p>
 
-## &nbsp;
+&nbsp;
 
 ## Matériel, serveurs, spécificités et autres joyeusetés
 
@@ -509,7 +509,7 @@ float
 
 ### Scripts upclient et downclient
 
-<p>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 !&nbsp;<img alt="devil" height="20" src="http://blog.héry.com/plugins/ckeditor/ckeditor/plugins/smiley/images/devil_smile.gif" title="devil" width="20" />)</p>
+<p>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 !&nbsp;\o/)</p>
 
 <p>Donc, upclient.sh :</p>
 

content/Système/configurer-reverse-proxy-apache.md

@@ -34,7 +34,7 @@ Status: published
 
 <p>On y arrive.&nbsp;;-)</p>
 
-<p><strong>EDIT décembre 2015 : </strong>j'ai écris un <a href="http://blog.héry.com/article21/configurer-un-reverse-proxy-sous-haproxy">nouvel article</a> pour utiliser haproxy en tant que reverse-proxy, logiciel plus léger et plus adapté qu'apache à cet usage.</p>
+<p><strong>EDIT décembre 2015 : </strong>j'ai écris un <a href="/2015/12/configurer-reverse-proxy-haproxy.html">nouvel article</a> pour utiliser haproxy en tant que reverse-proxy, logiciel plus léger et plus adapté qu'apache à cet usage.</p>
 
 <p>Or donc, si vous avez plusieurs serveurs web mais une seule connexion Internet, alors vous avez sans doute déjà eu cette problématique.</p>
 

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?
+
+<p><strong>Note : </strong>Ceci est la version anglaise de l'article, pour la version française, voir <a href="http://blog.victor-hery.com/article22/utiliser-let-s-encrypt-avec-haproxy">ici</a>.</p>
+
+### Haproxy :
+
+<p><a href="http://www.haproxy.org/">Haproxy </a>is a proxy software. It has many use, but here we will use its capacity to reverse proxying HTTP and HTTPS.</p>
+
+<p>For this post, we will consider you have a working Haproxy server and a working configuration.</p>
+
+### Let's Encrypt :
+
+<p><a href="https://letsencrypt.org/">Let's Encrypt</a> is an open source project sponsored by Mozilla foundation and Cisco.</p>
+
+<p>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.</p>
+
+<p>Regarding usual cost of SSL certificate, this a very interesting project!</p>
+
+<p>In addition to that, Let's Encrypt is really easy to use, mainly thank to an API allowing to create certificate very easily.</p>
+
+<p>We will use this API in this post through Let's Encrypt official python client.</p>
+
+<p><strong>EDIT : </strong>04/04/16 : add note about case when you use redirect HTTP to HTTPS in your HTTP haproxy frontend</p>
+
+<p><strong>EDIT</strong> : 09/16/16 : Update with new binary + add git repository with some scritps to automate LE management</p>
+
+## Concept
+
+<p>Let's Encrypt offers many option to create and validate certificate via its client.</p>
+
+<p>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.</p>
+
+<p>If you want to use this option, you can read this <a href="https://blog.infomee.fr/p/letsencrypt-haproxy">blog post </a>about using webroot and haproxy, including using a dedicated apache webserver for validation.</p>
+
+<p>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.</p>
+
+<p>In other word, your website(s) will be unavailable during all the process.</p>
+
+<p>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 :-)</p>
+
+<p>-- Many thanks to <a href="https://coolaj86.com/articles/lets-encrypt-with-haproxy/">coolaj86</a> as his post give me this idea to use haproxy and Let's Encrypt together ;-) --</p>
+
+## Get Let's Encrypt client
+
+<p>As LE is now officially released, a new official binary is available, more advanced and more easy to use than the previous letsencrypt-auto</p>
+
+<p>All information are available on the certbot <a href="https://certbot.eff.org/">official website</a>, but here are quick instructions how to use it.</p>
+
+<p><code>cd /root/</code></p>
+
+<p><code>mkdir letsencrypt</code></p>
+
+<p><code>cd letsencrypt</code></p>
+
+<p><code>wget https://dl.eff.org/certbot-auto</code></p>
+
+<p><code>chmod a+x certbot-auto</code></p>
+
+<p><br />
+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)</p>
+
+<p><code>./certbot-auto certonly&nbsp; --domains blog.victor-hery.com --renew-by-default --http-01-port 63443 --agree-tos</code></p>
+
+## Configure haproxy
+
+### Frontend
+
+<p>To avoid any downtime, we will use your existing frontend.</p>
+
+<p>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.</p>
+
+<p>Main idea is : during the process, Let's Encrypt&nbsp; request the base website URL, following by <em>/.well-known/acme-challenge/a_unique_id.</em></p>
+
+<p>So we are going to configure a haproxy ACL which match this path to redirect it to a specific backend!</p>
+
+<pre>
+frontend http-in
+    acl app_letsencrypt  path_beg   /.well-known/acme-challenge/
+    [...]
+    use_backend bk-letsencrypt if app_letsencrypt
+</pre>
+
+<ul>
+	<li>path_beg: match the path (the part just after the first /) that begin by <em>.well-known/acme-challenge/</em></li>
+</ul>
+
+<p>Doing so, all Let's Encrypt requests will be redirected to the <em>bk-letsencrypt</em> backend.</p>
+
+<p><strong>Warning : </strong>if you are using redirect from HTTP to HTTPS for your website, haproxy will also redirect Let's Encrypt request to your HTTPS frontend.</p>
+
+<p>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.</p>
+
+### Backend
+
+<p>About the backend, we are going to configure it to redirect request to the server launched by Let's Encrypt client.</p>
+
+<pre>
+backend bk-letsencrypt
+    log global
+    mode http
+    server srv_letsencrypt 127.0.0.1:63443
+</pre>
+
+<ul>
+	<li>mode http: allow to check the HTTP consistency of the request</li>
+	<li>server: this line redirect to the server that Let's Encrypt client will launch on localhost, port 63443</li>
+</ul>
+
+<p>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.</p>
+
+<p>Of course, you need to reload haproxy after doing these modifications.</p>
+
+<pre>
+systemctl reload haproxy.service</pre>
+
+## Configure and use of Let's Encrypt
+
+#### Configuration :
+
+<p>To simplify the command line usage, we use a configuration file for Let's Encrypt client.</p>
+
+<p>By default, the client uses the file <em>/etc/letsencrypt/cli.ini</em>. So this is the file we are going to edit.</p>
+
+<pre>
+rsa-key-size = 4096
+email = your_admin_email
+authenticator = standalone
+standalone-supported-challenges = http-01
+</pre>
+
+<ul>
+	<li>rsa-key-size: tell letsencrypt to direclty generate 4096 bits certificate, more strong that default 2048. You can downgrade to 2048 (but never less!) if your server is low performance to gain some generation time</li>
+	<li>email: use a valid email address, as it will be used if certificate recovery is needed through the Let's Encrypt website.</li>
+	<li>authenticator: as seen before, we will use <em>standalone</em> mode</li>
+	<li>standalone-supported-challenges: this option is specific to standalone mode, and allow to choose the method used for the verification process, between <em>http-01</em> and <em>tls-sni-01</em>. Here we use http-01 as our website has no valid certificate (the first time), and so haproxy will not have valid SSL certificate to use in its frontend for Let's Encrypt server request.</li>
+</ul>
+
+<p>Using HTTP for the verification process is safe, as only the verification request will be send in clear, and it has no secret inside.</p>
+
+### Generate the certificate
+
+<p>The command line to use to generate your certificate is the following:</p>
+
+<pre>
+/root/letsencrypt/certbot-auto certonly --domains yourdomain.tld --renew-by-default --http-01-port 63443 --agree-tos</pre>
+
+<ul>
+	<li>certonly: tell the client that we only want to generate the certificate, not using some installation plugin to install certificate somewhere.</li>
+	<li>domains: the domain or subdomain for which you want your certificate</li>
+	<li>renew-by-default: tell letsencrypt that, if the certificate already exist, it should renew it. If it does not exist, it will create it.</li>
+	<li>http-01-port: tell the network port to use for the temporary validation server launched. This is the port used in the haproxy backend we have configured before.</li>
+	<li>agree-tos: tell the client to automatically accept the therm of service of Let's Encrpt (If you are here, you have read it and agree, right ?)</li>
+</ul>
+
+### Installing the certificate
+
+<p>Certificates are created in a directory called&nbsp; <em>/etc/letsencrypt/live/yourdomain.tld/</em> by the client during the generation process.</p>
+
+<p>You will find multiple files inside:</p>
+
+<ul>
+	<li>cert.pem : the certificate public part (crt)</li>
+	<li>chain.pem : the authority chain (ca of authorities)</li>
+	<li>fullchain.pem : a concatenation of cert.pem and chain.pem</li>
+	<li>privkey.pem : the certificat private key</li>
+</ul>
+
+<p>In order to use with haproxy, you need to concatenate fullchain.pem and privkey.pem, and store it where haproxy read its certificates.</p>
+
+<pre>
+cat fullchain.pem privkey.pem &gt; domain.tld.pem</pre>
+
+<p>For example for the following HTTPS frontend:</p>
+
+<pre>
+frontend https-in
+    bind  IP:443 ssl crt /etc/haproxy/cert/
+</pre>
+
+<p>Here we need to store the domain.tld.pem file in <em>/etc/haproxy/cert/</em></p>
+
+<p>Once your certificate is stored in the right place, reload haproxy for it to re-read certificate, and everything should be OK.</p>
+
+<p>Of course do not forget to configure an HTTPS frontend with correct ACL for your website in haproxy!</p>
+
+<p>Usually, simply copy/paste of your HTTP frontend changing port to 443 (and adding ssl and crt option) will do the job.</p>
+
+## Limitations
+
+### Renew the certificate
+
+<p>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.</p>
+
+<p>Note that unlilke the beta client, certbot-auto is capable to use all your available certificates (thanks to the directory<em>/etc/letsencrypt/renewal/</em>) to allow automatic renewal .</p>
+
+<p>So remember to configure a cron job on your server to renew certificate:</p>
+
+<pre>
+crontab -e
+</pre>
+
+<pre>
+#renew certificate
+30 01 01,10,20,30 * * /root/letsencrypt/certbot-auto renew</pre>
+
+<p>This cron task will launch the renew command each 10 days to be sure your certificates will stay valids.</p>
+
+<p>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!</p>
+
+### Rate limit of certificate by domain
+
+<p>Because of its free use Let's Encrypt use a rate-limit sysytem to avoid generation of too many certificate for the same domain.</p>
+
+<p>You will get an error if you try to generate too quickly or too often certificates for the same domain</p>
+
+<p><strong>Be careful:</strong> the limitation take into account subdomain as well! All certificates finishing with domain.tld will be count.</p>
+
+### iNS :
+
+<p>For the moment, Let's Encrypt does not allow certificate for international Domain Name.</p>
+
+<p>This is impossible to generate a certificate for a domain or subdomain containing accent or special characters.</p>
+
+<p>For example, impossible to generate certificate for https://blog.héry.com unfortunately.</p>
+
+<p>There is currently a <a href="https://github.com/letsencrypt/boulder/issues/597">boulder</a> 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 :-)</p>
+
+## Bonus: some scripts
+
+<p>In order to make the process easier, I have written some scripts to allo generation and renewal of certificate, and haproxy interactions, easier.</p>
+
+<p>They are available in my <a href="https://git.lecygnenoir.info/LecygneNoir/letsencrypt-haproxy">git repository</a>, so you can easily clone them in your server:</p>
+
+<p><code>git clone https://git.lecygnenoir.info/LecygneNoir/letsencrypt-haproxy.git</code></p>
+
+<p>README simply describes how to use them, it pretty simple.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p><strong>Do not forget to check path in scripts, mainly where to store certificates for haproxy, and path to certbot binary</strong></p>
+
+<p>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 :-)</p>

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 ?
+
+<p><strong>Note: </strong>This is the French version of the post. English version <a href="https://blog.victor-hery.com/article23/use-haproxy-with-let-s-encrypt">here.</a></p>
+
+### Haproxy :
+
+<p><a href="http://www.haproxy.org/">Haproxy </a>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 <a href="http://blog.victor-hery.com/article21/configurer-un-reverse-proxy-sous-haproxy">mon article à ce sujet</a> si vous voulez en savoir plus.</p>
+
+<p>Dans cet article, nous considérerons que vous avez un serveur avec Haproxy fonctionnel pour les tests.</p>
+
+### Let's Encrypt :
+
+<p><a href="https://letsencrypt.org/">Let's Encrypt</a> est un projet soutenu entre autre par la fondation Mozilla et Cisco.</p>
+
+<p>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.</p>
+
+<p>Au regard du prix habituel d'un certificat, c'est un projet vraiment très intéressant !</p>
+
+<p>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.</p>
+
+<p>Nous nous appuierons ici sur cette API, à travers un client créé par Let's Encrypt.</p>
+
+<p><strong>EDIT : </strong>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</p>
+
+<p><strong>EDIT</strong> : 16/09/16 : Mise à jour avec les nouveaux binaires suite à la sortie de bêta de LE + amélioration et versionning des Scripts</p>
+
+
+## Concept
+
+<p>Let's Encrypt propose plusieurs options via le client pour télécharger et valider un certificat SSL.</p>
+
+<p>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 <a href="https://blog.infomee.fr/p/letsencrypt-haproxy">article de blog</a> explique très bien comment le faire interagir en utilisant un serveur apache dédié.</p>
+
+<p>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.</p>
+
+<p>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 :-)</p>
+
+<p>Merci à <a href="https://coolaj86.com/articles/lets-encrypt-with-haproxy/">coolaj86</a> dont l'article m'a donné cette idée d'utiliser haproxy et Let's Encrypt ensembles ;-)</p>
+
+<p>-- Many thanks to <a href="https://coolaj86.com/articles/lets-encrypt-with-haproxy/">coolaj86</a> as his post give me this idea to use haproxy and Let's Encrypt together ;-) --</p>
+
+<p>&nbsp;</p>
+
+## Récupérer le client Let's Encrypt
+
+<p>Maintenent que LE est officiellement sorti un binaire plus carré est disponible, et beaucoup plus simple à installer que le précédent letsencrypt-auto.</p>
+
+<p>Toutes les info sont présente sur le <a href="https://certbot.eff.org/">site officiel</a> de certbot, mais voici les instructions rapides pour l'installer.</p>
+
+<p><code>cd /root/</code></p>
+
+<p><code>mkdir letsencrypt</code></p>
+
+<p><code>cd letsencrypt</code></p>
+
+<p><code>wget https://dl.eff.org/certbot-auto</code></p>
+
+<p><code>chmod a+x certbot-auto</code></p>
+
+<p><br />
+Vous pouvez ensuite directement utiliser le binaire pour activer vos certificats</p>
+
+<p><code>./certbot-auto certonly&nbsp; --domains blog.victor-hery.com --renew-by-default --http-01-port 63443 --agree-tos</code></p>
+
+## Configurer haproxy
+
+### Frontend
+
+<p>Pour éviter toute coupure, nous allons utiliser votre (vos) frontend existant.</p>
+
+<p>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.</p>
+
+<p>L'idée est la suivante : lors de sa requête, Let's Encrypt interrogera l'url du site, suivi simplement de <em>/.well-known/acme-challenge/un-id_unique.</em></p>
+
+<p>Nous allons donc configurer une acl qui cherchera cette chaine pour la rediriger vers un backend spécifique !</p>
+
+<pre>
+frontend http-in
+    acl app_letsencrypt  path_beg   /.well-known/acme-challenge/
+    [...]
+    use_backend bk-letsencrypt if app_letsencrypt
+</pre>
+
+<ul>
+	<li>path_beg : cherche les URL dont le path (ce qui est après le premier / de l'url) commence par <em>.well-known/acme-challenge/</em></li>
+</ul>
+
+<p>Ainsi, toutes les requêtes de vérification de Let's Encrypt seront redirigées vers le backend <em>bk-letsencrypt</em>.</p>
+
+<p><strong>Attention :</strong> 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.</p>
+
+<p>Il faut alors ajouter l'acl et le use_backend bk-letsencrypt <strong>dans votre frontend https !</strong></p>
+
+### Backend
+
+<p>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.</p>
+
+<pre>
+backend bk-letsencrypt
+    log global
+    mode http
+    server srv_letsencrypt 127.0.0.1:63443
+</pre>
+
+<ul>
+	<li>mode http : permet, tant qu'à faire, de vérifier qu'il s'agit bien d'une requête http qui passe par ce backend</li>
+	<li>server : la ligne redirige vers le serveur que le client Let's Encrypt aura lancé sur localhost, sur le port 63443</li>
+</ul>
+
+<p>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.</p>
+
+<p>Bien sûr, rechargez haproxy après ces modifications.</p>
+
+<pre>
+systemctl reload haproxy.service</pre>
+
+## Configurer et utiliser Let's Encrypt
+
+### Configuration :
+
+<p>Pour simplifier la ligne de commande et faciliter l'automatisation, nous allons directement configurer un fichier pour Let's Encrypt.</p>
+
+<p>Let's Encrypt utilise par défaut le fichier <em>/etc/letsencrypt/cli.ini</em><em>. </em>Nous allons donc taper dedans directement.</p>
+
+<pre>
+rsa-key-size = 4096
+email = your_admin_email
+authenticator = standalone
+standalone-supported-challenges = http-01
+</pre>
+
+<ul>
+	<li>rsa-key-size ; permet de générer directement des certificats de 4096 bit, plus robustes que le 2048 par défaut. Vous pouvez redescendre à 2048 (mais pas en dessous !) si votre serveur est peu puissant pour gagner du temps de génération.</li>
+	<li>email : utilisez une adresse valide, car ce sera l'adresse utilisée pour récupérer le certificat sur le site web&nbsp; de Let's Encrypt si jamais le besoin s'en faisait sentir</li>
+	<li>authenticator : comme vu plus haut, nous utilisons le mode <em>standalone</em></li>
+	<li>standalone-supported-challenges : Cette option est spécifique au mode standalone, et permet de spécifier la méthode à utiliser pour la vérification, parmi <em>http-01</em> ou <em>tls-sni-01</em>. Nous utilisons http-01 car notre site n'a pas (forcément) encore de certificat, et donc lors d'un appel sur 403 haproxy n'aura pas de certificat valide à présenter.</li>
+</ul>
+
+<p>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.</p>
+
+### Génération du certificat
+
+<p>La ligne de commande à utiliser pour générer votre certificat est la suivante :</p>
+
+<pre>
+/root/letsencrypt/certbot-auto certonly --domains yourdomain.tld --renew-by-default --http-01-port 63443 --agree-tos</pre>
+
+<ul>
+	<li>certonly : précise que l'on souhaite simplement générer le certificat, et pas utiliser un plugin d'installation pour stocker les certificats quelque part</li>
+	<li>domains : le domaine ou sous domaine pour lequel vous voulez générer ce certificat</li>
+	<li>renew-by-default : indique que si le certificat existe déjà, il faut le renouveler. S'il n'existe pas, il sera créé dans la base de Let's Encrypt</li>
+	<li>http-01-port : permet de spécifier le port à utiliser pour le serveur de validation temporaire. C'est le port utilisé dans le backend haproxy plus haut</li>
+	<li>agree-tos : indique d'accepter les conditions d'utilisation de Let's Encrypt (vous les avez lues et êtes ok pour les accepter, pas vrai ?)</li>
+</ul>
+
+### Mettre en place le certificat
+
+<p>Les certificats sont mis en place dans le répertoire <em>/etc/letsencrypt/live/yourdomain.tld/</em> par le client lors de la génération.</p>
+
+<p>Vous y trouverez plusieurs fichiers :</p>
+
+<ul>
+	<li>cert.pem : le certificat (le crt)</li>
+	<li>chain.pem : la chaine de confiance (les certificats de l'authorité)</li>
+	<li>fullchain.pem : une concaténation des 2 premiers</li>
+	<li>privkey.pem : la clef privée du certificat</li>
+</ul>
+
+<p>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.</p>
+
+<pre>
+cat fullchain.pem privkey.pem &gt; domain.tld.pem</pre>
+
+<p>Un exemple :</p>
+
+<pre>
+frontend https-in
+    bind  IP:443 ssl crt /etc/haproxy/cert/
+</pre>
+
+<p>Ici, nous devons mettre notre fichier.pem dans le répertoire <em>/etc/haproxy/cert/</em></p>
+
+<p>Une fois le certificat placé là, rechargez haproxy pour qu'il le lise, et ça y est tout sera Ok.</p>
+
+<p>N'oubliez pas que pour que votre site fonctionne en HTTPS, il faudra un frontend https dans haproxy, avec les acl qui vont bien.</p>
+
+<p>En général, un copier/coller de votre frontend HTTP classique en changeant le port vers 443 fait l'affaire.</p>
+
+## Limitations
+
+### Renouveler le certificat
+
+<p>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.</p>
+
+<p>Notez que contrairement au binaire de bêta, certbot-auto peut scanner vos certificats disponibles (via le répertoire <em>/etc/letsencrypt/renewal/</em>) pour les renouveller automatiquement.</p>
+
+<p>Pensez donc à configurer une tache cron sur votre serveur pour renouveler le certificat régulièrement</p>
+
+<pre>
+crontab -e
+#renew certificate
+30 01 01,10,20,30 * * /root/letsencrypt/certbot-auto renew</pre>
+
+<p>Cette tâche permettra de lancer la commande tous les 10 jours, afin d'être sur d'avoir des certificats à jour.</p>
+
+<p>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 !</p>
+
+### Nombre de certificat par domaine
+
+<p>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.</p>
+
+<p>Vous aurez donc une erreur si vous tentez de générer trop vite ou trop souvent des certificats avec le même domaine.</p>
+
+<p><strong>Attention</strong>, c'est valable également pour les sous-domaine ! La limitation prend en compte tout ce qui se termine par domain.tld.</p>
+
+### iDN :
+
+<p>Actuellement Let's Encrypt ne gère pas les noms de domaines internationaux.</p>
+
+<p>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.</p>
+
+<p>Impossible par exemple de générer pour l'instant un certificat pour blog.héry.com malheureusement.</p>
+
+<p>Une <a href="https://github.com/letsencrypt/boulder/issues/597">requête</a> 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 ;-) )</p>
+
+## Bonus : des scripts
+
+<p>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.</p>
+
+<p>Ceux-ci sont disponibles sur <a href="https://git.lecygnenoir.info/LecygneNoir/letsencrypt-haproxy">mon dépôt git</a>, vous pouvez donc directement les cloner sur votre serveur :</p>
+
+<p><code>git clone https://git.lecygnenoir.info/LecygneNoir/letsencrypt-haproxy.git</code></p>
+
+<p>Le README décrit rapidement comment utiliser les scripts, c'est globalement assez simple.</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p><strong>Vérifiez les chemins dans les scripts, notamment où placer les certificats et le chemin vers le binaire certbot</strong></p>
+
+<p>&nbsp;</p>
+
+<p>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 !</p>

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 :)

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

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!

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

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