Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archives de la catégorie ‘Certificat-2010’

Lync & Certificats Publics.. : Pas si publics que ça … suite et fin ;-)

Publié par Teruin laurent le mars 14, 2012


Bon alors comme je voulais avoir le fin mot de l’histoire et surtout savoir si l’on devait déployer ces fameuses autorités de certification intermédiaire, je me suis mis en tête d’appeler Verisign. Bon après un demie heure de .. appuyer sur 1 appuyer sur 2 etc.. Pour finalement tomber sur un répondeur m’invitant à taper une extension de poste…., j’ai switcher sur le support Globalsign ou j’ai pu avoir le fin mot de l’histoire.

Remerciements au passage aux interlocuteurs de Globalsign pour leur disponibilité et la qualité de leurs échanges ainsi que du temps passé. C’est assez rare parfois, alors autant le souligner. ;-)

D’après le support, les autorités de certifications intermédiaires auraient été positionnées pour éviter de trop exposer les autorités racines. Utilisée sur un serveur Web elles n’impliqueraient pas la nécessité de déployer la chaine de certificat de l’autorité intermédiaire sur le poste de travail car rappelons le, l’utilisateur ne sera pas prompté si et seulement si les 4 conditions ci-dessous sont remplies:

  • Le certificat n’est pas révoqué
  • Le certificat contient le nom qui correspond à l’URL tapée par l’utilisateur
  • Le certificat est émis d’une autorité de certification approuvé par le poste de travail
  • Le certificat n’est pas expiré

Or les autorités de certifications intermédiaires permettraient (à conditions qu’elles soient néanmoins déployées sur le serveur Web) de ce passer de les déclarer sur les postes qui visiteraient le site. Entre nous….ce qui parait plausible.

Alors …j’ai testé en prenant un poste Windows 7 tout neuf et en allant sur un site Web (https://meet.mycompany.com) doté d’un beau certificat Wildcard Globalsign et ça marche !!! Pas de prompt !

Le poste est tout neuf, n’est pas dans le domaine et n’a rien à voir avec l’entreprise.

Alors installons le client Lync et testons l’accès au Edge doté cette fois ci d’un certificat SAN Globalsign.

Et …

Ca marche !


Passons maintenant à la dernière version du client Lync CU3

Résultat ;-))


Note : notre serveur Edge possède bien dans son magasin l’autorité de certification intermédiaire. C’est également le cas pour ce qui est des serveurs Edge de fédération qui de facto fonctionne

Donc .. le consultant GlobaSign ..avait raison ;-) . Voila de quoi me réconcilier avec ces chères institutions ;-)

Un grand merci encore une fois aux équipes de GlobalSign

Bonne soirée

Laurent Teruin

 


 

Publié dans Certificat-2010, Lync 2010, Lync Client | Leave a Comment »

Lync & Certificats Publics.. : Pas si publics que ça … mise à jour

Publié par Teruin laurent le mars 14, 2012


Bonjour

Plusieurs problèmes récents liés aux certificats et à Lync 2010 m’amène à poster cet article

Pour que les services Lync Edge / reverse proxy fonctionnent correctement, il faut que le mobile ou le pc approuve l’autorité de certification de confiance qui a émis ce certificat. L’autorité de certification la plus communément reconnue et par conséquent installée dans le magasin de certificat des ordinateurs semble être Verisign et Thawte.

Cependant, cela n’empêche pas les autres de fonctionner convenablement à condition que les autorités de certification qui ont délivrées le certificat, à savoir l’Autorité racine de confiance ou l’autorité intermédiaire soient présentes dans le magasin du périphérique qui accède à Lync. Périphérique qui peut être un téléphone mobile (Windows Phone, Iphone etc..) , un Serveur Lync Edge (Fédération), un Pc de l’entreprise dans le domaine, un pc externe inconnu.

Bien sûr me direz-vous que si vous achetez des certificats publics (au prix où parfois ils sont vendus ….), c’est pour justement ne pas avoir à mettre en place des certificats d’autorités de confiance dans les PC. J’en conviens mais……. Mais parfois ce n’est pas le cas.

Pour tester j’ai installé une machine Windows 7 «  from scratch » que je l’ai mis à jour.

Voici ce qu’elle possédé dans son magasin de certifications


 


On n’y trouve Thawte Verisign (qui semble être la même société par ailleurs) mais pas de trace de Comodo ni de Globalsign par exemple. Ce qui veut dire que pour ces autorités, il faudra déployer des certificats d’autorités de confiance Racines et voir intermédiaires sur les postes de travail de l’entreprise. En Gpo ça se fait très rapidement. Par contre sur les Smartphones, c’est selon le système d’exploitation parfois un peu plus compliqué, surtout si vous en avez beaucoup ;-))

Cependant reste le problème de l’accès WEB APP de Lync qui est censé être utilisé par des clients externes en https, et qui n’étant pas dans le domaine, n’auront pas forcement les bonnes autorités de certifications dans leurs magasins. Pour eux, lorsqu’ils tenteront d’accéder à une réunion par web app un warning de certificat s’affichera avec la possibilité de continuer néanmoins. C’est moyen je vous l’accorde mais ….pas le choix.

Si vous mettez en place une fédération alors il faudra également penser à ce que les deux serveurs Edge possèdent de part et d’autre les bonnes autorités de certification de confiance (racines et intermédiaires) et dans les bons conteneurs !.

D’autre part, il n’est pas exclu, même si vous choisissez une autorité connue par défaut dans Windows 7 que cela suffise. Pourquoi ? Parce que les autorités de certifications publiques peuvent si elle le souhaite, utiliser des nouvelles autorités de certifications intermédiaires pour délivrer des certificats publics. De facto, cette nouvelle autorité de certification publique de confiance et intermédiaire ne sera donc pas présente dans vos magasins. Et par conséquent cela ne fonctionnera pas. Un exemple ? un certificat récemment acheter auprès de Vérisign . Vous remarquerez le nom de l’autorité de certification intermédiaire


Concernant la fédération avec Windows Live et autre IM, peu de problème sont remontés pour le moment.

Certificat pour les Phone Edition

Pour les téléphones voici les autorités racines approuvés par défaut sur Lync Phone Edition

Fournisseur  

Nom du certificat  

Date d’expiration  

Longueur de la clé  

Comodo 

AAA Certificate Services 

12/31/2020 

2048 

Comodo

AddTrust External CA Root 

5/30/2020 

2048 

Cybetrust 

Baltimore CyberTrust Root 

5/12/2025 

2048 

Cybetrust 

GlobalSign Root CA 

1/28/2014 

2048 

Cybetrust 

GTE CyberTrust Global Root 

8/13/2018 

1024 

VeriSign 

Class 2 Public Primary Certification Authority 

8/1/2028

1024 

VeriSign 

Thawte Premium Server CA 

12/31/2020 

1024 

VeriSign 

Thawte Server CA 

12/31/2020 

1024 

VeriSign 

Comodo 

1/7/2010 

1000 

VeriSign 

Class 3 Public Primary Certification Authority 

8/1/2028 

1024 

Entrust 

Entrust.net Certification Authority (2048)

12/24/2019 

2048 

Entrust 

Entrust.net Secure Server Certification Authority 

5/25/2019 

1024 

Equifax 

Equifax Secure Certification Authority 

8/22/2018 

1024 

GeoTrust 

GeoTrust Global CA 

5/20/2022 

2048 

Go Daddy 

Go Daddy Class 2 Certification Authority 

6/29/2034

2048 

Go Daddy 

http://www.valicert.com/ 

6/25/2019 

1024 

Go Daddy 

Starfield Class 2 Certification Authority 

6/29/2034 

2048 

 

Donc avant de signer chez un fournisseur d’autorité de certification publique comme on dit dans le sud … Méfi !

Vérifier également sur le site de Microsoft que cette autorité de certifications publiques est bien certifiée UC par l’éditeur voir ci-dessous ou. lien suivant : http://support.microsoft.com/kb/929395


Au prix où ils le vendent leurs services ne serait-t-il pas de bon ton de les publier au moins via Windows Update non ? Sinon à quoi bon passer par une autorité de certification publique. J’ai dit une bêtise la ?

Laurent Teruin

 

 

Publié dans Certificat-2010, Lync 2010 | 3 Comments »

Certificats Publics et Communications unifiées

Publié par David PEKMEZ le septembre 6, 2011


Je viens de rencontrer un problème, et je ne suis pas le seul puisque mes chers collègues m’ont donné la solution ce soir après avoir été confrontés à la même situation,

Suite à l’achat d’un certificat public, il se peut que le certificat intermédiaire de la PKI ne soit pas installé sur les postes, et dans ce cas, vous verrez l’erreur suivante parce que le certificat ne pourra pas être vérifié :

Informations supplémentaires

https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO15171&actp=search&viewlocale=en_US&searchid=1282614432001

Merci à mes chers collègues !

Edit : 8 Sept 2011 

Il suffit d’ajouter, sur le serveur publié, le certificat intermédiaire dans le Store Certificats, ce qui permettra d’avoir la chaîne complète présentée au client lors de la connexion, puisque les clients disposent du certificat ROOT, et que la chaîne complète sera présentée, vous ne verrez plus ces erreurs et tout fonctionnera correctement !

David Pekmez

Publié dans Certificat-2010, Lync 2010 | Leave a Comment »

Exchange 2007/2010 : Certificat étoile une alternative intéressante ?

Publié par Teruin laurent le septembre 28, 2010


L’avènement de Microsoft exchange 2010 est les opérations de migration relance le débats sur l’utilisation des certificats de type étoile. En effet, pour migrer les services d’accès client vous devrez modifier les certificats clients existants pour ajouter un nom de type Legacy.fqdnpublic-des-services-cas. La mise en place de certificats de type *.fdqn est intéressant a ce point de vue car elle permet de garder le même certificat et éviter de couper le lien SSL de production.

D’autre part elle permet de faire porter aux services Cas plein de noms différents comme les noms des serveurs active directory, les autodiscover, webmail etc.. De ce point de vue-là, les certificats de type «  étoile » ont le vent en poupe. Un autre avantage est le prix car dans le cas de certificat SAN, la facturation de certaines sociétés se fera sur le prix du certificat et le nombre d’entrées alternatives. Ce qui risque de faire monter l’addition….
Un autre avantage reste la facilitée de gestion et le fait qu’il n’est pas nécessaire de les changer à chaque ajout de nom supplémentaire. Alors il faut bien quelques inconvénients non ?

Coté inconvénients nous allons trouver leurs incapacité à gérer plusieurs noms de domaine et pour cause. Les certificats étoiles que vous devrez acquérir seront de la sorte *.unifiedit.com. Si votre nom de domaine interne est identique à celui de l’externe pas de souci tout cela fonctionnera. On parle dans ce cas-là, de « SplitDNS ». Ce qui en soit est une configuration conseillée officiellement par Microsoft (voir techdays 2010). Il est vrai que cela est plus simple à tout point de vue. Dans le cas contraire, le certificat étoile (Wildcard) ne pourra rien pour vous. Si vos ressources externes sont joignables par *.unifiedit.com et que en interne, elles le sont par *.unifiedit.local point de salut. Les certificats San sont obligatoires.

Sachez que l’utilisation des certificats Wildcard va demander une modification du paramétrage Outlook pour que le fonctionnement du RPCoverHtpp (Outlook Anywhere reste possible). L’article suivant explique comment paramétrer les services Exchange lors de l’utilisation des certificats étoiles :

http://technet.microsoft.com/en-us/library/cc535023(EXCHG.80).aspx

Un autre inconvénient réside dans la non supportabilité vis-à-vis de Windows Mobile 5 (Cf article technet : http://technet.microsoft.com/en-us/library/cc182301.aspx).


Quand à Windows Mobile 6 cette version le supporte à la condition que le certificat étoile ne soit pas délivré par une PKI Microsoft.


Sachez enfin que l’utilisation des Certificats Wildcard ne fait pas partie des « Best Practice » Microsoft.

Important : A noter également que les certificats SAN via Outlook en accès POP et Imap inférieur à la version 2010 ne sont pas supportés sauf si vos Outlook 2007 possèdent le service pack2 ou supérieur.

Coté OCS ou plutôt Lync je vais aller me renseigner je reviens vers vous rapidement

Cordialement
Laurent Teruin

Publié dans Cas-2010, Certificat-2007, Certificat-2010, Windows Mobile | Leave a Comment »

Exchange 2010 et la gestion des certificats

Publié par David PEKMEZ le décembre 3, 2009


La gestion des certificats en Exchange 2007 fonctionnait essentiellement via des cmdlet powershell

CF cet article qui présente pour exchange 2007 la création des certificats et la publication des services de messagerie via ISA Server 2006

Dans Exchange 2010 l’interface Graphique a été dotée d’assistants permettant de simplifier cette démarche de création de certificat et d’affectation de ce même certificat aux services Exchange.

Pour rappel, lors de l’installation d’Exchange 2007 et d’Exchange 2010, un certificat est automatiquement créé, c’est un certificat auto signé qui est utilisé par Exchange pour les services IIS / SMTP ou autres.

L’opération consiste à créer et installer un certificat provenant d’une autorité de certification valide et de l’affecter à Exchange.

Les autorités de certification valides peuvent être :

- Une autorité de certification publique en achetant un certificat sur internet

- Une autorité de certification privée en installant une PKI interne.

L’une présente l’avantage d’un déploiement simple et rapide mais pouvant être couteuse alors que l’autre (PKI Interne) présente un cout financier moindre mais nécessitant le déploiement d’un certificat sur tous les clients de messagerie (Postes clients / PDA ..)

Ceci peut être facilité par Active Directory via les GPO pour les postes clients par exemple mais présente tout de même une charge de déploiement non négligeable.

Dans cet article je vais vous présenter comment configurer votre PKI Microsoft afin de délivrer des certificats pour vos serveurs Exchange, procéder à la création des certificats et les affecter aux services de messagerie.

Puisque ceci est maintenant possible via l’interface graphique, je vous propose de le faire via la console Exchange 2010.

Dans mon exemple le serveur héberge les rôles CAS, HUB et Mailbox, vous ne pouvez pas affecter de certificats à vos serveurs Mailbox.

Configuration de la PKI Microsoft

 

La première étape consiste à permettre la création de certificats SAN pour Exchange.

Les certificats SAN (Subject Alternative Name) permettent d’affecter plusieurs noms à un certificat unique

Pour de plus amples informations sur les SAN et les PKI Windows je vous propose le site Microsoft http://support.microsoft.com/kb/931351/en-us

Aller sur votre serveur PKI et lancez ces commandes :

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

net stop certsvc

net start certsvc

 

 
 

Création de la demande de certificat

 

Lancez la console Exchange, faite un clic droit sur votre serveur et sélectionnez « New Exchange Certificate »


L’assistant se lance


Entrez le nom du certificat et cliquez sur suivant,


Si vous cochez la case « Enable wildcard Certificate » votre certificat portera le nom *.domaine.com

L’utilisation de ce type de certificat permet de ne pas utiliser les certificats de type SAN avec plusieurs nom.

Attention toutefois, certaines problématiques peuvent apparaitre lors de l’utilisation de ce type de certificats

http://technet.microsoft.com/en-us/library/cc535023.aspx

Typiquement les périphériques mobiles Windows Mobile 5 supportent les certificats SAN mais pas les certificats de type Wildcard,

Les périphériques Windows Mobile 6 supportent les deux types de certificats.

Nous n’activerons pas la création de certificats de ce type pour cet article, nous utiliserons des certificats SAN


Veuillez ici remplir les informations demandées pour les différents services de messagerie

Exemple en déployant « Client Access Server (Outlook Web App) »


Ou encore « Client Access Server (Exchange ActiveSync) » pour configurer l’accès des périphériques mobiles


Ou encore Outlook Anywhere et les Web services


Configurez de la sorte tous les services de messagerie que vous voulez activer puis cliquez sur suivant,


Dans l’écran suivant, sélectionnez votre nom principal et cliquez sur l’option « Set as common name ».


Remplissez les champs et entrez le chemin pour la création du fichier de demande puis cliquez sur suivant


Cliquez ensuite sur « New » pour créer la demande.


La première étape est terminée.

A l’aide de ce fichier nous allons maintenant procéder à la création du certificat.

Création du certificat

 

Allez sur la page web de votre PKI et suivez les étapes ci-dessous

Vous pouvez vous connecter à votre PKI via l’URL http://NomServeur/certsrv


Cliquez sur « Request a certificate »

 
 


Cliquer sur « Advanced Certificate Request »

 
 


Cliquez sur « Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file »

Ensuite ouvrez le fichier créé lors de la génération de la demande de certificat,

Dans notre exemple « C:\Cert.req »


Sélectionnez les lignes de code, copiez-les, 


Collez le code dans la page web et sélectionnez un Template de type « Web Server »

 
 


Sélectionnez « Download Certificate » et enregistrez le certificat en local.

Une fois le certificat en local sur le serveur, il faut maintenant l’importer et l’activer pour les services Exchange.

Importation du certificat et activation pour les services

 

Ouvrez de nouveau la console Exchange, cliquez sur le certificat en sélectionnant tout d’abord votre serveur,


Sélectionnez « Complete Pending Request »


Sélectionnez le certificat venant d’être téléchargé


Cliquez sur Finish pour terminer l’import du certificat

Une fois importé, nous allons l’activer pour certains services de messagerie

Pour cela, sélectionnez de nouveau le certificat mais vous voyez maintenant l’option « Assign Services to Certificate … »



Sélectionnez votre serveur puis cliquez sur « Next »


Choisissez les services Exchange qui utiliseront ce certificat


Cliquez sur « Assign »


Une confirmation de remplacement de certificat vous sera demandé pour le service SMTP, cliquez sur « Yes »


Voici mon nouveau certificat prêt à l’emploi !



Voici les différents noms SAN du certificat, ici d’autres nom ont étés ajoutés pour un serveur Exchange 2007.

Si lorsque vous ouvrez votre certificat vous obtenez l’image ci-dessous, c’est que vous n’avez pas sur votre poste ou serveur le certificat racine de l’autorité de certification installé.


Pour cela vous devez retourner sur le site de votre PKI et télécharger le certificat racine


Une fois téléchargé, ouvrez une MMC et ajoutez le composant « Certificate » mais choisissez bien pour l’ordinateur local c’est important.


Naviguez dans « Trusted Root Certification Authorities » puis « Certificates » et choisissez la tâche d’import

L’assistant se lance et vous guide pas à pas



Sélectionnez le certificat téléchargé précédemment,



Une fois l’import terminé voici le certificat importé


Voilà un des nouveaux assistants découvert, sachez toutefois qu’il est toujours possible de faire tout çà via powershell 

Qui peut être plus pratique si vous êtes consultant et que vous voulez gagner du temps ;)

Publié dans Certificat-2010 | 4 Comments »

Comment configurer une Autorité de certification pour accepter un attribut SAN d’une demande de certificat

Publié par David PEKMEZ le août 17, 2008


Par défaut une autorité de certification configurée sur un ordinateur Windows Server 2003 ou 2008 n’émet pas de certificats qui contiennent l’extension SAN. Si les entrées SAN sont incluses dans la demande de certificat, ces entrées sont omises

À partir du certificat émis. Pour vous modifier ce comportement, exécuter les commandes suivantes à une invite de commandes

Sur le serveur qui exécute le service Autorité de certification. Appuyez sur ENTRÉE après chaque ligne.

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

net stop certsvc

net start certsvc

Dans la demande de certificat, dans ATTRIBUTE entrez les différents noms de certificat sous cette forme

san:dns=dns.name[&dns=dns.name]

Exemple:

san:dns=intra.net&dns=mail.intra.net

ou par la cmdlets Exchange New-ExchangeCertificate avec le paramètre -DomainName

Publié dans Certificat-2007, Certificat-2010, Publication-2007, Publication-2010, Sécurité-2007, Sécurité-2010 | Tagué: , , | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 223 followers