#RZK77167
Authentisierungfehler beim Verbindungsaufbau zum Kommunikationsserver
https://w2008fs:58452/datev/framework/idp/onpremise/.well-known/openid-configuration:
Das Remotezertifikat ist laut Validierungsverfahren ungültig.
Hintergrund: der Kommunikationsserver wurde beim Upgrade auf Windows Server 2012 in "w2012fs" umbenannt. Der alte Name blieb im DNS als Alias erhalten, somit funktionierte das ganze. Jetzt lief das Zertifikat aus und wurde mit CN "w2012fs" erneuert. Damit kann aber auf den Kommunikationsserver nicht mehr mit "https://w2008fs:58452/..." zugegriffen werden.
Wo konfiguriere ich den Hostnamen für den Zugriff auf den Kommunikationsserver, um dort den alten Namen "w2008fs" zu ersetzen?
Danke schon mal
Lars
Gelöst! Gehe zu Lösung.
@_lars_ schrieb:
Hintergrund: der Kommunikationsserver wurde beim Upgrade auf Windows Server 2012 in "w2012fs" umbenannt.
Das mag DATEV überhaupt gar nicht und wenn man es tut, braucht man eher ein Tool dazu, weil DATEV den Servernamen überall "hart" hinterlegt und der auch etliche Male in der Registry auftaucht.
@_lars_ schrieb:
Wo konfiguriere ich den Hostnamen für den Zugriff auf den Kommunikationsserver, um dort den alten Namen "w2008fs" zu ersetzen?
Bin skeptisch, ob das überhaupt geht oder wenn man es an dieser 1 Stelle ändern kann, man gleich ins nächste Fettnäpfchen tritt und ins nächste ... Der Serverumzugsassistent kann Server umbenennen. Das Tool kann aber auch auf die Nase fallen. Am Servernamen macht DATEV auch etliche Druckkomponenten fest und eine Vorschau oder drucken allgemein kann dann auch auf die Nase fallen.
Daher entweder den Server wieder so benennen, wie er mit DATEV installiert wurde oder, wenn's wirklich "nur" ein Kommunikationsserver ist: VM neu aufsetzen und dann kann man alles so benennen wie man möchte.
Leider hab ich das nicht gemacht, sondern die Installation nur übernommen. Ist eine normale Standard-Installation mit zwei Servern:
1) AD + DB + Komm usw.
2) WTS
Vermutlich wurde die Umbennung mit dem Assistenten gemacht und der hat das vergessen? Wenn ich dem 'hostconf'-Tool einfach einen "Subject Alternative Name" für's Zertifikat mitgeben könnte, würde das mein Problem vermutlich schon lösen.
@_lars_ schrieb:
Vermutlich wurde die Umbennung mit dem Assistenten gemacht und das hat er vergessen?
Weiß ich nicht. Ist aber auch nicht mit 2 Klicks durch: Server umziehen mit Server-Anpassungs-Assistent 2.1
@_lars_ schrieb:
Wenn ich dem 'hostconf'-Tool einfach einen "Subject Alternative Name" für's Zertifikat mitgeben könnte, würde das mein Problem vermutlich schon lösen.
Kann funktionieren aber zu 100% sauber ist das dann immer noch nicht und ist keine DATEV Standardvorgabe. Möglich, dass es in Zukunft dann noch mehr Probleme im Betrieb oder beim Update gibt.
Ich würde mal in der Registry nach dem alten Servernamen suchen. Taucht der in DATEV Zweigen noch etliche Mal auf, stimmt da was nicht. Gut, eine Neuinstallation ist mit einem "AiO" dann leider nicht so einfach möglich, wie es anders der Fall wäre.
Der DATEV SQL Server läuft aber? Auch nach dem Umbenennen des Servers? Würde mich auch wundern. Und den AD-Server hat man auch umbenannt? Was ist denn genau passiert? Migration von A nach B und B heißt anders als vorher aber man hat DATEV einfach so umgezogen? Geht auch, wenn man CONFIGDB dann weglässt und den WTS dann mit DATEV neu installiert.
Wir brauchen definitiv mehr Informationen, was genau getan wurde.
Das ganze lief jetzt über mindestens zwei Jahre so. Wie gesagt, ich habe das Windows-Upgrade nicht gemacht, das ist schon ziemlich lange her. Das Zertifikat muß am Freitag oder gestern abgelaufen sein. Wenn ich mir das neue anschaue, ist das für Zehn Jahre ausgestellt. Das war dann wohl beim alten ähnlich...
Ich hab mich jetzt mal durch die logs gewühlt und fand in dem vom DFÜ-Funktionstest das:
Name des Komm.-Servers: W2012FS (aus XML-Datei ermittelt)
Danach durch alle '*.xml' im DATEV-Verzeichnis nach "w2008fs" gegrept und voilà:
d:\WINDVSW1\DATEV\DATEN\RZKOMM\DATA\STANDARD\WebserviceKommunikation.xml
Darin den Hostnamen angepaßt (und aus Unwissenheit, ob und welche Dienste man hätte neu starten müssen, den ganzen Server rebootet) und es läuft wieder.
Das es nur das Zertifikat des Kommunikationsservers betraf, erwarte ich kein weiteres Problem.