Pages enfant
  • Installation des certificats esup-smsu

Vous regardez une version antérieure (v. /wiki/display/PROJSMSU/Installation+des+certificats+esup-smsu) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 7) afficher la version suivante »

Mise en place de l'authentification mutuelle entre front office et back office via certificats auto-signés

Principes – définitions

Le front office et le back office communiquent via SSL en utilisant des certificats x509.

L'authentification est dite « mutuelle ». Le front office et le back office doivent chacun avoir un certificat propre qu'ils s'échangent lors de chaque connexion l'un à l'autre.

Afin d'effectuer cette authentification mutuelle deux notions sont importantes sur chaque serveur : le keystore et le truststore.

  • Keystore : chaque serveur (front et back office) doit posséder un keystore. Le keystore contient des ensembles clé publique/clé privée/certificat. Ces éléments sont ses identifiants.
  • Truststore : chaque serveur (front et back office) doit posséder un truststore. Lors de la mise en place de a connexion front/back, chaque extrémité envoi à l'autre son certificat. L'extrémité doit alors valider ce certificat.

Si le certificat reçu est issu d'une autorité de certification, des mécanismes automatiques sont déclanchés pour valider le certificat.

Si le certificat reçu est auto-signé ou bien si le serveur dans l'incapacité d'utiliser les mécanismes automatiques de validation, le serveur va regarder dans une liste de certificats de confiance s'il y trouve ce certificat. Cette liste de certificats de confiance est un truststore.

Au sein d'un keystore ou d'un truststore, chaque certificat (et clés associées dans le cadre des keystore) est identifié par un alias.

Donc, au minimum dans le cadre d'une authentification via certificats auto-signés :

  • Chaque front office possède un keystore avec ses clés et certificat propres et un truststore contenant le certificat du back office auquel il est rattaché.
  • Le back office possède un keystore avec ses clés et certificat propres et un truststore contenant tous les certificats des front offices.

Génération des keystores

keystore back office

Dans tous les web services mis en place, les front offices sont des clients (ils initient la connexion) et le back office serveur. Le certificat d'un serveur doit respecter une règle :

le CN (Common Name, correspondant à la question nom et prénom lors de la génération par keytool) doit correspondre au nom de la machine.

Exécutez la commande suivante :

keytool -genkey -alias serverkey -keystore keystoreserver.jks

Répondez aux questions posées en respectant la règle énoncée ci-dessus.

keystore front office

Les keystore front office contiennent les certificats qui serviront à authentifier les applications appelantes au sein des back office. Chaque certificat front office doit respecter la règle suivante :

le CN (Common Name, correspondant à la question nom et prénom lors de la génération par keytool) doit correspondre au nom de l'application qui sera paramétrée dans le back office.

Exécutez la commande suivante :

keytool -genkey -alias clientkey -keystore keystoreclient.jks

Répondez aux questions posées en respectant la règle énoncée ci-dessus.
Ensuite, auto-signez le keystore créé avec la commande suivante :

keytool -selfcert -alias clientkey -keystore keystoreclient.jks

Ce keystore doit ensuite être ajouté à l'éventuel keystore existant dans l'environnement, par exemple au esup-portail.keystore.

Le certificat est un élément de paramétrage d'applications dans l'administration du back office. Pour extraire le certificat, exécutez la commande suivante :

keytool -export -alias clientkey -keystore keystoreclient.jks -file certifclient.crt

Génération des truststores

Un truststore contient tous les certificats de confiance d'une machine. Si la machine cible contient déjà un truststore, la manipulation consiste à ajouter un nouveau certificat au truststore existant. Le truststore client existe déjà à priori et contient le certificat du serveur CAS. Il ne faut surtout pas le supprimer.

Les manipulations suivantes sont à effectuer de manière à ce que :

  • le truststore du back office contienne tous les certificats des front offices.
  • Chaque truststore client contient le certificat du back office.

Extraire un certificat d'un keystore

Exécutez la commande suivante (à adapter suivant le certificat à extraire) :

keytool -export -alias serverkey -keystore keystoreserver.jks -file certifserveur.crt

Ajouter un certificat à un truststore

Exécutez la commande suivante (à adapter suivant le truststore et le certificat à importer)
Il faut ajouter le certificat du serveur au truststore du client :

keytool -import -keystore truststoreclient.jks -alias certifserver -file certifserveur.crt

Il faut ajouter le certificat du client au truststore du serveur :

keytool -import -keystore truststoreserver.jks -alias certifclient -file certifclient.crt

Paramétrage serveur back office

Le back office est déployé en tant que servlet. La mise en place de la liaison sécurisée avec authentification du client se fait au niveau du paramétrage du connecteur du serveur tomcat utilisé pour les web services.

En mode quick start

Lors d'un déploiement en mode quick start, le paramétrage des keystore et truststore back office s'effectue via les propriétés suivantes du fichier build.properties :

  • tomcat.keystore : chemin vers le keystore
  • tomcat.keypass : mot de passe du keystore
  • tomcat.truststore : chemin vers le truststore
  • tomcat.truststorePass : mot de passe du truststore

Le fichier server.xml utilisé par le serveur tomcat lancé est celui situé dans le dossier
utils/tomcat. Le connecteur est paramétré comme suit :

<Connector
    port="${tomcat.port}"
    maxHttpHeaderSize="8192"
    maxThreads="150"
    minSpareThreads="25"
    maxSpareThreads="75"
    enableLookups="false"
    redirectPort="8444"
    acceptCount="100"
    connectionTimeout="20000"
    disableUploadTimeout="true"
    scheme="https" secure="true"
    clientAuth="true" sslProtocol="TLS"
    keystoreFile="${tomcat.keystore}"
    keystorePass="${tomcat.keypass}"
    truststoreFile="${tomcat.truststore}"
    truststorePass="${tomcat.truststorePass}"
/>

Paramétrage front office

Déploiement servlet

Afin de faciliter la mise en place lors d'un déploiement servlet du front office, la mise en place des keystore et truststores (qui sont uniques pour un environnement) a été mise en place au sein même de l'application.

Les propriétés suivantes du fichier config.properties sont à renseigner :

  • smsuapi.ws.trustStore : chemin vers le truststore
  • smsuapi.ws.trustStorePassword : mot de passe du truststore
  • smsuapi.ws.keyStore : chemin vers le keystore
  • smsuapi.ws.keyStorePassword : mot de passe du keystore

Ensuite, décommentez le bean initSslParameters du fichier properties/client/client.xml

Déploiement portlet

Dans le cadre d'un déploiement portlet, keystore et truststore sont fournis par le portail. La mise en place des certificats du service SMS-U doit venir compléter l'existant (notamment utilisé pour l'authentification au serveur CAS). Les clés et certificats doivent être importés dans les keystore et truststore existants et être paramétrés pour être pris en compte au lancement du portail.

Une solution consiste à modifier le fichier env.cmd du portail de la sorte :

SET TRUST_CERT=[chemin du truststore]
SET KEY_CERT=[chemin du keytore]
SET PWD_KEYSTORE=[mot de passe du keystore]

Puis modifier le fichier start-esup pour y intégrer la commande suivante :

SET CATALINA_OPTS="-Djavax.net.ssl.keyStore=%KEY_CERT%" "-Djavax.net.ssl.keyStorePassword=%PWD_KEYSTORE%" "-Djavax.net.ssl.trustStore=%TRUST_CERT%"

Debuggage ssl

La sécurisation des connexions est un point sensible de l'environnement.
Il est possible de suivre les événements SSL de l'application en paramétrant le variable d'environnement suivante avant lancement du serveur Tomcat :

CATALINA_OPTS = "-Djavax.net.debug=ssl"

Glossaire

Glossaire des manuels du service SMS-U

  • Aucune étiquette