Choix et mise en place de certificats pour OWA
Le choix d’un certificat pour publier un site web OWA en utilisant le protocole HTTPS est fortement dépendant du nom de domaine public qui sera utilisé pour accéder à la messagerie, c'est-à-dire à l’URL qui sera saisie dans le
Les différents accès au travers d’une connexion Web (certificats pour OWA)
navigateur. Il faut tout d’abord disposer d’un nom de domaine Internet déposé auprès d’un prestataire autorisé (Registrar), puis utiliser un sous domaine pour accéder à Outlook Web Access OWA. Par exemple, si votre entreprise dispose d’un nom de domaine comme msexchange.fr, il sera alors possible de d’utiliser par exemple mail.msexchange.fr comme URL d’accès à OWA. Il faudra alors déclarer ce sous-domaine mail.msexchange.fr au niveau des DNS de votre registrar, puis y associer l’adresse IP publique de votre serveur ISA ou reverse-proxy. Le client tapera alors l’URL suivante dans son navigateur : https://mail.msexchange.fr/exchange (Exchange 2000 ou 2003) ou https://mail.msexchange.fr/owa (Exchange 2007).
Pour sécuriser la communication, il faut disposer d’un certificat correctement configuré et valide. La validation d’un certificat s’effectue à 3 niveaux qui sont le nom du domaine, l’autorité de certification et la date de validité du certificat. Si ces trois conditions ne sont pas vérifiées correctement, une erreur de certificat sera alors affichée au niveau de l’utilisateur et certains processus ne pourront pas être validés. Dans le cas d’une connexion OWA, il est possible d’utiliser un certificat avec une erreur, mais dans ce cas l’utilisateur devra répondre à chaque fois qu’il accepte l’utilisation de ce certificat non valide. Cette situation n’est pas toujours bien acceptée par les utilisateurs et peut générer des appels au support de l’entreprise.
Le nom du domaine pour lequel le certificat a été émis doit correspondre à la première partie de l’URL utilisée pour l’accès, c’est-à-dire mail.msexchange.fr dans notre exemple. Le choix de l’autorité de certification reste libre et le certificat peut être soit du type commercial, soit émis par sa propre autorité de certification dans le cadre d’une infrastructure PKI au sein de l’entreprise. Mais dans ce cas, il faudra gérer la distribution des certificats racines sur les postes clients car l’autorité de certification ne sera pas connue par le poste de travail lors d’une connexion à distance. Dans le cas d’un certificat commercial, ce problème n’existe pas car le certificat peut être validé avec une connexion Internet.
En conclusion, la mise en place d’un certificat pour sécuriser l’accès OWA ne demande que peu de contraintes, mais il est préférable de choisir un certificat public issu d’une autorité de certification reconnue par les navigateurs et de faire attention lors du choix du nom de domaine retenu pour la publication OWA.
Téléchargez cette ressource
Sécuriser Microsoft 365 avec une approche Zero-Trust
Découvrez comment renforcer la cyber-résilience de Microsoft 365 grâce à une approche Zero-Trust, une administration granulaire et une automatisation avancée. La technologie Virtual Tenant de CoreView permet de sécuriser et simplifier la gestion des environnements complexes, tout en complétant vos stratégies IAM, y compris dans les secteurs réglementés.
Les articles les plus consultés
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- Et si les clients n’avaient plus le choix ?
- Cybersécurité Active Directory et les attaques de nouvelle génération
- Activer la mise en veille prolongée dans Windows 10
- Afficher les icônes cachées dans la barre de notification
Les plus consultés sur iTPro.fr
- Sauvegarder les données ne suffit plus : il faut refonder le poste de travail
- Cybermalveillance : 2025, seuil franchi pour les victimes comme pour les cybercriminels
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- Construire la souveraineté numérique en Europe grâce à un écosystème ouvert et collaboratif
Articles les + lus
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
Adapter la sécurité OT aux réalités de l’industrie
Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
À la une de la chaîne Tech
- Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles
- DevX Summit EMEA : les développeurs au cœur de la révolution de l’IA
- Adapter la sécurité OT aux réalités de l’industrie
- Coder vite, mais coder juste : trouver l’équilibre à l’ère de l’IA
- Mixité dans la Tech : en 2026, un choix de souveraineté stratégique
