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.

C'est donc le serveur W3 qui doit être paramétré pour supporter le https. C'est dans la configuration du serveur W3 qu'on doit indiquer où trouver la clé privée du serveur, le certificat (qui contient lui-même la clé publique correspondante), et les certificats éventuels des Autorités de Certification faisant partie de la chaine de certification de délivrance du certificat du serveur, dans le cas d'un certificat non auto-signé).

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 :

• SSLCertificateKeyFile précise le nom du fichier qui contient la clé privée
• SSLCertificateFile précise le nom du fichier qui contient le certificat correspondant à 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 (sinon la chaine de certification sera cherchée dans le truststore)

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.