SSL error while using self signed certificate for an accessory device

Question

Created 2w

Replies 4

Boosts 0

Participants 2

I used the SSH approach method in the post https://developer.apple.com/forums/thread/703234 to add TLS trust for the local accessory device with a self signed certificate.

In the Info.plist, I disabled App Transport Security for local networking by setting the NSAllowsLocalNetworking property, as mentioned in the post.

However, I am still encountering the following SSL error:

ATS failed system trust
Connection 3: system TLS Trust evaluation failed(-9802)
Connection 3: TLS Trust encountered error 3:-9802
Connection 3: encountered error(3:-9802)
Task <9432C2C5-C7A1-44E4-95CC-2AFA49D6C501>.<1> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9802])
Task <9432C2C5-C7A1-44E4-95CC-2AFA49D6C501>.<1> finished with error [-1200] Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3

In the code everything is working fine. The certificates are compared and CFEqual(expected, actual), is returning true. Also in urlSession delegate method , the

return completionHandler(.useCredential, credential)

is returned.

When I disable ATS in Info.plist by setting NSAllowsArbitraryLoads, it works fine.

I have the following questions:

Should I disable ATS by setting NSAllowsArbitraryLoads along with setting ?
Instead of accepting the server certificate for the first time and saving it in the app, why can’t we embed the self-signed certificate in the app directly and use it for comparison?

Answered by DTS Engineer in 817226022

The accessory does not have a static IP or DNS since it is on a local network.

This doesn’t preclude a DNS name, just a global DNS name. Life will be better if your accessory supports Bonjour, and hence a .local DNS name. I talk about this more in Don’t Try to Get the Device’s IP Address and Working with a Wi-Fi Accessory, both linked to from my Extra-ordinary Networking post.

When I replaced the domain name with the IP address, the issue was resolved.

OK. I’m not entirely sure what’s going on here — and given that this is all placeholder stuff I’m not super inclined to dig too deeply — but one thing to watch out for is the Subject Alternative Name extension. That’s where I’d expect to find both any DNS names and IP addresses listed.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

2w

Accepted Answer

Instead of accepting the server certificate for the first time and saving it in the app, why can’t we embed the self-signed certificate in the app directly and use it for comparison?

That only works if all instances of your accessory uses the same self-signed digital identity. IME that’s rare. Usually each instance generates its own self-signed digital identity, either randomly or based on data that’s unique to that instance, like the serial number. That’s why I didn’t mention this possibility in TLS For Accessory Developers.

If that’s not the case here then:

You really should complain to your firmware folks, because using the same self-signed digital identity for all instances of your accessory makes it even more insecure.
Until that’s fixed, hard coding the certificate would work just fine.

Should I disable ATS by setting NSAllowsArbitraryLoads along with setting?

How are you addressing your accessory? With an IP address? Or a local DNS name? Or something else?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

SJose OP

2w

@DTS Engineer The accessory does not have a static IP or DNS since it is on a local network. Therefore, we will first discover its IP, which will then be used for subsequent connections

0

Answer 3

SJose OP

2w

@DTS Engineer The certificate implementation on the accessory side is not yet completed.

For the time being, I am using a website with a self-signed certificate to test this scenario. The issue occurred because I used the website's domain name. When I replaced the domain name with the IP address, the issue was resolved.

The changes need to be tested again with the accessory device once it is ready.

You really should complain to your firmware folks, because using the same self-signed digital identity for all instances of your accessory makes it even more insecure

This makes sense. I will discuss it with my device development team. Thank you very much for your valuable feedback.

0

Answer 4

DTS Engineer OP

Apple

1w

Recommended

The accessory does not have a static IP or DNS since it is on a local network.

This doesn’t preclude a DNS name, just a global DNS name. Life will be better if your accessory supports Bonjour, and hence a .local DNS name. I talk about this more in Don’t Try to Get the Device’s IP Address and Working with a Wi-Fi Accessory, both linked to from my Extra-ordinary Networking post.

When I replaced the domain name with the IP address, the issue was resolved.

OK. I’m not entirely sure what’s going on here — and given that this is all placeholder stuff I’m not super inclined to dig too deeply — but one thing to watch out for is the Subject Alternative Name extension. That’s where I’d expect to find both any DNS names and IP addresses listed.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0