PI Services

Le blog des collaborateurs de PI Services

SMG – Gestion des files d’attente SMTP en mode console sur Symantec Messaging Gateway 9.5.3

J’ai récemment été confronté à une situation complexe sur une architecture Symantec Messaging Gateway composée de trois nœuds :

  • Deux boitiers scanners
  • Un boitier control center

Le boitier control center était hors service (interface Web inaccessible); or, au même moment l’un de deux boitiers scanner était victime d’un problème de remise de messages (files d’attente Inbound et Outbound avec plusieurs milliers de messages en attente de traitement).

Dans ce cas de figure la seule méthode disponible pour administrer le boitier scanner (en l’absence de l’interface Web habituellement disponible sur le control center) consiste à prendre en la main en mode console (soit physiquement sur le serveur, soit à distance avec un client SSH comme putty).

Dans ce cas de figure, les trois commandes les plus importantes pour gérer les files d’attente sont les suivantes :

  • mta-control qui permet de gérer les files d’attente et de reconfigurer la pile MTA
  • monitor qui permet d’afficher le statut des files d’attente ainsi que le nombre de mail dans chaque file
  • service qui est une commande Linux standard permettant de redémarrer les services (dont le service MTA)

    Voici quelques exemples de commandes :

    mta-control pause-mode status (permet d’afficher le statut de la pile MTA)
image

    mta-control pause-mode pause-accept (reconfigure la pile MTA pour ne plus accepter les nouveaux messages; les messages toujours en file sont scannés, puis envoyés)
image

image

    mta-control pause-mode resume-accept (permet de revenir en arrière)

image

monitor mta (permet d’afficher l’état des différentes files; i_qmsgs correspond au nombre de message dans la file Inbound, o_qmsgs correspond au nombre de message dans la file Outbound et enfin d_qmsgs correspond au nombre de messages dans la file Delivery)

image

mta-control delivery flush (permet de forcer la réémission des messages bloqués dans la file d’attente Delivery)

image

service mta restart (permet de redémarrer le service MTA)

image

TMG2010SP2 – Erreur “The value specified for the parameter Scope is not valid for standalone mode” à l’importation d’un fichier de configuration

La problématique

J’ai récemment rencontré la problématique suivante sur un serveur TMG 2010 SP2 : suite à des problèmes matériels (plantages répétés du serveur) le service pare-feu refuse de démarrer.

La base de données AD LDS étant toujours accessible, il est toujours possible de se connecter à la console TMG et donc je réalise un export de la configuration de la ferme de serveurs.

Le dépannage du problème de démarrage sur le service TMG semblant complexe à résoudre décision est prise de désinstaller TMG, puis de le réinstaller et enfin d’importer la configuration précédemment sauvegardée au format XML.

Lors de l’import de la configuration sur le serveur fraichement réinstallé, l’erreur suivante s’est produite dans l’assistant d’importation de TMG :

Import Failed

The value specified for the parameter Scope is not valid for standalone mode.

image

Résolution apportée

La solution apportée n’est pas une solution très académique est plutôt à classer dans la catégorie des contournements :

Pour résoudre l’ensemble des balises Scope ont été supprimées manuellement dans le fichier de configuration à l’aide d’un éditeur de fichier XML (ici Notepad++).

La balise complète a été supprimée à chaque fois.

image

Suite à cette modification l’importation s’est terminée correctement et l’ensemble des services et des règles ont pu repartir en production.

Ce problème étant très spécifique je suppose que l’erreur rencontrée était due à la présence d’un reliquat de configuration ISA Server 2006 dans le fichier XML précédemment exporté.

Exchange2010 – Préparation de l’annuaire pour Exchange Server 2010 SP2

La préparation de l’annuaire Active Directory pour le déploiement du service pack 2 d’Exchange Server 2010 est tout à fait classique.

Mise à jour du schéma Active Directory

Dans un premier il faut déployer les extensions de schéma Echange Server 2010 SP2 à l’aide de la commande setup.com /PrepareSchema.

Remarque : Cette opération effectue des modifications sur la partition de schéma de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Schema Admins”.

image

Les extensions de schéma du service pack 2 intègrent de nouvelles classes et de nouveaux attributs. Parmi ces nouveaux attributs il y a notamment 5 nouveaux attributs nommés extensionCustomAttribute1 à extensionCustomAttribute5. Ces attributs supplémentaires peuvent être utilisés pour stocker des propriétés supplémentaires sur les objets destinataires (boîtes aux lettres, groupes, contacts…). Ils sont utilisables avec les commandes PowerShell suivantes :

Ainsi que le document de référence sur les extensions de schéma Exchange Server (document mis à jour suite à la sortie du SP2) :

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5401

Pour vérifier que le schéma a bien été mis à jour il suffit de vérifier la valeur de l’attribut rangeUpper sur la classe ms-Exch-Schema-Version-Pt à l’aide d’un outil comme ADSIEdit (ou via une requête de type dsquery par exemple).

Suite à la mise à jour du schéma, la valeur de l’attribut rangeUpper passe de 14728 (version Exchange 2010 SP1) à 14732 (version Exchange 2010 avec SP2).

image

Mise à jour de l’organisation Exchange

L’étape suivante consiste à mettre à jour l’organisation Exchange 2010 à l’aide de la commande setup.com /PrepareAd (dans cet exemple l’organisation se nomme PIServices).

Remarque : Cette opération effectue des modifications sur la partition de configuration de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Enterprise Admins”.

Pour valider la propagation des modifications apportées à la partition de configuration sur les différents contrôleurs de domaine le plus simple consiste à affichez les propriétés de l’organisation Exchange via ADSIEdit.

L’attribut objectVersion de l’organisation passe de 13214 (Exchange 2010 SP1) à 14247 (Exchange 2010 SP2).

image image

Mise à jour des domaines

Il faut enfin mettre à jour chaque domaine de la forêt Active Directory à l’aide de la commande setup.com /PrepareDomain.

Remarque : Cette opération effectue des modifications sur la partition de domaine du domaine concerné et par conséquent nécessite l’utilisation d’un compte membre du groupe “Domain Admins” dans le domaine concerné.

Suite à l’application du service pack 2 d’Exchange 2010 la valeur de l’attribut objectVersion sur l’objet CN=Microsoft Exchange System Objects présent à la racine du domaine passe à 13040 (cette valeur est identique à celle du SP1 d’Exchange 2010).

image

Déploiement du service pack 2 sur l’ensemble des serveurs

Une fois l’annuaire préparé et les modifications propagées sur l’ensemble des contrôleurs de domaine il est conseillé de mettre à jour les serveurs Exchange 2010 dans l’ordre suivant :

  • Serveurs CAS
  • Serveurs HUB
  • Serveurs Mailbox
  • Serveurs UM

Remarque : les serveurs Edge étant situés en workgroup ils peuvent être patchés en parallèle.

    Si la haute disponibilité est déployée sur l’environnement il faudra bien sur déployer le package successivement sur chaque nœud en pensant bien à isoler le nœud en train d’être patché (mode “drain” sur les serveurs CAS et/ou HUB en load balancing matériel ou NLB, mode maintenance sur un nœud appartenant à un DAG).

    Le déploiement du patch sur un serveur nécessite que les outils d’administration Exchange 2010 (console MMC et Powershell) soient fermés. De plus les services tiers accédant aux services Exchange (agent de sauvegarde, agent antivirus dédié à Exchange…) doivent également être arrêtés.

    Si certains services ou outils bloquent le déploiement du Service Pack alors une fenêtre équivalent à celle-ci s’affichera à l’issue de test des prérequis.

image

Attention, pas retour d’expérience, le service pack 2 peut mettre jusqu’à 1h, voir 1h30 pour se déployer sur certaines configurations.

Exchange 2003 - Obtenir des statistiques ActiveSync à l’aide des cmdlets PowerShell d’Exchange 2010

Contexte et problématique

Exchange Server 2007 et Exchange 2010 intègrent des commandes PowerShell permettant d’obtenir rapidement des statistiques d’utilisation autour d’ActiveSync.

Ca n’est malheureusement pas le cas d’Exchange Server 2003 qui n’apporte que peu d’outils pour répondre à ce besoin (l’outil MobileAdmin permet de visualiser les périphériques ActiveSync associés à un utilisateur mais il n’est pas conçu pour effectuer des extractions en masse).

Avec Exchange 2007 / 2010, les commandes suivantes sont disponibles :

  • Get-ActiveSyncDevice
  • Get-ActiveSyncDeviceStatistics
  • Export-ActiveSyncLog

Les deux premières commandes récupèrent de manière dynamique les informations sur les partenariats ActiveSync à partir de l’annuaire ActiveDirectory alors que la commande Export-ActiveSyncLog récupère des résultats sur les accès en analysant les logs IIS.

Remarque : La suite de billet est axée sur l’usage de la commande Export-ActiveSyncLog. Pour obtenir plus d’informations sur l’usage de la commande Get-ActiveSyncDeviceStatistics, vous pouvez consulter les deux liens suivants :

Méthode proposée

Même si la commande Export-ActiveSyncLog intégrée à Exchange Server 2010 a été conçue pour fonctionner avec des logs IIS version 7.0 (Windows Server 2008 SP2) et version 7.5 (Windows Server 2008 R2), celle-ci fonctionne également avec les logs de IIS 6.0 (Windows Server 2003).

En effet, par défaut le format de log utilisé est le format W3C qui est un format standard et identiques entre IIS 6.0 et 7.0 / 7.5 (à une colonne près !).

L’avantage de cette méthode est qu’elle ne nécessite pas le déploiement de serveurs Exchange 2010 sur l’environnement de production pour fonctionner !

En effet il est tout à fait possible d’extraire les fichiers de logs présents sur les serveurs Exchange 2003 de production pour aller ensuite les analyser avec la commande PowerShell sur un serveur Exchange 2010 de test / maquettage ou bien sur un environnement de pré-production.

Sur un environnement comportant des serveurs frontaux et dorsaux la méthodologie à suivre est la suivante :

1-) Récupération de l’ensemble des fichiers de logs IIS présent dans les répertoires “C:\Windows\System32\LogFiles” de chacun des serveurs frontaux
2-) Copie de ces fichiers dans un partage réseau ou sur un clé USB
3-) Analyse de ces fichiers avec la commande Export-ActiveSyncLog sur un serveur Exchange 2010 de test

Fonctionnement de la commande Export-ActiveSyncLog

La commande Export-ActiveSyncLog prend en entrée un ou plusieurs fichiers de logs et génère automatiquement un ensemble de fichiers CSV contenant des statistiques sur les utilisateurs connectés à ActiveSync, le type de Pocket PC, le volume de connexion sur chaque tranche horaire de la semaine, etc.

Voici la liste des fichiers CSV générés en sortie par la commande :

image

Les deux tableaux ci-dessous sont des exemples de fichiers CSV générés sur un environnement de maquette à partir de logs IIS Exchange 2003 :

image

Dans le CSV « Users », nous obtenons la liste des utilisateurs ayant utilisé un ou plusieurs périphériques ActiveSync ainsi que le type de périphérique et le nombre de connexions reçues.

image

Dans le CSV « UserAgent », nous obtenons des détails sur les versions de téléphones utilisées (iPhone3C1 par exemple) ainsi que le nombre d’unités référencé pour chaque version.

Afin d’analyser en une seule fois l’ensemble des logs présent dans un répertoire, une commande proche de celle-ci doit être saisie :

Dir C:\TEMP\PROD\*.log | Export-ActiveSyncLog –OutputPath C:\TEMP\CSV –StartDate:”2011/05/01” –EndDate:”2011/05/31

Les paramètres “StartDate” et “EndDate” permettent de limiter les résultats sur une période de temps données.

Cela est très pratique car l’objectif est ici d’obtenir des statistiques “terrain” pour savoir quels types de périphériques sont actuellement en usage dans la société. Dans la majorité des cas la génération de statistiques sur une période de 15 jours à 2 mois sera largement suffisante (on peut en effet considérer qu’un périphérique disposant d’un partenariat ActiveSync et qui ne s’est pas connecté depuis plus de 2 mois n’est plus en cours d’utilisation).

OCS 2007 R2 – Erreurs lors de la publication de CWA à travers IAG/UAG

Symptôme

Suite à la publication de l’interface Communicator Web Access à travers un équipement de type “reverse proxy” (ISA/TMG ou IAG/UAG), l’erreur suivante se produit de manière aléatoire (environ 1 fois sur 3) :

Cannot sign in because your computer clock is not set correctly or your account is invalid

Voici l’intitulé exact de l’erreur :

Cannot sign in because your computer clock is not set correctly or your account is invalid.(Error code: 0-1-492)

Explication

Cette erreur est un “classique” sur CWA. Elle se produit souvent lorsque l’URL utilisé pour accéder au service Web ne correspond pas au certificat positionné dans IIS ou bien encore aux URL d’accès publiées durant la configuration OCS (étape 4 de l’assistant d’installation du rôle CWA).

image

Cette erreur peut également se produire lorsque les SPN du compte ordinateur sont mal configurés et ne contiennent pas le SPN correspondant à l’URL publiée. Pour cela le SPN manquant peut être rajouté en suivant la procédure suivante :

    Dans ce cas précis, la bonne URL est utilisée lors de l’accès et les SPN du serveur hébergeant CWA sont correctement configuré ! De plus l’erreur ne se produit pas systématiquement mais de manière aléatoire, et ce, uniquement à travers un équipement de type “reverse proxy” (comprendre l’accès à CWA depuis le LAN fonctionne systématiquement et sans aucune erreur) !

Résolution

Après quelques recherches sur le Web, je suis tombé sur le billet suivant qui propose d’activer l’authentification de type Anonyme sur l’une des pages du site CWA (page AuthMainCommandHandler.ashx).

http://www.tincupsandstring.com/2009/03/31/cwa-error-code-0-1-492/

Dans notre cas, cette manipulation a totalement corrigé le problème rencontré avec les publications de CWA à travers Unified Access Gateway (UAG) et Intelligent Application Gateway (IAG).

Configurer la page AuthMainCommandHandler.ashx

Configurer la page AuthMainCommandHandler.ashx

Remarque : A priori ce problème peut également être rencontré lors de la mise en place d’un load balancing matériel (HLB) sur le site CWA (cf. Blog Technet de Stefan Plizga).

OCS 2007 R2 – Appliquer l’ensemble des mises à jour disponibles sur un serveur OCS

Depuis sa sortie en 2009, de nombreuses mises à jour sont régulièrement publiées pour OCS 2007 R2.

L’application de l’ensemble de ces patchs peut sembler complexe à première vue. En effet Microsoft ne développe pas de correctifs  “globaux” contrairement à Exchange ou TMG mais plutôt des correctifs ciblés sur chaque composant d’OCS :

  • Application Host
  • Application Sharing Server
  • Administration Tools
  • Audio/Video Confering
  • Core Components
  • Communicator Web Access
  • Conferencing Attendant
  • Conferencing Announcement Service
  • Monitoring Server
  • Mediation Sever
  • Outside Voice Control
  • Response Group Service
  • Standard / Enterprise edition Server
  • Standard / Enterprise edition Back-End
  • Unified Communications Managed API 2.0 Core Redist 64-bit
  • Web Conferencing Server
  • Web Components Server

En fonction des rôles installés sur chaque serveur OCS certains packages accepteront de s’installer et d’autres non !

Afin de simplifier l’application de l’ensemble des mises à jour sur un serveur OCS 2007 R2, Microsoft met à disposition deux outils très pratiques :

L’outil détecte les rôles installé sur le serveur local, télécharge les mises à jour associées et enfin les installe toute !

Pour mettre à jour entièrement un serveur OCS 2007 R2 nouvellement installé, les deux fichiers suivants doivent être téléchargés :

  • ServerUpdateInstaller.exe
  • OCS2009-DBUpgrade.msi
    Mises à jour OCS 2007 R2

Voici la fenêtre affichée par l’outil de déploiement des mises à jour sur un serveur Front-End OCS 2007 R2. Il suffit de cliquer sur le bouton Install Updates pour déclencher l’installation de l’ensemble des mises à jour.

Mises à jour OCS 2007 R2

Après une quinzaine de minutes (temps d’installation de l’ensemble des mises à jour), l’outil propose de redémarrer le serveur.

Mises à jour OCS 2007 R2

Suite au redémarrage du serveur il est probable que le service principal d’OCS (service Front-End) ne démarre pas.

En effet certaines mises à jour nécessitent une mise à jour de la base de données RTC associée à OCS 2007 R2.

Pour cela le fichier MSI précédemment téléchargé doit être exécuté avec le paramètre POOLNAME=<FQDN de votre pool de serveurs Front-End>.

A l’issue de ces manipulations, le serveur OCS 2007 R2 est 100% à jour.

OCS 2007 R2 – Erreur 0xC3EC78D8 lors de l’ajout d’un serveur à un pool existant

Symptôme

Lors de l’ajout d’un serveur OCS 2007 R2 au sein d’un pool de serveur front-end, l’erreur suivante peut se produire :

[0xC3EC78D8] Failed to read the Office Communications Server version information. This can happen if the computer clock is not set to correct date and time

Erreur 0xC3EC78D8 sur OCS 2007 R2

De plus l’erreur suivante peut également apparaître dans le journal d’évènements Applications (y compris si vous utilisez des sources auxquelles est associée une licence valide) :

The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.

Explication

Contrairement aux intitulés qui sont parfois trompeurs, ces erreurs ne sont pas dues à un problème de synchronisation d’horloge ni de” version” mais tout simplement à une mise à jour de Windows (bulletin de sécurité MS09-056).

Résolution

Pour résoudre ce problème et pouvoir ajouter avec succès le serveur au sein du pool OCS existant, deux alternatives sont possibles :

  • Désinstaller la mise à jour de sécurité KB974571
  • Utiliser l’outil OCSASNFix.exe

L’outil OCSASNFix est disponible à l’adresse suivante :

http://support.microsoft.com/kb/974571/en-us

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.

Exchange 2010 SP1 - Erreur "The action couldn't be completed. Please try again." lors d'une recherche OWA

Symptôme

Suite au déploiement du SP1 d'Exchange 2010, l'erreur suivante peut se produire dans le Webmail Outlook Web App lorsque la fonction de recherche est utilisée :

The action couldn't be completed

      image
        De plus l'erreur suivante apparaît dans le journal Application du serveur CAS Exchange 2010 :
      Log Name: Application
      Source: MSExchangeIS Mailbox Store
      Date: 07/02/2011 12:08:16
      Event ID: 9877
      Task Category: Content Indexing
      Level: Error
      Keywords: Classic
      User: N/A
      Computer: <FQDN du serveur>
      Description:
      Content Indexing function 'CISearch::EcGetRowsetAndAccessor' received an unusual and unexpected error code from MSSearch.
      Mailbox Database: <Nom de la base de données>
      Error Code: 0x80043629

    Un redémarrage du serveur ou bien le déplacement des boîtes aux lettres vers une nouvelle base de données ne résout pas le problème.

    Explication

    Ce problème serait dû à une erreur lors de l'application du SP1 (au niveau des phases de mise à jour du schéma et de mise à jour de l'organisation Exchange 2010).

    Résolution

    Pour résoudre ce problème, il faut ré-exécuter les commandes de préparation de l'annuaire Active Directory pour Exchange 2010 SP1 :

    Setup.com /PrepareSchema

    image

    Setup.com /PrepareAd

    image

    Il faut ensuite redémarrer le ou les serveurs Exchange 2010. Suite à ces manipulations la recherche dans le Webmail fonctionne de nouveau normalement.

Pour plus d'informations, vous pouvez consulter le lien suivant sur le forum Microsoft Technet :

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