Teams / Skype & Office 365

Partage et Collaboration par David HAEGEL

Étiquette : certificats

L’importance des certificats – Erreur 0x80071BBC

Bonjour,

Petit retour d’expérience sur une erreur que j’ai pu avoir dans une nouvelle installation où les certificats provenaient d’une Autorité de Certification Linux. Ces certificats provoquaient plusieurs erreurs dont des exceptions dans l’observateur d’évènements (Exception from HRESULT: 0x80071BBC) qui empêchaient le service principal de démarrer.
Ce service restait en mode « starting » même après plusieurs heures et rien n’y faisait pour qu’il finisse son démarrage correctement.

L’environnement est très standard et la seule variante restait l’autorité de certification par rapport à d’autres installations, de plus j’avais déjà eu quelques complications chez d’autres clients avec des autorités un peu exotiques ou configurées d’une manière spécifique malgré des prérequis que nous avions indiqués.

Lire la suite

Share

MAJ article PKI et accès en HTTP à la CRL

Je viens de mettre à jour l’article suivant https://www.davidhaegel.fr/2014/01/15/certificats-autoriser-lacces-en-http-la-crl-crt/.
Cette MAJ est liée au fait que j’ai découvert qu’il n’était pas nécessaire de publier un nouveau site WEB pour mettre à disposition les fichiers de révocation.

En fait, lors de l’installation d’une PKI sous Windows, celle-ci crée automatiquement un service WEB contenant deux éléments :
CertSrv qui permet d’accéder à la PKI et télécharger le fichier racine ou faire des demandes de certificats
14_PKI_CertSRV
CertEnroll qui met à disposition en HTTP les fichiers CRL nécessaires
14_PKI_CRL_WebSVC

Ainsi vous n’avez pas à créer de site WEB dédié pour remettre à disposition ces éléments, cependant l’action d’ajouter/générer les liens en HTTP dans tous vos nouveaux certificats est toujours valable et nécessite une configuration.
Pour cela, reportez-vous à l’article MAJ : https://www.davidhaegel.fr/2014/01/15/certificats-autoriser-lacces-en-http-la-crl-crt/.

Share

Exchange UM – Les notifications MWI ne remontent pas jusqu’aux postes

Il est possible que vous rencontrez le message suivant « Le serveur de messagerie unifiée n’a pas pu remettre la notification de l’indicateur de message en attente … (MWI) » lors d’une intégration avec Lync.
Source : MSExchange Unified Messaging
Événement : 1344

14_ExchUM_MWI_erreur

Ce message peut correspondre à plusieurs facteurs (activation ou non des messages MWI pour une Gateway, configuration de la Gateway IP, erreurs SIP, etc.) cependant il y a aussi un point à prendre en compte et dans le cas présent il s’agissait des certificats.

Lire la suite

Share

Certificats – Créer une demande personnalisée pour le reverse proxy incluant des SAN

Dans un environnement Lync publié via le couple Reverse Proxy/Edge, il est nécessaire de mettre en place des certificats pour les interfaces publiques.

Lync vous offre une interface et un assistant vous permettant aisément de créer vos requêtes (csr). Or en fonction du reverse proxy que vous mettez en place, celui-ci peut ne pas offrir d’assistant ou alors un assistant ne permettant pas l’intégration de champs SAN (champs DNS alternatifs nécessaires à l’environnement Lync, exemple lyncdiscover, meet, etc.).

Voici donc une méthode vous permettant de générer une demande de certificat incluant tous les champs dont vous avez besoin pour votre reverse proxy (SAN, O, CN, C, etc.).

Lire la suite

Share

Certificats – Autoriser l’accès en HTTP à la CRL / CRT de votre PKI

[MAJ 23/10/2014] Simplification de la procédure suite au fait que le rôle PKI de Windows génère par défaut un webservice pour la mise à disposition des informations (mais cependant n’est pas appliqué par défaut).

Les certificats sont des éléments sensibles qui permettent de sécuriser l’ensemble de l’infrastructure mais peuvent aussi provoquer quelques désagréments aux administrateurs si ceux-ci n’ont pas été correctement implémentés.

En dehors des échanges et tests effectués directement entre la ressource présentant son certificat et le système y accédant, ce même système accédant va en parallèle valider avec l’autorité de certification plusieurs éléments (L’autorité de certification étant le système tiers fournissant le certificat à la ressource publiée).

Les éléments validés avec l’autorité de certification sont entre autres la fameuse liste de révocation (CDP / CRL) et les méthodes d’accès à l’autorité (AIA). Ainsi par exemple le système accédant va rechercher le fichier crl (liste de révocation) afin de vérifier que le certificat présenté n’est pas présent dans cette liste et qu’il n’a pas été compromis ou révoqué.

Pour trouver le chemin de la CRL ou l’accès à l’autorité, le système lit tout simplement le certificat présenté par la ressource car c’est lui qui indique où se trouve ces informations.

La problématique :

En fonction de l’application, ces contrôles sont plus ou moins fort cependant par exemple par défaut IE va générer une erreur s’il n’arrive pas à récupérer le fichier crl ou si le nom ne correspond pas.

Or, une PKI Interne de type Windows Server Enterprise ne diffuse ces éléments (extensions CDP & AIA) que via un chemin LDAP par défaut et ainsi cela provoque une inaccessibilité aux informations pour tous les PC hors du domaine accédant aux ressources depuis votre réseau (en fonction de l’application).

Prenons un exemple concret, un PC hors du domaine accédant depuis l’interne à une conférence Lync présentant un document PPT via Office Web Apps. Vous avez beau mettre le certificat racine de votre PKI interne sur votre PC, une erreur de validation du certificat va apparaitre. Alors oui vous pouvez désactiver les contrôles dans IE dans ce cas, cependant cela rend votre navigateur moins sécurisé.

Voici ce qui peut arriver : Un problème s’est produit lors de la vérification du certificat sur le serveur.

14_PKI_Erreur_WAC

Lire la suite

Share

Fièrement propulsé par WordPress & Thème par Anders Norén