Exchange Zertifikatstatus konnte nicht ermittelt werden

Bei der Erstellung eines Zertifikates unter Exchange 2010 erscheint möglicherweise folgender Hinweis.

Der Zertifikatstatus konnte nicht ermittelt werden, da die Sperrungsüberprüfung  keinen Erfolg hatte.

Symptome
Zertifikat kann nicht abgeschlossen werden. Exchange Dienste können nicht zugeordnet werden.

Lösung
Damit die Sperrlisten-Verteilungspunkte eines PKI (public key infrastructures) Ausstellers erreichbar werden, muss die Firewall den Zugang zur URL der certificate revocation list (CRL – RFC 3280) erlauben. Bei UTM (Proxy Content Filter) ist darauf zu achten das der Download der CRL nicht blockiert wird. Die URL zur certificate revocation list erhält man durch öffnen des Zertifikates und Details.

Sperrlisten-Verteilungspunkte
Sperrlisten-Verteilungspunkte

Durch Aufruf der URL aus dem Browser wird die CRL geöffnet.

Zertifikatsperrliste
Zertifikatsperrliste

Auch kann es erforderlich sein, das die Proxy Einstellung des Servers geändert werden muss, dies geschieht mit folgendem Befehl aus einer als Administrator geöffneten Eingabeaufforderung.

netsh winhttp rpoxy
netsh winhttp proxy

Nach Umsetzung und Sicherstellung der Erreichbarkeit der CRL erscheint in der EMC das Zertifikat als gültig.

Zertifikatstatus
Zertifikatstatus

Exchange Sicherheitszertifikat stimmt nicht mit Namen der Webseite überein

Möchte man Outlook 2010/2013 mit der AutoErmittlung (Outlook Anywhere) automatisch konfigurieren, und das Postfach auf einem Exchange 2010/2013 liegt, wird man nach der Installation folgenden Sicherheitshinweis erhalten. exchange_logo

sicherheitshinweis

Dies liegt oft daran das kein Zertifikat vorliegt, welches von Microsoft Active Directory Certificate Services (AD CS) ausgestellt wurde.

Problembeschreibung
Nachdem ein neues Zertifikat von einer root CA Zertifizierungsstelle beim Exchange-Server importiert wurde, kann es zu Fehlermeldungen beim Start bei den Outlook Clients kommen.

Im Sicherheitshinweis Fenster sehen wir in der ersten Zeile, dass sich unser Exchange-Server mit seinem internen FQDN “exchsrv.domain.local” meldet. Ebenfalls gibt uns die Meldung die Information, dass das Zertifikat ungültig ist oder die Namen nicht übereinstimmen.

Symptome
Outlook oder das Mobiltelefon können nicht konfiguriert werden.

Outlook hat die Suche nach den URLs für die Autodiscover-Informationen Hardcodet und wird in folgender abfolge durchlaufen:

Autodiscover Lookup Reihenfolge
Autodiscover Lookup Reihenfolge

Wenn nun die nötigen DNS-Records fehlen oder keine der definierten URLs aus dem Internet erreichbar sind, kann Autodiscover nicht abgefragt werden.

zertifikatsinformation1

Der Name „autodiscover.domain.com“ ist auch im Zertifikat vorhanden, aber die Warnung tritt stattdessen für den Namen „exchsrv.domain.local“ auf.

Zertifikat Details
Zertifikat Details

Ursache
Nicht wie die Vorgänger, verwendet Outlook 2013 intern nicht nur den SCP (Service Connection Point) zur Suche nach Autodiscover, sondern macht gleichzeitig eine DNS-Auflösung gemäss oben dargestellten Reihenfolge. Wenn jetzt die DNS-Auflösung von exchsrv.domain.com auf einen Webserver mit HTTPS Binding zeigt, erscheint der oben gezeigte Sicherheitshinweis.

Lösung
Neues Exchange-Zertifikat erstellen

Exchange Zertifikat erstellen
Neues Zertifikat erstellen

Der EMC-2010 Assistent erstellt abschliessend die Anforderung welche in einer Datei(.req) gespeichert wird, dieser private Schlüssel wird benötigt um bei der CA Zertifizierung (z.B. CAcert.org) mittels Copy & Paste dann über das Formular den Public Key zu erzeugen. Anschliessend wird der ausgestellte Schlüssel mit „Anstehende Anforderung abschliessen“ der wiederum mit Copy & Paste von der Zertifizierungsstelle eingefügte Schlüssel erzeugt. Zuletzt noch dem Zertifikat die Dienste zuordnen.

Die von CA Cert Signing Authority ausgestellten X.509-Zertifikate enthalten nur im Internet auflösbare FQDN, daher müssen die Internen URLs per Exchange Management Shell angepasst werden.

Mit folgendem cmdlet wird die aktuelle URI abgefragt.

Exchange Management Shell
Exchange Management Shell

Die AutoDiscoverServiceInternalUri wird nun auf den Externen FQDN geändert, damit es dem ausgestellten Zertifikat entspricht.

und die folgenden VirtualDirectory noch ändern.

noch kontrollieren ob alles stimmt..

Ohne DNS geht nichts, deshalb erstellen wir eine neue Forward-Lookupzone, wir öffnen dnsmgmt und erstellen eine neue Zone für unser exchsrv.domain.com

dnsmgmt Forward-Lookupzone
dnsmgmt Neue Forward-Lookupzone

Rechts im Fenster wieder mit Rechtsklick ein neuen Host als Type A erstellen, das Name Feld leer lassen und die IP Adresse von exchsrv.domain.com eintragen.

Neuer Host A
Neuer Host A

Nun sollten die Exchange-Dienste neu gestartet werden, den IIS mit iisreset /noforce aktualisieren. Ist der Nameserver als BIND auf einem Linux/Unix Host, steht folgende Zone für unsere Mail Domain für Autodiscovery.

DNS Zone
DNS Zone

Für Windows wird im DNS-Manger im Kontextmenu unter weitere Einträge der Eintrag „Dienstidentifizierung SRV“ erstellt.

Windows DNS Manager
Windows DNS Manager

Zu guter letzt soll unser Zertifikat auf die Clients ausgerollt werden, hierzu bieten sich die Gruppenrichtlinien an.

Gruppenrichtlinien Editor
Gruppenrichtlinien Editor

Computerkonfiguration-Windows-Einstellungen-Sicherheitseinstellungen-Richtlinien öffentlicher Schlüssel-Vertrauenswürdige Stammzertifizierungsstellen.

Mit Rechtsklick auf Importieren gehen, mittels des Assistenten die zuvor exportierte Zertifikatsdatei (.cer) importieren.
Beim Client wird mit gpupdate /force die Policy aktualisiert.

Alternativ kann das Zertifikat auf den Clients auch mittels des cmd-Tool certutil importiert werden, beispielsweise aus einer Batch Datei.

Troubleshooting
Am einfachsten geht’s mit dem Browser um herauszufinden wohin die URL https://exchsrv.domain.com zeigt. Alternativ kann auch nslookup oder host aufgerufen werden.

Browser SSL Zertifikat
Browser SSL Zertifikat

Ebenso bietet sich hier das cmd-Tool certutil zur Überprüfung an.

Ob das Zertifikat an der richtigen stelle im Zertifikatsspeicher ist, lässt sich anhand der mmc-Konsole überprüfen.

mmc-Konsole
mmc-Konsole

Snap-In hinzufügen –  Zertifikate Hinzufügen – Computerkonto – Lokalen Computer.

Hinweis!
Das hier verwendete Zertifikat wird mit dem öffentlichen Schlüssel der kostenfreien Zertifizierungsstelle CAcert (cacert.org) ausgestellt, dies erfordert dass das Stammzertifikat von CAcert als Klasse 1 PKI Schlüssel im PEM oder DER Format zum Zertifikatsspeicher „Vertrauenswürdige Stammzertifizierungsstellen“ importiert werden muss.

Das Zertifikat ist für die dauer von einem Jahr gültig, danach muss es erneuert werden, wer dies mit „Exchange Zertifikat erneuern“ versucht, wird feststellen das dies nicht geht, Exchange 2010 möchte nur neue Zertifikate erstellen, deshalb die Methode mittels certutil.

Die Seriennummer findet man in den Zertifikat Details, danach das Exchange-Zertifikat importieren.

CAcert Zertifizierungsstelle

CAcert.org ist eine von einer Gemeinschaft betriebene Zertifizierungsstelle, die kostenfreie Zertifikate für jedermann ausstellt.cacert

Ziel von CAcert ist es, das Bewusstsein und die Unterrichtung über Computersicherheit durch die Benutzung von Verschlüsselung zu fördern, insbesondere durch die Herausgabe von Zertifikaten zur Verschlüsselung. Diese Zertifikate können benutzt werden, um E-Mails digital zu unterschreiben und zu verschlüsseln, einen Anwender beim Zugang zu Webseiten zu beglaubigen und zu berechtigen und eine gesicherte Datenübertragung über das Internet zu ermöglichen. Jede Anwendung, die das gesicherte Übertragungsprotokoll mit SSL oder TLS unterstützt, kann von Zertifikaten Gebrauch machen, die von CAcert signiert wurden, ebenso jede Anwendung, die X.509-Zertifikate benutzt, z.B. für Verschlüsselung oder Signierung von Code oder Dokumenten.

Kostenfreie Zertifikate ausstellen cacert.org

VM sicherung mit ghettoVCB für ESXi

ghettoVCB von William Lam (@lamw) ist eine freie alternative zur Sicherung von virtuellen Maschinen. Das Skript erstellt Backups von virtuellen Maschinen auf ESX(i)3.5/4.x/5.x/6.x-Server mithilfe einer Methode ähnlich wie des VMware VCB-Tool.

Es werden Snapshots von laufenden virtuellen Maschinen gemacht und sichert diese danach, nach Fertigstellung werden die Snapshots wieder gelöscht bis zur nächsten Sicherung. Der einzige unterschied zu VMware VCB ist dass der Prozess auf dem ESXi-Host selbst ausgeführt wird, dabei werden wenig Ressourcen belegt. Die Backups werden über die Service-Konsole (Busybox Console) des Hypervisor gefahren, im Gegensatz zu der traditionellen Methode bei der die Backups eine virtuelle Maschine als VCB-Proxy nutzt.

Download ghettoVCB

Die ESXi-Shell und TSM-SSH muss aktiviert werden, dies geschieht über die ESXi direkt Console oder aus dem vSphere Client.

ESXi-Shell

Nach dem download und entpacken, die Dateien mit WinSCP oder aus dem vSphere Client auf den ESXi-Host in ein Verzeichnis hochladen, hier ist es der Pfad
/vmfs/volumes/datastore1/ghettoVCB/

ghettoVCB-ESXi-WinSCP

Als Backup Speicher wird eine Synology RackStation genutzt, dabei könnte es auch eine DiskStation oder ein QNAP NAS sein, es wird der NFS Datenspeicher gemountet dieser auf dem NAS als NFS Freigabe bereitgestellt wurde.

NFS Berechtigungen
DSM NFS Berechtigungen

Der NFS Export des NAS wird aus dem vSphere oder vCenter gemountet, hierzu geht man auf: Konfiguration – Speicher – Speicher hinzufügen.

NFS_store

Der NFS Speicher des NAS wird eingebunden.

NFS_store1

Im Feld Server wird die IP Adresse des NAS eingetragen, im Feld Ordner der absolute Pfad der NFS Freigabe, bei der Synology RackStation ist dies in der regel /volume1 gefolgt vom Name der Freigabe. Als Datenspeichername wird der Name des NAS eingetragen, dieser Name muss in der Konfigurationsdatei, ghettoVCB.conf bei VM_BACKUP_VOLUME identisch sein.

vSphereClient
vSphere NFS Datenspeicher

Der NFS Speicher wird gemountet.

Nun den crontask anhalten mit

Eine Datei anlegen mit den VMs die gesichert werden sollen.
vi /vmfs/volumes/datastore1/ghettoVCB/vms.cfg

und die VM Konfiguration für homer wo die Backup Rotation definiert wird, dies ermöglicht eine unterschiedliche Backup Rotation, wird keine Konfiguration angelegt, gelten die Werte in der ghettoVCB.conf.

vi /vmfs/volumes/datastore1/ghettoVCB/homer

crontab beschreibbar machen und Backup um 22:01 Täglich ausführen.

vi /var/spool/cron/crontabs/root

crontab wieder starten

bei ESXi5.0

Testen ob der Script tut was er soll.

cronjob persistent machen, damit nach dem nächsten Reboot wieder alles läuft.

Die Datei rc.local editieren, vi /etc/rc.local

ab ESXi 5.1 und höher wird /etc/rc.local.d/local.sh genutzt.

Die Sicherung der konfigurierten VMs wird nun zur definierten Zeit starten, dabei wird nicht die Zeit der Konsole berücksichtigt, sondern die die Zeit die im vSphere Client angezeigt wird.

VMware esxi 5.5 support for ghettovcb.sh
Fixed the script by changing

in both the backup and restore scripts.

Troubleshooting

Wird ein ERROR protokolliert liegt dies oft daran das vor der ersten Snapshot Sicherung eine Konsolidierung gemacht werden sollte.

Snapshot Konsolidieren
Snapshot Konsolidieren

Snapshot Konsolidieren aus dem vSphere oder vCenter, dies vor der ersten ghettoVCB Sicherung ausführen.

Tip!

Zur Wiederherstellung einzelner Dateien oder Verzeichnisse aus einer virtuellen Festplatte, VMDK eines Snapshots, kann 7-Zip nützlich sein, das vorgehen wird hier beschrieben.

 

ASG Remote Desktop

ASG Remote Desktop (vRD) ist ein Tool für die Administration und Verwaltung von Server und Workstations über die Sitzungsprotokolle RDP, ICA, VNC, SSH etc.cicada3

ASG Remote Desktop
ASG Remote Desktop

(vRD): visionapp Remote Desktop speichert die Einstellungen und Verbindungsinformationen von Remote-Desktop-Sitzungen unter Windows, Citrix, Unix/Linux oder Mac OS X und stellt sie in einer Ordnerstruktur dar. Die Vollversion sichert Einstellungen in eine Datenbank, auf die auch andere Benutzer zugreifen können. Die vielseitige Integrierbarkeit von ASG Remote Desktop 2012 ermöglicht die Einbindung externer Programme wie PuTTY,  WinSCP, vSphere, oder VNC und weitere mehr.