Sommaire

Références

FAQ de l'IGC du CRU, en particulier, les documents keystore1 et keystore2
Utilisation de certificats X509 en Java
Recherche de dysfonctionnements CAS
Un exemple de mise en oeuvre à l'INT Evry

Pourquoi utiliser

...

Le serveur CAS doit travailler en HTTPS pour pouvoir utiliser pleinement ses fonctionnalités.

En particulier, pour l'URL de login, afin de crypter les échanges de mot de passe, et lors du transport du PGT, celui-ci devant être protégé.

Il est donc fortement recommandé que le serveur CAS ne soit accessible qu'en HTTPS.

Lors de la récupération d'un PGT, le serveur CAS génère une connexion https vers le proxy CAS; il faut donc que cette URL de 'callback' soit également accessible en HTTPS.

Ce document décrit deux méthodes de configuration de CAS :

avec des certificats auto-signés (pour des tests)
avec des certificats délivrés par la PKI pilote du CRU (en intégration avec uPortal)
Pour comprendre les besoins, il faut distinguer les deux types d'usage des certificats liés aux communications https directes entre une appli cliente java et un serveur https, l'appli cliente étant dans notre cas une servlet de même que l'appli serveur.
Côté serveur https

L'application serveur https doit être accessible en ... https.

...

certificats

...

Deux cas sont traité ici :

Le serveur est un serveur apache, frontal du serveur application
Tomcat traite directement les requêtes https
Apache en frontal

On utilise habituellement mod_ssl. Voir la documentation à ce sujet. D'une manière très succinte :

SSLCertificateFile précise le nom du fichier qui contient la clé privée
SSLCertificateChainFile précise le nom d'un fichier en format PEM qui contient le certificat du serveur, et des éventuelles Autorités de Certification.
Tomcat 'standalone'

Il faut préparer un keystore (magasin de certificat) qui doit contenir à la fois la clé privée du serveur https, et le certificat du serveur et éventuellement celui des AC de la chaine de certification.

Voir le document officiel tomcat.

Côté client https

Il faut que l'application cliente génère des connexions https vers le serveur. Il est donc nécessaire de lui faire connaitre les serveurs auxquels elle peut faire confiance. Il faut donc lui communiquer le certificat (pas la clé privée, bien sur) du serveur https, ou de l'une des AC de la chaine de certification éventuelle.

Dans l'environnement java, ceci se fait également avec un keystore, qui peut être paramétré de plusieurs façons :

Soit ajouter le certificat dans le keystore par défaut de la JVM
Soit préciser au lancement de la JVM (donc dans notre cas, de tomcat) de ne pas utiliser le keystore global de la JVM, mais celui qu'on aura préparé
Soit l'application java est programmée pour savoir lire un keystore particulier. Ce n'est pas le cas du serveur CAS ni d'uPortal.
Configuration de CAS avec des certificats auto-signés (pour des tests)

On suppose ici que le serveur CAS et uPortal fonctionnement avec la même instance de tomcat. Cette partie explique comment faire fonctionner CAS avec des certificats auto-signés.

Cette partie de documentation n'est utile que pour des tests ; il est déconseillé d'utiliser des certificats auto-signés en production, une PKI devient vite obligatoire.

Création du certificat

...

)

...

On désire ensuite enregistrer juste le certificat dans un keystore de certificats 'trusted' (autorisés).

On peut l'enregistrer dans le keystore de la JVM ; cette méthode n'est pas la meilleure. Il est préférable de l'enregistrer dans un keystore spécifique, qui sera pris en compte lors du lancement de tomcat au lieu du keystore de la JVM.

Génération du couple de clés

On commence par générer un couple de clés (certificat auto-signé) pour le serveur (cas.univ-xxx.fr) et on stocke dans le magasin serveur.keystore :

Bloc de code


% keytool -genkey -alias tomcat -dname "CN=cas.univ-xxx.fr,OU=X,O=Y,L=Z,S=XY,C=YZ" -keyalg RSA -storepass yyyyyy -keystore cas.keystore
Enter key password for <tomcat>
(RETURN if same as keystore password):

cas.keystore contient à la fois la clé privée du serveur, et le certificat auto-signé qui contient la clé publique.

Exportation du certificat auto-signé

On exporte ensuite le certificat dans un fichier (cas.cert) :

Bloc de code
% keytool -export -alias tomcat -storepass yyyyyy -file cas.cert -keystore cas.keystore Certificate stored in file <cas.cert>

cas-cert ne contient que le certificat, sans la clé privée.

Ajout du certificat dans le magasin global du JDK

Pas souhaitable. Il est préférable d'enregistrer ce certificat dans un kestore dédié à une instance de tomcat. Voir le paragraphe suivant.

Rappel : le mot de passe par défaut du magasin global de Java est "changeit".

Bloc de code


% keytool -import -v -trustcacerts -alias tomcat -file cas.cert -keystore $JAVA_HOME/jre/lib/security/cacerts -keypass xxxxxx -storepass changeit
Owner: CN=cas.ifsic.univ-rennes1.fr, OU=X, O=Y, L=Z, ST=XY, C=YZ
Issuer: CN=cas.ifsic.univ-rennes1.fr,   OU=X, O=Y, L=Z, ST=XY, C=YZ
Serial number: 3eb79610
Valid from: Tue May 06   13:01:36 CEST 2003 until: Mon Aug 04 13:01:36 CEST 2003
Certificate fingerprints:
   MD5: 0B:20:52:BC:7C:EA:28:58:16:FB:3C:2F:C4:D2:E2:35
   SHA1: 00:5A:F5:81:B1:07:1C:EB:C3:1F:C4:89:5E:76:87:43:D7:8F:F0:5F
Trust this certificate? [no]: yes
Certificate was added to keystore
[Saving /usr/java/j2sdk1.4.1_02/jre/lib/security/cacerts]

Contrôle :

Bloc de code


% keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit
Keystore type: jks
Keystore provider: SUN

Your keystore contains 16 entries

[...]
tomcat, May 6, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 0B:20:52:BC:7C:EA:28:58:16:FB:3C:2F:C4:D2:E2:35
[...]

Copier le fichier serveur.keystore dans un répertoire non listable HTTP (par exemple /etc/x509).

Enregistrement du certificat dans un keystore 'privé'

C'est la méthode préconisée. Au lieu d'enregistrer le certificat (qui ne contient que la clé publique du serveur) dans le keystore global de la JVM, on va l'enregistrer dans un keystore (cas-cacerts) qui sera déclaré lors du lancement de tomcat, et utilisé à la place du keystore global.

Bloc de code
keytool -import -v -trustcacerts -alias tomcat -file cas.cert -keystore cas-cacerts -keypass xxxxxx -storepass changeit

Maintenant, lors du lancement de tomcat qui doit faire confiance à CAS :

Bloc de code
CATALINA_OPTS="-Djavax.net.ssl.trustStore=cas-cacerts";export CATALINA_OPTS

Configuration de Tomcat

Modifier le fichier server.xml de tomcat :

Bloc de code


<!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->
  <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
             port="8443" minProcessors="5" maxProcessors="75"
             enableLookups="true"
             acceptCount="10" debug="0"    scheme="https" secure="true"
             useURIValidationHack="false">
    <Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
             clientAuth="false" protocol="TLS"
             keystoreFile="/etc/x509/cas.keystore" keystorePass="yyyyyyy"/>
  </Connector>

Configuration de CAS et uPortal avec des certificats de la PKI pilote du CRU

On suppose ici que le serveur CAS est porté sur la machine cas.univ-xxx.fr, et uportal sur la machine uportal.univ-xxx.fr

On dispose des fichiers suivants, générés par le CRU (stockés dans /etc/x509) :

Références

FAQ de l'IGC du CRU
cachain.pem : chaine d'autorités de CA (ac-racine -> ac-serveur)
ac-serveur.pem : c'est le certificat ac-serveur du CRU
cas.univ-xxx.fr.crt : le certificat pour la machine cas (signé par ac-serveur)
cas.univ-xxx.fr.key : la clé privée pour la machine cas
uportal.univ-xxx.fr.cer : le certificat pour la machine uportal (signé par ac-serveur)
uportal.univ-xxx.fr.key : la clé privée pour la machine uportal
Est décrite ici l'installation du certificat sur la machine cas. La procédure est similaire pour la machine uportal. Avertissement
title Important
Il est possible, avec la PKI du CRU, de travailler différemment ; c'est plus simple dans un environnement java.
Il suffit, à l'aide de keytool, de générer la bi-clé et une requête de certification.
Il faut alors d'envoyer cette requête de certification au CRU, qui va nous retourner le certificat X509 correspondant.
Toute la procédure pour générer le keystore peut alors se faire uniquement avec l'utilitaire keytools, sans avoir besoin d'autres outils.
Voir : Utilisation de certificats X509 en Java

Création du keystore pour le serveur CAS

Il faut au préalable récupérer le package org.mortbay.jetty-jdk1.2.jar livré avec la distribution de Jetty.

On va ensuite procéder en plusieurs étapes :

génération d'un certif pkcs12 depuis la clé privée du serveur et son certif
génération du keystore depuis le pkcs12
ajout de la chaine de certification
Si on n'ajoute pas la chaine de certification, celle-ci n'est pas transmise aux navigateurs clients, ce qui peut poser problème.
Récupération/installation de Jetty

Récupérer Jetty-x.y.z.tgz de http://jetty.mortbay.org (dernière version 4.2.9) et installer :

Bloc de code
% cd /usr/local % mv /tmp/Jetty-4.2.9.tgz src % tzxf src/Jetty-4.2.9.tgz

Le package contient l'utilitaire PKCS12Import qui sait créer un fichier keystore à partir d'un certificat pkcs12.

Génération du certificat serveur au format pkcs12

On génère le certif pkcs12 depuis la clé privée du serveur et son certificat PEM (on entre le mot de passe xxxxxx en interactif) :

Bloc de code
% cd /etc/x509 % openssl pkcs12 -export -inkey cas.univ-xxx.fr.key -in cas.univ-xxx.fr.cert -out cas.pkcs12 Enter Export Password: xxxxxx Verifying - Enter Export Password: xxxxxx

On peut le contrôler (keytool sait lire un fichier pkcs12) :

Bloc de code


% keytool -list -v -keystore cas.pkcs12 -storetype pkcs12 -storepass xxxxxx
Type Keystore : pkcs12
Fournisseur Keystore : SunJSSE

Votre Keystore contient 1 entrée(s)

Nom dalias : {0}
Date de création : 23 juin 2003
Type d'entrée : keyEntry
Longueur de chaîne du certificat : 1
Certificat[1]:
Propriétaire : EMAILADDRESS=reseau@univ-xxx.fr, CN=cas.univ-nancy2.fr, O=Universite xxx, C=FR
Émetteur : EMAILADDRESS=ca-admin@cru.fr, CN=ac-serveur, O=CRU, C=FR
Numéro de série : 6
Valide du : Wed Jun 04 17:13:25 CEST 2003 au : Fri Jun 04 17:13:25 CEST 2004
Empreintes de certificat :
         MD5 :  09:10:0D:03:77:A6:D2:2D:DA:92:7D:65:E8:A3:1E:90
         SHA1: C5:55:94:B1:39:8A:67:09:1B:E4:F0:C4:FE:2D:31:96:8F:9C:31:AC

Génération du magasin de clé

C'est le keystore qui va contenir clés privée et publique, et le certificat ; c'est celui qui devra être déclaré dans le fichier server.xml du serveur tomcat de CAS.

On utilise l'utilitaire PKCS12Import (on donne un mot de passe yyyyyy au nouveau magasin) :

Bloc de code


% java -classpath /usr/local/Jetty-4.2.9/lib/org.mortbay.jetty-jdk1.2.jar org.mortbay.util.PKCS12Import cas.pkcs12 cas.keystore
Enter input keystore passphrase: xxxxxx
Enter output keystore passphrase: yyyyyy
Alias 0: 1
Adding key for alias 1

Le nom d'alias créé est 1. Si on veut le changer (en cas, par exemple) :

Bloc de code
% keytool -keyclone -keystore cas.keystore -alias 1 -dest cas -storepass yyyyyy Spécifiez le mot de passe de la clé pour <cridev> (appuyez sur Entrée si le résultat est identique à <1>)

Contrôle (le magasin doit maintenant contenir les 2 alias) :

Bloc de code


% keytool -list -keystore cas.keystore -storepass yyyyyy
Type Keystore : jks
Fournisseur Keystore : SUN

Votre Keystore contient 2 entrée(s)

1, 23 juin 2003, keyEntry,
Empreinte du certificat (MD5) : 09:10:0D:03:77:A6:D2:2D:DA:92:7D:65:E8:A3:1E:90
cas, 23 juin 2003, keyEntry,
Empreinte du certificat (MD5) : 09:10:0D:03:77:A6:D2:2D:DA:92:7D:65:E8:A3:1E:90

On peut ensuite effacer le premier :

Bloc de code


% keytool -delete -alias 1 -keystore cas.keystore -storepass yyyyyy
% keytool -list -keystore cas.keystore -storepass yyyyyy
Type Keystore : jks
Fournisseur Keystore : SUN

Votre Keystore contient 1 entrée(s)

cridev, 23 juin 2003, keyEntry,
Empreinte du certificat (MD5) : 09:10:0D:03:77:A6:D2:2D:DA:92:7D:65:E8:A3:1E:90

Ajout de la chaine d'autorités de certification

Récupérer le fichier cachain.txt contenant les certificats des AC ac-racine et ac-serveur (donc, la chaine de certification) à http://igc.cru.fr/ac-serveur/, choisir 'Chaine de certification).

Pour cela, on concatène le fichier cas.univ-xxx.crt avec cachain.pem (le echo sert à ajouter un CR au fichier cas.univ-xxx.crt) :

Bloc de code
% (cat cas.univ-xxx.crt ; echo ; cat cachain.txt) > certchain-cas.pem

keytool n'aime pas ce format de fichier. 2 solutions, le transformer en format DER avec openssl, ou plus simple, éditer ce fichier pour éliminer tout ce qui n'est pas entre des lignes ----BEGIN CERTIFICATE--- et -----END CERTIFICATE----
On choisit cette seconde méthode, ce qui donne quelque chose du genre :

Bloc de code


----BEGIN CERTIFICATE-----
MIIEBzCCAu+gAwIBAgICANcwDQYJKoZIhvcNAQEEBQAwUDELMAkGA1UEBhMCRlIx
... certif de serv.univ.fr ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID1zCCAr+gAwIBAgIBAzANBgkqhkiG9w0BAQQFADBPMQswCQYDVQQGEwJGUjEM
... certif de l'ac-serveur ...
nbnQ04fo+LDLFWa9qCI8mLX1JGcP4WDKJ9hk
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIID1jCCAr6gAwIBAgIBADANBgkqhkiG9w0BAQQFADBPMQswCQYDVQQGEwJGUjEM
... certif de l'ac-racine ...
6cKi0FjWaBYjBOH6/ULalf1g4P38vbUAT4A=
-----END CERTIFICATE-----

et on importe dans le keystore :

Bloc de code


% keytool -import -alias cas -trustcacerts -file certchain-cas.pem -keystore cas.keystore -storepass yyyyyy
Certificat du plus haut niveau dans la réponse :

Propriétaire : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
Émetteur : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
Numéro de série : 0
Valide du : Thu Apr 17 16:16:24 CEST 2003 au : Sun Apr 14 16:16:24 CEST 2013
Empreintes de certificat :
         MD5 :  25:44:35:56:18:E4:EF:65:02:25:99:C6:4E:17:00:38
         SHA1: 33:88:49:67:76:43:8F:58:4D:1F:93:9B:55:CF:C3:A5:37:23:39:B4

... n'est pas digne de confiance. Installer la réponse quand même ? [non] :  oui
Réponse de certificat installée dans le Keystore

Contrôle (cas.keystore doit contenir une entrée de type keyEntry, une longueur de chaine de certif de 3, et les 3 certificats de la chaîne de confiance) :

Bloc de code


% keytool -list -v -keystore cas.keystore
Type Keystore : jks
Fournisseur Keystore : SUN

Votre Keystore contient 1 entrée(s)

Nom dalias : {0}
   Date de création : 23 juin 2003
   Type d'entrée : keyEntry
   Longueur de chaîne du certificat : 3
   Certificat[1]:
   Propriétaire : EMAILADDRESS=reseau@univ-nancy2.fr, CN=cridev.univ-nancy2.fr,    O=Universite de Nancy 2, C=FR
   Émetteur : EMAILADDRESS=ca-admin@cru.fr, CN=ac-serveur, O=CRU, C=FR
   Numéro de série : 6
   Valide du : Wed Jun 04 17:13:25 CEST 2003 au : Fri Jun 04 17:13:25 CEST 2004
   Empreintes de certificat :
   MD5 : 09:10:0D:03:77:A6:D2:2D:DA:92:7D:65:E8:A3:1E:90
   SHA1: C5:55:94:B1:39:8A:67:09:1B:E4:F0:C4:FE:2D:31:96:8F:9C:31:AC
   Certificat[2]:
   Propriétaire : EMAILADDRESS=ca-admin@cru.fr, CN=ac-serveur, O=CRU, C=FR
   Émetteur : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
   Numéro de série : 3
   Valide du : Fri May 16 11:39:11 CEST 2003 au : Fri Dec 14 10:39:11 CET 2012
   Empreintes de certificat :
   MD5 : 1D:51:5F:45:D1:CC:E9:C4:DA:4A:F6:F6:F9:CD:E3:11
   SHA1: 4E:27:8C:05:B5:6C:03:EA:A1:5B:F0:01:AE:D1:86:43:E9:03:6D:B6
   Certificat[3]:
   Propriétaire : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
   Émetteur : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
   Numéro de série : 0
   Valide du : Thu Apr 17 16:16:24 CEST 2003 au : Sun Apr 14 16:16:24 CEST 2013
   Empreintes de certificat :
   MD5 : 25:44:35:56:18:E4:EF:65:02:25:99:C6:4E:17:00:38
   SHA1: 33:88:49:67:76:43:8F:58:4D:1F:93:9B:55:CF:C3:A5:37:23:39:B4

Supprimer les fichiers intermédiaires

Bloc de code
/bin/rm certchain-cas.pem cas.pkcs12

Paramétrer tomcat pour https

La procédure est la même que pour l'installation rapide. Dans le fichier server.xml de tomcat :

Bloc de code


<!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 -->
  <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
             port="8443" minProcessors="5" maxProcessors="75"
             enableLookups="true" acceptCount="10" debug="0"
             scheme="https" secure="true" useURIValidationHack="false"
             disableUploadTimeout="true">
     <Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"
             clientAuth="false" protocol="TLS"
             keystoreFile="/etc/x509/cas.keystore" keystorePass="yyyyyy"/>
  </Connector>

Tester en accédant https://cas.univ-xxx.fr:8443.

Prise en compte de l'autorité de CA

Les paragraphes précédents ont permis de faire fonctionner les 2 serveurs tomcat (uportal et cas) en HTTPS.

Ces 2 serveurs vont avoir besoin de dialoguer directement entre eux en HTTPS. Il faut donc qu'ils puissent valider mutuellement le certificat de l'autre, sinon :

Bloc de code
ERROR - YaleCASContext: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Couldn't find trusted certificate

Pour celà, on va déclarer l'autorité de CA ac-racine dans le keystore de la machine virtuelle java.

Transformation du format du certificat de l'autorité racine

L'utilitaire keytool veut du format DER (en fait, il peut utiliser du format pem, mais expurgé du 'superflu' : il ne faut laisser que les infos entre 'BEGIN CERTIFICATE' et 'END CERTIFICATE'). On transforme donc les certificats comme ceci :

Bloc de code
% openssl x509 -in ac-racine.pem -out ac-racine.der -outform DER

Pour s'assurer de la lisibilité du certificat :

Bloc de code


% keytool -printcert -file ac-racine.der
Propriétaire : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
Émetteur : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
Numéro de série : 0
Valide du : Thu Apr 17 16:16:24 CEST 2003 au : Sun Apr 14 16:16:24 CEST 2013
Empreintes de certificat :
         MD5 :  25:44:35:56:18:E4:EF:65:02:25:99:C6:4E:17:00:38
         SHA1: 33:88:49:67:76:43:8F:58:4D:1F:93:9B:55:CF:C3:A5:37:23:39:B4

Intégration de l'autorité de certification du CRU dans Java

2 méthodes :

soit on enregistre l'AC du CRU dans le keystore global de la JVM
soit on l'enregistre dans un keystore dédié à une instance de JVM.
Les 2 solutions sont présentées.
Intégration de l'autorité de certification du CRU dans la JVM

Bloc de code


% keytool -import -alias CRU-ac-racine -file ac-racine.der -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit
Propriétaire : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
Émetteur : EMAILADDRESS=ca-admin@cru.fr, CN=ac-racine, O=CRU, C=FR
Numéro de série : 0
Valide du : Thu Apr 17 16:16:24 CEST 2003 au : Sun Apr 14 16:16:24 CEST 2013
Empreintes de certificat :
         MD5 :  25:44:35:56:18:E4:EF:65:02:25:99:C6:4E:17:00:38
         SHA1: 33:88:49:67:76:43:8F:58:4D:1F:93:9B:55:CF:C3:A5:37:23:39:B4
Faire confiance à ce certificat ? [non] :  oui
Certificat ajouté au Keystore

Contrôle :

Bloc de code


% keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit
Votre keystore contient 17 entrée(s)
Type Keystore : jks
Fournisseur Keystore : SUN

[...]
cru-ac-racine, 23 juin 2003, trustedCertEntry,
Empreinte du certificat (MD5) : 25:44:35:56:18:E4:EF:65:02:25:99:C6:4E:17:00:38

Intégration de l'autorité de certification du CRU dans un keystore 'privé'

L'objectif est de faire en sorte que le serveur de servlet (en l'occurence, tomcat) utilise un keystore qui lui est dédié pour les autorités de certification 'trusted', au lieu du keystore de la JVM.

Création du kestore :

Bloc de code
keytool -import -v -trustcacerts -alias CRU-ac-racine -file ac-racine.der -keystore cru-ac-racine.cert -storepass yyyyyy

Maintenant, lors du lancement de tomcat qui doit faire confiance à CAS :

...

Recherche de dysfonctionnements CAS

Pages enfant

Comparaison des versions

Ancienne version 2

Nouvelle version Actuel

Légende

Références

Côté serveur https

Apache en frontal

Tomcat 'standalone'

Côté client https

Création du certificat

Génération du couple de clés

Exportation du certificat auto-signé

Ajout du certificat dans le magasin global du JDK

Enregistrement du certificat dans un keystore 'privé'

Configuration de Tomcat

Références

Création du keystore pour le serveur CAS

Récupération/installation de Jetty

Génération du certificat serveur au format pkcs12

Génération du magasin de clé

Ajout de la chaine d'autorités de certification

Supprimer les fichiers intermédiaires

Paramétrer tomcat pour https

Prise en compte de l'autorité de CA

Transformation du format du certificat de l'autorité racine

Intégration de l'autorité de certification du CRU dans Java

Intégration de l'autorité de certification du CRU dans la JVM

Intégration de l'autorité de certification du CRU dans un keystore 'privé'

Pages enfant

Pages … Documentation Authentification Single Sign On CAS Utilisation de certificats X509 pour CAS Historique de la page

Comparaison des versions

Ancienne version 2

Nouvelle version Actuel

Légende

Références

Côté serveur https

Apache en frontal

Tomcat 'standalone'

Côté client https

Création du certificat

Génération du couple de clés

Exportation du certificat auto-signé

Ajout du certificat dans le magasin global du JDK

Enregistrement du certificat dans un keystore 'privé'

Configuration de Tomcat

Références

Création du keystore pour le serveur CAS

Récupération/installation de Jetty

Génération du certificat serveur au format pkcs12

Génération du magasin de clé

Ajout de la chaine d'autorités de certification

Supprimer les fichiers intermédiaires

Paramétrer tomcat pour https

Prise en compte de l'autorité de CA

Transformation du format du certificat de l'autorité racine

Intégration de l'autorité de certification du CRU dans Java

Intégration de l'autorité de certification du CRU dans la JVM

Intégration de l'autorité de certification du CRU dans un keystore 'privé'

Pages

Documentation
Authentification
Single Sign On CAS
Utilisation de certificats X509 pour CAS

Historique de la page