Blog du grouik - SSL HTTPS chiffrement et certificatsLe blog du grouik. Memos d'un Admin sys linux windows, logiciels libres, imprimante 3D2024-01-16T12:12:27+00:00Gniearkurn:md5:87c2396a7331cd5cd18f8751d216ec7bDotclearMémo: Ajouter une autorité de confiance sur un serveur Débianurn:md5:61a7f3a66d2d6129bc3e0e877ac09ce02018-02-14T10:25:00+01:002018-02-14T10:37:07+01:00gniearkSSL HTTPS chiffrement et certificatsSSL <p><img src="https://blog-du-grouik.tinad.fr/public/52406.png" alt="52406.png" style="float:left; margin: 0 1em 1em 0;" title="52406.png, fév. 2018" />J'ai installé un serveur Gitlab sur mon lan, le certificat https est signé par une autorité de confiance maison.</p>
<p>Du coup je me cogne le problème suivant des que je synchronise depuis un nouveau serveur.</p>
<pre>
user@server:~/scriptsGed$ git push -u origin master
fatal: unable to access 'https://gitlab.localdomain.local/user/nomDudepotGit.git/': server certificate verification failed.
CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
</pre>
<p>Le problème se pose aussi pour une simple utilisation de wget sur des ressources locales (dans le LAN) en https.</p>
<p>Voici le petit mémo pour ajouter un certificat dans le "magasin" des autorités de confiance sous Debian (et probablement sous Ubuntu).</p>
<p>Les commandes suivantes sont à faire avec le compte root (ou ajoutez "sudo" avant chaque commande)</p>
<pre class="brush: bash">#Remplacez localdomain.local par votre domaine à vous
#Créer le dossier où déposer le certificat
mkdir /usr/local/share/ca-certificates/localdomain.local
# Y déposer le certificat (dans mon cas, se placer dans le répertoire puis : wget http://apache.localdomain.local/cacert.crt)
#Raffraichir la liste des certificats
update-ca-certificates</pre>
<p>Et voila!</p>Securiser mon dédié#1 Usage sécurisé d’(Open)SSHurn:md5:02f62c79338ce7493a4925d444ee9bbc2018-01-14T00:23:00+01:002018-01-15T11:23:34+01:00gniearkSSL HTTPS chiffrement et certificatsANSSIdebianSSLSécuriser mon dédiéTLS <p><img src="https://blog-du-grouik.tinad.fr/public/randommart.png" alt="randommart.png" style="display:table; margin:0 auto;" title="randommart.png, janv. 2018" /></p>
<p>::TOC::</p>
<h3>Introduction</h3>
<p>J'ai récemment réinstallé le serveur qui héberge entre autres ce blog (il me reste à finaliser la protection de la messagerie, et peaufiner quelques réglages).</p>
<p>A peu près dans le même temps, je redécouvrais les <a href="https://www.ssi.gouv.fr/administration/bonnes-pratiques/">guides de bonnes pratiques de l'ANSSI</a> La majorité des documents sont très bien faits, précis, techniques et parfois m’apprennent des choses.</p>
<p>L'idée m'est venu de faire une série de billets sur la sécurisation de mon serveur en suivant les recommandations de l'ANSSI.</p>
<p>Mon serveur dédié (Debian 9, 32Go de RAM) a les fonctions suivantes:</p>
<table>
<tr><th>Serveur web</th><td>Nginx + PHP7-fpm + MariaDb</td></tr>
<tr><th>Serveur de messagerie</th><td>Postfix + Dovecot + Amavisd-new + spamassassin + dspam + clamav</td></tr>
<tr><th>Containerisation</th><td>Docker, pour le moment un seul container: collabora Online</td></tr>
</table>
<h3>Sécurisons le SSH en suivant les recommandations de l'ANSSI.</h3>
<p>Le document de référence pour ce premier billet est <a href="https://www.ssi.gouv.fr/administration/guide/recommandations-pour-un-usage-securise-dopenssh/" hreflang="fr">Usage sécurisé d’(Open)SSH</a> pour la suite je reprends le chapitrage du document en question.</p>
<p>Dans la suite, à chaque fois qu'on modifiera le fichier /etc/ssh/sshd_config, il faudra relancer le service ssh pour que ce soit pris en compte.</p>
<pre class="brush: bash">service sshd restart</pre>
<p>Par prudence, en supposant que le SSH soit votre seul moyen d"accès au serveur. Avant de faire les manipulations, je vous invite à ouvrir une connexion ssh vers celui-ci et laisser le terminal dans un coin de votre PC. Si jamais vous faisiez une erreur et plantiez sshd, normalement cette connexion restera ouverte et vous permettra de corriger.</p>
<h4>Protocole SSH</h4>
<p>Afin d'être sûr que seul ssh 2 est utilisé <sup>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#wiki-footnote-1" id="rev-wiki-footnote-1">1</a>]</sup>, on ajoute</p>
<pre>
Protocol 2
</pre>
<p>dans le fichier /etc/ssh/sshd_config.</p>
<h4>Authentification du serveur</h4>
<p>Je ne changerai rien de mon coté, par défaut openssh a le comportement Trust On First Use (TOFU), puis utilise le knowHost pour prévenir si le serveur présente une identité incorrecte.</p>
<h4>Cryptographie</h4>
<h5>Types de clefs</h5>
<p>En résumé: (dixit l'ANSSI)</p>
<ul>
<li>Clefs DSA à bannir</li>
<li>Clefs RSA OK à partir de 2048bits minimum</li>
<li>Clefs ECDSA OK et à préférer à partir de 256bits</li>
</ul>
<p>Appliquons, sur le(s) pc clients, on remplace les clefs par des ECDSA</p>
<pre class="brush: bash">#Creer une clef (les longueurs possibles sont 256, 384 or 521, ne me demandez pas pourquoi)
#Par défaut il met la clef publique dans /home/yourUser/.ssh/id_ecdsa.pub
# et la clef privée /home/yourUser/.ssh/id_ecdsa
ssh-keygen -t ecdsa -b 521</pre>
<p>Envoyer la clef sur le serveur (en utilisant le mot de passe ou l'ancienne clef), Depuis votre client; en remplaçant gnieark@serveur.domaine.com par ce qu'il faut:</p>
<pre class="brush: bash">ssh-copy-id -i ~/.ssh/id_ecdsa.pub gnieark@serveur.domaine.com</pre>
<h5>Choix des algorithmes symétriques</h5>
<p>J'ajoute dans le fichier /etc/ssh/sshd_config du serveur</p>
<pre>
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
</pre>
<p>afin d'écarter les algorithmes faibles.</p>
<p>Après avoir fait ça, ça fonctionne depuis mon PC, mais depuis mon téléphone portable avec l'application JuiceSSH:</p>
<p><img src="https://blog-du-grouik.tinad.fr/public/.Screenshot_20180112-220600_m.png" alt="Screenshot_20180112-220600.png" style="display:table; margin:0 auto;" title="Screenshot_20180112-220600.png, janv. 2018" /></p>
<p>Que faire? le document de l'ANSSI qui date de 2015 dit:</p>
<blockquote><p>Les HMAC SHA-256 et SHA-512 ne sont supportés que depuis la version 5.9 d’OpenSSH. Les
systèmes d’exploitation utilisant des versions antérieures doivent alors reposer sur un HMAC SHA-1.</p></blockquote>
<p>On pourrait ajouter le SHA-1 dans la liste, JuiceSSH semble le supporter.Mais très récemment, les chercheurs de Google ont réussi à créer une collision en SHA1<sup>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#wiki-footnote-2" id="rev-wiki-footnote-2">2</a>]</sup>
Au final pour résoudre ce problème, j'ai ajouté l'algo hmac-sha2-256 dans la directive MACs, comme ceci:</p>
<pre>
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-256
</pre>
<h4>Durcissement du système</h4>
<p>Concernant cette partie des recommandations, Je saute le passage concernant l'isolement des utilisateurs et le mode "sandbox" d'openssh. parce que je suis seul à administrer ce serveur <sup>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#wiki-footnote-3" id="rev-wiki-footnote-3">3</a>]</sup> <sup>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#wiki-footnote-4" id="rev-wiki-footnote-4">4</a>]</sup>.</p>
<h5>SFTP et Chroot</h5>
<p>Il est possible de "chrooter"<sup>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#wiki-footnote-5" id="rev-wiki-footnote-5">5</a>]</sup> les users sftp. Et ça ça m'arrange, car les rares utilisations du sftp que je fais sont pour les données des sites web. Mais ça, je l'aborderai dans le billet à venir sur la sécurisation des sites web #teasing</p>
<h5>Bloquer les tentatives de force brute</h5>
<p>Ajouter au sshd_config</p>
<pre>
MaxAuthTries 2
LoginGraceTime 30
</pre>
<p>Au bout de 2 essais ratés, le client (ou attaquant) devra attendre 30s.</p>
<p>Bon, ok, du brute force sur l'authentification par clef, ça fait sourire. Mais c'est toujours un durcissement, et il m'arrivera, (et vous arrivera) de temps en temps de repermettre l'authentification par mot de passe. Le temps d'ajouter une nouvelle clef par exemple.</p>
<p>Et tant qu'à faire, autant laisser openssh gérer ça nativement à priori, que le faire gérer par fail2ban à postériori<sup>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#wiki-footnote-6" id="rev-wiki-footnote-6">6</a>]</sup></p>
<h4>Authentification et contrôle d’accès utilisateurs</h4>
<p>Afficher la précédente connexion,Interdire l'accès à root et les mots de passe:</p>
<pre>
PrintLastLog yes
PasswordAuthentication no
PermitRootLogin no
</pre>
<p>Sortons du cas de mon serveur personnel. Il est aussi possible d'assouplir les règles. Imaginez un serveur pour lequel un acces SSH est utile depuis l'extérieur, mais depuis le LAN vos collègues tiennent à utiliser windows. La gestion des clefs avec Putty est galère.</p>
<p>De cette manière les users provenant du LAN (et pas depuis internet) et du groupe downstairs pourront quand même se connecter, tout en laissant l'authentification par clef obligatoire depuis l'extérieur.</p>
<pre>
Match Address 192.168.0.0/16 Group downstairs
PasswordAuthentication yes
</pre>
<p><sup>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#wiki-footnote-7" id="rev-wiki-footnote-7">7</a>]</sup></p>
<p>Un peu de la même manière, dans les tutos, AllowUsers est généralement présenté avec simplement la liste des utilisateurs autorisés. Mais on peut aussi préciser leur subnet.
Par exemple:</p>
<pre>
AllowUsers admin@192.168.17/24 user@10.127/16
</pre>
<h4>Faire des rebonds ssh.</h4>
<p>Faire des rebonds vous obligera à laisser des identifiants dans les serveurs intermédiaires. l'idéal est d'encapsuler les connexions ssh les unes dans les autres. Le <a href="https://github.com/moul/advanced-ssh-config">programme assh</a> écrit par Manfred sert justement à ça.</p>
<h4>Protocole et accès réseaux</h4>
<p>Idéalement l'acces SSH pour l'administration se fait via un autre acccès (la carte réseau et l'IP du serveur dédiée à l'administration). Dans le cas de mon serveur personnel, ce n'est pas faisable.</p>
<h5>X11Forwarding</h5>
<p>Le danger se situerait plutot dans l'autre sens, si le serveur a été corrompu, le x11forwarding pourrait permettre de faire fuiter des données de votre PC client.<sup>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#wiki-footnote-8" id="rev-wiki-footnote-8">8</a>]</sup></p>
<p>Le désactiver:</p>
<pre>
X11Forwarding no
</pre>
<p>D'autant que mon serveur n'ayant pas d'interface graphique, ce serait idiot.</p>
<h3>Conclusion</h3>
<p>Ça me parait plus rigoureux à présent ma gestion d'openssh. Je vous invite à nouveau à lire le document de l'ANSSI, car il y a quelques parties sur lesquelles j'ai fait l'impasse.</p>
<p>Prochain billet dans cette thématique (sécuriser son serveur dédié) à venir d'ici deux semaines je pense.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#rev-wiki-footnote-1" id="wiki-footnote-1">1</a>] Changement de standard pour le protocole ssh, la version 1 présentait des vulnérabilités</p>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#rev-wiki-footnote-2" id="wiki-footnote-2">2</a>] Il me semble peu probable qu'une collision trouvée, avec l'aide de datacenters entiers représente réellement une faille dans le sha1 concernant le ssh, mais bon par principe c'est obsolète. <a href="https://www.linformaticien.com/actualites/id/43271/sha1-google-provoque-une-collision-et-signe-l-arret-de-mort-de-la-fonction.aspx">SHA1 : Google provoque une collision et signe l’arrêt de mort de la fonction</a></p>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#rev-wiki-footnote-3" id="wiki-footnote-3">3</a>] le seul à avoir l’accès système, mais plusieurs admin sur la plateforme Dotclear et sur Nextcloud.</p>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#rev-wiki-footnote-4" id="wiki-footnote-4">4</a>] Il m'est déjà arrivé d'enregistrer temporairement dans le fichier authorized_keys la clef ssh publique d'un ami, ou d'un membre du hackerspace. A chaque fois, quelqu'un de confiance que je connais IRL et administrateur systèmes ou dev ops dans sa vraie vie, manipulant au quotidien des données beaucoup plus sensibles que ce qu'il y a sur mon serveur. C'est arrivé pendant mes vacances dans des coins sans 3G ou encore pour une aide sur l'optimisation du serveur. Moins d'une fois par an</p>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#rev-wiki-footnote-5" id="wiki-footnote-5">5</a>] meilleure traduction: encager?</p>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#rev-wiki-footnote-6" id="wiki-footnote-6">6</a>] Fail2Ban analyse les logs pour créer des règles iptables, il y a donc toujours un petit décalage entre l'évènement et l'action.</p>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#rev-wiki-footnote-7" id="wiki-footnote-7">7</a>] Voir ce <a href="https://ubuntuforums.org/showthread.php?t=1303735" hreflang="fr">thread sur le forum ubuntu</a></p>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2018/01/09/Recommandations-de-l-ANSSI-sur-mon-serveur-1-SSH#rev-wiki-footnote-8" id="wiki-footnote-8">8</a>] J'ai la flegme de faire un POC. En résumé, Celui qui a corrompu le serveur fait un alias d'une commande classique pour la transformer en service X window, qui pourra enregistrer vos frappes clavier.</p></div>
Lets encrypt pour sécuriser un serveur de messagerie Postfix et dovecoturn:md5:0e5c73d7c884a267f838de1d31f653c42016-04-06T11:14:00+02:002016-04-06T14:23:23+02:00gniearkSSL HTTPS chiffrement et certificatse-mailserveurSSLTLS <p><img src="https://blog-du-grouik.tinad.fr/public/postfix-mail-server.png" alt="postfix-mail-server.png" style="display:table; margin:0 auto;" title="postfix-mail-server.png, avr. 2016" /></p>
<p>Oui, les certificats pour les serveurs web sont les mêmes que pour les serveurs de messagerie.</p>
<p>Dans les fichiers de configuration de Dovecot et de postfix, Quels fichiers générés par Lets Encrypt faut-il renseigner?</p>
<h3>Créer la clé et le certificat avec lets encrypt.</h3>
<p>ce n'est pas vraiment l'objet de ce billet, si vous avez déjà créé vos certificats, passez au paragraphe suivant.</p>
<pre class="brush: bash">cd ~
#dl lets encript
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
#Stopper l'éventuel service qui utilise le port 80 (dans mon cas c'est apache)
#car letsencrypt en auraz besoin quelques secondes.
service apache2 stop
#générer le certificat
#Je ne mets pas le mode auto car ma configuration d'apache est un peu fouillie
# et lets encrypt n'arrivera pas à générer la configuration
# du coup je lui demande juste les certificats et le clefs:
# Adaptez en fonction de vos besoins
./letsencrypt-auto certonly --standalone --email email@domaine.fr -d domaine1.fr -d machine.domaine1.fr -d machine.domaine2.fr
#restart apache
service apache2 start</pre>
<h3>Postfix</h3>
<p>Ma partie certificats tls dans le /etc/postfix/main.cf est la suivante:</p>
<pre>
#tls
smtpd_tls_key_file = /etc/letsencrypt/live/tinad.fr/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/tinad.fr/cert.pem
smtpd_tls_CAfile = /etc/letsencrypt/live/tinad.fr/chain.pem
</pre>
<p>Évidemment vous remplacez tinad.fr par le nom du répertoire que vous trouvez dans /etc/letsencrypt/live</p>
<h3>Dovecot</h3>
<p>Pour dovecot (serveur IMAP)</p>
<pre>
ssl_protocols = !SSLv2 !SSLv3
ssl_ca = </etc/letsencrypt/live/tinad.fr/chain.pem
ssl_cert = </etc/letsencrypt/live/tinad.fr/cert.pem
ssl_key = </etc/letsencrypt/live/tinad.fr/privkey.pem
ssl_verify_client_cert = yes
ssl = required
</pre>Fournir, puis demander à un utilisateur un certificat pour l'authentifier sur notre site internet.urn:md5:a0b24a179c3339372a15cdc97abe89c42015-03-13T21:06:00+01:002021-08-30T21:12:00+02:00gniearkSSL HTTPS chiffrement et certificatsApacheLogiciel-librepkcsserveurSSLTLSTutoriel-mémo <p><img src="https://blog-du-grouik.tinad.fr/public/.rsaPlp_m.png" alt="rsaPlp.png" style="display:table; margin:0 auto;" title="rsaPlp.png, mar. 2015" /></p>
<p>::TOC::</p>
<h2>Pourquoi faire ça?</h2>
<p>A moins de s'appeler le trésor public<sup>[<a href="https://blog-du-grouik.tinad.fr/post/2015/03/13/Authentifier-un-client-web-via-un-certificat-TLS#wiki-footnote-1" id="rev-wiki-footnote-1">1</a>]</sup>, cette sécurité peut paraître exagérée.</p>
<p>Ça va me servir dans quelques semaines à sécuriser une appli web du travail pour laquelle seuls une dizaine d'utilisateurs auront accès depuis l'extérieur (via un reverse proxy apache) .</p>
<h2>Présentation des techniques employées:</h2>
<p>La configuration se fait au niveau d'apache et du module SSL.
Ce n'est pas compliqué, Mais c'est chiant à expliquer de façon claire. J'en suis à la troisième re-rédaction de ce billet pour tenter d'éclaircir les explications.</p>
<p>Ce billet contient tout un mémo de création d'une chaine de certification avec openSSL et un peu de config Apache.</p>
<p>Sur le serveur (mon Raspberry pi), je vais créer trois sites virtuels (VHOST) dans la configuration d'apache:</p>
<ul>
<li>home.tinad.fr (en http)</li>
<li>home.tinad.fr (en https)</li>
<li>prive.tinad.fr (en https, avec obligation pour l'utilisateur de posséder un certificat personnel signé par l'autorité de certification qu'on va créer):</li>
</ul>
<h2>Créer son autorité de certification et des certificats pour les deux sites en https</h2>
<h3>l'autorité de certification</h3>
<p>Malheureusement, il n'est pas possible d'obtenir un certificat ayant le rôle "autorité de certification" reconnu par tous les navigateurs. On devra faire en sorte que les utilisateurs ajoutent notre certificat dans leur navigateur. Je ne détaillerai pas ici comment faire, mais il voici trois pistes:</p>
<ul>
<li>Créer une page web intermédiaire fournissant le certificat, et expliquant comment et pourquoi l'installer</li>
<li>Si les utilisateurs sont dans un réseau sur lequel on est l'administrateur réseau : Via une GPO.</li>
<li>Offrir une boite de kinder chocolat à l'administrateur réseau pour qu'il fasse une GPO.</li>
<li>L'installer manuellement sur tous les postes.</li>
</ul>
<h4>Configuration</h4>
<pre class="brush: bash">#On créé l'architecture de dossiers et fichiers nécessaires à une gestion des
#clés et certificats dans le repertoire /srv/ssl
mkdir /srv/ssl
cd /srv/ssl
mkdir certs crl newcerts private
echo 01 > serial
touch index.txt
echo 01 > crlnumber
cp /usr/lib/ssl/openssl.cnf .</pre>
<h4>Editer le fichier /srv/ssl/openssl.conf et modifiez les parametres suivants:</h4>
<p>Dans le bloc CA_default :</p>
<ul>
<li>dir=/srv/ssl</li>
</ul>
<p>Dans le bloc [req_distinguished_name] :
.</p>
<pre class="brush: bash">countryName_default = FR
stateOrProvinceName_default = France</pre>
<h4>Clé privée certificat et signature</h4>
<pre class="brush: bash">#Créer une clé privée
openssl genrsa -des3 -out private/cakey.pem 4096
#certif signé
openssl req -config openssl.cnf -new -x509 -nodes -sha1 -days 1825 -key private/cakey.pem -out cacert.pem</pre>
<p>Adaptez les réponses en fonction,s de votre site, mais ne mettez pas le FDQN dans le common name. Il s'agit du certificat autorité, pas celui de votre site web.
Voici mon retour écran:</p>
<pre class="brush: bash">root@raspberrypi:/srv/ssl# openssl req -config openssl.cnf -new -x509 -nodes -sha1 -days 1825 -key private/cakey.pem -out cacert.pem
Enter pass phrase for private/cakey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [France]:
Locality Name (eg, city) []:Rouen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tinad
Organizational Unit Name (eg, section) []:Gnieark
Common Name (e.g. server FQDN or YOUR name) []:tinad.fr
Email Address []:gnieark@free.fr</pre>
<h4>Publier le certificat de l'autorité de certification</h4>
<pre class="brush: bash">cp /srv/ssl/cacert.pem /var/www/cacert.crt</pre>
<p>(Lors de la copie, on change l'extension .pem en .crt, car .crt est un type mime connu dans la configuration standard d'apache)</p>
<h4>Enregistrez le certificat dans le magasin de confiance de votre ordinateur local</h4>
<p>Ouvrez tout simplement votre navigateur à l'URL http://VotreServeur/cacert.crt
et cochez toutes les cases:</p>
<p><img src="https://blog-du-grouik.tinad.fr/public/firefoxCacertTinad.png" alt="firefoxCacertTinad.png" style="display:table; margin:0 auto;" title="firefoxCacertTinad.png, mai 2013" /></p>
<h3>Créer un certificat pour le serveur Web home.tinad.fr</h3>
<p>changez "home.tinad.fr" par le FDQN de votre serveur pour la suite des tests.</p>
<pre class="brush: bash">cd /srv/ssl
#Création de la clé privée pour home.tinad.fr
openssl genrsa -des3 -out home.tinad.fr.key.pem 4096
#demande de certificat:
openssl req -config openssl.cnf -new -key home.tinad.fr.key.pem -out home.tinad.fr.csr.pem</pre>
<p>Voici mon retour écran:</p>
<pre class="brush: bash">root@raspberrypi:/srv/ssl# openssl req -config openssl.cnf -new -key home.tinad.fr.key.pem -out home.tinad.fr.csr.pem
Enter pass phrase for home.tinad.fr.key.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [France]:
Locality Name (eg, city) []:Rouen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tinad
Organizational Unit Name (eg, section) []:home
Common Name (e.g. server FQDN or YOUR name) []:home.tinad.fr
Email Address []:gnieark@free.fr
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:</pre>
<p>Signature de la demande:</p>
<pre class="brush: bash">openssl ca -config openssl.cnf -policy policy_anything -out home.tinad.fr.cert.pem -infiles home.tinad.fr.csr.pem</pre>
<p>La valeur la plus importante est le common name. Elle corrspond au FDQN pour les autres champs, essayez simplement d'etre logique avec l'autorité de certification
Voici mon retour écran:</p>
<pre class="brush: bash">root@raspberrypi:/srv/ssl# openssl ca -config openssl.cnf -policy policy_anything -out home.tinad.fr.cert.pem -infiles home.tinad.fr.csr.pem
Using configuration from openssl.cnf
Enter pass phrase for /srv/ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: May 3 19:25:04 2013 GMT
Not After : May 3 19:25:04 2014 GMT
Subject:
countryName = FR
stateOrProvinceName = France
localityName = Rouen
organizationName = tinad
organizationalUnitName = home
commonName = home.tinad.fr
emailAddress = gnieark@free.fr
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
81:4B:C7:3E:9B:C6:EA:60:78:26:B3:8F:77:B4:43:07:07:DE:A8:02
X509v3 Authority Key Identifier:
keyid:BE:1D:5D:B9:F1:53:D6:BD:11:90:8E:5C:0F:D2:BC:99:22:BE:F1:48
Certificate is to be certified until May 3 19:25:04 2014 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated</pre>
<p>Voila, on a notre certificat signé: /srv/ssl/home.tinad.fr.cert.pem et sa clé privée: /srv/ssl/home.tinad.fr.key.pem (chiffrée par un mot de passe là)</p>
<p>On remarque au passage openssl a incrémenté la valeur dans le fichier /srv/ssl/serial .</p>
<p>Créer une clé non protégée par un mot de passe (ça servira à Apache)</p>
<pre class="brush: bash">cd /srv/ssl
openssl rsa -in home.tinad.fr.key.pem -out home.tinad.fr-EnClair.key.pem</pre>
<h3>Créer un certificat pour le serveur Web prive.tinad.fr</h3>
<p>Idem qu'au châpitre précedent, du coup je ne détaille pas:</p>
<pre class="brush: bash">cd /srv/ssl
#Création de la clé privée pour prive.tinad.fr
openssl genrsa -des3 -out prive.tinad.fr.key.pem 4096
#demande de certificat:
openssl req -config openssl.cnf -new -key prive.tinad.fr.key.pem -out prive.tinad.fr.csr.pem
#signature de la demande:
openssl ca -config openssl.cnf -policy policy_anything -out prive.tinad.fr.cert.pem -infiles prive.tinad.fr.csr.pem
#créer une clé non protégée:
openssl rsa -in prive.tinad.fr.key.pem -out prive.tinad.fr-EnClair.key.pem</pre>
<h2>Configuration du serveur web</h2>
<pre class="brush: bash">cd /var/www
#on va créer 5 dossier pour des vhosts:
mkdir home.tinad.fr
mkdir home.tinad.fr-https
mkdir prive.tinad.fr-https
#Il me semble que le VHOST par défault d'apache est le premier par ordre alphabétique;
#d'où le "0" au début du nom
mkdir 0-default
mkdir 0-default-https
#Supprimer les fichiers de vhosts créés à l’installation d'apache
cd /etc/apache2/sites-enabled
rm *</pre>
<h3>configuration des vhost</h3>
<p>Comme vous le verrez, je reste sur une configuration méga basique des VHOST, préférant les valeurs par défaut d’apache aux paramètres non ou mal compris.
De plus je n'utilise pas de script CGI, donc autant ne pas les activer.</p>
<h4>vi /etc/apache2/sites-available/home.tinad.fr</h4>
<pre class="brush: bash"><VirtualHost *:80>
ServerName home.tinad.fr
DocumentRoot /var/www/home.tinad.fr
</VirtualHost></pre>
<h4>vi /etc/apache2/sites-available/home.tinad.fr-https</h4>
<p>Ce VHOST est chiffré en HTTPS, cependant, aucune restriction d'accès n'est effectuée. Pour le test, j'ai mis le certificat de notre propre autorité de certification. Mais en production, autant mettre un vrai certificat (comptez maxi 30€/an). Pour cette maquette, j'y publie le certificat de l'autorité de certification, j'explique comment l'insérer, et je mets un formulaire qui permettra aux utilisateurs de demander leurs propres certificats. (dans le projet final ce sera l'administrateur qui aura accès au formulaire pour générer les certificats)</p>
<pre class="brush: bash"><VirtualHost *:443>
ServerName home.tinad.fr
DocumentRoot /var/www/home.tinad.fr-https
SSLEngine On
SSLCertificateFile /srv/ssl/home.tinad.fr.cert.pem
SSLCertificateKeyFile /srv/ssl/home.tinad.fr-EnClair.key.pem
SSLProtocol all -SSLv2
</Virtualhost></pre>
<h4>vi /etc/apache2/sites-available/prive.tinad.fr-https</h4>
<pre class="brush: bash"><VirtualHost *:443>
ServerName prive.tinad.fr
DocumentRoot /var/www/prive.tinad.fr-https
SSLEngine On
SSLCertificateFile /srv/ssl/prive.tinad.fr.cert.pem
SSLCertificateKeyFile /srv/ssl/prive.tinad.fr-EnClair.key.pem
SSLProtocol all -SSLv2
SSLCACertificateFile /srv/ssl/cacert.pem
SSLCARevocationFile /srv/ssl/crl.pem
SSLVerifyClient require
SSLVerifyDepth 1
SSLOptions +StdEnvVars
</Virtualhost></pre>
<p>Ce VHOST étant le plus intéressant, expliquons les directives</p>
<ul>
<li>SSLEngine On : active le SSL</li>
<li>SSLCertificateFile le fichier contenant le certificat TLS pour prive.tinad.fr</li>
<li>SSLCertificateKeyFile le fichier contenant la clé qui servira à chiffrer les connexions (à garder bien cachée ;) )</li>
<li>SSLProtocol all -SSLv2 On accepte tous les protocoles ssl supportés sauf le SSLV2 qui présente une faiblesse)</li>
<li>SSLCACertificateFile Le fichier certificat de l'autorité qui signe les certificats clients (apache vérifie les signatures)</li>
<li>SSLCARevocationFile Le fichier qui contient la liste des certificats révoqués (nécessaire si on veut gérer les utilisateurs)</li>
<li>SSLVerifyClient require Seuls les clients ayant un certificat valide sont admis</li>
<li>SSLVerifyDepth 1 On limite à une autorité de certification intermédiaire</li>
<li>SSLOptions +StdEnvVars Cette directive permet d'ajouter les informations concernant le certificat client aux variables d'environnement. On pourra ainsi adapter le code PHP en fonction du certificat de l'utilisateur.</li>
</ul>
<h4>Activation des vhost:</h4>
<pre class="brush: bash">a2ensite home.tinad.fr
a2ensite home.tinad.fr-https
a2ensite prive.tinad.fr-https
/etc/init.d/apache2 reload</pre>
<h3>Créer un couple certificat-clé client (fichier PKCS#12):</h3>
<pre class="brush: bash">cd /srv/ssl
mkdir home.tinad.fr-Clefs-clients
cd home.tinad.fr-Clefs-clients</pre>
<p>creer clé</p>
<pre class="brush: bash">openssl genrsa -des3 -out gnieark.home.tinad.fr.key.pem</pre>
<p>Créer le certificat:</p>
<pre class="brush: bash">openssl req -config ../openssl.cnf -new -key gnieark.home.tinad.fr.key.pem -out gnieark.home.tinad.fr.csr.pem</pre>
<p>Retour écran de la dernière commande:</p>
<pre class="brush: bash">Enter pass phrase for gnieark.home.tinad.fr.key.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [FR]:
State or Province Name (full name) [France]:
Locality Name (eg, city) []:Rouen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tinad
Organizational Unit Name (eg, section) []:home
Common Name (e.g. server FQDN or YOUR name) []:gnieark
Email Address []:gnieark@free.fr
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:</pre>
<p>Signer le certificat:</p>
<pre class="brush: bash">openssl ca -config ../openssl.cnf -policy policy_anything -out gnieark.home.tinad.fr.cert.pem -infiles gnieark.home.tinad.fr.csr.pem</pre>
<p>Retour écran de la commande:</p>
<pre class="brush: bash">root@raspberrypi:/srv/ssl/home.tinad.fr-Clefs-clients# openssl ca -config ../openssl.cnf -policy policy_anything -out gnieark.home.tinad.fr.cert.pem -infiles gnieark.home.tinad.fr.csr.pem
Using configuration from ../openssl.cnf
Enter pass phrase for /srv/ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: May 12 17:18:18 2013 GMT
Not After : May 12 17:18:18 2014 GMT
Subject:
countryName = FR
stateOrProvinceName = France
localityName = Rouen
organizationName = tinad
organizationalUnitName = home
commonName = gnieark
emailAddress = gnieark@free.fr
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
47:E4:92:85:3A:43:6A:BC:43:C7:5B:41:F4:67:66:E2:36:CA:D7:69
X509v3 Authority Key Identifier:
keyid:BE:1D:5D:B9:F1:53:D6:BD:11:90:8E:5C:0F:D2:BC:99:22:BE:F1:48
Certificate is to be certified until May 12 17:18:18 2014 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated</pre>
<p>Concatener et convertir au forlat PKCS#12 (.p12)</p>
<pre class="brush: bash">openssl pkcs12 -export -inkey gnieark.home.tinad.fr.key.pem -in gnieark.home.tinad.fr.cert.pem -out gnieark.home.tinad.fr.cert.p12 -name "Gnieark"</pre>
<p>Ça y est, j'ai une clé à) fournir à l'utilisateur Gnieark, il pourra l'intégrer à Firefox ou Internet Explorer (lol) et ainsi accéder au site que j'ai protégé précédent.</p>
<h2>Révoquer un certificat:</h2>
<p>En imaginant que je révoque un Zigazou</p>
<pre class="brush: bash">cd /srv/ssl
openssl ca -config openssl.cnf -revoke prive.tinad.fr/zigazou.prive.tinad.fr.cert.pem
#générer la liste de révocation:
openssl ca -config openssl.cnf -gencrl -out crl.pem
#la visualiser:
openssl crl -in crl.pem -text</pre>
<div class="footnotes"><h4>Note</h4>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2015/03/13/Authentifier-un-client-web-via-un-certificat-TLS#rev-wiki-footnote-1" id="wiki-footnote-1">1</a>] Pour déclarer nos impôts il n'y a plus besoin de certificat personnel, mais les interlocuteurs (fonctionnaires de collectivités) ont leurs propres clés PKCS pour communiquer avec cette administration</p></div>
Vos e-mails sont ils protégés?urn:md5:1d743b88da7434bbe1cd385d3fe1816c2012-12-06T15:18:00+01:002012-12-07T09:23:40+01:00gniearkSSL HTTPS chiffrement et certificatse-mailSSL <p>Je me disais qu'avant de commencer à chercher à faire du GNUPG pour chiffrer ses mails, il fallait peut être simplement regarder comment votre fournisseur de boite mail transmet ces derniers.</p>
<h3>Prenons les hypothèses suivantes:</h3>
<ol>
<li>J'ai entièrement confiance en l'intégrité de mon fournisseur de boites aux lettres.</li>
<li>Mon destinataire a aussi judicieusement choisi son prestataire, sinon je ne lui confierai pas de correspondance privée.</li>
<li>De bout en bout aux étapes 1, 2, 3 et 4 du schéma ci dessous un chiffrement des transmissions est appliqué. A aucune étape, le message ne passe en clair sur le réseau.</li>
</ol>
<p><img src="https://blog-du-grouik.tinad.fr/public/Etapes_envoi_email.png" alt="Etapes_envoi_email.png" style="display:block; margin:0 auto;" title="Etapes_envoi_email.png, déc. 2012" />
<em>Image provenant de wikimedia commons, réalisée par User:Denisg à l'aide du logiciel Dia sous Linux. Licence GFDL.</em></p>
<p>Si ces trois conditions sont réunies, Il n'y a aucune raison que mon e-mail ait pu être lu par quelqu'un d'autre que le destinataire.</p>
<p>Les conditions 1 et 2, je m'en remet à votre jugement. La troisième est l'objet de ce billet. Quels sont les fournisseurs de boites aux lettres qui vont correctement chiffrer les données à toutes les étapes?</p>
<p>Pour le test, le serveur "MTA domaine2.org" est mon serveur de mail qui accepte le TLS mais laisse le choix au correspondant de choisir le protocole qui lui plaît. En consultant les logs du serveur et les entêtes complets des messages reçus, j'ai pu remplir le tableau suivant.</p>
<style type="text/css">
<!--
.tablerapide {text-align: center;}
.ok{background-color: green;}
.bad{background-color: red;}
-->
</style>
<table class="tablerapide">
<tr>
<th>Fournisseur de BAL</th>
<th>Etape 1<br /> via smtp</th>
<th>Etape 1<br />via le webmail</th>
<th>Etape 2<br /> entre le serveur smtp de votre Fournisseur<br/> et celui du fournisseur de votre destinataire</th>
</tr>
<tr>
<td>Gmail</td>
<td class="ok">SSL</td>
<td class="ok">HTTPS</td>
<td class="ok">TLSv1 with cipher RC4-SHA (128/128 bits)</td>
</tr>
<tr>
<td>Facebook</td>
<td>???</td>
<td class="ok">HTTPS</td>
<td class="bad">non chiffré</td>
</tr>
<tr>
<td>Hotmail</td>
<td class="bad">non chiffré</td>
<td class="bad">HTTP *1</td>
<td class="bad">non chiffré</td>
</tr>
<tr>
<td>FREE</td>
<td class="bad">non chiffré</td>
<td class="bad">HTTP</td>
<td class="bad">non chiffré</td>
</tr>
<tr>
<td>Orange</td>
<td class="bad">non chiffré</td>
<td class="bad">HTTP</td>
<td class="bad">non chiffré</td>
</tr>
<tr>
<td>aol</td>
<td class="bad">non chiffré</td>
<td class="bad">HTTP *1</td>
<td class="bad">non chiffré</td>
</tr>
<tr>
<td>neuf</td>
<td class="bad">non chiffré</td>
<td>??? *2</td>
<td class="bad">non chiffré</td>
</tr>
<tr>
<td>mon serveur au travail</td>
<td class="ok">TLS</td>
<td class="ok">HTTPS</td>
<td class="ok">TLSv1 with cipher ADH-AES256-SHA (256/256 bits)</td>
</tr>
</table>
<ul>
<li>1 -> l'authentification sur le webmail se fait en https, mais la lecture en http</li>
<li>2 -> l'authentification était en https, mais n'ayant pas de compte neuf.fr, je ne suis pas allé plus loin.</li>
</ul>
<h3>Conclusion</h3>
<p>Hormis google<sup>[<a href="https://blog-du-grouik.tinad.fr/post/2012/12/06/S%C3%A9curiser-ses-mails%2C-choisir-son-fournisseur#pnote-1120-1" id="rev-pnote-1120-1">1</a>]</sup> aucun des fournisseurs de messagerie testés n'est digne de confiance techniquement, et même en utilisant un qui crypte, si ce n'est pas le cas de celui de votre destinataire, ça ne sert à rien..
Cependant la plus part des e-mails provenant d'entreprises ayant leurs serveurs propres sont chiffrées (constaté sur le serveur de messagerie du travail).</p>
<p>Bref créez vos propres serveurs de messagerie!
Au fait, le programme <a href="http://fr.wikipedia.org/wiki/Frenchelon" hreflang="fr">frenchelon</a>, fierté française... Pas forcément difficile à mettre en place vu que la majorité des e-mails passent en clair sur le réseau.</p>
<div class="footnotes"><h4>Note</h4>
<p>[<a href="https://blog-du-grouik.tinad.fr/post/2012/12/06/S%C3%A9curiser-ses-mails%2C-choisir-son-fournisseur#rev-pnote-1120-1" id="pnote-1120-1">1</a>] et encore, le chiffrement est de 128 bits seulement et les serveurs ne sont pas en Europe</p></div>
Signer ses mailsurn:md5:849127478bce3a4384b55d47755f27512010-06-27T00:02:00+02:002010-07-21T12:31:07+02:00gniearkSSL HTTPS chiffrement et certificatsRéseauSSL <p><img src="https://blog-du-grouik.tinad.fr/public/.SSL-SSL_Logo__red_t.jpg" alt="SSL-SSL_Logo__red.jpg" style="float:left; margin: 0 1em 1em 0;" title="SSL-SSL_Logo__red.jpg, juin 2010" />Nos avons vu dans <a "href="https://blog-du-grouik.tinad.fr/post/2010/06/16/Les-certificats-ssl">ce billet</a> comment faire une autorité de certification. Voyons comment s'en servir pour créer des certificats PKCS12 servant à signer les mails.
Ça n'a aucun intérêt car seuls les personnes ayant votre certificat racine pourront vérifier la signature (enfin pas eux, leur logiciel client mail). C'est juste pour le fun ce billet, Pour des certificats de signature de mail, il vaut mieux regarder du coté des autorités de certification telles que thawte verisign etc....</p>
<p>Creer le certificat et sa clé:</p>
<pre class="bash"><span style="color: #7a0874; font-weight: bold;">cd</span> ~<span style="color: #000000; font-weight: bold;">/</span>CERT
openssl req -new -keyout gnieark\<span style="color: #000000; font-weight: bold;">@</span>tinad.fr-key.pem -out gnieark\<span style="color: #000000; font-weight: bold;">@</span>tinad.fr-req.pem -days <span style="color: #000000;">365</span></pre>
<p>Adaptez les réponses à vos besoins, Cependant le "Organization Name" doit etre le même que le certificat racine:</p>
<pre>
Generating a 1024 bit RSA private key
...++++++
...++++++
writing new private key to 'gnieark@tinad.fr-key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Rouen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tinad
Organizational Unit Name (eg, section) []:tinad.fr
Common Name (eg, YOUR name) []:gnieark@tinad.fr
Email Address []:gnieark@tinad.fr
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
</pre>
<p>Signer le certificat:</p>
<pre class="bash"><span style="color: #7a0874; font-weight: bold;">cd</span> ~
openssl ca -out CERT<span style="color: #000000; font-weight: bold;">/</span>gnieark\<span style="color: #000000; font-weight: bold;">@</span>tinad.fr-cert.pem -infiles CERT<span style="color: #000000; font-weight: bold;">/</span>gnieark\<span style="color: #000000; font-weight: bold;">@</span>tinad.fr-req.pem</pre>
<pre>
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
81:c4:e6:a3:37:dc:50:0a
Validity
Not Before: Jun 25 09:11:12 2010 GMT
Not After : Jun 22 09:11:12 2020 GMT
Subject:
countryName = FR
stateOrProvinceName = France
organizationName = tinad
organizationalUnitName = tinad.fr
commonName = gnieark@tinad.fr
emailAddress = gnieark@tinad.fr
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
1F:AD:68:6F:CE:E3:33:23:6C:2E:4D:86:FD:FC:CD:A4:D9:F5:8F:32
X509v3 Authority Key Identifier:
keyid:2A:96:75:31:A5:A1:0F:1C:19:5E:8D:64:6F:DD:30:44:27:28:23:15
Netscape CA Revocation Url:
http://www.tinad.fr/certs/ca-crl.pem
Netscape CA Policy Url:
http://www.tinad.fr/certs/policys.pdf
Certificate is to be certified until Jun 22 09:11:12 2020 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
</pre>
<p>Convertir le certificat au format PKCS:</p>
<pre class="bash">openssl pkcs12 -<span style="color: #000000; font-weight: bold;">in</span> CERT<span style="color: #000000; font-weight: bold;">/</span>gnieark\<span style="color: #000000; font-weight: bold;">@</span>tinad.fr-cert.pem -inkey CERT<span style="color: #000000; font-weight: bold;">/</span>gnieark\<span style="color: #000000; font-weight: bold;">@</span>tinad.fr-key.pem -certfile demoCA<span style="color: #000000; font-weight: bold;">/</span>cacert.pem -out CERT<span style="color: #000000; font-weight: bold;">/</span>gnieark\<span style="color: #000000; font-weight: bold;">@</span>tinad.fr.p12 -name <span style="color: #ff0000;">"grouik"</span> -<span style="color: #7a0874; font-weight: bold;">export</span></pre>
<pre>
Enter pass phrase for CERT/gnieark@tinad.fr-key.pem:
Enter Export Password:
Verifying - Enter Export Password:
</pre>
<p>Maintenant il faut chopper gnieark@tinad.fr.p12
et le mettre sur son ordinateur.</p>
<p>Le paramétrage de Thunderbird est simple:
Editions paramètres des comptes, dans la partie "sécurité", Il y a tout ce qu'il faut. Ça permet d'envoyer des messages signée: la classe.
<a href="https://blog-du-grouik.tinad.fr/public/pkcsff5.jpg" title="pkcsff5.jpg"><img src="https://blog-du-grouik.tinad.fr/public/.pkcsff5_m.jpg" alt="pkcsff5.jpg" style="display:block; margin:0 auto;" title="pkcsff5.jpg, juin 2010" /></a></p>Les certificats ssl, mémourn:md5:2c014b3da15c397bc0e7928a61bd7d8a2010-06-22T23:48:00+02:002017-06-08T11:01:39+02:00gniearkSSL HTTPS chiffrement et certificatsApachedebianLogiciel-libreRéseauserveurSSLTutoriel-mémo <p>Je n'ai pas compris les mécanismes de cryptographie SSL, l’algorithme de signature des certificats et tout ça, mais le comportement du navigateur, je l'ai constaté:</p>
<p><a href="https://blog-du-grouik.tinad.fr/public/Diagrammessl.jpeg" title="logigramme reaction du navigateur en fonction du certificat"><img src="https://blog-du-grouik.tinad.fr/public/.Diagrammessl_m.jpg" alt="logigramme reaction du navigateur en fonction du certificat" style="display:table; margin:0 auto;" title="logigramme reaction du navigateur en fonction du certificat, juin 2010" /></a></p>
<p>Un serveur mail et un extranet, j'utilise des certificats.</p>
<p>Ça ne fait pas très pro les avertissements du logiciel client mail, ou du navigateur. Ça ne doit pas inspirer confiance aux utilisateurs. Il faut donc éviter toutes les sorties du logigramme en rouge.</p>
<p>La première solution consiste à installer chaque certificat sur tous les postes clients.
Dans le cas d'un LAN qui commence a être conséquent ce n'est plus possible (enfin si peut être par les GPO, mais faudra le faire pour toutes les applis)</p>
<p>La seconde solution consiste à passer par une autorité de certification et lui faire signer les certificats.
Si c'est pour un site web il faut prendre une autorité reconnue par la plupart des navigateurs par défaut: c'est payant.
Si c'est dans un lan ou un parc sur lequel vous avez la main. ça vaut le coup de la créer soi même car on pourra la faire reconnaître. Ce n'est pas ça qui occupera un serveur à temps plein. votre pc sous linux peut devenir une autorité de certification.</p>
<p>Avertissement:
L'autorité de certification ne doit pas avoir le même nom que le serveur applicatif (dans le cas d'un serveur web), sinon c'est de l'auto signé ôO.</p>
<h2>Prérequis, installer les logiciels</h2>
<p>Il y a juste le paquet openssl à installer.</p>
<pre class="brush: bash">apt-get install openssl</pre>
<p>sous suze:</p>
<pre class="brush: bash">zypper in openssl</pre>
<h2>Le fichier de configuration /etc/ssl/openssl.cnf</h2>
<p>Sa modification est optionnelle.<br />
Je l'aisse tout par défaut, sauf ces lignes là:</p>
<pre>
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
</pre>
<p>On va les dé-commenter et renseigner les paramètres. Le but de ces lignes est de marquer dans les certificats les URL qui seront utiles au gestionnaire de certificat du client. On publiera la liste des certificats révoqués par exemple.</p>
<p>pour le test, je vais déposer les fichiers à l'adresse http://www.tinad.fr/certs/</p>
<pre>
nsCaRevocationUrl = http://www.tinad.fr/certs/ca-crl.pem
nsBaseUrl = http://www.tinad.fr/certs/
#nsRevocationUrl #Le lien vers le formulaire où le client peut demander une révocation de son certificat (je laisse commenté)
#nsRenewalUrl #Le lien vers le formulaire où le cleient peut demander le renouvellement de son certificat (je laisse commenté)
nsCaPolicyUrl = http://www.tinad.fr/certs/policy.pdf #Une explication de quoi qu'est certifié par le certificat (la méthode de controle des informations telles que la validation des sites internet, la validité des adresses mail etc...)
#nsSslServerName
</pre>
<p>pour les publier sur le web je créé un lien symbolique. Adaptez la commande à votre configuration:</p>
<pre class="brush: bash">ln -s ~/demoCA/crl/ca-crl.pem /var/www/www.tinad.fr/certs/ca-crl.pem</pre>
<h2>Créer le certificat racine</h2>
<p>Tout en étant en root</p>
<pre class="brush: bash">cd ~
/usr/lib/ssl/misc/CA.pl -newca</pre>
<p>Le script va vous poser plusieurs questions:</p>
<ul>
<li>CA certificate filename (or enter to create)<br /></li>
</ul>
<p>appuyez sur entrée, c'est le premier et le seul certificat racine logiquement.</p>
<ul>
<li>Country Name (2 letter code) [AU]:FR</li>
</ul>
<p>C'est le code du pays</p>
<ul>
<li>State or Province Name (full name) [Some-State]:France</li>
</ul>
<p>Le pays</p>
<ul>
<li>Locality Name (eg, city) []:Rouen</li>
</ul>
<p>La ville (la localisation physique du serveur n'a aucune importance)</p>
<ul>
<li>Organization Name (eg, company) [Internet Widgits Pty Ltd]:gniearkcompany</li>
</ul>
<p>Le nom de l'organisation. Attention ne mettez pas de connerie comme moi, ça apparaitra sur tous les certificats.</p>
<ul>
<li>Organizational Unit Name (eg, section) []:gniearklan</li>
</ul>
<p>C'est facultatif, j'ai mis là le nom de domaine local. dans le cas du CA racine de tinad.fr, j'ai mis "tinad.fr" justement</p>
<ul>
<li>Common Name (eg, YOUR name) []:vm2.gniearklan</li>
</ul>
<p>Il est d'usage de mettre le FQDN complet de la machine. www.tinad.fr par exemple</p>
<ul>
<li>Email Address []:mail@domaine.fr</li>
</ul>
<p>Un contact "administratif"</p>
<p>Au passage le script utilisé a créé quelques dossiers et fichiers dans demoCA.</p>
<ul>
<li>cacert.pem , c'est le certificat qui servira à signer les autres certificats.</li>
<li>careq.pemUn truc qui sert aux demandes de certificat.</li>
<li>private Ce dossier contient la clé privé du certificat racine . Ne pas diffuser.</li>
</ul>
<h2>Diffuser/ installer la clé publique du certificat racine.</h2>
<p>C'est le fichier cacert.pem qu'il faut diffuser et installer dans les applications concernées.</p>
<h3>En utilisant un controleur de domaine win2003</h3>
<p>Dans les parametres de sécurité du controleur de domaine par défaut, on va dans autorités de certification en déroulant l'arbre de gauche, puis "action" et "ajouter". Voir screens ci dessous:
<img src="https://blog-du-grouik.tinad.fr/public/.gpossl0_m.jpg" alt="gpossl0.jpg" style="display:table; margin:0 auto;" title="gpossl0.jpg, juin 2010" /></p>
<p><img src="https://blog-du-grouik.tinad.fr/public/.gpossl1_m.jpg" alt="gpossl1.jpg" style="display:table; margin:0 auto;" title="gpossl1.jpg, juin 2010" /></p>
<p><img src="https://blog-du-grouik.tinad.fr/public/.gpossl_m.jpg" alt="gpossl.jpg" style="display:table; margin:0 auto;" title="gpossl.jpg, juin 2010" /></p>
<h3>Sur chaque poste, firefox</h3>
<p>Editions > préférences > Avancé> chiffrement > afficher les certificats> Autorités de certification
<img src="https://blog-du-grouik.tinad.fr/public/.sslsurff_m.jpg" alt="sslsurff.jpg" style="display:table; margin:0 auto;" title="sslsurff.jpg, juin 2010" /></p>
<h3>Internet explorer
Thunderbird</h3>
<p>C'est à peu près là même chose que sur firefox.</p>
<h3>Outlook</h3>
<p>Je n'ai pas trouvé. Je ne suis pas certain qu'il le prenne en charge (testé sur outlook 2007)</p>
<h2>Créer des certificats signés</h2>
<p>Imaginons que l'autorité de certification est www.tinad.fr et le <strong>site à certifier est www.tinaderp.com</strong> (ça tombe bien va falloir que je le fasse)</p>
<p>On se place pour ça dans le repertoire qui contient le dossier demoCA</p>
<pre class="brush: bash">cd ~</pre>
<p>Creer un dossier qui recevra les certificats et se placer dedans:</p>
<pre class="brush: bash">mkdir cert
cd cert</pre>
<p>Créer une clé privée ainsi qu'un certificat public non signé.</p>
<pre class="brush: bash">openssl req -new -nodes -keyout www.tinaderp.com-key.pem -out www.tinaderp.com-req.pem -days 365</pre>
<p>Je mets le même Organization Name que l'autorité de certification.
ça doit donner ça:</p>
<pre class="brush: bash">www:~/CERT# openssl req -new -nodes -keyout www.tinaderp.com-key.pem -out www.tinaderp.com-req.pem -days 365
Generating a 1024 bit RSA private key
.........++++++
.++++++
writing new private key to 'www.tinaderp.com-key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Rouen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tinad
Organizational Unit Name (eg, section) []:tinaderp
Common Name (eg, YOUR name) []:www.tinaderp.com
Email Address []:identifiant@domaine.fr
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:</pre>
<p>Signer le certificat:</p>
<pre class="brush: bash">cd ~
openssl ca -out cert/www.tinaderp.com-cert.pem -infiles cert/www.tinaderp.com-req.pem</pre>
<pre class="brush: bash">www:~# openssl ca -out CERT/www.tinaderp.com-cert.pem -infiles CERT/www.tinaderp.com-req.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./demoCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
81:c4:e6:a3:37:dc:50:05
Validity
Not Before: Jun 21 16:36:59 2010 GMT
Not After : Jun 18 16:36:59 2020 GMT
Subject:
countryName = FR
stateOrProvinceName = France
organizationName = tinad
organizationalUnitName = tinaderp
commonName = www.tinaderp.com
emailAddress = rpasserieu@tinad.fr
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
8E:EA:52:98:18:D1:F0:CD:5F:FD:97:36:A3:E8:98:73:F1:89:30:15
X509v3 Authority Key Identifier:
keyid:2A:96:75:31:A5:A1:0F:1C:19:5E:8D:64:6F:DD:30:44:27:28:23:15
Certificate is to be certified until Jun 18 16:36:59 2020 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated</pre>
<p>Le certificat signé est créé. on verra plus loin comment l'installer dans apache ou dans postfix</p>
<h2>Installer le certificat et sa clé dans apache.</h2>
<p>Tout d'abord on créé un fichier contenant la clé et le certificat qu'on fournira à Apache.</p>
<pre class="brush: bash">cd ~/cert
cat www.tinaderp.com-key.pem www.tinaderp.com-cert.pem > www.tinaderp.com-certkey.pem</pre>
<p>Mettre le fichier certkey dans les fichiers de conf d'apache</p>
<pre class="brush: bash">mkdir /etc/apache2/ssl
cp ~/cert/www.tinaderp.com-certkey.pem /etc/apache2/ssl/
chmod 600 /etc/apache2/ssl/*
chmod 400 ~/cert/*</pre>
<p>Créer le fichier vhost spécifique à l'https. le certificat est fourni à la directive SSLCertificateFile
pour tinaderp.com, le fichier est /etc/apache2/sites-available/www.tinaderp.com-https.
Sa configuration est relativement basique;</p>
<pre>
<VirtualHost *:443>
ServerName www.tinaderp.com
DocumentRoot /var/www/www.tinaderp.com
ServerAdmin webmaster(NOSPAM)tinad.fr
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/www.tinaderp.com>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined
SSLEngine on
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl/www.tinaderp.com-certkey.pem
SSLVerifyClient none
SSLVerifyDepth 10
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</VirtualHost>
</pre>
<p>activer le site er=t recharger la configuration d'apache:</p>
<pre class="brush: bash">a2ensite www.tinaderp.com-https
/etc/init.d/apache2 reload</pre>
<h2>Dans postfix et imapd</h2>
<h3>certificat smtp</h3>
<p>On suit la méthode ci dessus pour créer des certificats signés. Sauf que cette fois on ne va pas faire de fichier regroupant la clé et le certificat. Il faut lui fournir les deux. Par contre, je sui fourni aussi le cacert.pem qu'on trouve dans demoCa
Ce sont les parametres suivants dans le main.cf</p>
<pre>
smtpd_tls_key_file = /etc/postfix/tls/smtp.tinad.fr-key.pem
smtpd_tls_cert_file = /etc/postfix/tls/smtp.tinad.fr-cert.pem
smtpd_tls_CAfile = /etc/postfix/tls/cacert.pem
</pre>
<h3>certificat imap tls</h3>
<p>vu la config de mon serveur mail, dans le fichier /etc/courier/imapd-ssl
c'est la directive suivante : TLS_CERTFILE=/etc/courier/tinad-certkey.pem</p>
<h2>Révoquer un certificat</h2>
<p>se placer dans le dossier contenant le dossier demoCA, dans mon cas c'est ~</p>
<pre class="brush: bash">cd ~</pre>
<p>Révoquer le certificat en indiquant le fichier cert en parametre.</p>
<pre class="brush: bash">openssl ca -revoke CERT/www.tinaderp.com-cert.pem</pre>
<p>Générer la liste des certificats révoqués:</p>
<pre class="brush: bash">cd ~
www:~# openssl ca -gencrl -out demoCA/crl/cacrl.pem</pre>
<p>Supprimer les fichiers du certificat:</p>
<pre class="brush: bash">CERT
rm www.tinaderp.com-cert.pem
rm www.tinaderp.com-req.pem
rm www.tinaderp.com-key.pem</pre>
<h2>Liens francophones</h2>
<p><a href="http://www.docmirror.net/fr/linux/howto[/apps/SSL-Certificates-HOWTO/x248.html" hreflang="fr">http://www.docmirror.net/fr/linux/howto/apps/SSL-Certificates-HOWTO/x248.html</a><br />
<a href="http://www.starbridge.org/spip/" hreflang="fr">Starbridge</a> (même si les tutos ne portent pas sur les certificats, il y a plusieurs exemples d'utilisation d'openssl)<br />
<a href="http://www.admin-linux.fr/?p=1076" hreflang="fr">Admin linux</a></p>SSH sur la dediboxurn:md5:7a4aa991cb6b94e4b6cdbdf3459b53242009-02-20T21:12:00+01:002010-07-21T21:54:13+02:00gniearkSSL HTTPS chiffrement et certificatsserveurTutoriel-mémo <h2>SSH</h2>
<p><a href="http://doc.ubuntu-fr.org/ssh" hreflang="fr">lien vers la documentation utilisée</a><br /></p>
<p>Dans le cas d'un serveur dédié, ssh est le seul point d'entrée dans la configuration initiale. Autant le paramétrer dès le début car si on se rate, on perd définitivement la main sur le serveur et il faudra relancer l'installation automatique du système de base(qui prend 10 min) mais ça peut être râgeant si on a déja passé plusieurs heures à le configurer.</p>
<h3>installation</h3>
<p>il est installé par défaut sur un serveur dédié. Sinon pour l'installer:</p>
<pre class="bash">apt-get <span style="color: #c20cb9; font-weight: bold;">install</span> openssh-serveur</pre>
<h3>Configuration</h3>
<p>Le fichier de configuration est <em>/etc/ssh/sshd_conf</em>.<br />
Sérieusement, je ne donne pas un mois à votre serveur avant d'être corrompu si certains principes de sécurité ne sont pas appliqués.
Pour que le risque de se faire corrompre le serveur par ce biais se rapproche de 0, on va le configurer de la façon suivante:</p>
<ul>
<li>Interdire la connection de l'utilisateur de root. L'élévation des privilèges est possible en ssh par la suite avec la commande "su". Avec un peu de recul on s'aperçoit que les attaques en force brute (quotidiennes) se font la pluspart du temps par tentatives avec des identifiants bateau, root, par exemple, administrator, admin, webmaster... Interdire la connection à ces identifiants est déja une bonne protection.</li>
<li>Pas d'authentification par mot de passe mais par clé ssh. C'est ce point qui ramène le risque à quasiement 0. Je ne pense pas qu'il soit possible de casser une clé ssh. Par contre de la voler sur l'ordinateur client oui (quoiqu'elle est stockée cryptée)...</li>
<li>Changer le port d'écoute par défaut... Personnellement je ne l'ai pas fait, mais je pense" que c'est aussi une prévention supplémentaire intéressante.</li>
</ul>
<h4>Créer le couple de clés sur le PC client</h4>
<p>Sur le PC client, si vous n'avez pas déja un couple de clés, pour en créer un, avec votre compte utilisateur normal (pas en root):</p>
<pre class="bash"><span style="color: #c20cb9; font-weight: bold;">ssh-keygen</span> -t dsa</pre>
<p>L'utilisation d'une passphrase est conseillée.</p>
<p>Les clés sont placés généralement dans un dossier caché: « <a></a>/.ssh/id_dsa » pour la clé privé.</p>
<p>Pour le moment on peut s'identifier par mot de passe au serveur, utilisons ce biais pour placer la clé publique.</p>
<pre class="bash">ssh-copy-<span style="color: #c20cb9; font-weight: bold;">id</span> -i ~<span style="color: #000000; font-weight: bold;">/</span>.<span style="color: #c20cb9; font-weight: bold;">ssh</span><span style="color: #000000; font-weight: bold;">/</span>id_dsa.pub <span style="color: #000000; font-weight: bold;"><</span>username<span style="color: #000000; font-weight: bold;">>@<</span>ipaddress<span style="color: #000000; font-weight: bold;">></span></pre>
<p>puis pour autoriser la clé:</p>
<pre class="bash"><span style="color: #c20cb9; font-weight: bold;">ssh</span> <span style="color: #c20cb9; font-weight: bold;">login</span><span style="color: #000000; font-weight: bold;">@</span>serveur <span style="color: #ff0000;">"echo $(cat ~/.ssh/id_dsa.pub) >> .ssh/authorized_keys"</span></pre>
<h4>Appliquer la nouvelle méthode d'authentification:</h4>
<p>Sur le serveur, on modifie le fichier <em>/etc/ssh/sshd_conf</em> de la manière suivante:</p>
<p>On change:<br /></p>
<pre>
PermitRootLogin no
PasswordAuthentication no
UsePAM no
</pre>
<p>Eventuellement on définit les utilisateurs ayant accès à ssh (utile si pour certaines fonctions du serveur vous aurez besoin de créer des comptes unix qui n'ont pas lieu de faire du ssh)
On avoute la ligne suivante (remplacez par vos identifiants):</p>
<pre>
AllowUsers user1 user2
</pre>
<p>redémarrage du serveur ssh</p>
<pre class="bash"><span style="color: #000000; font-weight: bold;">/</span>etc<span style="color: #000000; font-weight: bold;">/</span>init.d<span style="color: #000000; font-weight: bold;">/</span><span style="color: #c20cb9; font-weight: bold;">ssh</span> restart</pre>
<p>On se connecte comme ça:</p>
<pre class="bash"><span style="color: #c20cb9; font-weight: bold;">ssh</span> user<span style="color: #000000; font-weight: bold;">@</span>FDQNouIPduServeur</pre>