Bonjour à tous,
Premier message sur ce forum, pour premier problème. Je me résout à l’exposer ici, après quelques jours de recherches et démarches personnelles …
Je suis dans ma boite depuis quelques mois, et je m’attaque maintenant à un problème : le web access du Citrix. Apparemment, à une époque tout fonctionnait parfaitement, et suite à une mise à jour (vraisemblablement plus restrictive sur les certificats) cela ne fonctionne plus.
La situation :
Un serveur Citrix MetaFrame 4.0, sous Windows 2003 SP2.
Un autre serveur DMZ sur lequel est installé le Web Access.
La connexion sur le site du web access ne pose pas de problème, l’authentification non plus, la liste d’applications publiées et visible, et lorsque l’on lance une connexion, le client ICA essaye et refuse de s’y connecter en affichant l’erreur “SSL Error 61 : You have not chosen to trust the issuer of the server’s security certificate”.
Je comprend bien l’idée : le certificat ne provient pas d’une “autorité de confiance”.
Le problème c’est que ce n’est pas possible de voir de quel certificat il parle, pas moyen de le voir, aucune option.
Ce que je n’arrive pas à comprendre, c’est à quel niveau s’applique ce certificat, où est-il paramétré.
Il est là pour certifier mon serveur Citrix MetaFrame, rien à voir avec le site web access de la DMZ ?
Ce certificat est déclaré au sein du MetaFrame (citrix), ou pour le serveur lui même (windows) ?
J’ai trouvé un certificat sur le serveur, je l’ai installé sur mon client, ce n’est pas celui ci.
Je vous remercie d’avance pour les réponses que vous pourriez m’apporter,
Damien
tu as trouvé toi-même la cause de ton souci… l’utilisation d’une autorité de certification privée nécessite l’installation sur l’ensemble des postes clients du certificat racine de celle-ci.
pour la configuration de la Web Interface (et non “Web Access”), vu que c’est un accès externe, j’espère fortement (et contrairement à d’autres sur le forum… et dans la vraie vie) que tu dispose au moins d’une Secure Gateway ou Access Gateway (vu l’age de la bête je penche pour Secure Gateway).
Le certificat se trouve donc… sur la Secure Gateway. Ce que je ne m’explique pas, c’est pourquoi cela fonctionne avec la WI et pas avec la SG… tu devrais avoir une alerte d’IE quand tu lance une session https vers la WI…
en clair, dans un environnement normal, le certificat est celui de la Secure Gateway et aucun autre que le client ICA a besoin de “truster”. L’adresse (externe) est indiquée dans le fichier ICA généré et le nom du serveur SG est détaillé dans le fichier webinterface.conf sur la Web Interface.
Je vise juste ?
En tout cas je te remercie pour tes infos précieuses. Citrix est aussi complexe qu'efficace, au début en tout cas.
J'ai bien envie de tout virer pour refaire entièrement une installation un peu plus catholiquement correcte. Mais il faut encore que je pige un peu à quoi m'attendre, pour une réinstallation complète (Web Interface + Secure Gateway).
Je retourne fouiner, si tu as encore quelques lumières pour moi, je suis preneur !
tu ne peux pas avoir d’erreur SSL si tu ne passes pas par SG (ou alors c’est que tu utilises SSLRelay pour XenApp… ???)
il est primordial de donner une copie du fichier ICA ainsi qu’une copie du webinterface.conf
OK pour le SG … Je ne le “visualise” donc pas !
Voilà pour le webinterface.conf et le fichier .ica :
ta WI est sur le serveur XenApp…
et tu as bien un serveur SG de configuré (ligne CSG_Server) donc c’est sur ce serveur qu’il faut vérifier quel type de certificat et quelle autorité de certification a été utilisée.
l’adresse CSG_sever est bien utilisée dans le fichier ICA et la communication avec le STA est bonne (encore heureux… tout est sur une seule machine…)
En fait -ce que je constate-, c’est qu’il y a bien une WI sur la DMZ, celle sur laquelle je me connecte (avec l’IP explicite du serveur, je ne peux pas me gourer)
Il y en a également une sur le metaframe. Opérationnelle, utile, … Aucune idée. Il est d’ailleurs arrêté (c’est moi qui l’ai arrêté)
Je regarde ce que tu me dis, merci.
Edit :
Mouai bon, pas grand chose ne s’éclaircit tellement. Ce n’est surement pas un simple problème d’installation de certificat, puisque directement depuis le serveur metaframe il ne se fait pas confiance lui même.
Je patauge …
la config que t’a envoyé concerne un WI en localhost donc installée sur le serveur XA.
le serveur CSG de cette WI est celui qui est envoyé au client ICA et donc son certificat doit etre reconnu par ce client.
Ce qui te fais dire qu’il est en local est cette ligne ?
Farm1=localhost,192.168.3.13,Name:Farm1,XMLPort:8081,Transport:HTTP,SSLRelayPort:443,BypassDuration:60,LoadBalance:On,ECSUrl:http://localhost:9000/Citrix/COrganizerWS/COrganizerWS.soap,TicketTimeToLive:200,RADETicketTimeToLive:200
Effectivement il y avait localhost en premier position, par contre .13 et bien le serveur d’applications. J’ai modifié, maintenant ça donne ça :
Farm1=192.168.3.13,Name:Farm1,XMLPort:8081,Transport:HTTP,SSLRelayPort:443,BypassDuration:60,LoadBalance:On,ECSUrl:http://localhost:9000/Citrix/COrganizerWS/COrganizerWS.soap,TicketTimeToLive:200,RADETicketTimeToLive:200
Bon après, les certificats, j’ai toujours du mal à saisir. Il y a en fait une autorité de certification installée. Le certificat vient forcément d’elle. Le client est sensé faire confiance aux certificats de cette autorité (j’ai le certificat de l’autorité bien installé).
D’après toi, le client quand il ouvre une session ica, il reçoit le certificat du serveur CSG, donc mon serveur dmz, WI … Pas celui du serveur d’applications ?
Ce certificat, si je veux le modifier sur le serveur, ça se passe où, comment ?
Je te remercie encore …
effectivement le client ICA fait une connexion vers le serveur CSG et aucun autre. le CSG agit comme un proxy pour la connexion ICA via SSL.
donc le certificat racine de l’autorité de certification utilisée pour générer le certificat pour la CSG DOIT être présent sur l’ensemble des postes clients qui devront accéder au travers de la CSG.
avec un double clic sur le .cer/.crt du root certificate, je n’ai jamais réussi à ce qu’il soit correctement placé dans le bon certificate store: il était toujours envoyé dans le Trusted Root Certification Authorities de l’utilisateur ET non de la machine, ce qui provoque l’erreur 61.
Egalement, le client ICA s’appuie sur le store Windows (tout comme IE) alors que Firefox a son propre store. Donc pour quelqu’un qui utilise FF, il faut le certificat importé dans FF pour les sites web MAIS il faut absolument l’importer dans Windows pour CSG/ICA.
Certaines choses se précisent …
En fait, la Secure Gateway n’était pas installé. Elle a dû être désinstallé pour essayer de supprimer cette erreur ssl … Je l’ai réinstallé (version 3.0, sur le même serveur que la WI donc). La configuration semble bonne (voir rapport du diagnostic en PJ)
Résultat : aucun changement.
Pourtant, ce certificat je l’ai fait avec l’autorité installée (je viens de le faire, au moins pour les tests) sur le même serveur. Je lui ai délivré le certificat qui va bien, installé localement chez le client dans les “autorités de certification racines de confiance” (il y a d’ailleurs 2 magasins du même nom, quelle différence ? Comment différencier ?!). Quand je visualise ce certificat, il me dit bien que j’ai “confiance en lui”.
Ce même certificat je l’ai mis aussi sur l’interface web, pour y accéder en https (et récupéré et installé chez le client comme ça). Avec ou sans, rien ne bouge …
Des modifications à faire dans les paramètres de la Web Interface ? J’ai essayé de voir du côté des “réglages de passerelle”, mais ils semblent ok car à la moindre modification une autre erreur se produit avant la vérification du certificat.
-> La Secure Gateway est bien sur le même serveur, FQDN OK via le port 443.
-> Le STA qui sur le serveur metaframe (et bien présent) est à la bonne adresse.
Par contre, si je met ma WI en https sur le port 443, il n’est plus libre pour le SG.
Ce que je trouve bizare, c’est que SG installée ou non, configurée ou non, le résultat est le même. Ca te semble normal ça ?
Têtue la bestiole …
Salut,
Je n’ai pas eut le temps de tout lire mais voici en vrac :
http://www.archy.net/2010/03/03/citrix-online-plug-in-ssl-error-61-you-have-not-chosen-to-trust/
http://support.citrix.com/article/CTX711855
J’avais eut un problème avec des certificats, une errue 61 aussi d’ou mon blog à ce sujet.
En espérant que ça te donne quelques pistes
Salut Stef,
Merci pour tes liens, mais ça ne m’a toujours pas fait trouver la solution ! Le problème semble différent … Peut-être pas sur le fond.
A force de bidouiller, je me pose toujours cette question : Comment savoir si le SG est actif … Car il me semble complètement inopérant. Installé ou non, service lancé ou non, les résultats sont les mêmes.
Je me suis résolu à analyser les trames avec wireshark pour essayer de voir quel certificat est envoyé, et de qui il provient. La capture est en pièce jointe.
Déjà, il provient directement de mon serveur Présentation Server. Le client est sensé ne jamais se connecter directement au serveur PS grâce à la SG … C’est déjà pas normal ?! Mauvaise configuration ?!
Ensuite, si j’analyse correctement cette trame (?), je lis que l’autorité qui a fournit ce certificat est “marmillon”. Je n’ai aucune autorité de ce nom, et je ne trouve ce certificat nul part sur le serveur. Il devrait apparaître dans la console de certificats puisqu’il est utilisé, non ?!
Enfin, ce certificat est expiré …
Comment remplacer ce certificat par un certificat valide ? Où, à quel niveau, est-il définit ??
Je ne sais pas si mes démarches et analyses sont tout a fait correctes, n’hésitez pas à me reprendre …
Ca y est, j’ai trouvé.
Si ça peut servir : c’était le certificat du SSL Relay sur le serveur metaframe. Il a fallu re-généré un certificat grâce à l’outil sslautoconfig.exe, présent sur les CD d’installation. La procédure est décrite dans le “Guide d’administration avancée Citrix Presentation Server pour Windows Version 4.0”, et en Français en plus. Il faut évidemment une autorité de certification.
Il a fallu relancer manuellement un service ensuite (oublié le nom, mais le message d’erreur le mentionne)
Tout n’est pas encore parfait (je suis en direct, pas de secure gateway), mais ça avance.
Merci à vous, vous m’avez tout de même bien aidé dans la compréhension du système !