Avant d’accéder à une page web cryptée (protocole https), le navigateur va réaliser deux vérifications :
Dans le protocole SSL v.2, les concepteurs ont prévu qu’à un site correspond un certificat. Mais avec le déploiement des « virtual hosts », qui permettent de faire héberger de multiples sites dans le même serveur, cette approche ne tient plus.
Cette situation ne serait, en soi, pas vraiment problématique, si le protocole ne prévoyait pas que le serveur doit fournir le certificat, basée sur l’adresse IP de destination, avant qu’il ne puisse lire le nom du domaine (le nom du site). Ainsi, il n’est pas possible de fournir plusieurs certificats pour une même adresse IP.
Pour remédier à ce problème, deux évolutions ont été mises en œuvre. La première consiste à autoriser la création de certificats « génériques », où le nom du domaine contiendrait des caractères génériques ; par exemple, on pourrait créer un certificat *.mondomaine.com. Tous les sites de ce domaine pourraient alors utiliser le même certificat. Cette solution présente des avantages, mais également pas mal d’inconvénients, et notamment le fait de ne pas avoir la liste exhaustive des sites rattachés. Les risques de rajout « intempestif » d’un site à partir d’un certificat générique pourraient être assez importants.
La seconde solution a consisté à faire évoluer la norme SSL-TLS, en autorisant le serveur à lire le nom du domaine pendant la négociation SSL, et donc d’envoyer le bon certificat correspondant à un vhost particulier.
Cette extension s’appelle Server Name Indication (SNI), et est implémentée dans tous les navigateurs récents. Elle n’est pas supportée dans Internet Explorer 7 dans Windows XP, mais l’est dans les versions des OS de Microsoft à partir de Vista.
Dans notre configuration, nous avons mis en place un accès à une arborescence bureautique, qui plus est accessible avec le protocole WEBDAV, protocole qui permet de modifier les fichiers en accédant à l’arborescence en mode http ou https. Dans notre cas de figure, l’accès n’est possible qu’en https.
Apache n’est capable d’accéder à un fichier qu’à partir du moment où le compte www-data (dans Ubuntu) dispose des droits d’accès. Nous devons donc, pour l’arborescence considérée, donner les droits d’accès à ce compte.
Si vous avez activé les ACL, il suffit de lancer les commandes :
setfacl -R -m u:www-data:rwx /monArborescence
setfacl -R -m d:u:www-data:rwx /monArborescence
pour que le compte www-data puisse écrire dans celle-ci. Si vous n’avez pas activé les acl, il faut mettre le compte www-data dans le groupe propriétaire de votre arborescence.
Nous allons activer le support de webdav dans Apache, ainsi que le support ldap :
a2enmod authnz_ldap
a2enmod ldap
a2enmod dav_fs
Il faut également que les fichiers créés par webdav aient le bon masque. Pour cela, rajoutez la ligne suivante dans /etc/apache2/envvars :
umask 007
Les fichiers seront créés avec le masque 770
Redémarrez ensuite Apache...
Le support de SNI est implémenté dans Apache à partir de la version 2.2.12, mais nécessite également que OpenSSL soit en version 0.9.8j. Pour Ubuntu 10.04, le support est total.
Vérifiez qu’openssl soit installé dans votre machine, de même qu’Apache. A titre d’exemple, voici les paquets installés sur ma machine :
aptitude search ssl|grep ^i
i libnet-ssleay-perl - Perl module for Secure Sockets Layer (SSL)
i libssl0.9.8 - SSL shared libraries
i openssl - Secure Socket Layer (SSL) binary and relat
i A ssl-cert - simple debconf wrapper for OpenSSL
aptitude search apache2|grep ^i
i A apache2 - Apache HTTP Server metapackage
i A apache2-mpm-worker - Apache HTTP Server - high speed threaded m
i A apache2-utils - utility programs for webservers
i A apache2.2-bin - Apache HTTP Server common binary files
i A apache2.2-common - Apache HTTP Server common files
Cette opération dépasse le cadre de ce document. En voici, en quelques mots, le principe :
openssl genrsa -out monserveur.pem 1024
(1024 pour une clé d’une longueur de 1024 bits).
pour chacun des sites hébergés, créez une requête de demande de signature de certificat avec la commande :
openssl req -new -key monserveur.pem -out monsiteweb.csr
Pour activer le support SSL et SNI, il faut activer le site par défaut ssl-default. Voici l’ensemble des opérations à réaliser (commandes effectuées avec Ubuntu 10.04, à adapter le cas échéant) :
cd /etc/apache2/sites-available
mv default-ssl 00_default-ssl
Editez le fichier 00_default-ssl :
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin adresse_admin@monsite.com
DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/apache2/error.log
LogLevel warn
CustomLog /var/log/apache2/ssl_access.log combined
Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>
SSLEngine on
SSLCertificateFile {{/etc/ssl/certs/monsitepardefaut.pem}}
SSLCertificateKeyFile {{/etc/ssl/private/monserveur.pem}}
SSLCACertificatePath /etc/ssl/certs/
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</VirtualHost>
NameVirtualHost *:443
# Go ahead and accept connections for these vhosts
# from non-SNI clients
SSLStrictSNIVHostCheck off
</IfModule>
Activez maintenant le mode ssl :
a2enmod ssl
a2ensite 00_default-ssl
service apache2 restart
Pour information, les commandes a2enmod et a2ensite ne font que créer des liens dans les dossiers apache2/sites-enabled et apache2/mods-enabled vers les fichiers déclarés dans apache2/sites-available et apache2/mods-available. Les commandes inverses sont a2dissite et a2dismod.
Vérifiez que votre serveur Apache fonctionne bien, sinon regardez votre configuration. En particulier, assurez-vous que vous n’avez bien qu’une seule commande listen 443...
Nous allons maintenant créer un vhost par site. Ces vhosts sont déclarés dans le dossier /etc/apache2/sites-available.
Pour chaque site, nous allons créer un fichier, par exemple 50_informatique.conf. Voici les différentes informations à déclarer.
Tout d’abord, nous protégeons l’accès au dossier qui héberge notre site. Dans notre cas de figure, il s’agit d’une arborescence bureautique, dont l’accès est limité aux membre du groupe INFORMATIQUE du domaine DOMAINE, déclaré dans un annuaire LDAP. L’accès est réalisé avec l’adresse https://informatique.masociete.fr :
<directory /opt/donnees/informatique>
Nous autorisons, pour ce dossier, la possibilité de suivre les liens (pas recommandé, il faut savoir ce que l’on fait) :
options Indexes FollowSymLinks
order allow,deny
allow from all
allowOverride all
Activons le mode webdav pour ce dossier :
dav on
Puis gérons l’identification :
authType basic
Nous indiquons le nom du domaine (l’information sera affichée dans le navigateur) :
AuthName DOMAINE
AuthBasicProvider ldap
Ici, deux serveurs ldap sont déclarés, en redondance :
AuthLDAPURL "ldaps://serveurldap1 serveurldap2 /ou=people,o=societe,c=fr?uid?sub"
AuthLDAPGroupAttributeIsDN off
AuthLDAPGroupAttribute memberUid
Nous allons maintenant gérer les droits d’accès selon deux modes : les droits en lecture, et les droits en écriture. Ici, le groupe draf pourra lire les fichiers, et le groupe msi les modifier.
# lecture-ecriture
<Limit GET POST OPTIONS PROPFIND PUT DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK HEAD>
require ldap-group cn=msi,ou=Group,o=societe,c=fr
</Limit>
# Lecture
<Limit GET POST OPTIONS PROPFIND>
require ldap-group cn=draf,ou=Group,o=societe,c=fr
</limit>
Il est possible d’autoriser autant de groupes que nécessaires, en dupliquant les lignes require. Avec ce mécanisme, il est facile de redéfinir les accès pour une arborescence complète, en complément des ACL classiques.
</directory>
Nous allons maintenant rediriger les appels en http vers https. Dans la première partie, nous redirigeons les adresses sans suffixe (accès depuis l’intranet, avec un suffixe DNS rajouté automatiquement) :
<VirtualHost *:80>
ServerName informatique
RewriteEngine On
RewriteRule ^ https://informatique.masociete.fr/%{REQUEST_URI} [R]
</VirtualHost>
<VirtualHost *:80>
ServerName informatique.masociete.fr
ServerPath /informatique.masociete.fr
RewriteEngine On
RewriteRule ^ https://informatique.masociete.fr/%{REQUEST_URI} [R]
</VirtualHost>
Et nous paramétrons maintenant notre accès en mode https:
<VirtualHost *:443>
ServerAdmin administrateur@masociete.fr
ServerName informatique.masociete.fr
ServerPath /informatique.masociete.fr
DocumentRoot /opt/donnees/informatique
SSLEngine on
Nous indiquons maintenant la clé publique signée, envoyée par l’autorité de certification :
SSLCertificateFile /etc/ssl/certs/informatique_masociete_fr.pem
et la clé privée, commune pour l’ensemble du serveur :
SSLCertificateKeyFile /etc/ssl/private/monserveur.pem
ainsi que le certificat de l’autorité racine (ici, celle de l’administration) :
SSLCACertificateFile /etc/ssl/certs/igca-racine-serveur.crt
</VirtualHost>
Il reste à activer notre site :
a2ensite 50_informatique.conf
service apache2 reload
Pour une raison inconnue, Ubuntu n’applique pas la directive umask définie dans le fichier envvars (cf. paragraphe 2 , Configuration d’Apache pour le mode WEBDAV). Il crée les fichiers en mode 600, ce qui limite les capacités de modifications par des tierces personnes...
Pour corriger ça, nous allons exécuter un script à intervalle régulier, qui va modifier les fichiers dont le mode est égal à 600. Pour cela, éditons le crontab :
crontab -e
00,10,20,30,40,50 * * * * find /opt/donnees/informatique -perm 600 -exec chmod 660 {} \;
Ainsi, toutes les 10’, le système va rechercher les fichiers en mode 600 pour les transformer en 660 dans notre arborescence.
Si cela pose des problèmes de performance, il faut alors modifier le déclenchement du script, pour qu’il ne s’exécute que 1 à 2 fois par jour, aux heures creuses...
Le mode webdav n’a été implémenté que très récemment par Microsoft. Il ne fonctionne, et encore de manière très imparfaite, qu’à partir de Windows XP (pas testé sous Windows 2000, mais il ne doit plus rester beaucoup de machines avec cet OS...). De plus, Windows XP ne supporte pas le mode webdav sécurisé en https...
Avec Windows Seven, théoriquement, le support est complet, mais il faut impérativement modifier une clé de registres pour qu’il puisse travailler avec un serveur webdav Apache :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WebClient\Parameters]
"BasicAuthLevel"=dword:00000002
Dans la pratique, ça ne fonctionne pas... Je conseille d’utiliser un logiciel client dédié : bitKinex, qui fonctionne parfaitement, bien qu’en anglais : http://www.bitkinex.com/
Le support dans Linux est complètement pris en charge (testé avec Ubuntu 10).
Pour Mac, je ne sais pas... mais je présume que ça doit fonctionner !