Christophe Le Bot

Voilà une nouvelle que j’attendais depuis 6 ans ! Avant d’expliquer pourquoi, voici la définition d’une autorité de certification (selon le site de sécurité de Teamlog) :

Une Autorité de Certification appelée aussi AC ou CA (Certificate Authority) est chargée d’émettre et de gérer des certificats numériques.

Elle est responsable de l’ensemble du processus de certification et de la validité des certificats émis. Une Autorité de Certification doit définir une Politique de certification qui va établir l’ensemble des règles de vérification, de stockage et de confidentialité des données appartenant à un certificat ainsi que la sécurité de stockage de sa propre clef privée nécessaire à la signature des certificats.

Les certificats émis par ces autorités permettent d’accéder à des services web sécurisés (paiement en ligne, consultation de comptes bancaires, services administratifs), mais aussi de signer des documents numériques pour en certifier l’origine et le contenu (e-mails, contrats, certificats de déclaration). Ils garantissent donc l’authenticité, la sécurité et la confidentialité des informations.

Le problème, c’est que les autorités de certification racine (celles qui certifient les autorités de certification, dites « autorités de certification déléguées ») sont toutes des sociétés de droit privé étrangères (pour ne pas dire américaines…). Dès lors, comment garantir le contrôle, la confidentialité et la fiabilité des échanges sécurisés de l’État français ? Pourquoi dépenser des sommes importantes dans la sécurisation des échanges, si la base est faillible ? J’ai souvent été confronté à ce dilemne lors de mes interventions dans des institutions publiques… sans avoir d’autre choix que d’installer des certificats américains sur des serveurs de l’administration française !

En devenant lui-même autorité de certification racine (grâce au RGS, Référentiel Général de Sécurité, qu’il vient de créer), l’État français gagne enfin son indépendance. Dorénavant, les services administratifs pourront obtenir des certificats du RGS pour permettre aux agents et aux administrés d’échanger des données en toute confiance.

Cependant, il reste deux zones d’ombre :

• Les navigateurs web vont devoir intégrer la reconnaissance du certificat racine du RGS (pour Firefox, ce sera vite fait, pour Internet Explorer, je suis beaucoup moins sûr…).
• Les entreprises privées et les particuliers doivent toujours assurer la sécurité de leurs informations sur des certificats racine délivrés par des sociétés américaines.

Source : linuxfr.org

Un internaute est un être précieux… mais volatile. Il suffit d’un détail pour que votre site passe aux oubliettes.

Dans la « top list » des petits trucs qui agacent : l’obligation d’entrer « www. » dans la barre d’adresse du navigateur pour accéder à un site. Quatre caractères qui n’apportent aucune information particulière, sauf celle de définir un site web (ce que l’on sait déjà puisqu’on utilise le protocole HTTP). Heureusement, la plupart des sites propose un accès via leur domaine seul (exemple.com) ou avec l’adresse complète (www.exemple.com).

Cependant, aux yeux des moteurs d’indexation, il s’agit de deux sites différents. Votre contenu sera donc diluer dans les index des moteurs de recherche. De même, les liens vers votre site ou son clone diminueront le « poids » de vos pages web (le fameux « page rank » de Google, par exemple).

Pour conserver l’avantage d’une adresse courte et éviter le double référencement, il suffit de placer ces lignes dans le fichier .htaccess situé à la racine du site :

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
RewriteRule (.*) http://www.exemple.com/$1 [QSA,R=301,L]

Cette règle de réécriture permettra au serveur de rediriger les visiteurs (et les moteurs d’indexation) vers l’adresse complète (www.exemple.com).

Pourquoi ne pas en profiter pour faire l’inverse, à savoir simplifier l’adresse en redirigeant vers le domaine seul ? Parce que la norme impose de garder « www » comme adresse principale d’un site web. Internet et les noms de domaines existaient bien avant le web (les premiers domaines en « .com » ont été achetés en 1985, cinq ans avant la naissance du web) et servent à d’autres services internet (messagerie, transferts de fichiers, surveillance réseau).

Google, Yahoo et Microsoft, frères ennemis ? Pas toujours ! Ils savent aussi travailler ensemble quand cela favorise leurs intérêts respectifs. Un exemple : le protocole Sitemap, initié par Google, fait maintenant l’objet d’un site dédié (sitemaps.org) et d’une licence Creative Commons pour favoriser son adoption. Autant dire de suite que Sitemap sera LE standard d’indexation du contenu des sites web.

Avec Sitemap, le webmaster reprend la main sur l’indexation de son site : il peut en décrire la hiérarchie, favoriser l’importance d’une page ou indiquer la régularité des mises à jour. Ces données sont stockées dans un ou plusieurs fichiers XML soumis directement aux moteurs d’indexation.

C’est toujours mieux que le simple fichier robots.txt, mais ce n’est pas encore la panacée. Sitemap est parfait quand la structure du site évolue peu. Par contre, lorsqu’à l’occasion d’une refonte, des contenus changent de rubriques, sont fusionnés ou éclatés, changent de domaine, Sitemap ne sait pas décrire ces changements. Certes, les codes de statut HTTP peuvent y remédier, notamment les 301, 302, 303 et 307, mais ils sont souvent mal exploités (quand ils le sont…) par les systèmes de gestion de contenu et sont plutôt destinés aux navigateurs web qu’aux moteurs d’indexation.

La bonne idée serait donc d’ajouter quelques balises dans les fichiers XML Sitemap pour indiquer les changements de structuration du contenu (suppression, déplacement, fusion, éclatement, pages liées, etc.). On pourrait alors se passer du fichiers robots.txt et de quelques balises META dans le code HTML de chaque page. On pourrait même imaginer se passer des codes de statut HTTP si le navigateur web savait exploiter les fichiers XML Sitemap. Il me reste à contacter les frères ennemis pour mettre tout cela en place !

Avec le projet « Tutoriel sur les serveurs » du site Linux-France, vous avez de quoi attraper une indigestion de lecture : c’est long, avec le look « geek Linux », mais quelle richesse !

Même si j’ai beaucoup de mal à lire cette prose dégoulinante à l’écran, j’y trouve souvent les petits détails qui règlent mes gros soucis !

Votre petit serveur Debian fonctionne toujours à merveille (comment pourrait-il en être autrement ?). Mais un matin, tout se bloque. Un rapide tour de la machine, un petit df -h en ligne de commande et le constat est sans appel : plus de place sur le disque ! Il faut en ajouter un second.

Voici brièvement comment monter un disque ATA :

1. Installer le disque (alimentation, connexion IDE sur le bon port, en maître ou en esclave, avec une nappe de 80 fils)
2. Partionner le disque (bien vérifier le nom du nouveau disque pour ne pas partitionner le premier !) :

   cfdisk /dev/hdb

3. Formater chaque partition :

   mke2fs -j /dev/hdb1

4. Tester chaque partition :

   cd /mnt
   mkdir disque2
   chmod 777 disque2
   mount -t ext3 /dev/hdb1 /mnt/disque2
   cd /mnt/disque2

5. Monter le disque au démarrage du système :

   cd /etc
   vi fstab

   Ajouter la ligne :

   /dev/hdb1 /mnt/disque2 ext3 defaults 1 1

   (options selon l’utilisation que vous en ferez)

Finalement, c’est plus simple qu’on ne l’imagine !