Hi. We are writing to report a critical issue we've encountered following the recent release of iOS 26 beta 6.
After updating our test devices, we discovered that our application is no longer able to establish HTTPS connections to several of our managed FQDNs. This issue was not present in beta 5 and appears to be a direct result of changes introduced in beta 6. The specific FQDNs that are currently unreachable are:
- d.socdm.com
- i.socdm.com
- tg.scodm.com
We have reviewed the official iOS & iPadOS 26 Beta 6 Release Notes, particularly the updates related to TLS. While the notes mention changes, we have confirmed that our servers for all affected FQDNs support TLS 1.2, so we believe they should still be compliant. We have also investigated several of Apple's support documents regarding TLS connection requirements (e.g., HT214774, HT214041), but the information does not seem to apply to our situation, and we are currently unable to identify the root cause of this connection failure.
Although we hope this issue might be resolved in beta 7 or later, the official release is fast approaching, and this has become a critical concern for us.
Could you please provide any advice or insight into what might be causing this issue? Any guidance on potential changes in the networking or security frameworks in beta 6 that could affect TLS connections would be greatly appreciated. We have attached the relevant code snippet that triggers the error, along with the corresponding Xcode logs, for your review. Thank you for your time and assistance.
#import "ViewController.h"
@interface ViewController ()
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
NSURL *url = [NSURL URLWithString:@"https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js"];
NSMutableURLRequest *req = [NSMutableURLRequest requestWithURL:url
cachePolicy:NSURLRequestReloadIgnoringLocalCacheData
timeoutInterval:30.0];
[self sendWithRequest:req completionHandler:^(NSData *_Nullable data,
NSHTTPURLResponse *_Nonnull response,
NSError *_Nullable error) {
if (error){
NSLog(@"Error occurred: %@", error.localizedDescription);
return;
}else{
NSLog(@"Success! Status Code: %ld", (long)response.statusCode);
}
}];
}
- (void) sendWithRequest:(NSMutableURLRequest *)request
completionHandler:(void (^ _Nullable)(NSData *_Nullable data,
NSHTTPURLResponse *response,
NSError *_Nullable error))completionHandler {
NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
NSURLSession *session = nil;
session = [NSURLSession sessionWithConfiguration:configuration
delegate:self
delegateQueue:nil];
NSURLSessionTask *task = [session dataTaskWithRequest:request
completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
[session finishTasksAndInvalidate];
NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *) response;
if (error) {
if (completionHandler) {
completionHandler(nil, httpResponse, error);
}
}
else {
if (completionHandler) {
completionHandler(data, httpResponse, nil);
}
}
}];
[task resume];
}
@end
- error
Connection 1: default TLS Trust evaluation failed(-9807)
Connection 1: TLS Trust encountered error 3:-9807
Connection 1: encountered error(3:-9807)
Task <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1> HTTP load failed, 0/0 bytes (error code: -1202 [3:-9807])
Task <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1> finished with error [-1202] Error Domain=NSURLErrorDomain Code=-1202 "The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk." UserInfo={NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, NSErrorPeerCertificateChainKey=(
"<cert(0x10621ca00) s: *.socdm.com i: GlobalSign RSA OV SSL CA 2018>",
"<cert(0x106324e00) s: GlobalSign RSA OV SSL CA 2018 i: GlobalSign>"
), NSErrorClientCertificateStateKey=0, NSErrorFailingURLKey=https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js, NSErrorFailingURLStringKey=https://i.socdm.com/sdk/js/adg-script-loader-b-stg.js, NSUnderlyingError=0x1062bf960 {Error Domain=kCFErrorDomainCFNetwork Code=-1202 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x10609d140>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9807, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9807, kCFStreamPropertySSLPeerCertificates=(
"<cert(0x10621ca00) s: *.socdm.com i: GlobalSign RSA OV SSL CA 2018>",
"<cert(0x106324e00) s: GlobalSign RSA OV SSL CA 2018 i: GlobalSign>"
)}}, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1>"
), _kCFStreamErrorCodeKey=-9807, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <C50BB081-E1DA-40FF-A1E5-A03A2C4CB733>.<1>, NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x10609d140>, NSLocalizedDescription=The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk.}
Error occurred: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “i.socdm.com” which could put your confidential information at risk.
折りたたむ
First up, I want to pass along a big “thank you” from the folks who manage our CT infrastructure. Your bug let them quickly identify the root cause of this issue, which is a configuration problem at our end O-:
The timing of this is a bit tricky. I can’t predict the future, obviously, but there may be a short window (weeks not months) between the release of iOS 26 and the release of this fix where your customers are affected by the issue. If that’s likely to cause you significant grief, you’ll need a workaround.
To understand the workaround I need to explain a little bit about the bug…
The bug you’ve found means that iOS won’t trust certificates issued by your CA in the 8 hours between 2026-07-01 00:00:00 GMT and 2026-07-01 08:00:00 GMT. And lo! your server’s certificate just happens to expire in that range:
% openssl x509 -inform der -in leaf.cer -text
…
Validity
Not Before: May 30 06:03:02 2025 GMT
Not After : Jul 1 06:03:01 2026 GMT
…
That’s just bad luck )-:
The workaround is to ask your CA to issue you a new certificate that expires outside of that window. Once you update your servers to use that, you’ll no longer see this failure.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"