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()
}
Prioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I have a small command-line app I've been using for years to process files. I have it run by an Automator script, so that I can drop files onto it. It stopped working this morning.
At first, I could still run the app from the command line, without Automator. But then after I recompiled the app, now I cannot even do that. When I run it, it's saying 'zsh: killed' followed by my app's path. What is that?
The app does run if I run it from Xcode.
How do I fix this?
Topic:
Privacy & Security
SubTopic:
General
Hi,
I develop a Mac application, initially on Catalina/Xcode12, but I recently upgrade to Monterey/Xcode13. I'm about to publish a new version: on Monterey all works as expected, but when I try the app on Sequoia, as a last step before uploading to the App Store, I encountered some weird security issues:
The main symptom is that it's no longer possible to save any file from the app using the Save panel, although the User Select File entitlement is set to Read/Write.
I've tried reinstalling different versions of the app, including the most recent downloaded from TestFlight. But, whatever the version, any try to save using the panel (e.g. on the desktop) results in a warning telling that I don't have authorization to record the file to that folder.
Moreover, when I type spctl -a -t exec -v /Applications/***.app in the terminal, it returns rejected, even when the application has been installed by TestFlight.
An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app returns a valid signature. I'm lost...
It suspect a Gate Keeper problem, but I cannot found any info on the web about how this system could be reset. I tried sudo spctl --reset-default, but it returns This operation is no longer supported...
I wonder if these symptoms depend on how the app is archived and could be propagated to my final users, or just related to a corrupted install of Sequoia on my local machine. My feeling is that a signature problem should have been detected by the archive validation, but how could we be sure?
Any idea would be greatly appreciated, thanks!
We recently deployed Attestation on our application, and for a majority of the 40,000 users it works well. We have about six customers who are failing attestation. In digging through debug logs, we're seeing this error "iOS assertion verification failed. Unauthorized access attempted." We're assuming that the UUID is blocked somehow on Apple side but we're stumped as to why. We had a customer come in and we could look at the phone, and best we can tell it's just a generic phone with no jailbroken or any malicious apps. How can we determine if the UUID is blocked?
The Core Problem
After Users sign out from the App, the app isn’t properly retrieving the user on second sign in. Instead, it’s treating the user as “Unknown” and saving a new entry in CloudKit and locally. Is there a tutorial aside from 'Juice' that is recent and up to date?
I'm writing an app on macOS that stores passwords in the Keychain and later retrieves them using SecItemCopyMatching(). This works fine 90% of the time. However, occasionally, the call to SecItemCopyMatching() fails with errSecAuthFailed (-25293). When this occurs, simply restarting the app resolves the issue; otherwise, it will consistently fail with errSecAuthFailed.
What I suspect is that the Keychain access permission has a time limitation for a process. This issue always seems to arise when I keep my app running for an extended period.
In iOS 18, i use CNContactPickerViewController to access to Contacts (i know it is one-time access).
After first pick up one contact, the Setting > Apps > my app > Contacts shows Private Access without any option to close it.
Is there any way to close it and undisplay it ?
I tried to uninstall and reinstall my app, but it didn't work.
Hi,
I'm working on developing my own CryptoTokenKit (CTK) extension to enable codesign with HSM-backed keys. Here's what I’ve done so far:
The container app sets up the tokenConfiguration with TKTokenKeychainCertificate and TKTokenKeychainKey.
The extension registers successfully and is visible via pluginkit when launching the container app.
The virtual smartcard appears when running security list-smartcards.
The certificate, key, and identity are all visible using security export-smartcard -i [card].
However, nothing appears in the Keychain.
After adding logging and reviewing output in the Console, I’ve observed the following behavior when running codesign:
My TKTokenSession is instantiated correctly, using my custom TKToken implementation — so far, so good.
However, none of the following TKTokenSession methods are ever called:
func tokenSession(_ session: TKTokenSession, beginAuthFor operation: TKTokenOperation, constraint: Any) throws -> TKTokenAuthOperation
func tokenSession(_ session: TKTokenSession, supports operation: TKTokenOperation, keyObjectID: TKToken.ObjectID, algorithm: TKTokenKeyAlgorithm) -> Bool
func tokenSession(_ session: TKTokenSession, sign dataToSign: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data
func tokenSession(_ session: TKTokenSession, decrypt ciphertext: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data
func tokenSession(_ session: TKTokenSession, performKeyExchange otherPartyPublicKeyData: Data, keyObjectID objectID: Any, algorithm: TKTokenKeyAlgorithm, parameters: TKTokenKeyExchangeParameters) throws -> Data
The only relevant Console log is:
default 11:31:15.453969+0200 PersistentToken [0x154d04850] invalidated because the client process (pid 4899) either cancelled the connection or exited
There’s no crash report related to the extension, so my assumption is that ctkd is closing the connection for some unknown reason.
Is there any way to debug this further?
Thank you for your help.
Can you please give me a hand with importing certificates under MacOS?
I want to connect to Wi-Fi with 802.1X authentication (EAP-TLS) using a certificate that my homebrew application imported into my data protection keychain, but the imported certificate does not show up and I cannot select the certificate.
It also does not show up in the Keychain Access app.
One method I have tried is to import it into the data protection keychain by using the SecItemAdd function and setting kSecUseDataProtectionKeychain to true, but it does not work.
Is there a better way to do this?
ID:
for id in identities {
let identityParams: [String: Any] = [
kSecValueRef as String: id,
kSecReturnPersistentRef as String: true,
kSecUseDataProtectionKeychain as String: true
]
let addIdentityStatus = SecItemAdd(identityParams as CFDictionary, nil)
if addIdentityStatus == errSecSuccess {
print("Successfully added the ID.: \(addIdentityStatus)")
} else {
print("Failed to add the ID.: \(addIdentityStatus)")
}
}
Certificate:
for cert in certificates {
let certParams: [String: Any] = [
kSecValueRef as String: cert,
kSecReturnPersistentRef as String: true,
kSecUseDataProtectionKeychain as String: true
]
let addCertStatus = SecItemAdd(certParams as CFDictionary, nil)
if addCertStatus == errSecSuccess {
print("Successfully added the certificate.: (\(addCertStatus))")
} else {
print("Failed to add the certificate.: (\(addCertStatus))")
}
}
Private key:
for privateKey in keys {
let keyTag = UUID().uuidString.data(using: .utf8)!
let keyParams: [String: Any] = [
kSecAttrApplicationTag as String: keyTag,
kSecValueRef as String: privateKey,
kSecReturnPersistentRef as String: true,
kSecUseDataProtectionKeychain as String: true
]
let addKeyStatus = SecItemAdd(keyParams as CFDictionary, nil)
if addKeyStatus == errSecSuccess {
print("Successfully added the private key.: \(addKeyStatus)")
} else {
print("Failed to add the private key.: \(addKeyStatus)")
}
}
Hi Apple Team and Community,
We encountered a sudden and widespread failure related to the App Attest service on Friday, July 25, starting at around 9:22 AM UTC.
After an extended investigation, our network engineers noted that the size of the attestation objects received from the attestKey call grew in size notably starting at that time. As a result, our firewall began blocking the requests from our app made to our servers with the Base64-encoded attestation objects in the payload, as these requests began triggering our firewall's max request length rule.
Could Apple engineers please confirm whether there was any change rolled out by Apple at or around that time that would cause the attestation object size to increase?
Can anyone else confirm seeing this?
Any insights from Apple or others would be appreciated to ensure continued stability.
Thanks!
Is there a way to unlock login keychain without using password and with any other authentication factor supported by 3rd party MFA options?
Hello, I am currently researching to develop an application where I want to apply the MacOS updates without the password prompt shown to the users.
I did some research on this and understand that an MDM solution can apply these patches without user intervention.
Are there any other ways we can achieve this? Any leads are much appreciated.
Having trouble decrypting a string using an encryption key and an IV.
var key: String
var iv: String
func decryptData(_ encryptedText: String) -> String?
{
if let textData = Data(base64Encoded: iv + encryptedText) {
do {
let sealedBox = try AES.GCM.SealedBox(combined: textData)
let key = SymmetricKey(data: key.data(using: .utf8)!)
let decryptedData = try AES.GCM.open(sealedBox, using: key)
return String(data: decryptedData, encoding: .utf8)
} catch {
print("Decryption failed: \(error)")
return nil
}
}
return nil
}
Proper coding choices aside (I'm just trying anything at this point,) the main problem is opening the SealedBox. If I go to an online decryption site, I can paste in my encrypted text, the encryption key, and the IV as plain text and I can encrypt and decrypt just fine.
But I can't seem to get the right combo in my Swift code. I don't have a "tag" even though I'm using the combined option. How can I make this work when all I will be receiving is the encrypted text, the encryption key, and the IV. (the encryption key is 256 bits)
Try an AES site with a key of 32 digits and an IV of 16 digits and text of your choice. Use the encrypted version of the text and then the key and IV in my code and you'll see the problem. I can make the SealedBox but I can't open it to get the decrypted data. So I'm not combining the right things the right way. Anyone notice the problem?
Topic:
Privacy & Security
SubTopic:
General
Trying to validate external reference identifiers with SecTrustEvaluateWithError Method by setting reference Ids to SecPolicyCreateSSL() & SecPolicyCreateWithProperties()
But two concerns are -
Validates for correct reference IDs but gives error for combination of wrong & correct reference Ids
398 days validity works mandatorily before reference Ids check.
Is there any other to validate external reference Ids?, which give flexibility
To pass multiple combinations of reference IDs string (wrong, correct, IP, DNS)
To validate reference ID without days validity of 398.
Please suggest. Any help here is highly appreciated.
I am developing a macOS application (targeting macOS 13 and later) that is non-sandboxed and needs to install and trust a root certificate by adding it to the System keychain programmatically.
I’m fine with prompting the user for admin privileges or password, if needed.
So far, I have attempted to execute the following command programmatically from both:
A user-level process
A root-level process
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.pem
While the certificate does get installed, it does not appear as trusted in the Keychain Access app.
One more point:
The app is not distributed via MDM.
App will be distributed out side the app store.
Questions:
What is the correct way to programmatically install and trust a root certificate in the System keychain?
Does this require additional entitlements, signing, or profile configurations?
Is it possible outside of MDM management?
Any guidance or working samples would be greatly appreciated.
WebAuthn Level 3 § 6.3.2 Step 2 states the authenticator must :
Check if at least one of the specified combinations of PublicKeyCredentialType and cryptographic parameters in credTypesAndPubKeyAlgs is supported. If not, return an error code equivalent to "NotSupportedError" and terminate the operation.
On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and an ES256 credential is created when an RP passes a non-empty sequence that does not contain {"type":"public-key","alg":-7} (e.g., [{"type":"public-key","alg":-8}]).
When I use Chromium 138.0.7204.92 on my laptop running Arch Linux in conjunction with the Passwords app (connected via the "hybrid" protocol), a credential is not created and instead an error is reported per the spec.
Binary code is associated with the NSUserTrackingUsageDescription deleted at present, but in the revised App privacy will contain NSUserTrackingUsageDescription, I feel very confused, don't know should shouldn't solve.
I am trying to generate public and private keys for an ECDH handshake.
Back end is using p256 for public key. I am getting a failed request with status 0
public func makeHandShake(completion: @escaping (Bool, String?) -> ()) {
guard let config = self.config else { completion(false,APP_CONFIG_ERROR)
return
}
var rData = HandshakeRequestTwo()
let sessionValue = AppUtils().generateSessionID()
rData.session = sessionValue
//generating my ECDH Key Pair
let sPrivateKey = P256.KeyAgreement.PrivateKey()
let sPublicKey = sPrivateKey.publicKey
let privateKeyBase64 = sPrivateKey.rawRepresentation.base64EncodedString()
print("My Private Key (Base64): \(privateKeyBase64)")
let publicKeyBase64 = sPublicKey.rawRepresentation.base64EncodedString()
print("My Public Key (Base64): \(publicKeyBase64)")
rData.value = sPublicKey.rawRepresentation.base64EncodedString()
let encoder = JSONEncoder()
do {
let jsonData = try encoder.encode(rData)
if let jsonString = String(data: jsonData, encoding: .utf8) {
print("Request Payload: \(jsonString)")
}
} catch {
print("Error encoding request model to JSON: \(error)")
completion(false, "Error encoding request model")
return
}
self.rsaReqResponseHandler(config: config, endpoint: config.services.handShake.endpoint, model: rData) { resToDecode, error in
print("Response received before guard : \(resToDecode ?? "No response")")
guard let responseString = resToDecode else {
print("response string is nil")
completion(false,error)
return
}
print("response received: \(responseString)")
let decoder = JSONDecoder()
do {
let request = try decoder.decode(DefaultResponseTwo.self, from: Data(responseString.utf8))
let msg = request.message
let status = request.status == 1 ? true : false
completion(status,msg)
guard let serverPublicKeyBase64 = request.data?.value else {
print("Server response is missing the value")
completion(false, config.messages.serviceError)
return
}
print("Server Public Key (Base64): \(serverPublicKeyBase64)")
if serverPublicKeyBase64.isEmpty {
print("Server public key is an empty string.")
completion(false, config.messages.serviceError)
return
}
guard let serverPublicKeyData = Data(base64Encoded: serverPublicKeyBase64) else {
print("Failed to decode server public key from Base64. Data is invalid.")
completion(false, config.messages.serviceError)
return
}
print("Decoded server public key data: \(serverPublicKeyData)")
guard let serverPublicKey = try? P256.KeyAgreement.PublicKey(rawRepresentation: serverPublicKeyData) else {
print("Decoded server public key data is invalid for P-256 format.")
completion(false, config.messages.serviceError)
return
}
// Derive Shared Secret and AES Key
let sSharedSecret = try sPrivateKey.sharedSecretFromKeyAgreement(with: serverPublicKey)
// Derive AES Key from Shared Secret
let symmetricKey = sSharedSecret.hkdfDerivedSymmetricKey(
using: SHA256.self,
salt: "AES".data(using: .utf8) ?? Data(),
sharedInfo: Data(),
outputByteCount: 32
)
// Storing AES Key in Config
let symmetricKeyBase64 = symmetricKey.withUnsafeBytes { Data($0) }.base64EncodedString()
print("Derived Key: \(symmetricKeyBase64)")
self.config?.cryptoConfig.key = symmetricKeyBase64
AppUtils.Log(from: self, with: "Handshake Successful, AES Key Established")
} catch {
AppUtils.Log(from: self, with: "Handshake Failed :: \(error)")
completion(false, self.config?.messages.serviceError)
}
}
} this is request struct model public struct HandshakeRequestTwo: Codable {
public var session: String?
public var value: String?
public enum CodingKeys: CodingKey {
case session
case value
}
public init(session: String? = nil, value: String? = nil) {
self.session = session
self.value = value
}
} This is backend's response {"message":"Success","status":1,"data":{"senderId":"POSTBANK","value":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAErLxbfQzX+xnYVT1LLP5VOKtkMRVPRCoqYHcCRTM64EMEOaRU16yzsN+2PZMJc0HpdKNegJQZMmswZtg6U9JGVw=="}} This is my response struct model public struct DefaultResponseTwo: Codable {
public var message: String?
public var status: Int?
public var data: HandshakeData?
public init(message: String? = nil, status: Int? = nil, data: HandshakeData? = nil) {
self.message = message
self.status = status
self.data = data
}
}
public struct HandshakeData: Codable {
public var senderId: String?
public var value: String?
public init(senderId: String? = nil, value: String? = nil) {
self.senderId = senderId
self.value = value
}
}
Hello,
I'm an application developer related to Apple system extensions. I developed an endpoint security system extension that can run normally before the 14.x system. However, after I upgraded to 15.x, I found that when I uninstalled and reinstalled my system extension, although the system extension was installed successfully, a system warning box would pop up when I clicked enable in the Settings, indicating a failure.
I conducted the following test. I reinstalled a brand-new MAC 15.x system. When I installed my applications, the system extensions could be installed successfully and enabled normally. However, when I uninstalled and reinstalled, my system extension couldn't be enabled properly and a system warning popped up as well. I tried disabling SIP and enabling System Extension Developers, but it still didn't work.
When the system warning box pops up, I can see some error log information through the console application, including an error related to
Failed to authorize right 'com.apple.system-extensions.admin' by client '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] for authorization created by '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] (3,0) (-60005) (engine 179)
as shown in the screenshot.
The same problem, mentioned in Cannot approve some extensions in MacOS Sequoia , but there is no solution
Dear Apple Developer Technical Support,
We are currently following the official Apple documentation “TN3159: Migrating Sign in with Apple users for an app transfer” to carry out a Sign in with Apple user migration after successfully transferring several apps to a new developer account.
Here is a summary of our situation:
Under the original Apple developer account, we had five apps using Sign in with Apple, grouped under a shared primary app using App Grouping.
Recently, we transferred three of these apps to our new Apple developer account via App Store Connect.
After the transfer, these three apps are no longer associated with the original primary App ID. We reconfigured individual Services IDs for each app in the new account and enabled Sign in with Apple for each.
More than 24 hours have passed since the app transfer was completed.
Now we are attempting to follow the migration process to restore user access via the user.migration flow. Specifically, we are using the following script to request an Apple access token:
url = "https://appleid.apple.com/auth/token"
headers = {"Content-Type": "application/x-www-form-urlencoded"}
data = {
"grant_type": "client_credentials",
"scope": "user.migration",
"client_id": "com.game.friends.ios.toptop.sea", # New Services ID in the new account
"client_secret": "<JWT signed with new p8 key>"
}
response = requests.post(url, headers=headers, data=data)
However, the API response consistently returns:
{
"error": "invalid_client"
}
We have verified that the following configurations are correct:
The client_secret is generated using the p8 key from the new account, signed with ES256 and correct key_id, team_id, and client_id.
The client_id corresponds to the Services ID created in the new account and properly associated with the migrated app.
The scope is set to user.migration.
The JWT payload contains correct iss, sub, and aud values as per Apple documentation.
The app has been fully transferred and reconfigured more than 24 hours ago.
Problem Summary & Request for Support:
According to Apple’s official documentation:
“After an app is transferred, Apple updates the Sign in with Apple configuration in the background. This can take up to 24 hours. During this time, attempts to authenticate users or validate tokens may fail.”
However, we are still consistently receiving invalid_client errors after the 24-hour waiting period. We suspect one of the following issues:
The transferred apps may still be partially associated with the original App Grouping or primary App ID.
Some Sign in with Apple configuration in Apple’s backend may not have been fully updated after the transfer.
Or the Services ID is not yet fully operational for the transferred apps in the new account.
We kindly request your assistance to:
Verify whether the transferred apps have been completely detached from the original App Grouping and primary App ID.
Confirm whether the new Services IDs under the new account are fully functional and eligible for Sign in with Apple with user.migration scope.
Help identify any remaining configuration or migration issues that may cause the invalid_client error.
If necessary, assist in manually ungrouping or clearing any residual App Grouping relationships affecting the new environment.
We have also generated and retained the original transfer_sub identifiers and are fully prepared to complete the sub mapping once the user.migration flow becomes functional.
Thank you very much for your time and support!
Topic:
Privacy & Security
SubTopic:
Sign in with Apple
Tags:
Sign in with Apple REST API
Sign in with Apple