General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello everyone. Hope this one finds you well) I have an issue with integrating a FIDO2 server with ASAuthorizationController. I have managed to register a user with passkey successfully, however when authenticating, the request for authentication response fails. The server can't validate signature field. I can see 2 possible causes for the issue: ASAuthorizationPlatformPublicKeyCredentialAssertion.rawAuthenticatorData contains invalid algorithm information (the server tries ES256, which ultimately fails with false response), or I have messed up Base64URL encoding for the signature property (which is unlikely, since all other fields also require Base64URL, and the server consumes them with no issues). So the question is, what encryption algorithm does ASAuthorizationController use? Maybe someone has other ideas regarding where to look into? Please help. Thanks)

I am working on implementing mTLS authentication in my iOS app (Apple Inhouse & intune MAM managed app). The SCEP client certificate is deployed on the device via Intune MDM. When I try accessing the protected endpoint via SFSafariViewController/ASWebAuthenticationSession, the certificate picker appears and the request succeeds. However, from within my app (using URLSessionDelegate), the certificate is not found (errSecItemNotFound). The didReceive challenge method is called, but my SCEP certificate is not found in the app. The certificate is visible under Settings > Device Management > SCEP Certificate. How can I make my iOS app access and use the SCEP certificate (installed via Intune MDM) for mTLS requests? Do I need a special entitlement, keychain access group, or configuration in Intune or Developer account to allow my app to use the certificate? Here is the sample code I am using: final class KeychainCertificateDelegate: NSObject, URLSessionDelegate { func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodClientCertificate else { completionHandler(.performDefaultHandling, nil) return } // Get the DNs the server will accept guard let expectedDNs = challenge.protectionSpace.distinguishedNames else { completionHandler(.cancelAuthenticationChallenge, nil) return } var identityRefs: CFTypeRef? = nil let err = SecItemCopyMatching([ kSecClass: kSecClassIdentity, kSecMatchLimit: kSecMatchLimitAll, kSecMatchIssuers: expectedDNs, kSecReturnRef: true, ] as NSDictionary, &identityRefs) if err != errSecSuccess { completionHandler(.cancelAuthenticationChallenge, nil) return } guard let identities = identityRefs as? [SecIdentity], let identity = identities.first else { print("Identity list is empty") completionHandler(.cancelAuthenticationChallenge, nil) return } let credential = URLCredential(identity: identity, certificates: nil, persistence: .forSession) completionHandler(.useCredential, credential) } } func perform_mTLSRequest() { guard let url = URL(string: "https://sample.com/api/endpoint") else { return } var request = URLRequest(url: url) request.httpMethod = "POST" request.setValue("application/json", forHTTPHeaderField: "Accept") request.setValue("Bearer \(bearerToken)", forHTTPHeaderField: "Authorization") let delegate = KeychainCertificateDelegate() let session = URLSession(configuration: .ephemeral, delegate: delegate, delegateQueue: nil) let task = session.dataTask(with: request) { data, response, error in guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { print("Bad response") return } if let data = data { print(String(data: data, encoding: .utf8)!) } } task.resume() }

Hi, We are using the MSAL library to authenticate users, with SSO authentication implemented through the Microsoft Authenticator app. The problem is that once or twice a day, a prompt for forced authentication appears, indicating that silent token acquisition is failing and resulting in a requirement for forced authentication. Below are some of the logs: ================================================= 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] Silent flow finished. Result (null), error: -51115 error domain: MSIDErrorDomain 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] acquireTokenSilent returning with error: (MSALErrorDomain, -50002) Masked(not-null) ==================================================== We initially raised this issue with Microsoft, but according to them: In the app's logs, the single one failure it contains, was when the SSO extension returned the error com.apple.AuthenticationServices.AuthorizationError, -6000 during a silent call. This error code is generated by the system framework (Apple), not by our code. It indicates that the framework encountered an unexpected internal issue before or after calling the SSO extension. MSAL returning interaction_required to the client app is the most effective way to recover from this error (as you mention, after the user selects the account the app continues working as expected). Additionally, as you also mention, the interactive call is made by switching to Authenticator (not displaying a "window" without leaving Eva Lite app), which means MSAL is not able to use the SSO extension and is using the fallback to legacy authentication. The recommended next step is for the customer to request support directly from Apple as this is an issue on their side. Additionally, the customer can also try to update to the latest iOS, in case Apple has already fixed this issue. ============================================= STEPS TO REPRODUCE There is no such steps its just that this is an enterprise application which is getting used on managed devices[iPhone 14]. The device are managed using some intune policy. Platform and Version: iOS Development Environment: Xcode 15, macOS 13.6.1 Run-time Configuration: iOS 18 Please let me know if there are any solutions to resolve this problem. Thank you.

Hello Apple Team We are integrating App Attest with our backend and seeing a 400 Bad Request response when calling the attestation endpoint. The issue is that the response does not include an X-Request-ID or JSON error payload with id and code, which makes it hard to diagnose. Instead, it only returns a receipt blob. Request Details URL: https://data-development.appattest.apple.com/v1/attestationData Request Headers: Authorization: eyJraWQiOiI0RjVLSzRGV1JaIiwidHlwIjoiSldUIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJOOVNVR1pNNjdRIiwiZXhwIjoxNzU3MDUxNTYwLCJpYXQiOjE3NTcwNDc5NjB9.MEQCIF236MqPCl6Vexg7RcPUMK8XQeACXogldnpuiNnGQnzgAiBQqASdbJ64g58xfWGpbzY3iohvxBSO5U5ZE3l87JjfmQ Content-Type: application/octet-stream Request Body: (Binary data, logged as [B@59fd7d35) Response Status: 400 Bad Request Response Headers: Date: Fri, 05 Sep 2025 04:52:40 GMT x-b3-traceid: 4c42e18094022424 x-b3-spanid: 4c42e18094022424 Response Body (truncated): "receipt": h'308006092A864886F70D01070... Problem The response does not include X-Request-ID. The response does not include JSON with id or code. Only a receipt blob is returned. Questions Can the x-b3-traceid be used by Apple to trace this failed request internally? Is it expected for some failures to return only a receipt blob without X-Request-ID? How should we interpret this error so we can handle it properly in production? Thanks in advance for your guidance.

Hello I'm using Auth0 for handling auth in my app When the user wants to sign in, it will show the auth system pop-up And when the user wants to log out it shows the same pop-up My issue is how to replace the Sign In text in this pop-up to show Sign Out instead of Sign In when the user wants to sign out?

Hello everyone, I'm developing a FIDO2 service using the AuthenticationServices framework. I've run into an issue when a user manually deletes a passkey from their password manager. When this happens, the ASAuthorizationError I get doesn't clearly indicate that the passkey is missing. The error code is 1001, and the localizedDescription is "The operation couldn't be completed. No credentials available for login." The userInfo also contains "NSLocalizedFailureReason": "No credentials available for login." My concern is that these localized strings will change depending on the user's device language, making it unreliable for me to programmatically check for a "no credentials" scenario. Is there a more precise way to determine that the user has no passkey, without relying on localized string values? Thank you for your help.

Hello Developers, I have ran into a problem while sending mail to apple private relay email. We have built a mobile application where user can sign up through apple and they can sign up using hide-my-email feature. Which provides private relay address for us. Now we want to communicate with them using private relay mail address. The technology we are using to send emails are amazon SES, have done SPF, DMIK, DMARC and added domains in apple identity services for mail communication, passed an SPF check as well. But still mail is not getting delivered what am i doing wrong or apple doesn't support third party apps for sending emails to private relay? Is there any other way to achieve this please let me know Using the same body as attached in image is working fine for rest emails.

We are interested in using a hardware-bound key in a launch daemon. In a previous post, Quinn explicitly told me this is not possible to use an SE keypair outside of the system context and my reading of the Apple documentation also supports that. That said, we have gotten the following key-creation and persistence flow to work, so we have some questions as to how this fits in with the above. (1) In a launch daemon (running thus as root), we do: let key = SecureEnclave.P256.Signing.PrivateKey() (2) We then use key.dataRepresentation to store a reference to the key in the system keychain as a kSecClassGenericPassword. (3) When we want to use the key, we fetch the data representation from system keychain and we "rehydrate" the key using: SecureEnclave.P256.Signing.PrivateKey(dataRepresentation: data) (4) We then use the output of the above to sign whatever we want. My questions: in the above flow, are we actually getting a hardware-bound key from the Secure Enclave or is this working because it's actually defaulting to a non-hardware-backed key? if it is an SE key, is it that the Apple documentation stating that you can only use the SE with the Data Protection Keychain in the user context is outdated (or wrong)? does the above work, but is not an approach sanctioned by Apple? Any feedback on this would be greatly appreciated.

We are using SecPKCS12Import C API in our application to import a self seigned public key certificate. We tried to run the application for the first time on Tahoe and it failed with OSStatus -26275 error. The release notes didn't mention any deprecation or change in the API as per https://developer.apple.com/documentation/macos-release-notes/macos-26-release-notes. Are we missing anything? There are no other changes done to our application.

Greetings, We are struggling to implement device binding according to your documentation. We are generation a nonce value in backend like this: public static String generateNonce(int byteLength) { byte[] randomBytes = new byte[byteLength]; new SecureRandom().nextBytes(randomBytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(randomBytes); } And our mobile client implement the attestation flow like this: @implementation AppAttestModule - (NSData *)sha256FromString:(NSString *)input { const char *str = [input UTF8String]; unsigned char result[CC_SHA256_DIGEST_LENGTH]; CC_SHA256(str, (CC_LONG)strlen(str), result); return [NSData dataWithBytes:result length:CC_SHA256_DIGEST_LENGTH]; } RCT_EXPORT_MODULE(); RCT_EXPORT_METHOD(generateAttestation:(NSString *)nonce resolver:(RCTPromiseResolveBlock)resolve rejecter:(RCTPromiseRejectBlock)reject) { if (@available(iOS 14.0, *)) { DCAppAttestService *service = [DCAppAttestService sharedService]; if (![service isSupported]) { reject(@"not_supported", @"App Attest is not supported on this device.", nil); return; } NSData *nonceData = [self sha256FromString:nonce]; NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; NSString *savedKeyId = [defaults stringForKey:@"AppAttestKeyId"]; NSString *savedAttestation = [defaults stringForKey:@"AppAttestAttestationData"]; void (^resolveWithValues)(NSString *keyId, NSData *assertion, NSString *attestationB64) = ^(NSString *keyId, NSData *assertion, NSString *attestationB64) { NSString *assertionB64 = [assertion base64EncodedStringWithOptions:0]; resolve(@{ @"nonce": nonce, @"signature": assertionB64, @"deviceType": @"IOS", @"attestationData": attestationB64 ?: @"", @"keyId": keyId }); }; void (^handleAssertion)(NSString *keyId, NSString *attestationB64) = ^(NSString *keyId, NSString *attestationB64) { [service generateAssertion:keyId clientDataHash:nonceData completionHandler:^(NSData *assertion, NSError *assertError) { if (!assertion) { reject(@"assertion_error", @"Failed to generate assertion", assertError); return; } resolveWithValues(keyId, assertion, attestationB64); }]; }; if (savedKeyId && savedAttestation) { handleAssertion(savedKeyId, savedAttestation); } else { [service generateKeyWithCompletionHandler:^(NSString *keyId, NSError *keyError) { if (!keyId) { reject(@"keygen_error", @"Failed to generate key", keyError); return; } [service attestKey:keyId clientDataHash:nonceData completionHandler:^(NSData *attestation, NSError *attestError) { if (!attestation) { reject(@"attestation_error", @"Failed to generate attestation", attestError); return; } NSString *attestationB64 = [attestation base64EncodedStringWithOptions:0]; [defaults setObject:keyId forKey:@"AppAttestKeyId"]; [defaults setObject:attestationB64 forKey:@"AppAttestAttestationData"]; [defaults synchronize]; handleAssertion(keyId, attestationB64); }]; }]; } } else { reject(@"ios_version", @"App Attest requires iOS 14+", nil); } } @end For validation we are extracting the nonce from the certificate like this: private static byte[] extractNonceFromAttestationCert(X509Certificate certificate) throws IOException { byte[] extensionValue = certificate.getExtensionValue("1.2.840.113635.100.8.2"); if (Objects.isNull(extensionValue)) { throw new IllegalArgumentException("Apple App Attest nonce extension not found in certificate."); } ASN1Primitive extensionPrimitive = ASN1Primitive.fromByteArray(extensionValue); ASN1OctetString outerOctet = ASN1OctetString.getInstance(extensionPrimitive); ASN1Sequence sequence = (ASN1Sequence) ASN1Primitive.fromByteArray(outerOctet.getOctets()); ASN1TaggedObject taggedObject = (ASN1TaggedObject) sequence.getObjectAt(0); ASN1OctetString nonceOctet = ASN1OctetString.getInstance(taggedObject.getObject()); return nonceOctet.getOctets(); } And for the verification we are using this method: private OptionalMethodResult<Void> verifyNonce(X509Certificate certificate, String expectedNonce, byte[] authData) { byte[] expectedNonceHash; try { byte[] nonceBytes = MessageDigest.getInstance("SHA-256").digest(expectedNonce.getBytes()); byte[] combined = ByteBuffer.allocate(authData.length + nonceBytes.length).put(authData).put(nonceBytes).array(); expectedNonceHash = MessageDigest.getInstance("SHA-256").digest(combined); } catch (NoSuchAlgorithmException e) { log.error("Error while validations iOS attestation: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } byte[] actualNonceFromCert; try { actualNonceFromCert = extractNonceFromAttestationCert(certificate); } catch (Exception e) { log.error("Error while extracting nonce from certificate: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } if (!Arrays.equals(expectedNonceHash, actualNonceFromCert)) { return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } return OptionalMethodResult.empty(); } But the values did not matched. What are we doing wrong here? Thanks.

I’m using a custom Installer plug-in (InstallerPane) to collect sensitive user input (username/password) during install. After the payload is laid down, I need to send those values to a newly installed agent (LaunchAgent) to persist them. What I tried I expose an XPC Mach service from the agent and have the plug-in call it. On the agent side I validate the XPC client using the audit token → SecCodeCopyGuestWithAttributes → SecCodeCheckValidity. However, the client process is InstallerRemotePluginService-* (Apple’s view service that hosts all plug-ins), so the signature I see is Apple’s, not mine. I can’t distinguish which plug-in made the call. Any suggestion on better approach ?

Hello everyone, I'm encountering a persistent 503 Server Temporarily Not Available error when trying to implement "Sign in with Apple" for my web application. I've already performed a full review of my configuration and I'm confident it's set up correctly, which makes this server-side error particularly confusing. Problem Description: Our web application uses Firebase Authentication to handle the "Sign in with Apple" flow. When a user clicks the sign-in button, they are correctly redirected to the appleid.apple.com authorization page. However, instead of seeing the login prompt, the page immediately displays a 503 Server Temporarily Not Available error. This is the redirect URL being generated (with the state parameter truncated for security): https://appleid.apple.com/auth/authorize?response_type=code&client_id=XXXXXX&redirect_uri=https%3A%2F%2FXXXXXX.firebaseapp.com%2F__%2Fauth%2Fhandler&state=AMbdmDk...&scope=email%20name&response_mode=form_post Troubleshooting Steps Performed: Initially, I was receiving an invalid_client error, which prompted me to meticulously verify every part of my setup. I have confirmed the following: App ID Configuration: The "Sign in with Apple" capability is enabled for our primary App ID. Services ID Configuration: We have a Services ID configured specifically for this. The "Sign in with Apple" feature is enabled on this Services ID. The domain is registered and verified under "Domains and Subdomains". Firebase Settings Match Apple Settings: The Services ID from Apple is used as the Client ID in our Firebase configuration. The Team ID is correct. We have generated a private key, and both the Key ID and the .p8 file have been correctly uploaded to Firebase. The key is not revoked in the Apple Developer portal. Since the redirect to Apple is happening with the correct client_id and redirect_uri, and the error is a 5xx server error (not a 4xx client error like invalid_client), I believe our configuration is correct and the issue might be on Apple's end. This has been happening consistently for some time. My Questions: What could be causing a persistent 503 Server Temporarily Not Available error on the /auth/authorize endpoint when all client-side configurations appear to be correct? What is the formal process for opening a technical support ticket (TSI) directly with Apple Developer Support for an issue like this? Thank you for any insights or help you can provide.

We are facing an issue with Keychain sharing across our apps after our Team ID was updated. Below are the steps we have already tried and the current observations: Steps we have performed so far: After our Team ID changed, we opened and re-saved all the provisioning profiles. We created a Keychain Access Group: xxxx.net.soti.mobicontrol (net.soti.mobicontrol is one bundle id of one of the app) and added it to the entitlements of all related apps. We are saving and reading certificates using this access group only. Below is a sample code snippet we are using for the query: [genericPasswordQuery setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass]; [genericPasswordQuery setObject:identifier forKey:(id)kSecAttrGeneric]; [genericPasswordQuery setObject:accessGroup forKey:(id)kSecAttrAccessGroup]; [genericPasswordQuery setObject:(id)kSecMatchLimitOne forKey:(id)kSecMatchLimit]; [genericPasswordQuery setObject:(id)kCFBooleanTrue forKey:(id)kSecReturnAttributes]; Issues we are facing: Keychain items are not being shared consistently across apps. We receive different errors at different times: Sometimes errSecDuplicateItem (-25299), even when there is no item in the Keychain. Sometimes it works in a debug build but fails in Ad Hoc / TestFlight builds. The behavior is inconsistent and unpredictable. Expectation / Clarification Needed from Apple: Are we missing any additional configuration steps after the Team ID update? Is there a known issue with Keychain Access Groups not working correctly in certain build types (Debug vs AdHoc/TestFlight)? Guidance on why we are intermittently getting -25299 and how to properly reset/re-add items in the Keychain. Any additional entitlement / provisioning profile configuration that we should double-check. Request you to please raise a support ticket with Apple Developer Technical Support including the above details, so that we can get guidance on the correct setup and resolve this issue.

Hi everyone, I'm experiencing an intermittent issue with Keychain data loss on the latest iOS Beta 2. In about 7% of cases, users report that previously saved Keychain items are missing when the app is relaunched — either after a cold start or simply after being killed and reopened. Here are the key observations: The issue occurs sporadically, mostly once per affected user, but in 3 cases it has happened 4 times. No explicit deletion is triggered from the app. No system logs or error messages from Apple indicate any Keychain-related actions. The app attempts to access Keychain items, but they are no longer available. This behavior is inconsistent with previous iOS versions and is not reproducible in development environments. This raises concerns about: Whether this is a bug in the beta or an intentional change in Keychain behavior. Whether this could affect production apps when the final iOS version is released. The lack of any warning or documentation from Apple regarding this behavior. Has anyone else encountered similar issues? Any insights, workarounds, or official clarification would be greatly appreciated. Thanks!

Hello everyone, I've noticed some unusual behavior while debugging my application on the iOS 26 beta. My standard testing process relies on the App Tracking Transparency (ATT) authorization status being reset whenever I uninstall and reinstall my app. This is crucial for me to test the permission flow. However, on the current beta, I've observed the following: 1 I installed my app on a device running the iOS 26 beta for the first time. The ATTrackingManager.requestTrackingAuthorization dialog appeared as expected. 2 I completely uninstalled the application. 3 I then reinstalled the app. Unexpected Result: The tracking permission dialog did not appear. And more importantly, the device's advertisingIdentifier appears to have remained unchanged. This is highly unusual, as the IDFA is expected to be reset with a fresh app installation. My question: Is this an intentional change, and is there a fundamental shift in how the operating system handles the persistence of the IDFA or the authorization status? Or could this be a bug in the iOS 26 beta? Any information or confirmation on this behavior would be greatly appreciated.

I added a feature to my app that retrieves only app settings (no personal data) from my API hosted on Cloudflare Workers. The app does not send, collect, track, or share any user data, and I do not store or process any personal information. Technical details such as IP address, user agent, and device information may be automatically transmitted as part of the internet protocol when the request is made, but my app does not log or use them. Cloudflare may collect this information. Question: Does this count as “data collection” for App Store Connect purposes, or can I select “No Data Collected”?

Testing my security agent plugin on Tahoe and find that when unlocking the screen, I now get an extra window that pops up over the SFAuthorizationPluginView that says "macOS You must enter a password to unlock the screen" with a Cancel (enabled) and OK button (disabled). See the attached photo. This is new with Tahoe. When unlocking the screen, I see the standard username and password entry view and I enter my password and click OK. That is when this new view appears. I can only click cancel so there is no way to complete authenticating.

Hi, I followed step by step documentation to implement SignIn with Apple in iOS/Android application. I created an AppId com.nhp.queenergy, a related ServiceId com.nhp.queenergy.apple, and a KeyId. Authorization request is correctly performed by using ServiceId as client_id and my backend redirect_uri I receive code on my backend Token request is performed by using ServiceId as client_id, same redirect_uri, the code I have just received and the client_secret as JWT signed with my .p8 certificate with the following decoded structure Header { "kid": , "typ": "JWT", "alg": "ES256" } Payload { "iss": , "sub": "com.nhp.queenergy.apple", "aud": "https://appleid.apple.com", "exp": 1756113744, "iat": 1756111944 } I always receive "invalid_grant" error without any further error description. Moreover the error is always the same even though I use any fake string as client secret. If the code expires, as expected the error changes by adding "The code has expired or has been revoked." I really don't know how to solve this issue Best regards

Private relay emails are not being delivered, even though we've followed the guidance here, https://developer.apple.com/help/account/capabilities/configure-private-email-relay-service/ iCloud, gmail etc. get delivered fine but as soon as its a private relay email address they get bounced as unauthorized sender. We've tried a couple of domains but here I'll document test.x.domain.com We have registered domains (test.x.domain.com), also the sender communication emails just to be safe (noreply at test.x.domain.com). Passed SPF Authentication, DKIM Authentication. ESP account shows as all green checks in mailgun. Is there any way to track down what the actual rejection reason is? { "@timestamp": "2025-08-20T14:30:59.801Z", "account": { "id": "6425b45fb2fd1e28f4e0110a" }, "delivery-status": { "attempt-no": 1, "bounce-type": "soft", "certificate-verified": true, "code": 550, "enhanced-code": "5.1.1", "first-delivery-attempt-seconds": 0.014, "message": "5.1.1 <bounce+b53c9e.27949-6qj4xaisn4k=privaterelay.appleid.com@test.x.domain.com>: unauthorized sender", "mx-host": "smtp3.privaterelay.appleid.com", "session-seconds": 1.7229999999999999, "tls": true }, "domain": { "name": "test.x.domain.com" }, "envelope": { "sender": "noreply@test.x.domain.com", "sending-ip": "111.22.101.215", "targets": "6qj4xaisn4k@privaterelay.appleid.com", "transport": "smtp" }, "event": "failed", "flags": { "is-authenticated": true, "is-delayed-bounce": false, "is-routed": false, "is-system-test": false, "is-test-mode": false }, "id": "1gtVBeZYQ0yO1SzipVP99Q", "log-level": "error", "message": { "headers": { "from": "\"Test Mail\" <noreply@test.x.domain.com>", "message-id": "20250820143058.7cac292cf03993f2@test.x.domain.com", "subject": "Test Mail", "to": "6qj4xaisn4k@privaterelay.appleid.com" }, "size": 22854 }, "primary-dkim": "s1._domainkey.test.x.domain.com", "reason": "generic", "recipient": "6qj4xaisn4k@privaterelay.appleid.com", "recipient-domain": "privaterelay.appleid.com", "recipient-provider": "Apple", "severity": "permanent", "storage": { "env": "production", "key": "BAABAgFDX5nmZ7fqxxxxxxZNzEVxPmZ8_YQ", "region": "europe-west1", "url": [ "https://storage-europe-west1.api.mailgun.net/v3/domains/test.x.domain.com/messages/BAABAgFDXxxxxxxxxxxxxxNzEVxPmZ8_YQ" ] }, "user-variables": {} }

Hello, We recently implemented SSL pinning in our iOS app (Objective-C) using the common approach of embedding the server certificate (.cer) in the app bundle and comparing it in URLSession:didReceiveChallenge:. This worked fine initially, but when our backend team updated the server certificate (same domain, new cert from CA), the app immediately started failing because the bundled certificate no longer matched. We’d like to avoid shipping and updating our app every time the server’s certificate changes. Instead, we are looking for the Apple-recommended / correct approach to implement SSL pinning without embedding the actual certificate file in the app bundle. Specifically: . Is there a supported way to implement pinning based on the public key hash or SPKI hash (like sha256/... pins) rather than the full certificate? . How can this be safely implemented using NSURLSession / SecTrustEvaluate (iOS 15+ APIs, considering that SecTrustGetCertificateAtIndex is deprecated)? . Are there Apple-endorsed best practices for handling certificate rotation while still maintaining strong pinning? Any guidance or code samples would be greatly appreciated. We want to make sure we are following best practices and not relying on brittle implementations. Thanks in advance!