Hello Andreas, thanks for the input, but I was under the impression that (and my previous experience confirms this) that „didReceiveChallenge“ should be invoked regardless, because in that delegate method I can chose to ignore the hostname, and/or chose to accept (or reject) the presented certificate.
In my case, I my code is never presented with that choice, which seems very strange. Thanks Alex > Am 25.02.2019 um 15:02 schrieb Andreas Fink <af...@list.fink.org>: > > > >> On 25 Feb 2019, at 14:53, Alexander von Below <be...@mac.com> wrote: >> >> Hello Networking List, >> >> The setup: >> >> * We are an ISP, and we provide customers with internet access routers. >> >> * On these routers there is a Linux Container (lxc) running a service on an >> nginx. >> >> * The DHCP on the router is providing a hostname for the lxc in the local >> network. >> >> * The nginx has a self-signed certificate >> >> The problem: >> >> When we are accessing the service using NSURLSession using the IP of the >> lxc, the NSURLSessionDelegate’s „didReceiveChallenge“ is called as expected, >> and we can perform our own challenge handling. This is the expected behaviour >> >> When we are accessing the service in an identical manner but using the >> _hostname_, the task fails with an error -1200 "An SSL error has occurred >> and a secure connection to the server cannot be made.“ without ever calling >> the delegate. > > If you are talking SSL, then there is always a certificate involved. > If you connect via IP, it is known that then the certificate can not be > checked and its validation might simply be skipped. > If you connect via hostname, the certificate has to match the hostname and > the certificate can be validated. > > My guess is that the certificate's name doesn't match the hostname you use to > connect. > > That would be logical to break irrespectively of if the signature is signed > by a known root or if its self signed. _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to arch...@mail-archive.com