Xcode 8.2.1 Swift 3 IOS10 Zugriff auf Server via GET nicht möglich

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • OSXDev schrieb:

    gritsch schrieb:

    verwende doch einfach mal ein valides zertifikat zb von letsencrypt (da gibts auch den manuellen, umständlcihen weg ein solches zu erstellen).
    Okay. Probiere ich aus.
    Hast Du eine Idee warum die Einträge in der info.plist nicht die gewünschte Wirkung zeigen?
    du rückst ja keine url raus sodass man das cert und den server überprüfen könnte.
    vielleicht verwendest das cert einen nicht mehr erlaubten signing-algo.

  • gritsch schrieb:

    OSXDev schrieb:

    gritsch schrieb:

    verwende doch einfach mal ein valides zertifikat zb von letsencrypt (da gibts auch den manuellen, umständlcihen weg ein solches zu erstellen).
    Okay. Probiere ich aus.Hast Du eine Idee warum die Einträge in der info.plist nicht die gewünschte Wirkung zeigen?
    du rückst ja keine url raus sodass man das cert und den server überprüfen könnte.vielleicht verwendest das cert einen nicht mehr erlaubten signing-algo.
    Mag sein. Deshalb werde ich das Zertifikat auch ersetzen.

    Dennoch sollte - zumindest meinem Verständnis nach - durch die Einträge in die info.plist (Ausschalten von ATS) dies keine Rolle spielen. Nicht jeder kann einfach mal einen Zertifikatstausch durchführen. Wie kann man sich in so einem Fall behelfen, eigentlich doch nur durch die Einträge in die info.plist oder gibt es da noch weitere Möglichkeiten?

    Bin für jede Info dankbar.

  • OSXDev schrieb:

    gritsch schrieb:

    OSXDev schrieb:

    gritsch schrieb:

    verwende doch einfach mal ein valides zertifikat zb von letsencrypt (da gibts auch den manuellen, umständlcihen weg ein solches zu erstellen).
    Okay. Probiere ich aus.Hast Du eine Idee warum die Einträge in der info.plist nicht die gewünschte Wirkung zeigen?
    du rückst ja keine url raus sodass man das cert und den server überprüfen könnte.vielleicht verwendest das cert einen nicht mehr erlaubten signing-algo.
    Mag sein. Deshalb werde ich das Zertifikat auch ersetzen.
    Dennoch sollte - zumindest meinem Verständnis nach - durch die Einträge in die info.plist (Ausschalten von ATS) dies keine Rolle spielen. Nicht jeder kann einfach mal einen Zertifikatstausch durchführen. Wie kann man sich in so einem Fall behelfen, eigentlich doch nur durch die Einträge in die info.plist oder gibt es da noch weitere Möglichkeiten?

    Bin für jede Info dankbar.
    die antwort ist wieder mal 42!

  • Verwendest Du jetzt http oder https für die Requests?

    http sollte eigentlich funktionieren, da Du per App Transport Security Settings Arbitrary Loads ja erlaubst. Evtl. versuche mal NSExceptionAllowsInsecureHTTPLoads zu entfernen.

    Wenn Du https verwendest, dann musst Du ggf. ein Delegate setzten und Teile vom NSURLSessionDelegate Protocol, speziell urlSession(_:didReceive:completionHandler:), implementieren und darin die NSURLAuthenticationChallenge mit der authenticationMethod (protectionSpace) NSURLAuthenticationMethodServerTrust validieren.

    Wenn der Server ein Zertifikat hat, dann sollte er nur https Verbindungen erlauben. Somit wirst Du das NSURLSessionDelegate Protocol verwenden müssen.

    Alternativ musst Du ein gültiges Zertifikat auf dem Server verwenden.

    BTW: Sollte jemand eine einfachere Lösung für iOS bei https Requests zu einem Server mit einem Self Signed Certificate kennen, dann bitte her damit. Aktuell habe ich dies nur per NSURLSessionDelegate Protocol hinbekommen.

  • MCDan schrieb:

    Verwendest Du jetzt http oder https für die Requests?

    http sollte eigentlich funktionieren, da Du per App Transport Security Settings Arbitrary Loads ja erlaubst. Evtl. versuche mal NSExceptionAllowsInsecureHTTPLoads zu entfernen.

    Wenn Du https verwendest, dann musst Du ggf. ein Delegate setzten und Teile vom NSURLSessionDelegate Protocol, speziell urlSession(_:didReceive:completionHandler:), implementieren und darin die NSURLAuthenticationChallenge mit der authenticationMethod (protectionSpace) NSURLAuthenticationMethodServerTrust validieren.

    Wenn der Server ein Zertifikat hat, dann sollte er nur https Verbindungen erlauben. Somit wirst Du das NSURLSessionDelegate Protocol verwenden müssen.

    Alternativ musst Du ein gültiges Zertifikat auf dem Server verwenden.

    BTW: Sollte jemand eine einfachere Lösung für iOS bei https Requests zu einem Server mit einem Self Signed Certificate kennen, dann bitte her damit. Aktuell habe ich dies nur per NSURLSessionDelegate Protocol hinbekommen.
    Danke gritsch. So langsam fühle ich mich wirklich wie ein Tramper durch die Galaxy der aus dem Grübeln nicht mehr herauskommt. :D

    Nun zu meinen Ergebnissen:
    Server 2 und 3 können nur via https angesprochen werden, wie MCDan es bereits mitgeteilt hat. Fazit: Alles im grünen Bereich.

    Server 1 hat nun ein neues Zertifikat. Eine Verhaltensänderung hat weder die App noch die Abfrage via nscurl erbracht. ?(

    Danke MCDan. Werde Deine Vorgehensweise ausprobieren und dann zukünftig beibehalten. Zumindest bis ich wieder an einer 42! ankomme.

    Im übrigen gilt mein Dank ALLEN die hier Ihr Wissen mitteilen. :thumbsup: (Muss auch mal gesagt werden!)

  • MCDan schrieb:

    (...) Alternativ musst Du ein gültiges Zertifikat auf dem Server verwenden.


    BTW: Sollte jemand eine einfachere Lösung für iOS bei https Requests zu einem Server mit einem Self Signed Certificate kennen, dann bitte her damit. Aktuell habe ich dies nur per NSURLSessionDelegate Protocol hinbekommen.
    Mir fallen heute so wieso kaum Gründe ein noch ein selfsigned Certificate zu verwenden, außer man will sich unbedingt unnötigen Stress machen. Nicht mal für Testzwecke würde ich das verwenden, weil das ja den Test verzerrt.

  • MacounFFM schrieb:

    MCDan schrieb:

    (...) Alternativ musst Du ein gültiges Zertifikat auf dem Server verwenden.


    BTW: Sollte jemand eine einfachere Lösung für iOS bei https Requests zu einem Server mit einem Self Signed Certificate kennen, dann bitte her damit. Aktuell habe ich dies nur per NSURLSessionDelegate Protocol hinbekommen.
    Mir fallen heute so wieso kaum Gründe ein noch ein selfsigned Certificate zu verwenden, außer man will sich unbedingt unnötigen Stress machen. Nicht mal für Testzwecke würde ich das verwenden, weil das ja den Test verzerrt.
    Wenn Du mir sagst, wie/wo man laut Apple/iOS valide Zertifikate für localhost oder interne Server bekommt, dann werden wir diese liebend gerne verwenden. ;)

  • MCDan schrieb:

    MacounFFM schrieb:

    MCDan schrieb:

    (...) Alternativ musst Du ein gültiges Zertifikat auf dem Server verwenden.


    BTW: Sollte jemand eine einfachere Lösung für iOS bei https Requests zu einem Server mit einem Self Signed Certificate kennen, dann bitte her damit. Aktuell habe ich dies nur per NSURLSessionDelegate Protocol hinbekommen.
    Mir fallen heute so wieso kaum Gründe ein noch ein selfsigned Certificate zu verwenden, außer man will sich unbedingt unnötigen Stress machen. Nicht mal für Testzwecke würde ich das verwenden, weil das ja den Test verzerrt.
    Wenn Du mir sagst, wie/wo man laut Apple/iOS valide Zertifikate für localhost oder interne Server bekommt, dann werden wir diese liebend gerne verwenden. ;)
    mail-validated certs und du bekomsmt für localhost (ok, nicht für "localhost" aber zb für "local.deinedomain.tld" ein valides zertifikat - und local löst dann eben auf 127.0.0.1 auf ;-))

  • MCDan schrieb:

    MacounFFM schrieb:

    Mir fallen heute so wieso kaum Gründe ein noch ein selfsigned Certificate zu verwenden, außer man will sich unbedingt unnötigen Stress machen. Nicht mal für Testzwecke würde ich das verwenden, weil das ja den Test verzerrt.
    Wenn Du mir sagst, wie/wo man laut Apple/iOS valide Zertifikate für localhost oder interne Server bekommt, dann werden wir diese liebend gerne verwenden. ;)
    Das ist eine Ausnahme, auf die sich das "kaum" bezog. Und welche natürlich die Regel bestätigt. :P

    P.S.: Ich meine irgendeine CA stellt sowas wirklich als Klasse 0/1 Zertifikat aus.

  • MCDan schrieb:

    Verwendest Du jetzt http oder https für die Requests?

    http sollte eigentlich funktionieren, da Du per App Transport Security Settings Arbitrary Loads ja erlaubst. Evtl. versuche mal NSExceptionAllowsInsecureHTTPLoads zu entfernen.

    Wenn Du https verwendest, dann musst Du ggf. ein Delegate setzten und Teile vom NSURLSessionDelegate Protocol, speziell urlSession(_:didReceive:completionHandler:), implementieren und darin die NSURLAuthenticationChallenge mit der authenticationMethod (protectionSpace) NSURLAuthenticationMethodServerTrust validieren.

    Wenn der Server ein Zertifikat hat, dann sollte er nur https Verbindungen erlauben. Somit wirst Du das NSURLSessionDelegate Protocol verwenden müssen.

    Alternativ musst Du ein gültiges Zertifikat auf dem Server verwenden.

    BTW: Sollte jemand eine einfachere Lösung für iOS bei https Requests zu einem Server mit einem Self Signed Certificate kennen, dann bitte her damit. Aktuell habe ich dies nur per NSURLSessionDelegate Protocol hinbekommen.
    @MCDan
    Bin gerade mit der Implementierung beschäftigt und dabei ist folgende Frage aufgekommen. Bei meinen OS X Apps habe ich das Zertifikat des Servers auf dem Client als Vertrauenswürdig eingestuft. Laufen alle ohne Probleme.

    Im iOS Simulator habe ich nun testweise das Zertifikat installiert und als vertrauenswürdig bestätigt und dennoch erhalte ich den Fehlercode 9813.

    Offensichtlich sind die Validierungsabläufe zwischen iOS und OS X unterschiedlich. Ist dies wirklich so oder übersehe ich hier etwas?

  • gritsch schrieb:

    wahrscheinlich hast du das cert (die gesamte kette?) nicht korrekt installiert auf dem gerät.
    ruf doch einfach eine url zu dem server in safari auf und schaue ob dann eine zert-warnung kommt oder nicht!
    Hat ein bisschen gedauert um alles nach zu lesen. Mit Deinem Hinweis, dass etwas mit der Zertifikatsreihenfolge nicht stimmt - liegst Du richtig.

    Wie kann ich dies korrigieren?

  • OSXDev schrieb:

    gritsch schrieb:

    wahrscheinlich hast du das cert (die gesamte kette?) nicht korrekt installiert auf dem gerät.
    ruf doch einfach eine url zu dem server in safari auf und schaue ob dann eine zert-warnung kommt oder nicht!
    Hat ein bisschen gedauert um alles nach zu lesen. Mit Deinem Hinweis, dass etwas mit der Zertifikatsreihenfolge nicht stimmt - liegst Du richtig.
    Wie kann ich dies korrigieren?
    verwende doch einfach mal ssllabs.com/ssltest/ und schau was da rauskommt.