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

Reply via email to