HTTP Status cod 403 with client certificate authentication

Question

James G OP

Created Oct ’17

Replies 3

Boosts 0

Views 5k

Participants 3

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,

Answered by DTS Engineer in 268938022

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"

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’17

Accepted Answer

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"

0

Answer 2

James G OP

Oct ’17

Thanks for the update.

0

Answer 3

janders3 OP

Aug ’23

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.

1