Exchange 2010: certificaten - IT-professional Community Blog
Zoeken binnen blogs.microsoft.nl

IT-professional Community Blog

Exchange 2010: certificaten

May 31 2011, 02:51 PM

In deze blog werpen we een blik op het certificaten deel van Exchange 2010. In vergelijking met Exchange Server 2003 hebben certificaten binnen Exchange 2007 en Exchange 2010 een veel grotere rol.

We beginnen met een stukje achtergrond informatie over certificaten en gaan vervolgens een certificaat aanvragen en installeren op onze Exchange 2010 omgeving.

Hoe werkt een certificaat?

Een certificaat bestaat uit twee delen:

  • Private key, dit deel van de key is alleen aanwezig op de server waarop het Certificate Signing Request (CSR) is aangevraagd. Daarnaast kan deze key inclusief de private key geëxporteerd en geïmporteerd worden op een andere server.
  • Public key, dit is het deel van de key dat we terug ontvangen van de Certificate Authority (CA). Dit wordt gedaan op basis van het CSR wat mee verzonden wordt tijdens de aanvraag.

Deze twee key’s samen vormen het certificaat; ontbreekt één van de twee dan is het certificaat niet geldig (lees: stuk). Om te controleren of een certificaat vertrouwd wordt is een certificaat ondertekend namens de CA met één root en één of meerdere intermediate certificate authorities. De CA garandeert dat het certificaat vertrouwd wordt en er dus een veilige en versleutelde connectie opgebouwd kan worden. Wordt een certificaat niet vertrouwd (bijvoorbeeld bij een self-signed certificaat dan wordt wel de verbinding versleuteld, maar omdat de herkomst niet vastgesteld kan worden moet dit als ‘niet veilig’ beschouwd worden.

Wanneer je dit in een diagram zet ziet dit er als volgt uit:

cachain

Figuur 1. Voorbeeld van een certification path

Dit geheel wordt ook wel “certificate chain” genoemd.

In dit geval is het certificaat ondertekend door een Intermediate Certificaat, die op zijn beurt weer is getekend door het Root CA certificaat. Wanneer je dit certificaat op een server installeert dien je naast het Root CA certificaat ook het Intermediate Certificaat op de server te installeren.

Wanneer een certificaat niet meer geldig is, bijvoorbeeld omdat het is ingetrokken door de CA, komt dit certificaat te staan op de Certificate Revocation List (CRL). Als een client een connectie maakt zal de CRL geraadpleegd worden om te controleren of het certificaat hierop niet voorkomt. Is dit wel het geval dan zal er een waarschuwing getoond worden aan de gebruiker.

Een certificaat dat verlopen is komt niet op de CRL te staan. Een client die een certificaat leest op een server checkt automatisch de verloopdatum. Is het certificaat verlopen dan wordt een waarschuwing getoond en wordt het certificaat niet langer als “veilig” beschouwd.

Nu we hebben gekeken hoe een certificaat werkt gaan we verder met het kijken welke type certificaten we voor Exchange 2010 kunnen gebruiken.

Welke type certificaten zijn er voor Exchange 2010?

Wanneer je op internet zoekt zul je diverse soorten certificaten tegenkomen bijvoorbeeld: web certificaten, Unified Communications (UC) certificaten en wild card certificaten. Alleen de laatste twee type certificaten zijn te gebruiken i.c.m. Exchange 2010.

Maar wat zijn de verschillen tussen een UC en een wildcard certificaat? Een UC certificaat is een certificaat met één Common Name (CN) en één of meerdere Subject Alternate Names (SAN’s). Door gebruik te maken van een UC certificaat is het dus mogelijk om één certificaat te gebruiken om meerdere fully qualified domain names (FQDN’s) te beveiligen.

Een wildcard certificaat bevat maar één Common Name (CN) in het volgende formaat *.domain.com. Met dit certificaat is het net als een UC certificaat mogelijk om meerdere FQDN’s te beveiligen. Het verschil met een UC certificaat is echter dat achter dit certificaat elke server in het domein domain.com geplaatst kan worden. Waardoor dit certificaat dus minder veilig is, immers de identiteit kan niet volledig gegarandeerd worden.

In onderstaande tabel is een overzicht van de kenmerken van de type certificaten:

UC Certificaat

Wildcard Certificaat

Meerdere namen op één certificaat

Eén wildcard entry als Common Name

Werkt op de meeste mobiele devices

Wordt niet ondersteund op oudere mobiele devices

Additionele kosten voor extra SAN entries

Minder veilig dan UC certificaat

 

Mogelijk problemen met integratie met andere applicaties

 

Extra configuratie nodig

Tabel 1: Kenmerken UC en Wildcard certificaten

 

Welke soorten Certificate Authorities (CA’s)zijn er?

Zoals al eerder besproken wordt een certificaat ondertekend door een Certificate Authority. In dit deel van het artikel kijken we welke CA’s er zijn en kijken we naar de voor en nadelen.

Er bestaan drie type certificate authorities:

  • Self-signed
  • Windows PKI
  • 3rd Party CA

Self-Signed

Alhoewel dit eigenlijk geen CA is wil ik dit type toch benoemen. Een self-signed certificaat is een certificaat dat niet is ondertekend door een root CA certificaat. Wanneer je naar het certification path van een self-signed kijkt zul je zien dat alleen het certificaat zelf in het path voorkomt.

Standaard wordt op elke Exchange 2010 server een self-signed certificaat geïnstalleerd tijdens de setup. De Exchange servers onderling kunnen dit certificaat gebruiken echter clients vertrouwen dit certificaat standaard niet. In het geval van CAS proxying wordt dit certificaat alleen gebruikt voor encryptie en niet voor authenticatie. Is dit wel een wens van de organisatie dan dient een aanpassing gemaakt te worden in het register:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeOWA\AllowInternalUntrustedCerts

Bovenstaande key is een Dword en dient de waarde 0 te hebben. Hiermee wordt ervoor gezorgd dat er tijdens het proxying wordt gecontroleerd of het een geldig certificaat is.

Windows PKI

Sommige bedrijven kiezen ervoor om een eigen CA server te bouwen. Deze CA server kan naast de eerder genoemde certificaten ook andere type certificaten uitgeven. Bijvoorbeeld om bestanden te versleutelen of e-mails digitaal te ondertekenen.

Eén van opties die je hiervoor hebt is het inrichten van een Windows Public Key Infrastructure (PKI) omgeving. Hiervoor moet je de Certificate Authority role installeren op een server. Een uitgebreide beschrijving (in het Engels) hoe je een Windows PKI kunt gebruiken vind je hier.

3rd Party CA

Het derde type is een 3rd Party CA, een externe Certificate Authority. Deze CA’s geven ook meerdere certificaten uit maar verschillen vaak in prijs. Eén van de oorzaken van het prijsverschil zit in het verzekerde bedrag van een certificaat.

In onderstaande tabel is een overzicht te zien van de kenmerken van de verschillende CA types:

Self-signed

Windows PKI

3rd Party CA

Automatisch gegenereerd tijdens setup

Werkt met alle services

Werkt met alle services

Root certificaat dient aanwezig te zijn op non domain clients en mobiele devices

Meeste root certificaten zijn al aanwezig op de clients

Certificaat moet in trusted root authorities geïnstalleerd worden van de clients. Dit om certificaat waarschuwingen te voorkomen

Certificaat wordt middels een CSR aangevraagd

Certificaat wordt middels een CSR aangevraagd

 

Mogelijk nodig om CRL beschikbaar te stellen via internet

 

Tabel 2: Kenmerken CA’s

Welke CA moet ik gebruiken?

Nu we weten welke CA’s er beschikbaar zijn is het tijd om te bepalen welk CA we gaan gebruiken voor onze Exchange omgeving.

Het Self-signed certificaat valt eigenlijk al meteen af. Hieraan zitten diverse nadelen maar misschien wel het belangrijkste: het is niet veilig. Het certificaat is immers niet ondertekend door een Certificate Authority die de geldigheid kan garanderen en eigenlijk is een self-signed certificate ook alleen bedoeld voor quick and dirty testen van een CAS Server na installatie.

Dus er blijven eigenlijk twee CA’s over: Windows PKI of een 3rd Party CA. Er zijn meerdere mogelijkheden:

  • Windows PKI
  • 3rd Party CA
  • Combinatie Windows PKI en 3rd CA

Welke er gekozen wordt is afhankelijk van welke functionaliteiten je wilt gebruiken en daarnaast nog een aantal beheerstechnische redenen.

Windows PKI

Deze PKI vraagt, vergeleken met een 3rd Part CA, wat meer aandacht van een beheerder. Wanneer er nog geen PKI omgeving aanwezig is zal deze opgezet moeten worden en vervolgens beheerd moeten worden.

Het root certificaat zal na de installatie van de CA gedistribueerd dienen te worden naar de clients. Dit zijn vaak niet alleen laptops en desktops maar ook smartphones. Vooral deze laatste groep is in veel gevallen lastig. Dit omdat niet iedere organisatie m.b.v. management software de telefoons beheerd of het ook toestaat om prive smartphones te gebruiken om te synchroniseren.

In deze gevallen zal het root certificaat van de CA handmatig geïnstalleerd moeten worden op de smartphones. Afhankelijk van het type smartphone kan de procedure per smartphone verschillen. Op onderstaande sites kun je meer informatie over deze procedures vinden:

Wanneer de organisatie gebruik wenst te maken van het veilig berichten uit kunnen wisselen met een andere organisatie. Dan zal het root certificaat uitgewisseld dienen te worden tussen de organisaties.

Om de geldigheid van het certificaat te controleren zal de externe organisatie echter ook toegang nodig hebben tot de CRL. De CRL van de interne organisatie zal daarom ook gepubliceerd moeten worden via het internet. Dit laatste kan bijvoorbeeld gedaan worden door de CRL te publiceren m.b.v. Microsoft Forefront TMG 2010.

3rd Party

In sommige gevallen wordt ervoor gekozen om het 3rd party certificaat zowel op de reverse proxy als op de CAS servers te installeren. Voordeel hiervan is dat het beheer redelijk eenvoudig is. Verloopt het certificaat dan dient dit op alle CAS servers en de reverse proxy vervangen te worden.

Echter, om dit mogelijk te maken dient er een keuze gemaakt te worden. Deze keuze is afhankelijk van een aantal vragen die gesteld moeten worden:

· Is het mogelijk een split-dns zone aan te maken?

· Is het mogelijk om Pin point dns zones aan te maken?

Bij sommige bedrijven is het aanmaken van een split-dns niet mogelijk. In dit geval kun je nog overwegen om gebruik te maken van pinpoint DNS zones. Dit zijn zones waar die gebruikt worden voor specifieke FQDN’s, bijvoorbeeld autodiscover.domain.com. Alle overige DNS requests voor dit domein worden in dat geval door de externe DNS server afgehandeld. Meer informatie kun je terugvinden op deze pagina. Indien voor één van deze opties gekozen wordt is het van belang dat de interne urls voor de diverse webservices worden aangepast. Deze dienen dan gelijk te zijn aan de externe url’s.

Als beide opties niet mogelijk zijn dan heb je maar één keuze registreer de interne servernamen ook op het certificaat. Houd er in dit geval rekening mee dat dit extra geld kost vanwege de extra SAN entries.

Combinatie Windows PKI en 3rd Party CA

Als laatste mogelijkheid een combinatie van een Windows PKI en 3rd Party CA. Met deze manier worden de CAS servers voorzien van een certificaat van de Windows PKI en de reverse proxy van een 3rd party certificaat.

Qua beheer is dit iets complexer omdat je de geldigheidsduur van twee certificaten in de gaten moet houden. Echter heb je in dit geval wel de vrijheid om zoveel namen als je wilt te registreren op het interne certificaat zonder hoge kosten.

Indien je echter ook veilig berichten uit wil wisselen met een andere organisatie dan is het handig om voor SMTP een 3rd Party certificaat aan te schaffen. Dit certificaat kan dan specifiek toegewezen worden aan de SMTP service van Exchange.

Certificaat aanvragen voor Exchange 2010

In de vorige paragrafen hebben we gekeken naar hoe een certificaat werkt en welke type certificaten er zijn. Nu we deze achtergrond informatie hebben is het tijd om te kijken hoe we een certificaat kunnen aanvragen voor Exchange.

In dit voorbeeld maken we gebruik van een Windows PKI omgeving die zich bevindt op het LAN. Binnen de organisatie is één Exchange server aanwezig waarop zowel de CAS, Hub als Mailbox rol is geïnstalleerd.

Open de Exchange Management Console (EMC) en ga naar Server Configuration. Selecteer vervolgens de Exchange server in het midden console. Indien er meerdere Exchange servers aanwezig zijn binnen de organisatie let dan goed op dat je de correcte server selecteert.

Kies in het Action menu aan de rechterzijde van het scherm de optie New Exchange Certificate, er zal nu een wizard worden gestart. Als eerst zal gevraagd worden om een naam. Deze naam wordt puur voor identificatie binnen het OS en Exchange gebruikt. Vul hier dus een naam in waardoor je het certificaat makkelijk kunt identificeren.

In de tweede stap hebben we de mogelijkheid om te kiezen voor een wildcard certificaat. Wanneer je deze optie selecteert zul je hierna alleen nog de informatie over de organisatie hoeven te specificeren.

Wanneer je dit echter niet doet zal je het volgende scherm te zien krijgen:

clip_image004

Figuur 2. Exchange certificaat wizard

In dit scherm zijn de diverse services terug te vinden die door Exchange worden aangeboden. Vergeet je hier bijvoorbeeld de optie Unified Messaging server aan te vinken wil dit echter niet zeggen dat het certificaat hier niet voor gebruikt kan worden. Dit scherm haalt alleen de namen op die geconfigureerd staan in Exchange.

In bovenstaand voorbeeld is bijvoorbeeld te zien dat de FQDN voor ActiveSync mail.contoso.com is. Als je hetzelfde bekijkt voor OWA dan zijn hier twee FQDN’s terug te vinden: de interne en externe.

Zorg er dus voor dat deze FQDN’s goed geconfigureerd staan voordat je deze wizard opstart. In dit geval selecteren we de volgende opties:

  • Client Access Server (Outlook Web App)
  • Client Access Server (Exchange ActiveSync)
  • Client Access Server (Web Services, Outlook Anywhere, and AutoDiscover)

Wanneer deze services eenmaal zijn geselecteerd kunnen we verder met de volgende stap.

clip_image006

Figuur 3. Exchange certificaat wizard: Common Name instellen

Standaard wordt de common name op domain.local ingesteld. Pas dit aan naar de externe FQDN van de CAS Server, in dit geval mail.contoso.com en druk op next.

Geef in de volgende stap de informatie op van de organisatie en specificeer de locatie waar het CSR bestand opgeslagen moet worden.

clip_image007

Figuur 4. Locatie voor CSR bestand

Als alle informatie is verzameld kan het CSR gecreëerd worden. Maar voordat dit gebeurd krijg je eerst nog een korte samenvatting van wat er precies geconfigureerd is.

Door op New te drukken wordt het daadwerkelijke CSR gecreëerd en kunnen we het certificaat aanvragen bij de CA.

Ben je bekend met Powershell dan kun je er ook voor kiezen om bovenstaand proces m.b.v. het New-ExchangeCertificate cmdlet uit te voeren:

$CSR=New-ExchangeCertificate -FriendlyName 'Exchange certificaat'
-GenerateRequest -PrivateKeyExportable $true -KeySize '2048'
-SubjectName 'C=NL,S="UT",L="Utrecht",O="Lab",OU="IT",CN=mail.contoso.com'
-DomainName ex.corp.local','mail.contoso.com','corp.local',
'autodiscover.corp.local','autodiscover.contoso.com' -Server 'EX'

Set-Content -path "C:\Certificaten\ExchangeCertRequest.req" -Value $CSR

In het eerste stuk van het script maken we het certificaat aan en zorgen we dat de output hiervan wordt opgeslagen in een variabele $CSR. Vervolgens zorgen we ervoor dat het CSR bestand wordt aangemaakt.

Wanneer je naar één van de twee methodes kijkt in de EMC zal je het volgende zien:

clip_image008

Figuur 5. Overzicht Exchange certificaten in de EMC

Nu we het CSR bestand hebben kunnen we het certificaat aanvragen. Op de Windows PKI omgeving is ook de web enrollment functionaliteit geïnstalleerd. Hiermee is het mogelijk om via een web applicatie het certificaat aan te vragen.

Open voordat je dit gaat doen het CSR bestand en kopieer de inhoud. De web enrollment applicatie is standaard te bereiken via een adres in dit formaat https://servernaam.domein.com/certsrv

Nadat je bent geauthentiseerd zul je de volgende pagina te zien krijgen:

clip_image010

Figuur 5. CA Web enrollment applicatie

Kies hier de optie Request a certificate gevolgd door advanced certificate request en 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.

Nadat deze opties zijn geselecteerd kom je uiteindelijk terecht op de volgende pagina:

clip_image012

Figuur 7. Submit a Certificate Request or Renewal Request

In het Saved Request veld plak je de inhoud van het CSR bestand en bij Certificate Template kies je voor Web Server. Wanneer deze velden goed zijn ingesteld druk je op Submit.

Zodra je op submit hebt gedrukt wordt het certificaat gegenereerd. Dit kan automatisch gebeuren maar het kan ook zijn dat er nog een handmatige handeling is vereist van de CA beheerder. In het eerste geval zul je onderstaande pagina te zien krijgen:

clip_image013

Figuur 8. Certificate Issued

Klik op Download certificate om het certificaat te downloaden.

Wanneer er een handmatige actie is vereist van de beheerder van de CA server zal je moeten wachten tot het certificaat is gegenereerd. Als de beheerder het certificaat heeft goedgekeurd ga je opnieuw naar de web enrollment applicatie en kies je voor View the status of pending certificate requests. Zoek hier het request op en download vervolgens het certificaat.

Zorg voordat je het certificaat gaat installeren dat het root certificaat van de CA server aanwezig is. Als dit niet het geval is zal je een foutmelding krijgen tijdens het importeren van het certificaat.

Het root certificaat kan via dezelfde web applicatie gedownload worden door de optie Download a CA Certificate, certificate chain or CRL te selecteren.

Wanneer dit allemaal goed staat is het tijd om het certificaat te installeren.

Certificaat installeren

Ook dit kan, net als het aanmaken van het CSR, op twee manieren. Als eerst via de EMC, ga hiervoor wederom naar Server Configuration en selecteer de correcte server.

Selecteer het certificaat met de status This is a pending certificate signing request en kies in het Action menu de optie Complete Pending Request.

Er zal nu een wizard gestart worden die je helpt bij het installeren van het certificaat. Selecteer het gedownloade certificaat bestand en klik op complete.

De status van het certificaat zal nu veranderen in The certificate is valid for Exchange Server usage. Alleen zijn er op dit moment nog geen services gekoppeld aan het certificaat. Kies de optie Assign Services to Certicate in het Action menu.

Er zal wederom een wizard worden gestart, controleer of de correcte servernaam wordt weergeven en druk op Next.

clip_image015

Figuur 9. Services toewijzen aan een certificaat

In de volgende stap kun je aangeven welke services er aan het certificaat worden toegewezen. Hierbij dient opgemerkt te worden dat het in de Exchange niet mogelijk is om verschillende certificaten toe te wijzen aan de verschillende web applicaties.

Wanneer alle services zijn geselecteerd druk je op Next gevolgd door Assign. Als dit proces is voltooid zul je het volgende zien in de EMC:

clip_image016

Figuur11. Certificaat overzicht in de EMC

Zoals eerder aangegeven kan dit ook m.b.v. de Exchange Management Shell (EMS).

Import-ExchangeCertificate –Path c:\certificaten\exchange.cer |
Enable-ExchangeCertificate –Services “IIS”

Nu het certificaat is toegewezen aan IIS maken alle webservices van Exchange gebruik van dit certificaat.

Best practices

Net als bij diverse andere producten of onderdelen van producten zijn er ook best practices voor certificaat gebruik en Exchange.

  • Gebruik bij voorkeur een certificaat van een 3rd party CA, aangezien de meeste client al het root certificaat is het meestal niet nodig om het root certificaat te distribueren;
  • Gebruik een UC certificaat, een UC of SAN certificaat is veiliger dan een wildcard certificaat. Daarnaast kan een wildcard in sommige gevallen voor problemen zorgen, denk hierbij aan met andere applicaties die communiceren met Exchange;
  • Vermeld zo min mogelijk namen op het certificaat, minder namen is minder complex en uiteindelijk ook veiliger;
  • Gebruik de certificate wizard van Exchange 2010, door gebruik te maken van de wizard is de kans kleiner dat je vergeet een FQDN te registreren op het certificaat.

Tot zover mijn blog over certificaten mocht je nog vragen hebben n.a.v. dit blog stuur me dan gerust een mail.

Wat denkt u?

(Verplicht) 

(Verplicht) 

(Optioneel)

(Verplicht) 
CaptchaCube Vraag:


Antwoord: