none
SSL Zertifikat im 2016 ändern RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Nachdem ich das Zertifikat im 2016 geändert hatte, konnte ich weder beim ECP noch beim OWA einloggen. Der blitzte nur kurz auf mit irgendwas und war dann wieder draussen... Daher habe ich das Zeug zurückgestellt (war gar nicht mal so einfach) und im IIS hab ich dann manuell den Mist noch zurückgebaut... jetzt aber meine Frage: Wie kann ich das SSL Zertifikat ändern? Auf was muss ich achten, damit es geht? Stimmt der Mythos, dass man nur SHA-1 Zertifikate nutzen darf und kein SHA-2 oder höher bei der Erstellung verwendet werden darf? Oder muss ich drauf achten, dass im IIS alle Teile vom Exchange das gleiche Zertifikat verwenden (also auch dieses komische Back-End oder wie das heisst?) oder... worauf kommt's wirklich an?

    [und noch inoffiziell: wer baut eigentlich solche Menüs, die es erlauben, dass der Exchange sich selber zusammenschiesst??]

    Rudolf

    Mittwoch, 18. Mai 2016 18:49
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    das mit SHA-1-Zertifikaten stimmt natürlich nicht. Was allerdings zutrifft, ist, dass der Login Cookie zwischen OWA FBA und anderen Teilen von OWA/ECP nur die herkömmliche RSA-Kryptographie und nicht den Next Generation Crypto Provider verwenden kann. Daher muss man entweder bei der Ausstellung des Zertifikates aufpassen oder bei der Importierung explizit den Provider angeben: 

    certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx <Certificate File Name>

    Gruß

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert Rudolf Meier Donnerstag, 19. Mai 2016 09:58
    Mittwoch, 18. Mai 2016 18:59
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    das mit SHA-1-Zertifikaten stimmt natürlich nicht. Was allerdings zutrifft, ist, dass der Login Cookie zwischen OWA FBA und anderen Teilen von OWA/ECP nur die herkömmliche RSA-Kryptographie und nicht den Next Generation Crypto Provider verwenden kann. Daher muss man entweder bei der Ausstellung des Zertifikates aufpassen oder bei der Importierung explizit den Provider angeben: 

    certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx <Certificate File Name>

    Gruß

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert Rudolf Meier Donnerstag, 19. Mai 2016 09:58
    Mittwoch, 18. Mai 2016 18:59
    |
  • Question
    Anmelden
    0
    Anmelden
    :-) na super... die CA hab ich selber geschrieben. Aber ich hab die doch rein auf CNG aufgebaut... ich probier's später aus und melde das Resultat dann.
    Mittwoch, 18. Mai 2016 21:00
    |
  • Question
    Anmelden
    0
    Anmelden

    Ja, das hat geholfen... ich hab den CSR mit dem Exchange-Tool gebaut (ich wollte meinen CSR Generator nicht auf das alte Format umbauen :-) ) und der baut den Key offenbar im alten Format, womit er dann umgehen kann...

    Ich frage mich manchmal, wie man da draufkommen soll? ... aber gut, danke für den Tipp.

    Rudolf

    Donnerstag, 19. Mai 2016 09:58
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich frage mich manchmal, wie man da draufkommen soll? ... aber gut, danke für den Tipp.

    Ich persönlich frage mich eher, warum man sich irgendwas selbst baut, obwohl das Produkt alles korrekt und funktionierend mitbringt.

    Wobei man sich das theoretisch sogar selbst bauen kann, wenn man weiß, wie.

    Daher noch mal grundsätzlich für andere, die über den Thread stolperen:

    Grundsätzlich Zertifikate immer mit den Exchange Werkzeugen verwalten. Nur mit anderen Werkzeugen, wenn man genau weiß, was man tut und im IIS grundsätzlich keine Einstellungen manuell vornehmen. Die Einstellungen müssen von Exchange aus gesetzt werden, teilweise werden manuelle Änderungen im IIS sonst sogar von Exchange wieder zurückgeändert.

    Und niemals am Zertifikat für die "Backend"-Site irgendwas ändern - sonst zerlegt man sich die Webservices inkl. der Bedienung von Exchange. Um das Backend kümmert sich Exchange ganz alleine.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 19. Mai 2016 13:35
    |
  • Question
    Anmelden
    0
    Anmelden

    Ja richtig. Allerdings habe ich schon mal eine Novell-CA erlebt, die die CSP-Einstellungen im CSR einfach ignoriert und das als CNG rausgereicht hat...

    Ansonsten: 100% ACK!

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 19. Mai 2016 14:02
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich frage mich manchmal, wie man da draufkommen soll? ... aber gut, danke für den Tipp.

    Ich persönlich frage mich eher, warum man sich irgendwas selbst baut, obwohl das Produkt alles korrekt und funktionierend mitbringt.

    Wobei man sich das theoretisch sogar selbst bauen kann, wenn man weiß, wie.

    Daher noch mal grundsätzlich für andere, die über den Thread stolperen:

    Grundsätzlich Zertifikate immer mit den Exchange Werkzeugen verwalten. Nur mit anderen Werkzeugen, wenn man genau weiß, was man tut und im IIS grundsätzlich keine Einstellungen manuell vornehmen. Die Einstellungen müssen von Exchange aus gesetzt werden, teilweise werden manuelle Änderungen im IIS sonst sogar von Exchange wieder zurückgeändert.

    Und niemals am Zertifikat für die "Backend"-Site irgendwas ändern - sonst zerlegt man sich die Webservices inkl. der Bedienung von Exchange. Um das Backend kümmert sich Exchange ganz alleine.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Dazu noch 2 Punkte. Das Backend-Zertifikat hatte ich gar nicht geändert. Wieso das auf was anderem stand ist mir ein Rätsel. Und das mit der CA... wenn jeder so denken würde (also "gibt's schon, muss ich nicht selber bauen"), dann gäbe es die welche es gibt auch nicht. Das mal der erste Punkt und der zweite: Ich habe ganz spezielle Anforderungen an meine CA und die Zertifikate und habe mir die daher selber programmieren müssen. Ausserdem vertreiben wir diese jetzt auch als Produkt. ... und dann ist doch logisch, dass ich den CSR meiner CA verwende und nicht den vom Exchange. Weil einem ja auch keiner sagt, dass man aufpassen muss... und dass heute etwas nicht mit CNG arbeiten kann, das ist etwas unlogisch für mich. Aber... es ist einfacher geworden im Exchange-Menü. Das stimmt schon... früher war's sau kompliziert, ein Zertifika für den Exchange anzufordern.

    Rudolf

    Freitag, 20. Mai 2016 11:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 20.05.2016 schrieb Rudolf Meier:

    Das stimmt schon... früher war's sau kompliziert, ein Zertifika für den Exchange anzufordern.

    Das ist ja eher subjektiv. ;)

    Bye
    Norbert

    Freitag, 20. Mai 2016 14:17
    |