Projet

Général

Profil

Tâche #12023

Scénario #12015: Assistance aux utilisateurs (26-28)

Problème de changements de certificats entre un seshat et un scribe.

Ajouté par Nicolas Penot il y a presque 9 ans. Mis à jour il y a presque 9 ans.

Statut:
Fermé
Priorité:
Normal
Début:
18/06/2015
Echéance:
% réalisé:

50%

Temps estimé:
6.00 h
Temps passé:
Restant à faire (heures):
0.0

Description

Bonjour,

Nous avons 2 serveurs EOLE. Un seshat 2.3 servant de guichet unique d'authentification (seshat.ac-caen.fr) et un scribe 2.3 avec POSH / ENVOLE (intranet.ac-caen.fr) utilisant le seshat distant (seshat.ac-caen.fr).
Nous changeons nos certificats de l'IGC à TERENA.
Nous avons changé avec succès les certificats pour le eole-sso et l'EAD sur le serveur seshat.

Par contre, lorsque nous changeons les certificats IGC pour TERENA sur le scribe ayant POSH / ENVOLE, après authentification sur le seshat, nous avons bien le certificat TERENA sur le 443 mais le scribe nous renvoie un "Authentification CAS failed" au retour.

Le serveur seshat est à jour en 2.3. (Maj-auto)
Nous avons gardé les certificats IGC et ajouté ceux de TERENA dans le ca.crt (celui de TERENA a aussi été mis dans /etc/ssl/local_ca) sur le seshat et le scribe.

Sur le seshat, dans les logs eolesso.info.log, nous avons :

Jun 18 13:00:17 seshat eolesso: [LDAPClient,client] utilisateur authentifié (uid: bdelannoy, cn: Delannoy Benoit). Session créée: TGC-seshat.ac-caen.fr-19da5f9932d78071f263764a30aa14d29819ea4701d35d34d4fea562
Jun 18 13:00:17 seshat eolesso: [LDAPClient,client] TGC-seshat.ac-caen.fr-19da5f9932d78071f263764a30aa14d29819ea4701d35d34d4fea562 -- Session autorisée pour le service https://intranet.ac-caen.fr/intranet-academique/portal/login.php (filtre de données : default)
Jun 18 13:00:17 seshat eolesso: [LDAPClient,client] Redirection vers l'application appelante avec le ticket : https://intranet.ac-caen.fr/intranet-academique/portal/login.php
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,14,172.17.10.106] TGC-seshat.ac-caen.fr-19da5f9932d78071f263764a30aa14d29819ea4701d35d34d4fea562 -- Demande d'un ticket PGT pour devenir proxy CAS auprès du service https://intranet.ac-caen.fr/intranet-academique/portal/login.php
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,14,172.17.10.106] Starting factory <HTTPClientFactory: https://intranet.ac-caen.fr/intranet-academique/portal/login.php>
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,14,172.17.10.106] Starting factory <twisted.protocols.policies.WrappingFactory instance at 0xa0067cc>
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] !! Proxy non validé : https://intranet.ac-caen.fr/intranet-academique/portal/login.php !!
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] 
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011!! --> (20, 'certificate verify failed') !!
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] Stopping factory <HTTPClientFactory: https://intranet.ac-caen.fr/intranet-academique/portal/login.php>
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] Stopping factory <twisted.protocols.policies.WrappingFactory instance at 0xa0067cc>

Et dans le eolesso.alert.log du seshat :

Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] Unhandled Error
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011Traceback (most recent call last):
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011  File "/usr/lib/python2.6/dist-packages/twisted/python/log.py", line 84, in callWithLogger
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011    return callWithContext({"system": lp}, func, *args, **kw)
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011  File "/usr/lib/python2.6/dist-packages/twisted/python/log.py", line 69, in callWithContext
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011    return context.call({ILogContext: newCtx}, func, *args, **kw)
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011  File "/usr/lib/python2.6/dist-packages/twisted/python/context.py", line 59, in callWithContext
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011    return self.currentContext().callWithContext(ctx, func, *args, **kw)
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011  File "/usr/lib/python2.6/dist-packages/twisted/python/context.py", line 37, in callWithContext
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011    return func(*args,**kw)
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011--- <exception caught here> ---
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011  File "/usr/lib/python2.6/dist-packages/twisted/internet/selectreactor.py", line 146, in _doReadOrWrite
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011    why = getattr(selectable, method)()
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011  File "/usr/lib/python2.6/dist-packages/twisted/internet/tcp.py", line 460, in doRead
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011    return self.protocol.dataReceived(data)
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011  File "/usr/lib/pymodules/python2.6/M2Crypto/SSL/TwistedProtocolWrapper.py", line 312, in dataReceived
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011    raise e
Jun 18 13:00:17 seshat eolesso: [TLSProtocolWrapper,client] #011M2Crypto.BIO.BIOError: (20, 'certificate verify failed')

Il semblerait que le seshat n'arrive pas à vérifier le certificat TERENA que lui renvoie le scribe ? Alors que le seshat possède déjà cette autorité de certification dans sa chaîne de certification...
Avez-vous déjà rencontré ce problème ?

Merci d'avance,
Nicolas PENOT, Rectorat de Caen.

Historique

#1 Mis à jour par Fabrice Barconnière il y a presque 9 ans

  • Tracker changé de Anomalie à Tâche
  • Temps estimé mis à 6.00 h
  • Tâche parente mis à #12015
  • Restant à faire (heures) mis à 6.0

#2 Mis à jour par Fabrice Barconnière il y a presque 9 ans

  • Statut changé de Nouveau à En cours
  • Assigné à mis à Fabrice Barconnière
  • % réalisé changé de 0 à 10

Il faut peut-être concaténer les certificats de la chaîne de certification TERENA dans le fichier certificat serveur TERENA.

#3 Mis à jour par Fabrice Barconnière il y a presque 9 ans

  • % réalisé changé de 10 à 50
  • Restant à faire (heures) changé de 6.0 à 3.0

Le problème est-il résolu ?

#4 Mis à jour par Nicolas Penot il y a presque 9 ans

Bonjour,

Non, le problème n'est pas résolu, je n'ai pas encore pu tester votre solution.
Je la teste et je reviens vers vous lundi.

Merci pour votre aide,
Cordialement,
Nicolas PENOT.

#5 Mis à jour par Nicolas Penot il y a presque 9 ans

Bonjour,

Comme promis, je reviens vers vous.
J'ai ajouté la chaîne de certification TERENA dans le fichier certificat serveur TERENA.

Le problème est toujours le même.

Pour infos :

root@seshat:/etc/ssl/certs/IGC# ./voir_all_certif.sh seshat.ac-caen.fr.crt
-----------------------------------------------
            Not After : Sep  9 23:59:59 2018 GMT
        Subject: OU=Domain Control Validated, CN=seshat.ac-caen.fr
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
            X509v3 Subject Alternative Name:
-----------------------------------------------
            Not After : Oct  8 23:59:59 2024 GMT
        Subject: C=NL, ST=Noord-Holland, L=Amsterdam, O=TERENA, CN=TERENA SSL CA 2
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
        Subject Public Key Info:
            X509v3 Subject Key Identifier:

root@seshat:/etc/ssl/certs/IGC# ./voir_all_certif.sh ../eole.crt
-----------------------------------------------
            Not After : Sep  9 23:59:59 2018 GMT
        Subject: OU=Domain Control Validated, CN=seshat.ac-caen.fr
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
            X509v3 Subject Alternative Name:
-----------------------------------------------
            Not After : Oct  8 23:59:59 2024 GMT
        Subject: C=NL, ST=Noord-Holland, L=Amsterdam, O=TERENA, CN=TERENA SSL CA 2
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------

#6 Mis à jour par Fabrice Barconnière il y a presque 9 ans

Le répertoire /etc/ssl/local_ca doit contenir tous les certificats CA des chaînes de certification utilisées sur les 2 serveurs. Ces certificats CA sont concaténés dans /etc/ssl/ca.crt au moment du reconfigure.
C'est peut-être ce qui pose problème.
Donc, mettre tous les certificats de la chaîne CA TERENA dans /etc/ssl/local_ca des 2 serveurs (Seshat et Scribe) et lancer reconfigure.

#7 Mis à jour par Nicolas Penot il y a presque 9 ans

Bonjour,

C'est bien ce que nous avons fait mais cela ne fonctionne pas.

#8 Mis à jour par Fabrice Barconnière il y a presque 9 ans

Nous ne disposons pas de certificats TERENA et ne pouvons pas tester. Je vous propose d'exposer votre problème sur le liste scribe@listeseole.ac-dijon.fr

#9 Mis à jour par Bruno Boiget il y a presque 9 ans

Le problème est-il toujours d'actualité ?

Quelques pistes pour vérifier le comportement (sur Seshat) :

Récupérer le certificat de scribe utilisé pour le portail (en l'exportant depuis firefox par exemple), et le recopier sur seshat (par ex. root/scribe.crt)

Vérifier quel fichier EoleSSO utilise pour valider les certificats:
  • cd /usr/share/sso
  • python -c "import config;print config.CA_LOCATION" (renvoie '/etc/ssl/certs/ca.crt' avec la configuration par défaut)
Vérfier avec openssl que le certificat de scribe peut être validé avec ce fichier. Par exemple:
  • openssl verify -CAfile /etc/ssl/certs/ca.crt /root/scribe.crt (remplacer ca.crt par le fichier détecté dans l'étape précédente si besoin)
Si ce n'est pas le cas, il manque probablement un certificat dans ca.crt. Il faut la chaine complète.
J'ai testé sur le certificat de notre nouveau site (https://pcll.ac-dijon.fr/eole/) en concaténant les certificats suivants :
  • AddTrust_External_CA_Root.pem
  • USERtrust_RSA_Certification_Authority.pem
  • TERENA_SSL_CA_2.pem

Attention, si vous mettez des fichiers dans /etc/ssl/local_ca, il faut lancer reconfigure pour les prendre en compte. Cela ne marche que si eole-sso utilise ca.crt (sinon il faut concaténer manuellement les fichiers).

Si ça ne marcher toujours pas, une dernière idée peut être de concaténer la chaîne complète directement dans le certificat serveur sur scribe.

#10 Mis à jour par Nicolas Penot il y a presque 9 ans

Bonjour,

Oui, le problème est toujours d'actualité :(

J'ai lancé les différentes commandes sur le seshat après avoir récupérer le .crt du certificat que l'on essai de mettre sur le portail.

root@seshat:/usr/share/sso# python -c "import config;print config.CA_LOCATION" 
/etc/ssl/certs/ca.crt
root@seshat:/usr/share/sso# openssl verify -CAfile /etc/ssl/certs/ca.crt /root/intranet.ac-caen.fr.crt
/root/intranet.ac-caen.fr.crt: OK
root@seshat:/usr/share/sso#

Le certificat a l'air correct, je ne comprends pas pourquoi le eole-sso me met en message d'erreur qu'il n'arrive pas à vérifier le certif...
Et dans notre ca.crt, nous avons tous nos certificats.
Est-ce que le fait d'avoir toujours les certificats de l'IGC dans le ca.crt ne pourrait avoir quelques chose à voir avec le problème ?

Contenu du ca.crt :

root@seshat:/etc/ssl/certs/IGC# ./voir_all_certif.sh ../ca.crt
-----------------------------------------------
            Not After : May 29 13:41:02 2016 GMT
        Subject: C=fr, O=Ministere Education Nationale (MENESR), OU=110 043 015, OU=ac-caen, OU=0140096D, CN=CA-seshat
        Subject Public Key Info:
-----------------------------------------------
            Not After : Dec 22 10:00:00 2015 GMT
        Subject: C=FR, O=Ministere education nationale (MENESR), OU=110 043 015, CN=AC Infrastructures
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : Dec 22 11:00:00 2015 GMT
        Subject: emailAddress=igc@orion.education.fr, C=FR, O=Ministere Education Nationale (MENESR), OU=110 043 015, CN=AC Enseignement Scolaire
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : Dec 22 14:00:00 2015 GMT
        Subject: emailAddress=igc@orion.education.fr, C=FR, O=Ministere Education Nationale (MENESR), OU=110 043 015, CN=AC Education Nationale
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : Oct 17 14:29:22 2020 GMT
        Subject: C=FR, ST=France, L=Paris, O=PM/SGDN, OU=DCSSI, CN=IGC/A/emailAddress=igca@sgdn.pm.gouv.fr
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : May 29 13:42:40 2016 GMT
        Subject: C=fr, O=Ministere Education Nationale (MENESR), OU=110 043 015, OU=ac-caen, OU=0140096D, CN=CA-envole-dev
        Subject Public Key Info:
-----------------------------------------------
            Not After : Dec 22 10:00:00 2015 GMT
        Subject: C=FR, O=Ministere education nationale (MENESR), OU=110 043 015, CN=AC Infrastructures
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : Dec 22 11:00:00 2015 GMT
        Subject: emailAddress=igc@orion.education.fr, C=FR, O=Ministere Education Nationale (MENESR), OU=110 043 015, CN=AC Enseignement Scolaire
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : Oct  8 23:59:59 2024 GMT
        Subject: C=NL, ST=Noord-Holland, L=Amsterdam, O=TERENA, CN=TERENA SSL CA 2
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
            Not After : May 30 10:48:38 2020 GMT
        Subject: C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
        Subject Public Key Info:
            X509v3 Subject Key Identifier:
-----------------------------------------------
root@seshat:/etc/ssl/certs/IGC#

Merci pour vos réponses qui nous permettent d'avancer un peu plus sur le problème.

#11 Mis à jour par Bruno Boiget il y a presque 9 ans

Je ne pense pas que la présence des certificats IGC pose problème.

Par contre, je vois que vous n'avez pas inclus le certificat racine (AddTrust External CA Root). EoleSSO ne reconnait que les autorités inclues dans le fichier (pas celles installées au niveau système).

La CA en question a pour sujet :

Subject: C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root

#12 Mis à jour par Nicolas Penot il y a presque 9 ans

Je confirme que la présence des certificats IGC ne posent pas de problème car j'ai réussi à faire fonctionner mon portail avec le certificat TERENA !

Effectivement, la cause du problème était de ne pas avoir le certificat racine (AddTrust External Root) dans mon ca.crt.
Nous avons ajouté ce certificat dans le ca.crt du seshat, puis remplacer le certificat IGC par le certificat TERENA sur notre portail intranet et nous n'avons pas eut d'erreur, le certificat TERENA a bien été pris en compte sur notre portail.

Il ne me reste donc plus qu'à ajouter ce certificat (AddTrust External Root) dans la chaîne TERENA qui est dans /etc/ssl/local_ca et de faire un reconfigure afin de valider que cela fonctionne en cas de reconfigure.

Je vous remercie grandement pour votre aide,
Cordialement,

Nicolas PENOT, rectorat de Caen.

#13 Mis à jour par Joël Cuissinat il y a presque 9 ans

  • Statut changé de En cours à Fermé
  • Restant à faire (heures) changé de 3.0 à 0.0

Formats disponibles : Atom PDF