Jump to content
Sign in to follow this  
andrew

Exchange 2016: Exchange Admin Center zeigt erstelltes Zertifikat (von interner CA) als ungültig an

Recommended Posts

hello together

 

=> Installiere zurzeit einen Exchange 2016

=> habe eine AD integrierte RootCA installiert (weiter, weiter, fertigstellen) (Anpassungen wie Sperrliste usw. folgen noch)

=> habe in der Exchange Admin Center Konsole eine neue Zertifikatsanforderung erstellt

=> diese bei der RootCA eingereicht

=> via RootCA daraus das Exchange Zertifikat erstellt

=> via Exchange Admin Center die Zertifikatsanforderung abgeschlossen

=> zu dieser Zeit war der Status des Exchange Zertifikats ungültig - dachte, ok: liegt logischerweise daran, dass noch keine Dienste an das Zertifikat gebunden sind

=> Danach habe ich via Exchange Shell Enable-ExchangeCertificate -Thumbprint B2218DBFFDC4F40C66C8E50044621AA290A8F32E -Services POP,IMAP,SMTP,IIS die Dienste an das Zertifikat gebunden

=> Exchange Admin Konsole aktualisiert, Aber: das Zertifikat wird immer noch als ungültig angezeigt, hö? Verstehe ich nicht, hat Jemand eine schlaue Erklärung hierzu?

 

OWA Test schlug somit auch Fehl

=> Danach habe auf der RootCA MMC das Root Zertifikat exportiert

=> auf dem Exchange, wo ich auch gleich das OWA testen wollte, das Root Zertifikat unter den "Vertrauenswürdigen Zertifizierungsstellen" eingefügt bzw. importiert

=> OWA Seite https://exchange.domain.ch/owa (interne AD Domain lautet auf .ch) aufgerufen Und: eine weisse Seite erscheint, kein OWA, nada

Share this post


Link to post
Share on other sites

Wenn das eine AD Integrierte CA ist, sollte der Exchange die CA doch automatisch in den vertrauenswürdigen Stammzertifizierungsstellen haben. Und "weiter weiter fertigstellen" ist gerade bei CAs definitiv eine schlechte Idee. Erst Recht, wenn du danach schon Zertifikate ausstellst. Spontan würde ich sagen, der Exchange kann nicht auf die CRL zugreifen und meckert deswegen. Das sollte ggf. aber im Eventlog zu finden sein.

 

Bye

Norbert

Share this post


Link to post
Share on other sites

muss kurz ausholen: zuvor habe ich schon einmal eine Unternehmens CA (einstufige, AD integrierte) erstellt und bereits diverse Dinge angepasst wie

=> CRL (Sperrliste)

=> OCSP konfiguriert

=> OCSP Pfad im Zertifikat hinterlegt

=> die CA gesichert

=> Schlüsselarchivierung (Schlüsselwiederherstellungsagent)

=> eine Zertifikatsvorlage erstellt, welche den Schlüssel archiviert (Vorlage für zukünftige Zertifikate)

 

Danach habe ich ebenfalls wie bereits ober erwähnt, in der Exchange Admin Konsole

=> eine Zertifkatsanforderung erstellt

=> die Zertifikatsanforderung der RootCA eingereicht

=> das daraus resultierende Zertifikat auf dem Exchange Server wieder implementiert, sprich, die Zertifikatsanforderung abgeschlossen

=> Aber hierbei hatte ich das Problem, dass ich erst gar nicht versucht habe, dem Zertifikat Dienste zuzuweisen, weil dieses in der Konsole wie Du beim jetzigen Fall vermutest, auch explizit gemeldet hat, dass der Exchange nicht auf die Sperrliste zugreifen kann, was er im jetzigen Fall ja nicht sagt.

 

Weil ich zurzeit etwas im Schuss bin und keine Zeit habe, nun stundenlang nach dem Fehler zu suchen, habe ich kurzerhand die ganze AD integrierte RootCA platt gemacht und wie in der Beschreibung vorhin diese neu via "weiter, weiter, fertigstellen" eingerichtet und nun neu, nicht wie vorher, noch die ganzen CA gerechten Nacharbeiten vorgenommen, sondern direkt versucht, ein neues Exchange Zertifikat, also ein SAN Zertifikat mit drei FQDNs zu erstellen.

=> exchange.domain.ch

=> autodiscover.domain.ch

=> outlookanywhere.domain.ch

 

Das sind oder wären die drei Namen, welche ich im Zertifikat integriert habe, aber eben, die Exchange Admin Center Konsole meldet dieses Zertifkat mit dem Status ungültig Und: bitte korrigieren mich, wenn ich falsch bin, aber betrachte ich die neu erstellte RootCA, rechte Maustaste auf die RootCA, Eigenschaften, Reiter Erweitert (Sperrlisten-Verteilpunkt/ Zugriff auf Stelleninformationen > AIA), so ist unter anderem per default bereits auch ein LDAP Pfad hinterlegt, welcher dafür zuständig ist (meiner Ansicht nach), dass die Clients dann schlussendlich via diesen Pfad den Weg im AD zu der Sperrliste finden oder finden sollten (Darum meiner Ansicht nach nun jetzt keine Meldung im Exchange Admin Center, dass die Sperrliste ungültig sei oder nicht gefunden werden kann)

 

P.S. Zuvor hatte ich übrigens diesen Pfad am soeben, genannten Ort entfernt :-) > wollte testen, ob es möglich ist, wenn ich als Info nur

=> einen HTTP Pfad

=> und mit Hilfe von OSCP bzw. dessen Pfad ebenfalls auch am genannten Ort in Form einer URL hinterlege

 

Aber anscheinend ist mir da, zumindest beim ersten Mal einrichten der RootCA wohl ein Fehler unterlaufen, dass damals schon die Exchange Admin Center Konsole motzte und sagte, Sie könne nicht auf die Sperrinformationen zugreifen (oder so ähnlich lautete die Fehlermeldung)

 

Darum bin ich ja so verwundert, jetzt wo ich die RootCA neu eingerichtet habe und wirklich nur weiter, weiter, fertigstellen gemacht habe, mir die Exchange 2016 Admin Center Konsole das neu erstellte Exchange Zertifikat nicht anerkannt (Status ungültig)

Share this post


Link to post
Share on other sites

moin,

muss den obigen Board Eintrag wieder aufleben lassen, da Problem noch immer vorhanden, Situation aber nicht mehr genau gleich wie vorher:

 

Zuerst vorweg: Ja, ich habe den Eintrag von Norbert gelesen, vielen Dank Norbert für die damals gelieferten Tipps/ Ratschläge :-)

 

In der Zwischenzeit habe ich folgendes gemacht, betreffend RootCA

=> RootCA komplett von Board geworfen, neu installiert (RootCA > AD integriert)

=> RootCA: In den Eigenschaften der RootCA/ Reiter Erweiterungen:

     > Sperrlisten-Verteilungspunkt (URLs angepasst)

     > Zugriff auf Stelleninformationen angepasst

 

P.S. Habe mich hierzu auf folgenden Blog Eintrag bezogen http://asichel.de/2013/03/06/active-directory-zertifikatsdienste-ad-cs-grundkonfiguration/

Das einzige, was ich nicht so gemacht habe wie er hier im Blog beschreibt ist: Zum Abschluss der Konfiguration noch eine GPO erstellt, welche das RootCA im AD verteilt. Hierzu kann ich sagen, dass eine AD integrierte AD das RootCA ohne zu tun automatisch an die Geräte in der AD verteilt (siehe hierzu auf jedem Gerät eine MMC, Snap-In Zertifikate hinzufügen) Und: man prüfe den Punkt: Vertrauenswürdige Stammzertifizierungsstellen/ Zertifikate

 

Genau hier habe ich nach der Installation meiner RootCA auf jedem Server lokal das entsprechende RootCert vorgefunden, ohne dass ich wie der hier im Blog eine GPO erstellt hat, welche dieses Cert verteilt (nur am Rande erwähnt, hat oben auch Norbert so mir mitgeteilt, dass dies automatisch geschehen muss)

 

     > Langer Rede kurzer Sinn: die RootCA neu installiert, die Sperrliste so angepasst, dass diese auf http://crl.domain.ch/crl/ verweist.

     > sichergestellt, dass wenn ich zum Beispiel vom Exchange aus den Internet Explorer aufrufe, mich ohne Fehlermeldung auf http://crl.domain.ch/crl/ zugreifen kann, genau.

 

 

In der Zwischenzeit habe ich folgendes gemacht, betreffend Active Directory

=> via ADSI- Edit alle Exchange Einträge entfernt

 

 

In der Zwischenzeit habe ich folgendes gemacht, betreffend Exchange 2016

=> das OS, auf welchem der Exchange 2016 laufen soll, neu aufgesetzt

=> die Exchange 2016 Installation ohne Fehler installiert

 

=> eine neue Zertifikatsanforderung auf dem Exchange erstellt

=> auf der RootCA via http://localhost/certsrv die Zertifikatsanforderung eingereicht und das daraus resultierende, für den Exchange gedachte Zertifikat (SAN mit drei URLs) heruntergeladen (von der RootCA) und dem Exchange 2016 gefüttert (versucht, die noch offene Anfrage abzuschliessen)

=> genau nach diesem Schritt erscheint der Status des soeben neu eingepflanzten Cersts in der Exchange 2016 GUI (Webkonsole) folgendes: Sperrungsüberprüfung fehlgeschlagen

 

 

Betreffend: Sperrungsüberprüfung fehlgeschlagen

=> getestet, ob ich auf die CRL per Internet Explorer zugreifen kann, Antwort: Ja, das kann ich, ohne Fehlermeldung

=> certutil -verify -URLfetch D:\Speicherpfad-zum-Zertifikat\ExchangeZertifikat.cer hat unter anderem folgende Zeile(n) im Resultat enthalten

 

Fehler beim Abrufen der URL: Nicht gefunden (404). 0x80190194 (-2145844844 HTTP_E_STATUS_NOT_FOUND)
    http://crl.domain.ch/crl/Kunde-RootCA.crl

 

und hier

 

Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offli
ne war. 0x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE)
------------------------------------
Sperrungsüberprüfung übersprungen -- Server ist offline

FEHLER: Die Sperrstatusüberprüfung des untergeordneten Zertifikats hat Die Sperr
funktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war. 0
x80092013 (-2146885613 CRYPT_E_REVOCATION_OFFLINE) zurückgegeben.
CertUtil: Die Sperrfunktion konnte die Sperrung nicht überprüfen, da der Sperrserver offline war.

CertUtil: -verify-Befehl wurde erfolgreich ausgeführt.

 

Habe hier ein paar dicke Fragezeichen, warum um Gottes Willen soll denn mein Gerät, welches via installierten IIS das virtuelle Verzeichnis CRL enthält angeblich OFFLINE sein???

=> siehe hierzu ein paar Zeilen weiter oben, den Punkt: Betreffend: Sperrungsüberprüfung fehlgeschlagen

Share this post


Link to post
Share on other sites

Das einzige, was ich nicht so gemacht habe wie er hier im Blog beschreibt ist: Zum Abschluss der Konfiguration noch eine GPO erstellt, welche das RootCA im AD verteilt. Hierzu kann ich sagen, dass eine AD integrierte AD das RootCA ohne zu tun automatisch an die Geräte in der AD verteilt (siehe hierzu auf jedem Gerät eine MMC, Snap-In Zertifikate hinzufügen) Und: man prüfe den Punkt: Vertrauenswürdige Stammzertifizierungsstellen/ Zertifikate

Ja, aber zwei Anmerkungen dazu. 1. Kann man auch einer AD integrierten CA das kopieren des Root-Certs in den Domain Head abgewöhnen und 2. bei der Verteilung per GPO hat man ein paar mehr Optionen, damit bspw. Extended Validation funktioniert, muß man dem Rootzert noch ein paar mehr Optionen mitgeben. Und das geht per GPO sehr einfach.

 

> Langer Rede kurzer Sinn: die RootCA neu installiert, die Sperrliste so angepasst, dass diese auf http://crl.domain.ch/crl/ verweist.

     > sichergestellt, dass wenn ich zum Beispiel vom Exchange aus den Internet Explorer aufrufe, mich ohne Fehlermeldung auf http://crl.domain.ch/crl/ zugreifen kann, genau.

Du bist mit deinem IE aber nicht der Exchange.

 

 

 

In der Zwischenzeit habe ich folgendes gemacht, betreffend Active Directory

=> via ADSI- Edit alle Exchange Einträge entfernt

Wozu das? Und gleich die nächste Frage, ist das ein produktives System, oder reden wir hier von einer Testumgebung?

 

=> genau nach diesem Schritt erscheint der Status des soeben neu eingepflanzten Cersts in der Exchange 2016 GUI (Webkonsole) folgendes: Sperrungsüberprüfung fehlgeschlagen

Eigentlich doch aussagekräftig, oder? ;)

 

Habe hier ein paar dicke Fragezeichen, warum um Gottes Willen soll denn mein Gerät, welches via installierten IIS das virtuelle Verzeichnis CRL enthält angeblich OFFLINE sein???

=> siehe hierzu ein paar Zeilen weiter oben, den Punkt: Betreffend: Sperrungsüberprüfung fehlgeschlagen

WAs sollen sie denn sonst so hinschreiben? Ihre CRL ist nicht erreichbar, weil ihr Server offline ist, oder sie ihn nicht erreichen können, oder vielleicht weil sie kein Kabel reingestöpselt haben? ;)

Also wenn das alles nicht funktioniert, dann nimm halt fiddler oder wireshark und schneide den Part mit, wenn der Exchange das Zertifikat überprüfen will. Da sollte dann relativ klar erkennbar sein, was das Problem ist.

 

Bye

Norbert

Share this post


Link to post
Share on other sites

moin together

 

Danke Norbert für die Inputs. Habe die Lösung gefunden, anbei aber zuerst noch eine Frage in Bezug GPO für Zertifikatsdienste

 

Ja, aber zwei Anmerkungen dazu. 1. Kann man auch einer AD integrierten CA das kopieren des Root-Certs in den Domain Head abgewöhnen und 2. bei der Verteilung per GPO hat man ein paar mehr Optionen, damit bspw. Extended Validation funktioniert, muß man dem Rootzert noch ein paar mehr Optionen mitgeben. Und das geht per GPO sehr einfach.

 

Wie ich oben erwähnt hatte, habe ich mich beim Einrichten der RootCA (AD integriert) auf folgenden Blog Artikel hier gestützt: http://asichel.de/2013/03/06/active-directory-zertifikatsdienste-ad-cs-grundkonfiguration/

Dieser erwähnt auch unter Schritt 5 - Gruppenrichtlinie, dass eine GPO auf Domain Ebene verknüpft werden soll und zwei Punkte angepasst werden sollen

=> Zertifikatsclient - automatische Registrierung

=> Einstellungen der automatischen Zertifikatsanforderungen

 

Das Problem, welches ich hier habe ist:

=> Verbinde mich per RDP auf den Exchange 2016 via EMC (GUI)

=> rufe Punkt Server/ Zertifikate auf

=> nachdem ich die oben erwähnte GPO auf dem AD Server erstellt hatte, das GPO Objekt auf Domain Ebene verknüpft wurde Und: auf dem Exchange ein gpupdate/ force aufgerufen wird, passiert folgendes (wegen dieser GPO):

     der Exchange listet gleich ein neues, weiteres Cert auf, welches auf seinen eigenen Namen lautet > Exchange.domain.ch Und: dieses Cert hat keinen Anzeigenamen und dem wurden auch keine Dienste zugewiesen, somit ist das für mich eher störend, da dieses ohne zugewiesene Dienste eh nicht funktionsfähig ist. Daher habe ich ein WMI Filter erstellt, welcher bewirkt, dass die GPO auf alle Computer Objekte angewendet wird ausser auf den Exchange und mir somit NICHT automatisch ein Cert auf dem Exchange installiert wird, welches auf Ihn selber lautet.

 

 

Wozu das? Und gleich die nächste Frage, ist das ein produktives System, oder reden wir hier von einer Testumgebung?

 

Nachdem ich das OS neu installiert hatte, danach obendrauf den Exchange 2016 neu installierte, hatte ich zuvor selbstverständlich mit dem ADSI-Edit Tool den Exchange 2016 komplett aus dem AD gekickt. Grund: Dies, damit beim neu installieren des Exchange 2016 keine Fehlermeldungen erscheinen. Wie ich weiter unten in diesem Beitrag hier gleich meine Lösung erklären werde, lag es schlussendlich nicht am Exchange bzw. an dessen Installation, daher war dieser Schritt (Exchange neu aufsetzen) völlig überflüssig gewesen (im nachhinein ist man immer schlauer)

 

Die Umgebung wird eine produktive Umgebung, welche ich zurzeit am Aufsetzen bin - also keine Test Umgebung.

 

Das Problem war folgendes bzw. die Lösung lautet:

1. Auf dem Server, welcher die RootCA beherbergt, war unter dem Punkt Sperrlisten-Verteilungspunkt mir der Fehler unterlaufen, dass auf einen UNC Pfad verwiesen habe und am Schluss das .crl vergessen hatte, hinten anzuhängen

    Sieht nun korrekt so aus \\crl.domain.ch\<crl$\CaName><CRLNameSuffix><DeltaCRLAllowed>.crl << (dieses .crl hatte ich vergessen)

2. Weil ich beim Punkt 1 für diesen UNC Pfad hinterlegt habe

   > Sperrlisten an diesem Ort veröffentlichen

   > Deltasperrlisten an diesem Ort veröffentlichen

   Wurden zwar die Sperrliste von der RootCA vom Ordnerpfad C:\Windows\System32\certsrv\CertEnroll korrekt in die Freigabe (auf einem anderen virtuellen Server) \\crl.domain.ch\crl$ kopiert, jedoch hatten die kopierten Dateien nicht die Endung .crl, was natürlich beim Überprüfen der Sperrlisten zu einem sehr logischen Fehler führt, die CA sei Offline :-)

 

 

WAs sollen sie denn sonst so hinschreiben? Ihre CRL ist nicht erreichbar, weil ihr Server offline ist, oder sie ihn nicht erreichen können, oder vielleicht weil sie kein Kabel reingestöpselt haben? ;)
Also wenn das alles nicht funktioniert, dann nimm halt fiddler oder wireshark und schneide den Part mit, wenn der Exchange das Zertifikat überprüfen will. Da sollte dann relativ klar erkennbar sein, was das Problem ist

 

Wie wäre es, wenn beim Überprüfen mit certutil -verify -URLfetch D:\Speicherpfad-zum-Zertifikat\ExchangeZertifikat.cer beispielsweise eine Fehlermeldung erschienen wäre mit dem Inhalt: falscher Dateityp? kurz, prägnant Und: vor allem Aussagekräftig!  (mit der heutigen Programmiertechnik wäre dies absolut kein Problem, das Certutil Tool dazu zu bringen, eine schlauere Fehlermeldung auszuspucken :-)

 

Nun funktioniert die CRL Überprüfung, super Sache :-)

Share this post


Link to post
Share on other sites
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...