Disable-ExchangeCertificate

Ne is keressük a címben szereplő EMS cmdletet. Nincs ilyen. A párja az Enable-ExchangeCertificate természetesen létezik. Van még olyan, hogy Remove-ExchangeCertificate, de az nem ugyanaz.
Miről is van szó?
Egy kissé is tapasztalt Exchange rendszergazda tudja, hogy az Enable-ExchangeCertificate parancsal lehet, a certificate store-ban tárolt tanúsítványokat az Exchange különböző szolgáltatásaihoz rendelni.
Néhány héttel ezelőtt az egyik ügyfelünknél azt a feladatot kaptam, hogy rakjam rendbe a tanúsítványokat. Ez abból állt volna, hogy a régi, már nem használt tanúsítványokat leszedjük a szolgáltatásokról, majd a tesztidőszakot követően eltávolítjuk a store-ból.
Először elkezdtem keresni, hogy milyen parancsal lehet ezt megtenni. Sokat keresgéltem, de csak azt találtam, hogy a tanúsítványt el tudom távolítani a store-ból, de a szolgáltatást nem tudom leszedni róla.
Az ügyfélnél ez egy alacsony prioritású feladat volt, így  a dolgot végül is ennyiben hagytuk.

Tegnap a nagy álljunk vissza androidra című felbuzdulásom kapcsán nekiálltam, hogy rendbetegyem a saját Exchange-emen az IMAP tanúsítványát. A problémáról itt írtam: http://it-pro-hu.blogspot.hu/2013/02/mi-bajom-az-androiddal.html A feladat a következő:
Az IMAP-nak a már jó ideje megvett, de be nem üzemelt Netlockos tanúsítványt kell használnia, az IISnek ugyanakkor a saját CA által kiállítottat mert nem akartam most szétszedni az egyész SAN-os/Autodiscover-es miskulanciát.
Megpróbáltam az IMAP-ról leszedni a régi tanúsítványt és természetesen újra a néhány héttel ezelőtti problémába futottam. Itt és most viszont nem akartam feladni. Arra gondoltam, hogy az Exchange azt az információt, hogy melyik tanúsítvány van hozzárendelve egy adott szolgáltatáshoz, biztosan tárolja valahol. Az Exchange tudtommal a különböző konfigurációs beállításokat alapvetően két helyen tárolja: az Active Directory-ban és különböző XML konfigurációs fájlokban:
- ADSIEdit -> configuration namespace -> semmi
- LDIFDE -> configuration namespace export -> az export fájlban keresgélve -> semmi
- Előkerestem az IMAP és POP3 szolgáltatás .Net Assembly-jét -> .config fájl -> semmi
- IIS Metabase -> semmi
Kezd a dolog kifogni rajtam. Felhívtam Józsit, hátha van valami ötlete. Sajnos nem volt.
Tovább keresgélve ráakadtam erre a cikkre:
http://www.msexchange.org/articles-tutorials/exchange-server-2007/management-administration/managing-exchange-certificates-part3.html
Itt ezen megakadt a szemem:

By running the cmdlet, Enable-ExchangeCertificate, you will enable a certificate for one or more services by updating the metadata stored with the certificate.
Every service has different metadata requirements, and will have different properties updated:

• POP3-IMAP4: msExchPopImapX509CertificateName property will be updated;
• IIS: Default Web Site will be updated;
• SMTP: the Network Service account will be granted Read access to the appropriate private file key in the directory Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys;
• UM: certificate property will be updated to include Unified Messaging.

Hoppá, ezek szerint nem reszelgetünk konfigurációs információkat, hanem a névegyezőségből és a tanúsítvány jogokból adódik, hogy mi látszik a Get-ExchangeCertificate parancs kimenetében.
Ellenőrzésképpen tettem is egy gyors próbát.
Az alapállapot az volt, hogy mind a saját CA-m által kiállított tanúsítvány, mind a NetLock-os hozzá volt rendelve az IMAP szolgáltatáshoz.
Az IMAP szolgáltatáson elrontottam a site nevét.
Láss csodát: Mindkét tanúsítványról eltűnt az IMAP flag. Ezek után persze kérdés, hogy a rendszer mi alapján dönt, ha több lehetséges tanúsítvány van.
A másik része a dolognak az All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys könyvtár tartalma. Itt találhatóak a Local System tanúsítványai. Sajnos a fájlnevek köszönő viszonyban sincsenek a tanúsitvány thumbprintjével, firendly nevével, vagy CN-jével, vagy akár bármi értelmezhető paraméterével. Az itt található tanúsítványok közül az használható SMTP hitelesítésre amilyikre a Network Service usernek olvasási joga van (az az érzésem, hogy ez az olvasási jog ugyanúgy szükséges a POP3-hoz és az IMAP-hoz is de ezt még nem tudtam tesztelni, ha ez igaz és szükséges a tanúsítványok szétválasztása, akkor érdemes elgondolkozni, hogy a Network Service helyett egyedi service accountokat használjuk a szolgáltatásokhoz).
Ha itt állítani akarunk valamit akkor merül fel a kérdés, hogy a fájlok közül vajon melyiket kell piszkálnunk, amikor mi csak a tanúsítvány thumbprintjét ismerjük (jó lenne ezeket a jogokat a certificate mmc-ben állítani, de ott sajnos erre nincs lehetőség).
Vajon hogyan tudjuk a thumbprintet összerendelni a fájlokkal? Újabb keresgélés a neten. A megoldás innen adódik:
http://jorgequestforknowledge.wordpress.com/2012/02/10/managing-certificates-on-a-windows-computer-with-powershell/
Az itt található scripteket kicsit átpofozva írtam egy scriptet ami a thumbprint alapján megadja a fájl nevét és a jogosultságait:

param([string]$ThumbPrint)
$Cert = dir cert:\LocalMachine\My | where {$_.ThumbPrint -eq $ThumbPrint}
$MachineKeysLocation = $env:ALLUSERSPROFILE + "\Microsoft\Crypto\RSA\MachineKeys\"
$KeyFileName = $Cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName
$KeyFilePath = $MachineKeysLocation + $KeyFileName
Write-Host FriendlyName: $Cert.FriendlyName
Write-Host Subject: $Cert.Subject
Get-Acl $KeyFilePath | fl