We are using the Network framework to open TLS listener on the network and set options this way: configure_tls = ^(nw_protocol_options_t tls_options) { sec_protocol_options_t sec_options = nw_tls_copy_sec_protocol_options(tls_options); sec_identity_t sec_identity=sec_identity_create(identity); sec_protocol_options_set_local_identity(sec_options, sec_identity); sec_protocol_options_set_min_tls_protocol_version(sec_options, tls_protocol_version_TLSv12); sec_options=nil; }; This works fine; however, the listener's TLS negotiation only returns the certificate, not the trust chain. We have a requirement from a government agency to return the trust chain: "In addition to the certificate itself, you should provide a “chain” of intermediate certificates that give the connecting browser or client enough information to connect the certificate to a trusted root certificate. Failing to provide intermediates could prevent various browsers and clients from successfully connecting to your service, especially mobile browsers and non-browser clients (such as cURL, and tools based on libcurl). Some browsers will cache intermediates from a previous connection or attempt to automatically download missing intermediates that are presented in a certificate’s Authority Information Access (https://tools.ietf.org/html/rfc5280#section-4.2.2.1) extension, and so it can be easy to miss this problem during initial configuration. Though most browsers have an option to inspect the certificates on a site, they vary in whether they show the exact certificates the server presented or a chain as reconstructed through the fetching of an intermediate listed in the AIA extension. In general: You do not need to serve the trusted root that the certificate chains to. The client will compare the chain to a local root store, so serving the root will only waste bytes and slow the connection. You do need to serve any intermediate certificates that connect your web server certificate to the trusted root. Doing so removes the potential for problems caused by the variation in how clients facilitate trust verification." Is there a way to provide the chain of trust in the TLS options? I could not find any way to do this.

I have a macOS app with a helper tool that communicates via an XPC connection. In 10.15 Beta 4, a document-based security scoped bookmark fails when it is passed from the main macOS app to the helper app.In the sample code below from the main app, a bookmark is created from a URL and the attribute is saved on “/Users/tperfitt/passing”: NSURL *wimURL=[NSURL fileURLWithPath:@"/Users/tperfitt/Desktop/test.winclone/Windows.wim"]; NSError *error; NSData *bookmark = [wimURL bookmarkDataWithOptions:NSURLBookmarkCreationWithSecurityScope includingResourceValuesForKeys:nil relativeToURL:[NSURL fileURLWithPath:@"/Users/tperfitt/passing"] error:&error]; If I resolve this in the main app, it resolves fine. However, if I pass the NSData to the helper app over an XPC connection and attempt to resolve it, it resolves as nil and error is set. The system log shows:2019-07-23 18:02:03.577313-0500 localhost com.twocanoes.WincloneHelper[3026]: (CoreServicesInternal) the ScopedBookmarkAgent service could not be found (configuration error)I verified that the NSData is being passed from the main app to the helper app: NSURL *url = [NSURL URLByResolvingBookmarkData:data options:NSURLBookmarkResolutionWithSecurityScope relativeToURL:[NSURL fileURLWithPath:@"/Users/tperfitt/passing"] bookmarkDataIsStale:NULL error:&error];This returns nil and the error is set as :Error Domain=NSCocoaErrorDomain Code=256 "ScopedBookmarksAgent did not return error domain during resolution" UserInfo={NSDebugDescription=ScopedBookmarksAgent did not return error domain during resolution}The file has an xattr on it:root@MacBook-Pro ~ # xattr passing com.apple.security.private.scoped-bookmark-keyI expected that the helper tool could resolve the URL and have access to the file. Instead, it returned nil.