Apache HTTPS

Bonjour,

Je dispose d’un serveur sur internet qui héberge un site internet (SPIP) et des listes de diffusion (MailMan). J’ai installé PHPMyAdmin pour gérer MySQL et PHPLDAPAdmin pour gérer les identités.

J’ai voulu configurer le serveur de telle sorte que lorsqu’un visiteur accède à PHPMyAdmin ou PHPLDAPAdmin ou MailMan, il soit automatiquement dirigé vers une connexion sécurisée (HTTPS). Je n’y suis pas parvenu : impossible d’avoir plusieurs accès SSH …

Est-ce que vous confirmez ? Est-ce possible ou pas d’avoir plusieurs accès HTTPS pour protéger chaque interface d’administration ?

[quote=“skerain”]Bonjour,

Je dispose d’un serveur sur internet qui héberge un site internet (SPIP) et des listes de diffusion (MailMan). J’ai installé PHPMyAdmin pour gérer MySQL et PHPLDAPAdmin pour gérer les identités.

J’ai voulu configurer le serveur de telle sorte que lorsqu’un visiteur accède à PHPMyAdmin ou PHPLDAPAdmin ou MailMan, il soit automatiquement dirigé vers une connexion sécurisée (HTTPS). Je n’y suis pas parvenu : impossible d’avoir plusieurs accès SSH …

Est-ce que vous confirmez ? Est-ce possible ou pas d’avoir plusieurs accès HTTPS pour protéger chaque interface d’administration ?[/quote]

je ne vois pas pour le ssh mais sinon, tu peux toujours faire une redirection permanente au niveau d’apache.

En supposant que ta configuration SSL est opérationnelle, dans ton VirtualHost Apache tu peux faire :

[code]RewriteEngine On

RewriteCond %{REQUEST_URI} ^/phpmyadmin
RewriteRule ^/(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L][/code]
(pour activer le module de réécriture d’URL, c’est la commande a2enmod rewrite)

Ou si tu veux plusieurs redirections :

RewriteCond %{REQUEST_URI} ^/phpmyadmin [OR] RewriteCond %{REQUEST_URI} ^/pattern1 [OR] RewriteCond %{REQUEST_URI} ^/pattern2 RewriteRule ^/(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

[quote=“skerain”]Bonjour,
Est-ce que vous confirmez ? Est-ce possible ou pas d’avoir plusieurs accès HTTPS pour protéger chaque interface d’administration ?[/quote]

je confirme. https et virtualhost ne font pas bon menage. la raison est que apache quand il voit une requête cryptée arriver ne peut savoir quelle URL tu as demandé il ne voit que l’adresse IP destination. il ne sait donc pas l’envoyer dans un virtualhost.

donc avec https un seul host par adresse IP.

la meilleur solution quand on a une seule IP publique est de tout mettre sur le même virtualhost comme ceci

mondomaine.com -> ton site spip
mondomaine.com/phpldapadmin
mondomaine.com/phpmyadmin

++

j’ai fait un simple

j’ai la même chose pour phpmyadmin et je n’ai pas de problème.

Merci à tous ! :slightly_smiling:

C’est une erreur commune, mais il est tout a fait possible de faire du https avec plusieurs virtual hosts. Au choix :

  • Les virtual hosts peuvent se partager le même certificat (celui ci doit alors être multi-domaine)
  • L’emploi des extensions SNI (navigateur pas trop vieux et Apache 2.2.12)

C’est une erreur commune, mais il est tout a fait possible de faire du https avec plusieurs virtual hosts. Au choix :

  • Les virtual hosts peuvent se partager le même certificat (celui ci doit alors être multi-domaine)
  • L’emploi des extensions SNI (navigateur pas trop vieux et Apache 2.2.12)[/quote]

–> http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts

[quote]Why can’t I use SSL with name-based/non-IP-based virtual hosts?

The reason is very technical, and a somewhat “chicken and egg” problem. The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this, mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to go to the correct virtual server Apache has to know the Host HTTP header field. To do this, the HTTP request header has to be read. This cannot be done before the SSL handshake is finished, but the information is needed in order to complete the SSL handshake phase. Bingo!

Why is it not possible to use Name-Based Virtual Hosting to identify different SSL virtual hosts?

Name-Based Virtual Hosting is a very popular method of identifying different virtual hosts. It allows you to use the same IP address and the same port number for many different sites. When people move on to SSL, it seems natural to assume that the same method can be used to have lots of different SSL virtual hosts on the same server.

It comes as rather a shock to learn that it is impossible.

The reason is that the SSL protocol is a separate layer which encapsulates the HTTP protocol. So the SSL session is a separate transaction, that takes place before the HTTP session has begun. The server receives an SSL request on IP address X and port Y (usually 443). Since the SSL request does not contain any Host: field, the server has no way to decide which SSL virtual host to use. Usually, it will just use the first one it finds, which matches the port and IP address specified.

You can, of course, use Name-Based Virtual Hosting to identify many non-SSL virtual hosts (all on port 80, for example) and then have a single SSL virtual host (on port 443). But if you do this, you must make sure to put the non-SSL port number on the NameVirtualHost directive, e.g.

NameVirtualHost 192.168.1.1:80

Other workaround solutions include:

Using separate IP addresses for different SSL hosts. Using different port numbers for different SSL hosts.[/quote]

J’insiste, c’est tout à fait possible. On peut avoir plusieurs virtual host en https sur une même IP.
Ou alors j’ai des hallucinations très convaincantes avec mon Apache. :laughing:

Je peux te faire une démo si tu insistes (deux noms de domaine différents pointant sur la même IP, qui servent pourtant deux sites https différents). Mais si tu peux te contenter de ces liens ma flemme t’en sera reconnaissante :wink:
Extension SNI :
en.wikipedia.org/wiki/Server_Name_Indication
Sans les extensions SNI, en partageant le même certificat :
crsr.net/Notes/Apache-HTTPS- … -host.html
Un PDF traitant du sujet :
switch.ch/pki/meetings/2007 … lhosts.pdf
Une doc Gentoo sur ce sujet :
en.gentoo-wiki.com/wiki/Apache2/ … tual_Hosts

J’ai moi aussi cru que ce n’était pas possible. La doc Apache, je l’avais lu et je m’étais arrêté là. Mais il faut croire qu’elle n’a pas été mise à jour depuis longtemps. Résultat, de multiples sites Internet relaie cette information “partielle” (pour ne pas dire erronée). Internet c’est parfois une vraie plaie. Un truc abscons qui a été vrai il y a longtemps et ne l’est plus maintenant se retrouve en têtes des moteurs de recherche pendant un bon bout de temps.

[quote]The following combinations do not support SNI:

Client side

* Konqueror/KDE in any version[18]
* Internet Explorer (any version) on Windows XP
* Safari on Windows XP
* wget[19]
* BlackBerry Browser
* Windows Mobile up to 6.5[20]
* Android default browser[21] (Targeted for Honeycomb but won't be fixed until next version for phone users as Honeycomb will be reserved to tablets only)
* Oracle Java JSSE (As of 2011[update])

[/quote]

effectivement ça à l’air génial …

dan sce cas à dit pas que ça marche, ni que c’est possible … c’est juste un vulgaire bidouillage

[quote=“thomas.leclerc”]
effectivement ça à l’air génial …

dan sce cas à dit pas que ça marche, ni que c’est possible … c’est juste un vulgaire bidouillage[/quote]

Tu as mal lu, c’est pas faute de m’être répété pourtant.
On a PLUSIEURS choix :

  • avec les extensions SNI. Ce n’est PAS du bidouillage, c’est une extension implémentée par tous les produits qui veulent bien s’en donner la peine. De plus son adoption s’élargit au fil du temps. Est-ce que toutes les normes qui mettent du temps à s’installer constitue un “bidouillage”?
  • SANS les extensions SNI, c’est possible et ça marche aussi. Il faut que les sites partagent le même certificat. C’est effectivement une contrainte, mais pas pour tout le monde (moi je m’en fiche, c’est la solution que j’utilise et ça m’arrange bien)

Bref, je préfère dire que ça marche et que c’est possible (même si c’est sous condition) que d’affirmer péremptoirement “avec https un seul host par adresse IP”, ce qui est faux. Et de ne pas en démordre en ergotant ensuite sur un “bidouillage”.