3
Exchange 2010: der Zertifikatstatus konnte nicht ermittelt werden
Hallo Community,
Ich habe einen Exchange 2010 der mir nach dem Einspielen eines Zertifikates, von Letsencrypt, folgenden Fehler in der EMC wiedergibt.
Der Zertifikatstatus konnte nicht ermittelt werden, da die Sperrungsüberprüfung keinen Erfolg hatte.
Umgebung:
Windows 2008 R2, Exchange 2010
Direkter Internet Zugang Firewall PFsense
Der Ansatz hat mich leider nicht weitergebracht.
Auch das Einspielen nur über die Powershell gab das gleiche zurück.
Hintergrund:
Ich habe vor ca knapp 90 Tagen ein Zertifikat mit dieser Anleitungeingespielt.
Da das jetzige abläuft wollte ich das neue Einspielen.
Hat einer eine Idee?
Danke für Eure Antworten.
Gruß jenni
Ich habe einen Exchange 2010 der mir nach dem Einspielen eines Zertifikates, von Letsencrypt, folgenden Fehler in der EMC wiedergibt.
Der Zertifikatstatus konnte nicht ermittelt werden, da die Sperrungsüberprüfung keinen Erfolg hatte.
Umgebung:
Windows 2008 R2, Exchange 2010
Direkter Internet Zugang Firewall PFsense
Der Ansatz hat mich leider nicht weitergebracht.
Auch das Einspielen nur über die Powershell gab das gleiche zurück.
Hintergrund:
Ich habe vor ca knapp 90 Tagen ein Zertifikat mit dieser Anleitungeingespielt.
Da das jetzige abläuft wollte ich das neue Einspielen.
Hat einer eine Idee?
Danke für Eure Antworten.
Gruß jenni
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 304870
Url: https://administrator.de/forum/exchange-2010-der-zertifikatstatus-konnte-nicht-ermittelt-werden-304870.html
Ausgedruckt am: 31.12.2024 um 04:12 Uhr
3 Kommentare
Neuester Kommentar
Below are the steps recommended by Microsoft to resolve this issue:
To view the WinHTTP proxy settings, at a command prompt, run the following command:
netsh winhttp show proxy
To resolve this issue, you must configure the WinHTTP proxy setting and the server FQDN in the WinHTTP bypass list.
Note If you do not configure both the proxy setting and the server FQDN in the WinHTTP bypass list, the Exchange Management Shell and the Exchange Management Console cannot contact the Remote PowerShell.
To resolve this issue, open a command prompt, type the following command, and then press ENTER:
netsh winhttp set proxy proxy-server="http=myproxy" bypass-list="*.host_name.com"
The myproxy placeholder represents the proxy server name, and host_name represents the Exchange Server 2010 host name.
If the proxy settings are correct, and it still doesn't work, try the following commands to clear the OCSP/CRL cache:
certutil -urlcache ocsp delete
certutil -urlcache crl delete
Reboot the server if required.
Die Schalter
certutil -urlcache ocsp delete
certutil -urlcache crl delete
brachten leider auch keine Abhilfe.
Jemand eine Idee
To view the WinHTTP proxy settings, at a command prompt, run the following command:
netsh winhttp show proxy
To resolve this issue, you must configure the WinHTTP proxy setting and the server FQDN in the WinHTTP bypass list.
Note If you do not configure both the proxy setting and the server FQDN in the WinHTTP bypass list, the Exchange Management Shell and the Exchange Management Console cannot contact the Remote PowerShell.
To resolve this issue, open a command prompt, type the following command, and then press ENTER:
netsh winhttp set proxy proxy-server="http=myproxy" bypass-list="*.host_name.com"
The myproxy placeholder represents the proxy server name, and host_name represents the Exchange Server 2010 host name.
If the proxy settings are correct, and it still doesn't work, try the following commands to clear the OCSP/CRL cache:
certutil -urlcache ocsp delete
certutil -urlcache crl delete
Reboot the server if required.
Die Schalter
certutil -urlcache ocsp delete
certutil -urlcache crl delete
brachten leider auch keine Abhilfe.
Jemand eine Idee
Hier die Lösung:
After spending most of the day on this exact same issue I hope I will make most of you very happy as I think I have found the solution..
As with everyone else, the X1 certificate was nowhere to be found yet IIS managed to serve it in the chain.
After a lot of head banging I finally found the one place no one had looked before. The user certificate store for the Local System account. That's right - there is such a thing and it is not the same as the computer store.
To get to it, you need to download PsTools from SysInternals61 and run psexec -i -s mmc.exe, go to File -> Add-Remove Snap-in, choose Certificates and My user account. Now go into Intermediate Certificate Authorities and you should find that elusive X1 certificate hiding there.
It might be enough to remove the X1 and then restart IIS, but I ended up adding X3 certificate here just to be sure (right click on the certificate list - click All Tasks -> Import and choose the X3 file).
After this you need to "touch" the bindings in IIS (for example, change the certificate and then back again or delete/add the binding) and after IIS is then restarted it will finally start to serve the correct chain.
https://community.letsencrypt.org/t/iis-8-5-building-incorrect-chain-wit ...
After spending most of the day on this exact same issue I hope I will make most of you very happy as I think I have found the solution..
As with everyone else, the X1 certificate was nowhere to be found yet IIS managed to serve it in the chain.
After a lot of head banging I finally found the one place no one had looked before. The user certificate store for the Local System account. That's right - there is such a thing and it is not the same as the computer store.
To get to it, you need to download PsTools from SysInternals61 and run psexec -i -s mmc.exe, go to File -> Add-Remove Snap-in, choose Certificates and My user account. Now go into Intermediate Certificate Authorities and you should find that elusive X1 certificate hiding there.
It might be enough to remove the X1 and then restart IIS, but I ended up adding X3 certificate here just to be sure (right click on the certificate list - click All Tasks -> Import and choose the X3 file).
After this you need to "touch" the bindings in IIS (for example, change the certificate and then back again or delete/add the binding) and after IIS is then restarted it will finally start to serve the correct chain.
https://community.letsencrypt.org/t/iis-8-5-building-incorrect-chain-wit ...
Danke, damit hat es geklappt.
Wichtig sind die Bindings und der restart des IIS
Wichtig sind die Bindings und der restart des IIS
