SSL Webservices im SAP nutzen

Autor: Tobias Harmes | 3. Februar 2011

10 | 35

Für die Anbindung von produktiven Webservices ist eine verschlüsselte Verbindung aus naheliegenden Gründen natürlich bevorzugt. Allerdings muss man für eine SSL-Verbindung einige Vorarbeiten leisten, die man auf Client-Seite (z.B. mit einem Internet Explorer) in der Regel nicht hat.

Z.B. möchte ein SAP-System im Trust-Manager genau die Stammzertifikate mitgeteilt bekommen, denen es Vertrauen darf. Hat man das nicht getan, tauchen in den Programmen Fehler wie “ICM_HTTP_INTERNAL_ERROR” und im ICM-Log (Transaktion smicm->Springen->Trace Datei) folgende Fehlermeldungen auf:

Fehlermeldung

[Thr 4832] ***ERROR during SecudeSSL_SessionStart()fromSSL_connect()==SSL_ERROR_SSL
[Thr 4832] session uses PSEfile "xxxSAPSSLC.pse"
[Thr 4832] SecudeSSL_SessionStart:SSL_connect()failed secude_error 9 (0x00000009)="the verification of the server's certificate chain failed"
[Thr 4832] >>Begin of Secude-SSL Errorstack>>
[Thr 4832] ERROR in ssl3_get_server_certificate:(9/0x0009) the verification of the server's certificate chain failed #ERROR in af_verify_Certificates:(24/0x0018)Chain of certificates is incomplete:"OU=Class 3 Public Primary Certification Auth ERROR in get_path:(24/0x0018) Can't get path because the chain of certificates is incomplete#
[Thr 4832] <<End of Secude-SSL Errorstack
[Thr 4832] SSL_get_state()returned 0x00002131 "SSLv3 read server certificate B"
[Thr 4832] SSL NI-sock:local=x.x.x.x:12345 peer=y.y.y.y:443
[Thr 4832] <<-ERROR:SapSSLSessionStart(sssl_hdl=000000000248AAF0)==SSSLERR_SSL_CONNECT
[Thr 4832] ***ERROR=>IcmConnInitClientSSL:SapSSLSessionStart failed(-57):SSSLERR_SSL_CONNECT

Dieser Fehler wird auch in SAP Hinweis 1094342 beschrieben.

Für den Import der Stammzertifikate benötigt man diese in Dateiform. Dies geht relativ einfach mit dem Internet Explorer. Wichtig: Den IE als Administrator ausführen, ansonsten ist ein Zertifikatsexport in eine Datei nicht möglich.


Auf der Zielseite einen Doppelklick auf das Zertifikatssymbol.


Der Zertifikatspfad zeigt die notwendigen Stammzertifikate, die importiert werden müssen.


Für jeden Eintrag der Zertifikatskette muss man einmal “In Datei kopieren” auswählen.


Dort vorzugsweise ein binär-codiertes Zertifikat verwenden. Das Base-64-Format, dass im Hinweis erwähnt wird, hat nicht funktioniert.

Der Importvorgang im SAP muss dann über die Transaktion STRUST in einer Client-PSE erfolgen. Je nach dem wie man den Aufruf macht, müssen die Zertifikate in andere PSEs importiert werden. Die genutzte PSE kann man z.B. in dem ICM-Log sehen. Die verwendete SAPSSLC.pse entspricht hier der “SSL-Client (Standard)” im Trust-Manager.

harmes_180x227
Zu zweit schneller zum Ergebnis 🙂
Expert Session mit dem Autor Tobias Harmes anfragen

Vier Augen sehen mehr als zwei! Wenn Sie die Inhalte aus diesem Artikel schnell umsetzen wollen, kann ich Ihnen gerne dabei helfen.
Autoren Expert Session


Um das Zertifikat der Zertifikatsliste hinzuzufügen, auf “Zertifikat importieren” gehen.


Die Datei auswählen und “Binär” auswählen.

SSL Webservices im SAP nutzen
Danach das angezeigte Zertifikat in die Liste aufnehmen und sichern. Danach den ICM-Server durchstarten (smicm).

Nun sollte der Zugriff funktionieren. Wichtig ist, dass die Domain in der URL mit dem Common Name in dem Zertifikat übereinstimmt. Ansonsten gibt einen Fehler vergleichbar mit der IE-Zertifikatswarnung “Der Hostname stimmt nicht überein”, und die Verbindung schlägt fehl.

Im ICM-Log würde das so aussehen:

[Thr 1560] MatchTargetName("t1234.example.com", "CN=z99999.example.com, OU=Applications, O="example.com, Inc.", L=Hannover
[Thr 1560] SSL NI-sock: local=x.x.x.x:53253 peer=y.y.y.y:443
[Thr 1560] <<- ERROR: SapSSLSessionStart(sssl_hdl=000000000252FE20)==SSSLERR_SERVER_CERT_MISMATCH
[Thr 1560] *** ERROR => IcmConnInitClientSSL: SapSSLSessionStart failed (-30): SSSLERR_SERVER_CERT_MISMATCH {0003000b} [icxxconn

Tipp: In der SM59 eine “HTTP-Verbindung zu ext. Server” anlegen, damit kann man in der Regel schneller testen, als jedes Mal den Webservice zu debuggen.

Sie benötigen Unterstützung bei der Umsetzung? Unser Autor Tobias Harmes ist Berater für dieses Thema. Fragen Sie ihn an über das RZ10.de Partnerprodukt Berater für SAP Basis


Artikel war hilfreichArtikel empfehlen


Dieser Beitrag ist auch als Download verfügbar:
Tobias Harmes

Autor

Tobias Harmes

Experte, Speaker, Herausgeber rz10.de

Fragen? Anmerkungen?
Kontaktieren Sie mich

10 Kommentare zu "SSL Webservices im SAP nutzen"

Super Anleitung, genau das habe ich gesucht! Vielen Dank!

Vielen Dank für die Anleitung. Wie teste ich das dann mit SOAP UI?
Ich muss ja dann im SOAP UI irgendwo auch das Zertifikat mitgeben?

Hallo Tobias,
wenn ich auf meinem PC SAP Java App Server oder sld oder Fiori aufrufen, dann bekomme ich diese Fehlermeldung:
Dem Sicherheitszertifikat dieser Website wird von Ihrem PC nicht vertraut.
Fehlercode: DLG_FLAGS_INVALID_CA

Welchen Zertifikat soll ich implementieren, um diesen Fehler für alle SAP Benutzer zu beheben ?

Vielen Dank

Hallo,
ich denke, im Grunde ist es das hier: https://www.heise.de/security/artikel/Chrome-blockt-Zertifikate-mit-Common-Name-3717594.html
Typischerweise tritt dieses Problem bei Unternehmen auf, die auf den Microsoft Edge wechseln. Diese verwendet als Engine mittlerweile den Chrome. Und deshalb muss das SAP Zertifikat in der STRUST auch (“plötzlich”) einen Subject Alternative Name haben. Neuere Netweaver-Releases bieten das direkt an, ältere Releases muss man das per genpse-Tool unterschieben.

Es gibt auch Hinweise von der SAP dazu:
2725592 – Warning “Not Secure” when access to AS ABAP system via HTTPS on Google Chrome Version 58+
2478769 – Erhalt von Zertifikaten mit Alternativnamen des Inhabers (SAN) in STRUST

Viele Grüße
Tobias

Hallo Tobias,
Ich habe eine Frage zu SSL. Ich habe unter STRUST Server Standard PSE ein PSE erstellt, somit wird dann ein Privater und öffentlicher Schlüssel erstellt.
Wie kann ich das Zertifikat von Server Standard (also mit Create Certificate Request) signieren, wenn ich keine Zertifizierungsstelle habe ?

Vielen Dank.

Hi Steve,
die meisten Unternehmen haben eine interne Zertifizierungsstelle durch das Active Directory / AzureAD. Wenn du da nichts zur Verfügung hast, dann musst du auf eine externe certificate authority (CA) zurückgreifen. Zum Beispiel Thawte oder Verisign. Da sollte es ein Anbieter sein, dessen Root-Zertifikat bei deinen Usern in dem Browser auch vorhanden ist. Früher funktionierte das auch mal SAP mit ihrem Trustcenter Services (TCS), das haben sie aber Ende 2020 eingestellt. Self-signed (=Selbstsigniert) macht heutzutage wirklich nur bei einem Labortest Sinn, weil der Enduser sich ansonsten durch eine lange Liste von (berechtigten) Warnmeldungen klicken muss.
Viele Grüße
Tobias

Hallo Tobias,
wie kann man Zertifikate selbssignieren ? Würden die selbssegnierten Zerifikate innerhalb von Intranet (also man bleibt immer im VPN Netz) ausreichen ?

Danke schön

Hallo,

grundsätzlich würden die selbstsignierten Zertifikate ausreichen. Die Certificate Authority (CA) – also der Zertifikatsaussteller – müsste aber in allen Clients als vertrauenswürdig hinterlegt werden, damit moderne Browser die Webseiten dann noch anzeigen.

Viele Grüße

Hallo Herr Schmits,

wird das Hauptzertifikat für den Trust benötigt, oder ist es ausreichend nur die Root/Zwischenzertifikate zu importieren? Unser Dienstleister ist der Meinung, dass diese auch importiert werden müssen. Lt. Ihrer Beschreibung verstehe ich das so, dass nur das Root/Zwischenzertifikat importiert werden muss. (“Der Zertifikatspfad zeigt die notwendigen Stammzertifikate, die importiert werden müssen”). Wir haben im STRUST einige Zertifikate (Hautpzert.), die schon lange abgelaufen sind, können aber keine Einschränkungen im Betrieb feststellen.
Wenn ich das mal mit der Handhabung im Browser vergleiche importiere ich ja dort auch nicht alle Zertifikate, sondern nur die Root/Zwischenzertifikate, denen ich vertraue. Diese müssen auch nicht so oft aktualisiert werden…

Mit freundlichen Grüßen

Rainer Schmidle

Hallo Herr Schmidle,

hier die Antwort unserer Expertin:

“Es ist korrekt, dass nur die Root- und Zwischenzertifikate von vertrauenswürdigen CAs in der STRUST hinterlegt werden müssen. Es ist normalerweise nicht notwendig ein Server- bzw. Clientzertifikat zur Liste der vertrauenswürdigen Zertifikate hinzuzufügen. Die Frage bezüglich Einschränkungen im Betrieb ist nicht so leicht zu beantworten. Im Browser wird einem bei einem abgelaufenen Zertifikat angezeigt, dass dieses “Nicht sicher” ist – es wird also keine HTTPS-Verbindung hergestellt. Wenn HTTP-Verbindungen aber auch möglich sind, dann wird die Webseite trotzdem geöffnet. Das gleiche gilt für SAP-Systeme. Ist HTTP bei Ihnen deaktiviert bzw. sind Sie sicher, dass Ihre Webservices HTTPS nutzen?”

Wenn Sie weitere Fragen zum Thema haben, schreiben Sie uns gerne auch eine Mail an info@rz10.de

Viele Grüße aus der RZ10-Redaktion

Kommentar verfassen


Unsere Top-Downloads

Kontaktieren Sie uns!
Renate Burg Kundenservice