HTTP Status cod 403 with client certificate authentication

Hi,


I would like to ask one question in regards to HTTP status code 403 request with client certificate authentication challenge.

So, I was implementing a solution that requires mutusl TLS which will set the delegate responded to the client identity authentication challenge, and experienced the issue when the request fails with 403, the iOS SDK returns the error NSURLErrorClientCertificateRequired rather than the error that was actually returned from the server side.


I found the thread in the forum that explains the exactly the same issue, but would like to clarify few more things here.


From my experiment, what I found is that this behaviour only happens for the first 5 or 10 minutes of NSURLSession's session.

For example, I will get the NSURLErrorClientCertificateRequired only for the first five or ten minutes, and after that, I am receiving the expected error message from the server side.


This reminds me of TLS caching issue back in iOS 9 or below with NSURLConnection and NSURLSession (which resolves by re-contructing NSURLSession object); however, in this case, it is not simple to reconstruct the NSURLSession object based on the response from the server side.


Was this officially reported or known to Apple as a bug? or is this kind of expected behaviour? Is there any official statement from Apple acknowledging this issue (like known-issues)? Can you help me direct to places where I can find this information, if any?


Thanks,

Up vote post of James G Down vote post of James G
4.3k views
Posted by
James G
Reply
Add a Comment

Accepted Reply

Was this officially reported or known to Apple as a bug?

You saw the bug number in my other post, right? I just checked on that bug and it’s not been reported as fixed. Beyond that, there’s really not much I can say without looking into your specific issue in more detail.

The way I see it there’s two issues in play here:

  • How can you get the 403 response in general?

  • Why does the behaviour change after N minutes?

With regards the first issue, I think my other post covers that effectively, namely:

  • There are specific criteria under which you don’t get the 403

  • It’d be nice if there were a better way

  • Hence the bug report

Is there a specific reason you need the 403 response? The developer in the other thread needed the 403 in order to choose the correct client identity with which to respond to the challenge. Is that the case here too? If so, I suggested some alternative approaches in that other thread (like changing the server so that the challenge’s 

distinguishedNames
is populated with useful info).

With regards the second issue, I’ve got nothing. If you want to continue investigating this I recommend that you take a look at a CFNetwork diagnostic log (see QA1887 CFNetwork Diagnostic Logging) to see if you can work out what changes at the infection point between NG and OK. If you’d like formal help with that, I recommend that you open a DTS tech support incident. There’s a limit to how much help I can provide via DevForums and this stuff is well beyond that limit.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

Was this officially reported or known to Apple as a bug?

You saw the bug number in my other post, right? I just checked on that bug and it’s not been reported as fixed. Beyond that, there’s really not much I can say without looking into your specific issue in more detail.

The way I see it there’s two issues in play here:

  • How can you get the 403 response in general?

  • Why does the behaviour change after N minutes?

With regards the first issue, I think my other post covers that effectively, namely:

  • There are specific criteria under which you don’t get the 403

  • It’d be nice if there were a better way

  • Hence the bug report

Is there a specific reason you need the 403 response? The developer in the other thread needed the 403 in order to choose the correct client identity with which to respond to the challenge. Is that the case here too? If so, I suggested some alternative approaches in that other thread (like changing the server so that the challenge’s 

distinguishedNames
is populated with useful info).

With regards the second issue, I’ve got nothing. If you want to continue investigating this I recommend that you take a look at a CFNetwork diagnostic log (see QA1887 CFNetwork Diagnostic Logging) to see if you can work out what changes at the infection point between NG and OK. If you’d like formal help with that, I recommend that you open a DTS tech support incident. There’s a limit to how much help I can provide via DevForums and this stuff is well beyond that limit.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Thanks for the update.

Posted by
James G
Up vote reply of James G Down vote reply of James G
Add a Comment

Somehow this is still an issue 5 years later. We're using client cert based authentication in our NSURLSession and finding that in some cases a 403 from the server will result in:

NSURLErrorClientCertificateRequired

It's pretty easy to prove, by just returning a 200 from the server instead and everything works (the full TLS handshake succeeds).

The fact that NSURLResponse is completely nil in a 403 and it appears that the TLS handshake is failing (when its not) is a bug that IMO should have been fixed years ago.

Posted by
janders3
Post not yet marked as solved Up vote reply of janders3 Down vote reply of janders3
Add a Comment