UAG est un produit magique. Problème, c’est quand on veut tout faire avec le même UAG mutualisé et dans le même projet, qu’on commence le sport. Outre la coordination de projet, se pose le problème des certificats publics. Pour DirectAccess, c’est facile, un seul certificat public IP-HTTPS suffit. Coté publication UAG, cela dépend du nombre d’URL à publier.
Dans le cas qui nous occupait, nous avions tellement de ressources à publier en SSL que finalement, nous avons opté pour un certificat Wildcard. Pour la publication de ressources avec UAG, c’est très pratique. Par contre coté DirectAccess, cela restait à valider.
Après quelques recherches, effectivement, c’est supporté depuis UAG 2010 SP1 : Designing your PKI for Forefront UAG DirectAccess. Dans les fait, cela se concrétise de la manière suivante :

Lorsqu’on sélectionne le certificat wildcard, automatiquement la console UAG nous indique qu’il ne peut pas utiliser ce certificat car il n’y a pas de nom d’hôte qui puisse être résolu sur Internet. Ce point est essentiel, car UAG doit créer un listener pour le protocole IPHTTPS. Cette même URL sera nécessaire pour créer l’interface IPHTTPS sur les clients. Pour cette raison, il nous faut compléter l’interface avec un véritable nom pleinement qualifié tel qu’illustré ci-dessous :

Une fois cette correction effectuée, l’activation de la configuration DirectAccess ne pose pas de problème particulier. On constatera que le nom que nous avons renseigné dans l’interface se retrouve maintenant dans la déclaration de l’interface IPHTTPS sur notre serveur UAG.

Un bon truc à savoir.
Benoits – Simple and Secure by Design but Business compliant.