Certificats SSL Wildcard

avril 02, 2007  |   Blog   |     |   Commentaires fermés sur Certificats SSL Wildcard

Certificat SSL JokerLes certificats X.509 Wildcard (ou Joker en français) permettent de prouver l’identité de tous les serveurs d’un même domaine *.mondomaine.fr.

L’utilisation de ce type de certificats procure une évidente économie en terme de coût d’acquisition et de facilité de gestion (déploiement, renouvellement, renommage, etc..) comparée à l’acquisition de multiples certificats individuels.

Mais, c’est également le seul moyen d’utiliser SSL sur un serveur Web (ou un reverse Proxy) hébergeant de multiples Virtual Hosts appartenant à un même domaine.


En effet, les requete HTTP sont transmises au serveur après l’établissement du canal sécurisé SSL (les étapes du schéma ci-dessous entre parenthèses et relatives à l’authentification du client sont optionnelles) :

SSL Handshake

Ainsi, la couche SSL doit présenter au client le certificat SSL du serveur demandé alors que le client n’a pas encore effectué la requête HTTP (contenant le Header Host) et donc précisé le nom du Virtual Host auquel il veut s’addresser.

Si tous les Virtual Host possèdent des noms du type *.mondomaine.fr, alors le certificat wildcard sera accepté sans restriction par le client.

On voit ci dessous une trace réalisée avec curl :
# curl -v -o dump.txt https://www.mondomaine.fr
* About to connect() to www.mondomaine.fr port 443
* Trying xxx.xxx.xxx.xxx... connected
* Connected to www.mondomaine.fr (xxx.xxx.xxx.xxx) port 443
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* SSLv2, Client hello (1):
SSLv3, TLS handshake, Server hello (2):
SSLv3, TLS handshake, CERT (11):
SSLv3, TLS handshake, Server key exchange (12):
SSLv3, TLS handshake, Server finished (14):
SSLv3, TLS handshake, Client key exchange (16):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSLv3, TLS change cipher, Client hello (1):
SSLv3, TLS handshake, Finished (20):
SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* subject: /C=FR/ST=IDF/L=Ville Cedex/O=MonDomaine/CN=*.mondomaine.fr
* start date: 2007-mm-dd 14:44:02 GMT
* expire date: 2009-mm-dd 14:44:02 GMT
* common name: *.mondomaine.fr (matched)
* issuer: /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
* SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.15.1 (powerpc-unknown-linux-gnu) libcurl/7.15.1 OpenSSL/0.9.8a zlib/1.2.3 libidn/0.5.18
> Host: www.mondomaine.fr
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Mon, 02 Apr 2007 20:45:06 GMT
< Server: RP M
< Location: http://web.mondomaine.fr/default.asp
< Content-Length: 0
< Content-Type: text/plain
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connection #0 to host www.mondomaine.fr left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):

On voit bien que le certificat est accepté à la comparaison entre le nom fourni à l’applicatif (ici curl) et du CN (Common Name) inscrit dans le certificat.
Cette étape est bien antérieure à la requête HTTP :
> GET / HTTP/1.1
> User-Agent: curl/7.15.1 (powerpc-unknown-linux-gnu) libcurl/7.15.1 OpenSSL/0.9.8a zlib/1.2.3 libidn/0.5.18
> Host: www.mondomaine.fr
> Accept: */*

Pour l’anecdote, on peut également noter la redirection HTTP (code 403) vers la page spécifiée dans le Header Location envoyé par le serveur http://web.mondomaine.fr/default.asp.

De par leur nature, les certificats Wildcard ont vocation à être intégrés sur de nombreux serveurs et applicatifs qui n’ont pas généré le CSR initial (Certificate Signing Request). Certains applicatifs ne permettent l’import d’un certificat et de la clé privé qu’au moyen d’un format PKCS#12.

Pour créer un container PKCS#12 contenant la clé privée et le certificat, il suffit de lancer la commande suivante avec OpenSSL (porté sur la plupart des OS existants) :
# openssl pkcs12 -export -in server.crt -inkey server.key -export -name "MonContainer" -out cert.p12

On peut en vérifier l’intégrité par :

# openssl pkcs12 -in cert.p12 -info -noout
Enter Import Password:
MAC Iteration 2048 MAC verified OK
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag
PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

Certaines restrictions demeurent cependant :

  • les sous-domaines (i.e *.sousdomaine.mondomaine.fr) ne sont pas supportés par le certificat *.mondomaine.fr. Il faut donc commander des certificats pour chacun de ces sous-domaine si c’est nécessaire.
  • certains clients peuvent ne pas reconnaitre ou supporter intégralement ce type de certificats (notamment les technologies Microsoft, voir ici)
  • les Autorités de Certification facturent parfois une licence proportionnelle au nombre de serveurs physiques utilisant le certificat wildcard. Le certificat étant numérique, il peut être dupliqué à volonté sans redevance mais alors en violation de la licence « commerciale ».

Enfin, comme on a pu le voir dans un précédent article, cette factorisation des certificats (et donc la dissémination induite de l’unique clé privée) n’a pas d’impact si les ciphers autorisés sont forts.

Les commentaires sont fermés.