• Bewerte uns auf OMR Reviews: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

AS4 Marktkommunikation: (3) Ihr Marktpartner-Konto hinzufügen

wewert

Member
Bzw:
Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

da "5: Geben Sie unter Routing den externen Endpunkt für die AS4-Kommunikation sowie den internen Empfänger ein"
Diesen Endpunkt muss doch der NoSpamProxy-Server selber bereitstellen! oder? Woraus ergibt sich dann die URI-Adresse, speziell der Pfad am Schluss? Oder wird gar kein Pfad benötigt?
Vielen Dank
 
Guten Morgen @wewert ,

Stefans Aussage ist ggf. nicht ganz eindeutig.
In das Eingabefeld muss der Wert rein der am ende in deinem TLS Zertifikat drin steht.

Bei direkter Kommunikation mit dem NSP ist das "https://fqdn:6063/as4", also mit Pfad und sogar Portangabe.
Wenn du hingegen eine Firewall oder einen Reverse Proxy davor hast kannst du es auf alles mögliche umbiegen, eben auch auf "https://fqdn".
Aus Admin Sicht würde ich dies immer vorziehen, da deine Zertifikate dann allgemein gültig bleiben falls du deine Infrastruktur im Nachhinein anpassen solltest, zudem ziehst du eine weitere Sicherheitsebene in die Netzwerkkommunikation.

Ich werde mal in der Doku schauen ob wir unseren Standardendpunkt dort wirklich festgehalten haben =)

Gruß
Jan
 
Danke für die Antwort und weiteren Hinweise, Jan,

ich habe die Weiterleitung von unserem Reverse Proxy davor auf https://nsp:6063/as4 geändert, und
siehe da, da kommt als Antwort jetzt

HTTP (POST) request sent, awaiting response... 401 Unauthorized
Username/Password Authentication Failed.

Sieht jetzt viel besser aus - und für das oben Genannte sind die noch nicht bereitgestellten Zertifikate zuständig.
Gruß Wolfgang
 
Hallo Wolfgang,

perfekt. Genau so wie, zumindest ich mir das, gedacht habe :D

Damit kann man doch super ins Wochenende starten ;)

LG
Jan
 
Hallo Jan,
so,
die Zertifikate sind nun erstellt und wurden installiert - bei einem Konnektivitäts-Test mit einem bekannten Partner mit bestehender AS4-Kommunikation kommt jetzt die etwas nichtssagende Meldung "Zertifikatsproblem" - das hätte ich gern etwas detaillierter.

2) Oben hatten wir uns über die Adressen, URI, u.a. auch bei einer Konfiguration mit vorgeschaltetem (Reverse) Proxy, unterhalten. Meines Wissens muss jetzt dieser das TLS-Zertifikat aus dem Triple zur Verfügung gestellt bekommen. Wie bekommen wir das TLS-Zertifikat (einschließlich Private Key) dorthin exportiert?
Viele Grüße Wolfgang
 
Hallo Wolfgang,

Kannst du den Test noch einmal machen und dabei die DEV Tools vom Browser offen haben?
Hier ist dann hoffentlich mehr zu sehen. Schau zusätzlich bitte auch einmal in das Eventlog auf der Gateway Rolle.

Zum Reverseproxy:
Da komme ich später nochmal auf dich zu, ein Kollege hat die Befürchtung geäußert, dass ein Export vom Private Key gegen die Richtlinien Verstößen könnte, damit wäre das Konzept natürlich hinfällig und nur noch das NATing an der Firewall machbar.
Das hatte ich bei meiner ersten Antwort leider nicht berücksichtigt. Wir schauen grade nochmal und dann melde ich mich wieder 👍
 
Zurück
Oben