Laden...

self-signed Zertifikat akzeptieren in Webreferenzen

Erstellt von MikeA vor 7 Jahren Letzter Beitrag vor 7 Jahren 7.281 Views
M
MikeA Themenstarter:in
12 Beiträge seit 2016
vor 7 Jahren
self-signed Zertifikat akzeptieren in Webreferenzen

Hallo Forum,
ich bin dabei mich in mit dem Thema zu beschäftigen und scheitere an dem selbst-signierten Zertifikat des Servers.
Ich benutze VisualStudio 2015 und .Net 4.5 für die ich noch keine funktionierende Lösung gefunden habe.
Wenn ich die Abfrage starte erhalte ich den Fehler:> Fehlermeldung:

ERROR in request; System.Net.WebException: Die zugrunde liegende Verbindung wurde geschlossen: Für den geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden.. ---> System.Security.Authentication.AuthenticationException: Das Remotezertifikat ist laut Validierungsverfahren ungültig.

Den einzigsten Ansatz den ich im Internet gefunden habe, und der keinen Fehler bei der Kompilierung verursacht ist:


try {
using (var svc = new WebReference.WebService()) {
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
var result = svc.getVersion();
this.output.Text = result; }
catch (Exception error) {
this.output.Text = "ERROR in request: " + error + "\n"; }

Ich nutze diesen Code wie empfohlen vor dem Aufruf des WebDienstes, jedoch leider scheint er nicht zu funktionieren da der obige Error immer noch erscheint.
Hat jemand einen Tip wie ich eine funktionierende Lösung bekomme ?

Ich möchte mir gerne eine Anwendung basteln die ich nach und nach ausbaue. Dazu muss ich aber erst mal die Hürde hier nehmen.
Ich wäre für Hilfe dankbar.

Danke und LG

Mike

16.842 Beiträge seit 2008
vor 7 Jahren

Was genau hast Du denn überhaupt vor? Warum hat der Dienst denn überhaupt ein selbst erstelltes Zertifikat?

Ein SSL Zertifikat ohne Überprüfung pauschal zu akzeptieren ist der erste Schritt zur Sicherheitsanfälligen Anwendung.

M
MikeA Themenstarter:in
12 Beiträge seit 2016
vor 7 Jahren

Hallo Abt,

danke für Deine Rückmeldung.
Ja Du hast sicherlich Recht damit dass es eine Sicherheitslücke wäre ein selbst-signiertes Zertifikat zu akzeptieren.
Aber es handelt sich hier um einen Server der nicht im öffentlichen Netz hängt, daher ist es nicht sooo gravierend.

Zu diesem Server habe ich eine API Beschreibung um Daten abzurufen und auch um Daten auf den Server zu pushen.
Es steckt keine wirkliche Lösung dahinter. Ich will das nur einmal machen und dabei lernen. Macht mir eben Spaß zu programmieren und es dann auch noch funktioniert.
Letzteres ist leider noch nicht so oft der Fall, aber daran arbeite ich 😃

Ich möchte mir eine Anwendung erstellen mit der ich eben die Daten vom Server abrufen und auch Daten eingeben kann.
Aber alles Schritt für Schritt.

WebService über WSDL ist bereits eingebunden.

Das mit dem Zertifikat hat sich glaube ich schon erledigt.
Nachdem ich kurze Pause gemacht, und danach den PC wieder hochgefahren habe, ist der Fehler nicht mehr aufgetreten. Vermutlich hat da das VS2015 etwas gecached, was zu diesem Fehler geführt hat.
Jetzt bekomme ich einen Authentifizierungsfehler.
Da geht es vermutlich darum dass ich Username/Password übergeben muss.
Das ist dann die nächste Herausforderung.

Ich muss zwar noch viel Suchen und Lesen, was erfahrene aus dem Handgelenk machen, aber ich werde es hinkriegen. Auch wenn es viel länger dauert.
Ich möchte als Nächstes ein Eingabeformular kreieren in dem der Benutzer seine Daten eingibt die dann für die Authentifizierung für den WebService genutzt wird.

Vielleicht hast du da eine Idee für mich.

LG

Mike

16.842 Beiträge seit 2008
vor 7 Jahren

Es ist völlig OK einem self-signed Zertifikat zu vertrauen; was ich aber anmäkle ist, dass Du mit diesem Code jedem ungültigen Zertifikat vertraust.
Dieses Code-Snippet mit return true ist leider weit verbreitet und öffnet Man-in-the-Middle Attacken Tür und Tor.

Kerry Lothrop hat auf der Technical Summit gezeigt, wie viele Apps dieses Snippet verwenden und man dadurch Problemlos die Apps teilweise eklatant manipulieren kann.
Daher lieber in der Routine prüfen, ob es das eigene Zertifikat ist und dann "true" zurück geben. Kann man sich bei Interesse bald auf Channel9 anschauen.

Also wenigstens noch eine Überprüfung einbauen, statt blind allem zu vertrauen.
zB via Certificate Hashcode Verification

ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain,
    errors) =>
        {
                return certificate.GetCertHashString().Equals(<dein cert hash hier>, StringComparison.OrdinalIgnoreCase);
        };

Im produktiven Stand würde man sich das *.cert-File irgendwo in der Applikation ablegen, sodass man keine Hash-Codes als Magic Strings im Code hat und man jederzeit das Zertifikat, dessen SSL-Fehler man ignorieren will, austauschen kann.

 var hash = X509Certificate.CreateFromCertFile("mycert.cer").GetCertHashString();

Mir gehts in diesem Fall vor allem darum, sich keine Sicherheitslücken anzugewöhnen. Sensibilisierung.

Dein Snippet an für sich sollte diesen Fehler aber ohnehin nicht mehr auslösen.
ServicePointManager.ServerCertificateValidationCallback ist aber eine globale Einstellung, gilt also für die gesamte Anwendungsinstanz.
Führe sie also aus, wenn die Anwendung startet; nach dem Webcall ist es zu spät.

PS: WSDL macht man heutzutage nicht mehr, sondern die aktuelle Technologie sind REST-basierte Webservices, die sich mit Json austauschen.
Als Vertragsgrundlage nimmt man Swagger Contracts.
Das kannste mal googlen und durch hier informieren.

M
MikeA Themenstarter:in
12 Beiträge seit 2016
vor 7 Jahren

Hallo Abt,

vielen Dank für Deine ausführliche Beschreibung.
Ich werde sie mir zu Herzen nehmen.
Was Dein Code angeht, diesen Weg hatte ich auch schon mal probiert, aber ich habe bei meiner Version gar nicht die Möglichkeiten wie certificate, chain oder errors zu nutzen. Einzigst sender wird mir angeboten. Daher habe ich auch die ganzen Beispiele im Internet nicht zum Laufen bekommen.

Als zusätzliche Directiven habe ich folgende eingebunden:


using System.Net;
using System.Security.Cryptography.X509Certificates;

Was das WSDL angeht wurde es mir empfohlen weil REST Zugriffe zu langsam seien. Ich könnte auch per REST auf den Server zugreifen, habe es aber wegen der Empfehlung nicht getan.

LG

Mike

16.842 Beiträge seit 2008
vor 7 Jahren

REST ist eine Art und Weise wie man auf APIs zugreift. Ein Standard.
REST an für sich beschreibt keine Performance. Wenn bei denen REST langsamer ist als SOAP, dann liegt das an denen; nicht an Dir.
Oder die Person hatte keine Ahnung 😉

Wenn möglich: IMMER REST verwenden.
SOAP ist tot, obsolete.

Du verwendest das Delegate inkl. dem Ignorieren aller Parameter.
Daher hast Du auch kein Zugriff drauf. Verwende das Delegat mit Konstruktor und es klappt.

M
MikeA Themenstarter:in
12 Beiträge seit 2016
vor 7 Jahren

Hello again,

wenn dem so ist will ich natürlich auch nicht auf das falsche Pferd setzen.
Ich habe mir im Internet nun ein Tutorial angeschaut wie man per REST auf die API zugreift. Aber jetzt geht das Spiel wieder los mit dem selbst-signierten Zertifikat.
Da muss ich nun wieder rausfinden wie ich das bei dem REST Zugriff umgehe.

Aber für heute reicht's mir. Mache morgen Abend weiter.

Danke Dir !!

LG

Mike

16.842 Beiträge seit 2008
vor 7 Jahren

Wie gesagt; Du musst das mit dem ValidationCallback halt an der richtigen Stelle ausführen.

M
MikeA Themenstarter:in
12 Beiträge seit 2016
vor 7 Jahren

Hi,

Ich möchte gerne die Lösung nutzen bei der ich den Hash-Code des Server-Zertifikates prüfe. Ich habe es eingesehen dass dies wohl die bessere und auch richtige Art ist so einen Fall zu behandeln.

Mit der Platzierung des Codes an der richtigen Stelle scheine ich wohl noch etwas Probleme zu haben.

LG

Mike