Socket exception errSSLPeerBadCert CFStreamErrorDomainSSL Code -9825

Problem : Connection error occurs in iOS26 beta while connecting to the device's softap via commercial app (Socket exception errSSLfeerBadCert CFSreamErrorDomainSSL code -9825). iOS 18 release version does not occur. Why does it cause problems? Does the iOS 26 version not cause problems? Is there a way to set it up in the app so that the iOS 26 beta doesn't cause problems?

error : 

"alias":"SOCKET_LOG",
"additional":{"currentNetworkStatus":"socket e=errSSLPeerBadCert ns WifiStatus: Connected Error Domain kCFStreamErrorDomainSSL Code-9825 "(null)"

 UserInfo={NSLocalizedRecoverySuggestion=Error code definition can be found in Apple's SecureTransport.h}

Description : It's an issue that happens when you connect our already mass-produced apps to our home appliances (using SoftAP), and it's currently only happening in iOS 26 beta. This particular issue didn't appear until iOS 18 version.

Let me know to make sure that this issue will persist with the official release of iOS 26? If the issue continues to occur with the official version, would you share any suggestions on how to mitigate or avoid it. Also, it would be helpful to find out if there are known solutions or processes such as exemptions to fix this issue.

Answered by DTS Engineer in 849088022

Hmmm, it looks like you already filed a bug about this (FB18597374) back on 4 Jul. I wish you’d mentioned that here. It’d have saved us some back’n’forth.

Anyway, your bug report is definitely the best path forward for this issue.

Looking at your bug, I don’t see any sysdiagnose logs attached. I recommend that you do the following:

  1. Install the Network Diagnostics for iOS/iPadOS debug profile. See the instructions on our Bug Reporting > Profiles and Logs page.
  2. Reproduce the problem.
  3. Immediately after seeing it, trigger a sysdiagnose log.
  4. Attach that log to your bug report.

It might also help if you captured an RVI packet trace of the problem and attached that to the bug report. See Recording a Packet Trace for info on how to do that.

Share and Enjoy

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

Error -9825 is errSSLPeerBadCert, which isn’t a good sign. Over the years iOS has become increasingly strict about the format of certificates, and it seems likely that the certificate returned by your accessory is malformed, and thus triggers this error.

Let me know to make sure that this issue will persist with the official release of iOS 26?

I’m gonna recommend that you promptly file a bug about this. Before I do that, however, I’d like to get a better understanding of where this certificate is coming from. It seems like you’re building an accessory that acts as a Wi-Fi access point (AP). So:

  • Is this certificate involved in the AP itself? For example, does the AP present it to iOS as part of EAP-TLS authentication?
  • Or does the AP have an HTTPS server? And thus iOS sees this certificate after it’s joined the AP’s network and connecting to this HTTPS server?

This matters because it’ll inform the best diagnostic info to attach to your bug.

Share and Enjoy

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

Please refer my comments below.

Q) I’m gonna recommend that you promptly file a bug about this. Before I do that, however, I’d like to get a better understanding of where this certificate is coming from. It seems like you’re building an accessory that acts as a Wi-Fi access point (AP). So:

. Is this certificate involved in the AP itself? For example, does the AP present it to iOS as part of EAP-TLS authentication?

. Or does the AP have an HTTPS server? And thus iOS sees this certificate after it’s joined the AP’s network and connecting to this HTTPS server?

This matters because it’ll inform the best diagnostic info to attach to your bug.

=> A) Yes, this certificate is made by the AP itself, and it is included inside.

This certificate is used for SSL/TLS connections (HTTP server <-> clients).

Additionally, it reads and communicates information between devices and apps through SSL while connected to the softap on devices and do not connect with other apps.

HTTP server <-> clients

OK. So what clients does this affect? Specifically, does it fail like this with:

  • Safari?
  • nscurl?
  • URLSession [1]?
  • A third-party browser, like Firefox, that uses its own TLS stack?

Share and Enjoy

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

[1] I recommend that you create a small test app for this, making sure to disable ATS using NSAllowsArbitraryLoads.

We met following issue when our app. tries to connect to the softAp on the IoT device.

  • Steps to Reproduce

Launch the app (ex: ThinQ app )on an iOS 26 Beta device. Connect to the IoT device’s SoftAP Wi-Fi network (e.g., SSID: LG_SMART_XXX_XXXX). The app attempts to establish a TLS connection to the device’s TCP server (e.g., IP: 192.168.120.100). TLS handshake fails with error -9825.

  • Expected Behavior

The app should successfully establish a TLS connection with the IoT device, as it does in iOS 18 and earlier versions.

Hmmm, it looks like you already filed a bug about this (FB18597374) back on 4 Jul. I wish you’d mentioned that here. It’d have saved us some back’n’forth.

Anyway, your bug report is definitely the best path forward for this issue.

Looking at your bug, I don’t see any sysdiagnose logs attached. I recommend that you do the following:

  1. Install the Network Diagnostics for iOS/iPadOS debug profile. See the instructions on our Bug Reporting > Profiles and Logs page.
  2. Reproduce the problem.
  3. Immediately after seeing it, trigger a sysdiagnose log.
  4. Attach that log to your bug report.

It might also help if you captured an RVI packet trace of the problem and attached that to the bug report. See Recording a Packet Trace for info on how to do that.

Share and Enjoy

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

The log size is too large to attach and cannot be transferred. Is there a way to transfer it?

The log size is too large to attach

To large to attach where?

My suggestion is that you attach this stuff to your bug report in Feedback Assistant, and it accepts very large attachments.

Share and Enjoy

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

I attached sysdiagnose logs to https://feedbackassistant.apple.com/feedback/18597374.

One is success logs in iOS18. The other is failed logs in iOS26. Please check these logs.

I attached sysdiagnose logs to [FB18597374]

Thanks.

I checked your bug and it looks like the logs arrived correctly this time. Cool.

Please check these logs.

Just to be clear, I personally won’t be looking at these logs. Rather, this bug is being investigated by our engineering teams. If they need to get in touch, they’ll do so via your Feedback Assistant report. I recommend that you keep a close eye on that.

Share and Enjoy

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

Socket exception errSSLPeerBadCert CFStreamErrorDomainSSL Code -9825
 
 
Q