SSL-Zertifikat - Teilweise probleme
Hallo Zusammen,
ich habe einen Exchange Server mit Domain Controller (AD).
Der Exchange Server läuft auf der Domain server.domain.tld
Für diese Domain habe ich ein SSL Zertifikat bestellt und eingebunden. Im Webaccess klappt alles hervorragend.
Im Outlook verbindet er sich mit servername.server.domain.tld und meldet das das Zertifikat nicht korrekt ist.
Wie kann ich dieses Problem lösen, dass der Server auf server.domain.tld hört, wie es auch im Zertifikat steht?
ich habe einen Exchange Server mit Domain Controller (AD).
Der Exchange Server läuft auf der Domain server.domain.tld
Für diese Domain habe ich ein SSL Zertifikat bestellt und eingebunden. Im Webaccess klappt alles hervorragend.
Im Outlook verbindet er sich mit servername.server.domain.tld und meldet das das Zertifikat nicht korrekt ist.
Wie kann ich dieses Problem lösen, dass der Server auf server.domain.tld hört, wie es auch im Zertifikat steht?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 244185
Url: https://administrator.de/forum/ssl-zertifikat-teilweise-probleme-244185.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
3 Kommentare
Neuester Kommentar
Wie Thomas schon schrieb benötigst du SAN Zertifikate oder auch "multidomain" genannten Zertifikaten.
Dabei kommt es darauf an, welche Version von Exchange du laufen hast und auch ,was für ne Server Edition, also ob Enterprise oder Standard usw. Hier wird dies gut erklärt: http://www.msxfaq.de/signcrypt/privatca.htm
Ich geh jetzt davon aus das du die Zertifikatsdienste und auch die Zertifikatsdienste-Webregistrierungs Rollen/Features installiert hast und ne Standard AD integrierte Stamm CA hast. (Servermanger / Startseite der Rollen)
Hatte gerade das gleiche Problem mit SBS 2008+Exchange 2007 und bei einem anderen Kunden mit einem SBS 2011 + Exchange 2010.
Bei Exchange 2007 mit einem Standard Server geht nur der Weg über die Exchange-Powershell. Zudem wird das Zertifikat nur für ein Jahr ausgestellt. Versucht man den Weg über ein Template und die mmc Zertifizierungsstelle, werden die requests nicht angenommen.
Mit einem Enterprise Server und ner AD Stamm CA kann man auch die Zertifikattemplates verwenden und dann auch für Jahre bis zur Rente + 5 ausstellen. Aber Importieren sollte man nur über die ExchangeManagment-Shell machen und nicht über die GUI, den Dienste zuweisen auch.
Hier: http://www.msxfaq.de/howto/e2k7ssl.htm unter Kurzfassung und zur Verdeutlichung.
Und hier zum Thema SAN´s allgemein: http://www.msxfaq.de/signcrypt/sancert.htm
allerdings habe ich nicht die Syntax übernehmen können so wie sie bei msxfaq angegeben ist.
Mein Weg ist/war:
Set-Content -path "C:\certnew.req" -Value (New-ExchangeCertificate -GenerateRequest -KeySize 2048
-SubjectName "c=DE, o=firmenname, cn=remote.domäne.de" -DomainName remote.domäne.de, SERVERNAME.domäne.local, SERVERNAME, domäne.dyndns.org, owa.domäne.de,
autodiscover.domäne.de -PrivateKeyExportable $True)
nach dem erstellen des Zertifikat-Requests über die Zertifikats-Webregistrierung Https://servername/certsrv das Zertifikat erstellen und runterladen.
Dann der Import wieder über die exchange managment shell, adminrechte nicht vergessen,:
Import-ExchangeCertificate -Path C:\certnew.cer
An der Stelle den Thumbprint des Zertifikats aufheben weil du den gleich brauchen wirst.
Get-ExchangeCertificate | fl
zeig dir alle Zertifikate an und auch die dazugehörigen Thumbprints
Und am wichtigsten zum Schluss das zuweisen zu den Diensten:
Enable-ExchangeCertificate -Thumbprint XYZ1234567890KJI UIUUN56HHGH -Services IIS,POP,IMAP,UM,SMTP
Dabei aufpassen welchen Diensten du es zuweist. Hast du z.b. Unified Messeging nicht installiert bzw aktiv bekommst du eine Fehlermeldung. Daher rausnehmen was du an Diensten nicht brauchst. Ich brauchte den UM z.b. nicht.
Aus Sicherheitsgründen würde ich die Zertifikats-Webregistrierung Rolle/Feature nach der Aktion deinstallieren. Eine potentielle Sicherheitslücke weniger.
Mit Exchange 2010 gibt es wie erwähnt den Assistenten der dich bequem zum SAN Zertifikat führt. Solltest du die Shell zum importieren und zuweisen der Dienste verwenden, darauf achten das der Importbefehl für Exchange 2010 so ausgeführt wird : Zitat msxfaq:
"In Exchange 2010 funktioniert das so nicht mehr. Statt dessen hilft folgende komplizierterer Aufruf
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\cert.crt -Encoding byte -ReadCount 0))"
Den Diensten zuweisen wie bei 2007 auch: Enable-ExchangeCertificate -Thumbprint XYZ1234567890KJI UIUUN56HHGH -Services IIS,POP,IMAP,UM,SMTP
Exchange 2013 geht Vollständig über Assistenten und die GUI und funktioniert auch Habs gleich mit überprüft.
Beim Einfügen in die Shell auf falsche Formatierung achten , wie Zeilenumbrüche u.ä
Zum Thema PKI, Zertifikate und Zertifizierungsstellen gibt es noch viel mehr zu wissen und auch ne menge was man falsch machen und auch ganz sicher zig weiter Möglichkeiten die Aufgabe zu lösen, kann aber das würde den Rahmen hier sprengen.
Wenn man z.B. bloß für einen Client, eine Testumgebung oder auch just for fun ein Zertifikat braucht, kann man auch mit Tools wie makecert.exe sich mal, eben eins "selbstsigniertes Zertifikat" erstellen und dies stumpf in den Speicher für vertrauenswürdige Zertifikate installieren. Dann sind die Fehlermeldungen auch weg. Aber dies würde ich nicht empfehlen.
Mit Gruß
TomTest
Dabei kommt es darauf an, welche Version von Exchange du laufen hast und auch ,was für ne Server Edition, also ob Enterprise oder Standard usw. Hier wird dies gut erklärt: http://www.msxfaq.de/signcrypt/privatca.htm
Ich geh jetzt davon aus das du die Zertifikatsdienste und auch die Zertifikatsdienste-Webregistrierungs Rollen/Features installiert hast und ne Standard AD integrierte Stamm CA hast. (Servermanger / Startseite der Rollen)
Hatte gerade das gleiche Problem mit SBS 2008+Exchange 2007 und bei einem anderen Kunden mit einem SBS 2011 + Exchange 2010.
Bei Exchange 2007 mit einem Standard Server geht nur der Weg über die Exchange-Powershell. Zudem wird das Zertifikat nur für ein Jahr ausgestellt. Versucht man den Weg über ein Template und die mmc Zertifizierungsstelle, werden die requests nicht angenommen.
Mit einem Enterprise Server und ner AD Stamm CA kann man auch die Zertifikattemplates verwenden und dann auch für Jahre bis zur Rente + 5 ausstellen. Aber Importieren sollte man nur über die ExchangeManagment-Shell machen und nicht über die GUI, den Dienste zuweisen auch.
Hier: http://www.msxfaq.de/howto/e2k7ssl.htm unter Kurzfassung und zur Verdeutlichung.
Und hier zum Thema SAN´s allgemein: http://www.msxfaq.de/signcrypt/sancert.htm
allerdings habe ich nicht die Syntax übernehmen können so wie sie bei msxfaq angegeben ist.
Mein Weg ist/war:
Set-Content -path "C:\certnew.req" -Value (New-ExchangeCertificate -GenerateRequest -KeySize 2048
-SubjectName "c=DE, o=firmenname, cn=remote.domäne.de" -DomainName remote.domäne.de, SERVERNAME.domäne.local, SERVERNAME, domäne.dyndns.org, owa.domäne.de,
autodiscover.domäne.de -PrivateKeyExportable $True)
nach dem erstellen des Zertifikat-Requests über die Zertifikats-Webregistrierung Https://servername/certsrv das Zertifikat erstellen und runterladen.
Dann der Import wieder über die exchange managment shell, adminrechte nicht vergessen,:
Import-ExchangeCertificate -Path C:\certnew.cer
An der Stelle den Thumbprint des Zertifikats aufheben weil du den gleich brauchen wirst.
Get-ExchangeCertificate | fl
zeig dir alle Zertifikate an und auch die dazugehörigen Thumbprints
Und am wichtigsten zum Schluss das zuweisen zu den Diensten:
Enable-ExchangeCertificate -Thumbprint XYZ1234567890KJI UIUUN56HHGH -Services IIS,POP,IMAP,UM,SMTP
Dabei aufpassen welchen Diensten du es zuweist. Hast du z.b. Unified Messeging nicht installiert bzw aktiv bekommst du eine Fehlermeldung. Daher rausnehmen was du an Diensten nicht brauchst. Ich brauchte den UM z.b. nicht.
Aus Sicherheitsgründen würde ich die Zertifikats-Webregistrierung Rolle/Feature nach der Aktion deinstallieren. Eine potentielle Sicherheitslücke weniger.
Mit Exchange 2010 gibt es wie erwähnt den Assistenten der dich bequem zum SAN Zertifikat führt. Solltest du die Shell zum importieren und zuweisen der Dienste verwenden, darauf achten das der Importbefehl für Exchange 2010 so ausgeführt wird : Zitat msxfaq:
"In Exchange 2010 funktioniert das so nicht mehr. Statt dessen hilft folgende komplizierterer Aufruf
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\cert.crt -Encoding byte -ReadCount 0))"
Den Diensten zuweisen wie bei 2007 auch: Enable-ExchangeCertificate -Thumbprint XYZ1234567890KJI UIUUN56HHGH -Services IIS,POP,IMAP,UM,SMTP
Exchange 2013 geht Vollständig über Assistenten und die GUI und funktioniert auch Habs gleich mit überprüft.
Beim Einfügen in die Shell auf falsche Formatierung achten , wie Zeilenumbrüche u.ä
Zum Thema PKI, Zertifikate und Zertifizierungsstellen gibt es noch viel mehr zu wissen und auch ne menge was man falsch machen und auch ganz sicher zig weiter Möglichkeiten die Aufgabe zu lösen, kann aber das würde den Rahmen hier sprengen.
Wenn man z.B. bloß für einen Client, eine Testumgebung oder auch just for fun ein Zertifikat braucht, kann man auch mit Tools wie makecert.exe sich mal, eben eins "selbstsigniertes Zertifikat" erstellen und dies stumpf in den Speicher für vertrauenswürdige Zertifikate installieren. Dann sind die Fehlermeldungen auch weg. Aber dies würde ich nicht empfehlen.
Mit Gruß
TomTest
Guten Morgen.
Lösung ohne neues Zertifikat:
Wenn owa ohne Zertifikatsfehler klappt dann hört der Server schon richtig. Stelle im Exchange external und internal urls auf die owa Adresse.
Damit du dann auch mit autodiscover keine Probleme bekommst informiere dich über die autodiscover Redirect Methode.
Gruß
Andi
Vom iPhone geschrieben
Lösung ohne neues Zertifikat:
Wenn owa ohne Zertifikatsfehler klappt dann hört der Server schon richtig. Stelle im Exchange external und internal urls auf die owa Adresse.
Damit du dann auch mit autodiscover keine Probleme bekommst informiere dich über die autodiscover Redirect Methode.
Gruß
Andi
Vom iPhone geschrieben