We're running into an issue with certificate trust exceptions that is a bit puzzling. We have the following situation, starting with a pretty normal sequence: - NSURLConnection configured to use a background serial NSOperationQueue for delegate callbacks - … connecting to a server with a self-signed certificate - On the first attempt, we get a challenge and notice we have no trust exceptions for the certificate, so we call -continueWithoutCredentialForAuthenticationChallenge: - The user confirms this is OK via SFCertificateTrustPanel, but only for now (so the certificate isn't added to Keychain) - We archive the trust exception data in an in-memory store of temporarily approved exceptions - The operation is started again, we notice it is user-approved and we use +credentialForTrust: and -useCredential:forAuthenticationChallenge: (and then provide actual user credentials on the next challenge). But then: - Shut down the Apache server, generate a new certificate and restart it (client app still running) - On the next client connection, we do get a certificate challenge, notice we don't trust it and call -continueWithoutCredentialForAuthenticationChallenge: - But the connection proceeds anyway! We've also tried -performDefaultHandlingForAuthenticationChallenge:, -rejectProtectionSpaceAndContinueWithChallenge:, and -useCredential:forAuthenticationChallenge: (with nil credentials here), but they have the same issue. Calling -cancelAuthenticationChallenge: deadlocks in NSOperationQueue-based connections, sadly (which I have yet to build a reproducible test case for, sadly). Any thoughts on whether we are doing things right here? Known bug? Thanks! -tim _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists... This email sent to site_archiver@lists.apple.com