Galère avec apache2 et gnutls

Support Debian
#1

Salut,
Je n’ai pas vu de fil au sujet de gnutls sur le forum, mais sait-on jamais…

J’essaye de faire fonctionner gnutls (à la place de ssl) sur apache: Succès mitigé…

J’ai 2 vhosts:
1 sur le port 22443 qui fonctionne…
1 sur le port 443 qui ne fonctionne pas…

/etc/apache2/ports.conf (j’ai essayé plein de trucs… les lignes commentées…)

[code]#
# If you add NameVirtualHost *:443 here, you will also have to change
# the VirtualHost statement in /etc/apache2/sites-available/default-ssl
# to <VirtualHost *:443>
# Server Name Indication for SSL named virtual hosts is currently not
# supported by MSIE on Windows XP.
#Listen 443
#

#
#Listen *:443
#NameVirtualHost xxx.xxx.xxx.xxx:443
#NameVirtualHost *:443
#Listen 127.0.0.1:443
#

#
#Listen 443
#

#Listen *:22443
Listen 22443
#NameVirtualHost xxx.xxx.xxx.xxx:22443
#NameVirtualHost [ipv6]:22443
#NameVirtualHost *:22443

Listen 80
#Listen *:80
#NameVirtualHost *:80

Listen 443
NameVirtualHost xxx.xxx.xxx.xxx:443
#Listen *:443[/code]

Le vhost qui fonctionne:

NameVirtualHost *:22443 ... GnuTLSEnable on GnuTLSPriorities NORMAL:!DHE-RSA:!DHE-DSS:!AES-256-CBC:%COMPAT GnuTLSDHFile /etc/certs/gnutls/dh.key GnuTLSClientCAFile /etc/certs/gnutls/ca.crt GnuTLSCertificateFile /etc/certs/gnutls/apache.crt GnuTLSKeyFile /etc/certs/gnutls/apache.key ServerName domain.tld:22443 ...

Le vhost qui ne fonctionne pas:

[code]
…
GnuTLSEnable on
GnuTLSPriorities NORMAL:!DHE-RSA:!DHE-DSS:!AES-256-CBC:%COMPAT
GnuTLSDHFile /etc/certs/gnutls/dh.key
GnuTLSClientCAFile /etc/certs/gnutls/ca.crt

GnuTLSCertificateFile /etc/certs/gnutls/apache.crt

    GnuTLSCertificateFile /etc/certs/gnutls/sous.domain.tld.crt

GnuTLSKeyFile /etc/certs/gnutls/apache.key

    GnuTLSKeyFile /etc/certs/gnutls/sous.domain.tld.key

…
ServerName sous.domain.tld:443[/code]

J’ai essayé de générer un certificat et clef pour le sous domaine, j’ai toujours la même erreur.
C’est ch… :12

Je précise que le vhost qui ne fonctionne pas est un sous-domaine, celui qui fonctionne est sur le domaine principal.

#2

Bonjour,

Il faut créer la structure des certificats avec le nom du sous-domaine, lors de l’exécution de la commande suivante,

pour que cela fonctionne correctement.
En d’autres termes, le certificat doit être établi au nom du sous-domaine (à ne pas confondre avec le nom du fichier lui-même).

#3

Salut,
Merci pour le précision. J’avais essayé ça aussi. J’utilise les outils de gnutls et pas ceux d’openssl:
Et j’ai bien créé un “template” pour le sous-domaine avec comme “common name” le sous-domaine lui-même.

certtool --generate-privkey --outfile sous.domain.tld.key certtool --generate-certificate --load-privkey sous.domain.tld.key --load-ca-certificate ca.crt --load-ca-privkey ca.key --template sous.domain.tld.tpl --outfile sous.domain.tld.crt

Tu penses qu’il vaut mieux utiliser les outils “openssl” pour les clef et ceetificats ?

#4

Re,
Je vais refaire un essai, mais cette fois-ci en créant un nouveau ca.key et ca.crt…

#5

Inutile, il n’y a pas le cn dans les ca…

Toujours cette erreur:
Iceweasel: SSL a reçu un enregistrement qui dépasse la longueur maximale autorisée. (Code d’erreur : ssl_error_rx_record_too_long)
Chromium: Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

:017

#6

Je ne comprend pas…

J’arrive à accéder à sous.domain.tld:443 (alors que mod_ssl n’aime pas du tout…)

Ça a un sens pour vous ?

Et j’ai toujours l’erreur avec gnutls quand j’utilise les certificats qui fonctionnent bien avec mod-ssl…

#7

[quote=“lol”]Tu penses qu’il vaut mieux utiliser les outils “openssl” pour les clef et ceetificats ?[/quote]Je n’en ai aucune idée.
Nous avons utilisé OpenSSL, car ils sont aussi présents, en standards, sur d’autres appliances Linux.

#8

Bon, après moultes recherches, il semblerait que la version de openssl et de apache que j’utilise supporte le SNI (Server Name Indication).

Et il semble que ça fonctionne…

[code]# Go ahead and accept connections for these vhosts

from non-SNI clients

SSLStrictSNIVHostCheck off[/code]

Et du coup il est possible d’avoir de multiples vhosts en https sans passer par gnutls…
wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Actif sur openssl depuis la version 0.9.8f et sur apache2 depuis la version 2.2.12 (d’après mes lectures).

On va dire que c’est résolu (disons contourné si on se réfère au titre du post)

#9

[quote=“lol”]Bon, après moultes recherches, il semblerait que la version de openssl et de apache que j’utilise supporte le SNI (Server Name Indication).[/quote]Je l’ai aussi lu, mais pas testé.
Nous avions fait le choix d’installer GnuTLS pour couvrir notre besoin car, à l’époque, il semblait que seule cette solution (GnuTLS) permettait d’avoir des hôtes virtuelles en mode sécurisé. (https)
Je serais intéressé par un retour d’expérience sur le mode ssl d’Apache pour gérer plusieurs sites en mode sécurisé (https).

#10

Salut,
Pas de soucis, je vais faire des essais et je donnerais un retour.

J’utilise Ispconfig3 sur mon serveur, et la gestion du SSL est un peu différente de la gestion “classique” d’Apache2; Il faut que j’adapte un peu pour mes essais - à moins que je teste sur un autre dédié ovh (Au Canada).
Il faut le temps que je génère les certificats avec startssl (on peux pas dire que ce soit très “user friendly” leur interface…) et que je mette en place le vhost.

#11

Voilà, tout fonctionne:

madagascarportal.com/
a.madagascarportal.com/
b.madagascarportal.com/
c.madagascarportal.com/
portalmadagascar.com/
a.portalmadagascar.com/
b.portalmadagascar.com/
c.portalmadagascar.com/

Certificat de chez cacert.org

[code]apt-cache policy openssl
openssl:
Installed: 0.9.8o-4squeeze4

apt-cache policy apache2
apache2:
Installed: 2.2.16-6+squeeze7[/code]

Pas d’erreur dans les logs, rien de spécial dans la conf d’apache au sujet de SNI.

[quote]c.madagascarportal.com
The identity of this website has been verified by CA Cert Signing Authority.

Your connection to c.madagascarportal.com is encrypted with 256-bit encryption.

The connection uses TLS 1.0.

The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and DHE_RSA as the key exchange mechanism.

The connection is compressed with DEFLATE.[/quote]

:023

#12

:038 :clap:

et merci du retour