PI Services

Le blog des collaborateurs de PI Services

ADCS / Erreur : Modèles de certificats non visibles

Problème rencontré

Après l'installation d'une autorité de certification d'entreprise, j'ai rencontré une erreur m'empêchant de publier des modèles de certificats dont la version est supérieures à 1. Ce problème fut rencontré sur Windows 2012 R2 mais ne peut être généralisé à toute installation avec ce système d'exploitation. Néanmoins, cet article permet de résoudre cet incident. Voici tout de même le contexte dans lequel s'est produit ce problème. L'autorité de certification était de type Subordinate  Enterprise et avait été installé avec un fichier CAPolicy.inf contenant notamment la ligne "LoadDefaultTemplates=False". Ce dernier évite de publier les modèles par défaut.

Bien qu'il soit possible de créer des nouveaux modèles dans l'annuaire Active Directory, ces derniers n'étaient pas visibles lors de leur publication via la console de gestion d'autorité de certification.

image

De plus, même les modèles générés par défaut comme “Workstation Authentication” (modèle de version 2) ou encore “OCSP Response Signing” (modèle de version 3) n'apparaissent pas dans la liste des modèles publiables.

Contrairement à un mauvais choix de type d'autorité de certification (standalone au lieu d'enterprise), il reste possible de publier des certificats mais seulement ceux dont le numéro de version est égale à 1.

Solution

Cette erreur est due à un problème de configuration du registre. Pour rappel, les paramètres de configuration de l'autorité de configuration sont stockés dans “HKLM\System\CurrentControlSet\Services\Certsvc\Configuration\NOM_CA” où “NOM_CA” représente le nom de l'autorité de certification.

Pour corriger l'erreur, il faut mettre à jour le registre via la ligne de commande ci-dessous (celle-ci doit être exécutée en mode administrateur) :

Enfin, pour que la modification soit prise en compte, il est nécessaire de redémarrer le service d'autorité de certification. Vous pouvez réaliser cette opération graphiquement ou via les commandes suivantes :

NB : Une KB Microsoft (http://support.microsoft.com/kb/967332) décrit un problème similaire lors de la mise à jour d'une autorité de certification 2003 ou 2008 en édition Standard vers une édition Enterprise de Windows 2008. En effet, seule cette dernière permet d'installer une autorité de certification de type Enterprise. Cependant, cette KB n'existe pas sous Windows 2012 et supérieure. Il n'y a d'ailleurs plus de contrainte sur l'édition du système d'exploitation installée (tous les types d'autorités de certification pouvant être installées sur une édition standard comme datacenter depuis Windows Server 2012). Néanmoins, l'erreur décrite dans cet article peut tout de même être rencontrée.

Powershell / Exchange : Erreur 9323 - Certificat expiré sur un objet AD

Introduction

Cet article permet de montrer la gestion des certificats via Powershell au travers d'un problème concret rencontré sur une infrastructure Exchange. Une solution basée sur un script Powershell sera détaillée.

Erreur rencontrée

Contexte : Infrastructure Exchange 2010 avec plusieurs dizaine de milliers de contacts Active Directory importés et mis à jour par un outil tierce.

Dans l’observateur d’événements de nombreux événements 9323 apparaissent.

9323

Ces derniers sont liés à la génération de l'OAB. Exchange détecte un utilisateur dont un certificat est expiré. Ces événements n'apparaissent que sur des objets de type "Contact"  La solution doit contrôler tous les objets Active Directory de ce type.

Solution

La soluton proposée pour purger les certificats invalides des contacts Active Directory se base sur un script Powershell V2. Ce dernier analyse l'attribut UserCertificate (il s'agit d'une liste de certificat).

Avec le type d'objet "System.Security.Cryptography.X509Certificates.X509Certificate2", il est possible d'obtenir des informations sur les certficats contenus dans cet attribut sous forme lisible (et non pas un tableau de bytes ou de valeur hexadécimal comme sur la console Active Directory Users and Computers).

Ci-dessous, un exemple de données récupérées sur les certificats d'un objet Active Directory (ici, il n'y a qu'un seul certificat et la variable $User est un utilisateur Active Directory).

Certificate

On remarque qu'on accède à des renseignements comme l'émetteur ou le sujet. Les informations qui nous interessent (dates de validité du certificat) sont aussi présentes. Il suffit donc de comparer la date d'expiration contenue dans l'attribut "notAfter" avec la date du jour en cours pour détecter les certificats expirés.

Grâce à la cmdlet "Set-ADObject", il sera ensuite possible de supprimer les certificats qui ne sont plus valides.

Script

En amont de ce script, un transcript est lancé afin de loguer toute les opération effectuées. Une vérification de la présence du module ActiveDirectory ainsi que son chargement sont ensuite réalisées.

Le script appelle une fonction créée pour traiter tout objet AD (ou tableau d'objets AD) qui lui est passé. Pour ma part, je transmets en paramètre tous les contacts présents dans Active Directory. Cependant cette fonction peut très bien être utilisée avec des utilisateurs. Voici l'algolrithme mis en place dans la fonction Test-CertExpiration :

  1. Filtrage des objets pour ne conserver que ceux ayant au moins un certificat présent dans l'attribut userCertificate.
  2. Boucle ForEach sur tous les utilisateurs :
    1. Boucle For sur tous les certificats de l'utilisateur (pas de ForEach afin d'être certain de la position du certificat dans l'attribut userCertificate)
    2. Analyse de la date d'expiration
    3. Si le paramètre DeleteExpired est présent alors on supprime le certificat dans Active     Directory s'il n'est plus valide.
    4. Si le paramètre DeleteExpired n'est pas présent alors deux attributs sont ajoutés à l'objet     AD :
      1. CertExpired : contient les index des certificats expirés dans le tableau de l'attribut userCertificate
      2. CertValid : contient les index des certificats valides dans le tableau de l'attribut userCertificate
  3. Si le paramètre Export et ExportPath ont été renseigné alors le tableau d'objet AD est exporté sous format CSV avec la liste des index des certificats valides et expirés.

Ci-dessous, vous trouverez le script intégralement commenté. A noter, que le compte exécutant ce script doit posséder les droit suffisants à la modifications des objets AD concernés (via une délégation par exemple).

Ici, la fonction Test-CertExpiration, est utilisée en mode suppression, cependant il est aussi possible de se servir du mode Export pour n'effectuer qu'un simple audit (logué dans un fichier) des objets concernés via la commande suivante :

$ADObjets est un tableau d'objets Active Directory.

Il est enfin possible de ne donner qu'un tableau d'objets AD à traiter sans spécifier le mode export ou suppression :

Dans ce cas, un tableau d'objets AD est retourné. Pour chaque objet, les attributs CertExpired et CertValid sont ajoutés.

Quelques points clés du fonctionnement de la fonction Test-CertExpiration :

Les paramètres Export et DeleteExpired sont de type switch et ne peuvent apparaître ensemble. Le paramètre ExportPath est dynamique et n'est disponible que si le paramètre Export a été choisi.

Pour information, il n'est pas nécessaire de paralléliser le processus de contrôle du certificat. Après un test effectué sur plus de 90000 contacts Active Directory, il s'avère que ce dernier a duré moins de 5 minutes. Utiliser du multi thread (workflow ou job Powershell) alourdirai le script et ralentirai le processus au lieu de l'accélérer.

OCS 2007 R2 – Echec des connexions TLS sous Windows Server 2008 R2

Symptôme

Suite au déploiement d’une architecture OCS 2007 R2 composée de plusieurs serveurs (typiquement un serveur front-end déployé dans le réseau local associé à un serveur Edge situé en DMZ), les erreurs suivantes peuvent se produire si l’un des serveurs ou les deux exécutent Windows Server 2008 R2 :

Event ID : 14428, Source : OCS Protocol Stack

Event ID : 14428, Source : OCS Protocol Stack

Voici le détail de chacune des deux erreurs :

Log Name: Office Communications Server
Source: OCS Protocol Stack
Date: 23/12/2010 00:53:43
Event ID: 14428
Task Category: (1001)
Level: Error
Keywords:  Classic
User:  N/A
Computer: <FQDN du serveur OCS source>
Description:
TLS outgoing connection failures. Over the past 15 minutes Office Communications Server has experienced TLS outgoing connection failures 122 time(s). The error code of the last failure is 0x80004005 (Unspecified error) while trying to connect to the host “<FQDN du serveur OCS de destination>”.

 

Log Name: Office Communications Server
Source: OCS Protocol Stack
Date: 23/12/2010 00:46:08
Event ID: 14502
Task Category: (1001)
Level: Error
Keywords: Classic
User: N/A
Computer: <FQDN du serveur OCS source>
Description:
A significant number of connection failures have occurred with remote server <FQDN du serveur OCS de destination>”. IP <Adresse IP du serveur OCS de destination>”. There have been 60 failures in the last 7 minutes. There have been a total of 60 failures.  The specific failure types and their counts are identified below.

Instance count   - Failure Type
60                
80004005 

 

Explication

Ces erreurs sont dues à un problème “connus” avec OCS 2007 R2 et Windows Server 2008 R2 autour de la fonction InitializeSecurityContext de la couche TLS.

Ces erreurs empêchent toute communication TLS entre les serveurs et entraînent donc des disfonctionnement au sein d’OCS (le protocole SIPs étant utilisé par défaut).

Résolution

Pour résoudre ces problèmes, il faut installer un correctif sur l’ensemble des serveurs OCS 2007 R2. Ce correctif est disponible sur demande à l’adresse suivante :

Suite à l’installation, les serveurs doivent être redémarrés.

SBG - Déployer un certificat sur une Appliance Symantec Brightmail Gateway à partir d'une autorité de certification Microsoft

La problématique

Lors du déploiement d'une Appliance Symantec Brightmail Gateway un certificat numérique auto-signé est automatiquement généré et assigné à l'interface Web du rôle Control Center.

image

La principale conséquence de cette configuration est l'apparition systématique d'une fenêtre d'avertissement lors de la connexion à l'interface Web d'administration (cf. capture d'écran ci-dessous).

image

De plus l'URL du navigateur apparaît en rouge pour rappeler que le certificat SSL utilisé pour chiffrer les données est invalide.

image

Cela n'est pas gênant lorsque seule une population d'administrateur se connecte à l'interface Web. Cependant, lorsque l'accès utilisateur à la quarantaine est activée, il devient nécessaire de corriger ce comportement.

Cette configuration doit être effectuée en plusieurs étapes :

1) Configuration de l'URL d'accès à la quarantaine
2) Import de l'autorité de certification interne dans l'Appliance
3) Génération d'une requête de certificat (CSR)
4) Validation de la requête auprès de l'autorité de certification interne (ou externe)
5) Import du certificat signé par l'autorité dans l'Appliance
6) Positionnement du certificat sur l'interface Web

Procédure à suivre

1) Configuration de l'URL d'accès à la quarantaine

La première étape consiste à définir, puis à configurer l'URL d'accès à la quarantaine utilisateur. Pour cela il faut se connecter à l'interface Web d'administration en tant qu'administrateur, cliquer sur l'onglet Spam, puis sur le lien Quarantine Settings dans le menu de gauche.

On peut ensuite spécifier l'URL d'accès à la quarantaine dans le champ Spam Quarantine Login URL. Dans l'exemple ci-dessous l'URL retenue est la suivante :

image

Remarque : L'accès utilisateur à la quarantaine nécessite également que l'option Administrator-only Quarantine soit décochée et donc que l'accès à un annuaire soit configuré (pour l'authentification LDAP). De plus une entrée DNS doit également être créée pour effectuer la correspondance entre le FQDN de l'interface Web (exemple : sbg.piservices.fr) et l'adresse IP du control center.

2) Import de l'autorité de certification interne dans l'Appliance

Dans l'hypothèse où l'on souhaite utiliser un certificat émis par une autorité de certification interne, il faut impérativement insérer le certificat de l'autorité de certification racine dans le magasin Certificate Authority de l'Appliance.

Pour cela l'administrateur doit se connecter à l'interface Web d'administration, cliquer sur l'onglet Administration, puis sur le lien Certificates dans le menu de gauche. Il faut ensuite sélectionner l'onglet Certificate Authority, puis cliquer sur le bouton Update.

image

L'assistant propose alors d'injecter un certificat présent localement sur le poste de l'administrateur. Ce certificat doit respecter le format PEM (CER encodé en base64).

image

Remarque : Dans le cas où l'autorité de certification interne est issue du monde Microsoft (serveurs sous Windows Server 2003, 2003 R2, 2008 ou 2008 R2), les formats généralement utilisés sont les formats CER ou CRT. Pour les convertir au format PEM un utilitaire de conversion comme Crypto4PKI peut être utilisé.

image

3) Génération d'une requête de certificat (CSR)

L'étape suivante consiste à créer une requête de demande de certificat dans l'interface Web d'administration. Pour cela il faut aller dans l'onglet TLS & HTTPs Certificates, puis cliquer sur le bouton Add.

image

Dans l'assistant de création de la requête il faut sélectionner Certification Authority Signed dans le type de certificat, renseigner le nom commun qui doit correspondre à l'URL d'accès à la quarantaine (ici "sbg.piservices.fr") ainsi que tous les champs descriptifs demandés.

Le bouton Request permet ensuite de générer la demande de certificat ou CSR (Certificate Signing Request).

image

La requête obtenue doit ensuite être conservée en mémoire (cf. capture d'écran ci-dessous).

image

Suite à cette manipulation le certificat apparaît comme étant Requested dans l'interface Web.

image

4) Validation de la requête auprès de l'autorité de certification interne

La requête de certificat doit ensuite être validée et signée numériquement par l'autorité de certification interne. Si il s'agit d'une autorité de certification Microsoft, l'une des méthodes consiste à se connecter à l'interface Web d'administration (l'URL est généralement du type https://server/certsrv).

Pour commencer l'administrateur doit sélectionner le lien Request a certificate, puis advanced certificate request et enfin 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.

image

image

image

Dans la page Submit a Certificate Request or Renewal Request il faut insérer la requête précédemment générée, sélectionner le modèle de certificat Web Server et enfin cliquer sur le bouton Submit.

image

Si l'autorité de certification est de type "entreprise" et si le compte utilisateur possède les bonnes autorisations alors un certificat signé numériquement au format CER est immédiatement émis par l'autorité de certification (dans le cas d'une autorité de certification "autonome", l'émission du certificat doit être validée manuellement dans la console MMC Autorité de certification).

image

Remarque : Le certificat émis étant au format CER, il doit être converti au format PEM pour pouvoir être utilisé au sein de l'interface Web Brightmail.

5) Import du certificat signé par l'autorité dans l'Appliance

Pour importer le certificat au format PEM dans l'interface Web Brightmail, il faut cliquer sur l'onglet Administration, puis sur le lien Certificates et enfin sur le bouton Import.

image 

image

Suite à l'opération d'import un message indique que le certificat a été correctement importé et le certificat apparaît comme étant disponible (available).

image

6) Positionnement du certificat sur l'interface Web

La dernière étape consiste à positionner le certificat sur l'interface Web d'administration du control center. Pour cela il faut cliquer sur l'onglet Administration, puis sur le lien Control Center.

Dans la page Control Center Settings, il faut ensuite cliquer sur l'onglet Certificates, puis sélectionner le nouveau certificat dans la liste déroulante User interface HTTPs certificate.

image

image

Une fois cette dernière modification opérée, aucun message d'erreur n'est généré dans les navigateurs lors de l'accès à l'interface Web et l'URL du site ne s'affiche plus sur fond rouge mais sur un fond blanc ou vert (en fonction du type de certificat utilisé).

image

SCOM - Certificats pour les agents en workgroup

Etapes principales de mise en place de certificats pour les agents SCOM en workgroup et pour le serveur SCOM sans utiliser de gateway server.

1) Installer une authorité de certification de type « stand alone server » sur une machine (cette machine peut etre physique ou virtuelle)

2) Exporter le certificat racine de l’authorité (nom par defaut : certnew.p7b) vers un dossier partagé

3) Depuis le serveur en workgroup ou le serveur SCOM, lancer une mmc et ajouter le composant enfichable « Certificates »
Dans la console « Certificates » faites un clic droit sur le dossier « Authorite de certification racine de confiance » (en anglais : Trusted Root Certification Authorities) et selectionner Importer. Allez Rechercher le fichier certnew.p7b crée plus haut. Laissez l’assistant placer le fichier dans le magasin « Authorite de certification racine de confiance ».

4) Toujours depuis le serveur en workgroup ou le serveur SCOM, ouvrez votre navigateur et allez a l’adresse http://nom_du_serveur_hebergeant_authorite_certif/certsrv


Cliquez sur "Request a certificate" (Demander un certificat)



Cliquez sur "advanced certificate request"



Cliquez sur Create and submit a request to this CA


Renseignez le formulaire de creation de certificate de la manière ci-dessus, c’est a dire:
Name : le nom de votre serveur en workgroup (Doit etre identique au champ Friendly Name au bas du formulaire)
Company : le nom de la société
Type of certificate needed : selectionnez Other... et renseignez les OID suivant:
1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2   (pas d’espace autour de la virgule!)

Cochez les cases “Mark Key as Exportable” et “Store certificate in the local computer certificate store”

Renseignez le friendly name (I.E : Doit etre identique au champ Name)

Cliquez Submit

Cliquez Yes si le message ci-dessus apparait

5) Depuis le serveur hébergeant l’autorité de certification, ouvrez la console mmc « Autorité de certification »



Ouvrez le dossier « Pending Request ». le certificat demandé plus haut doit apparaitre. Il est en attente d’approbation



Cliquez droit dessus et selectionnez « Issue »



Le certificat doit apparaitre désormais dans le dossier Issued Certificates

6) Depuis le serveur en workgroup ou le serveur SCOM, retournez sur l’adresse http://nom_du_serveur_hebergeant_authorite_certif/certsrv

Selectionnez Afficher le statut d’une requete de certificat en attente

Selectionnez le certificat



Installez le certificat



Il apparait désormais dans le dossier Personal/Certificates de la console mmc « Certificates » du serveur en workgroup ou du serveur SCOM

7) Depuis la console « Certificates » du serveur en workgroup, faites un clic droit sur le fichier de certificat present sous le dossier Personal et selectionnez « Export ». Exportez le vers le dossier partagé crée en etape 2.








Selectionnez Yes Export the private key



Laissez les options par défaut



Renseignez un mot de passe pour le certificat

Renseignez le dossier partagé vers lequel exporter le certificat




 

8) Sur le serveur en workgroup si l’agent SCOM est déjà installé passez a l’étape 9, sinon effectuez une installation manuelle de l’agent SCOM

9) Sur le serveur en workgroup ou sur le serveur SCOM, ouvrez une ligne de commande vers l’outil MOMCertimport.exe
Tapez la ligne de commande suivante :

Momcertimport.exe <chemin_du_certificat_exporté> /password <password_du_certificat>

Cette commande ajoute une valeur dans le registre de SCOM  représentant le certificat :

10) Redémarrez le service de l’agent sur le serveur en workgroup.

Le nouvel agent doit à présent apparaitre dans la vue Pending de la console SCOM.

Il ne reste plus qu’a l’approuver.