Mojave
App Transport Security allow all connections override removed from plist
I need to talk to a self-signed server from a daemon process running even when no user is logged in.
I added the cert for the server to the System keychain.
this succeeds:
nscurl --ats-diagnostics https://insideFirewall.mydomain.com/blah
this fails:
sudo nscurl --ats-diagnostics https://insideFirewall.mydomain.com/blah
Is this expected?
Is this a bug?
Am I doing something wrong?
Thanks.
Customers use self-signed servers inside of their firewalls.
I try to avoid using self-signed certificates where possible. In most managed environments it’s better for the manager to set up a certificate authority (CA) and then install that CA’s root certificate on client machines via MDM. They can then use that CA to issue certificates to an internal server, and code running on client machines will trust that server in the same way it’d trust any other server.
From your perspective the main advantage to this approach is that you don’t have to write any code to customise server trust evaluation. You can just connect to the server and both ATS (if applicable) and RFC 2818-style server trust evaluation checks will succeed.
it would make sense for ATS to be able to be enabled (…) for our daemon.
True. Currently there’s no way for daemons to opt in to ATS, but that would make a fine enhancement request.
If you do file an enhancement request, please post your bug number here, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"In general App Transport Security (ATS) does not apply to daemons. The “App” in the name is meant to be taken literally: The extra security checks done by ATS only apply to apps and app-like things, for example, app extensions. Given that, testing with
nscurl--ats-diagnosticsI need to talk to a self-signed server from a daemon process running even when no user is logged in.
You shouldn’t need to mess with ATS to achieve this goal. The best way to proceed really depends on the specifics of your environment. Is this a test server? A server deployed in a managed environment, like a business or a school? A local server, for example, on a Wi-Fi based accessory? Or something else?
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"Customers use self-signed servers inside of their firewalls.
If we add the cert to the system keychain then it would make sense for ATS to be able to be enabled (as a security conformance/best practices type of thing) for our daemon.
However, if that isn't how it works, then we don't have that option.
Thanks much for the clarification.
Customers use self-signed servers inside of their firewalls.
I try to avoid using self-signed certificates where possible. In most managed environments it’s better for the manager to set up a certificate authority (CA) and then install that CA’s root certificate on client machines via MDM. They can then use that CA to issue certificates to an internal server, and code running on client machines will trust that server in the same way it’d trust any other server.
From your perspective the main advantage to this approach is that you don’t have to write any code to customise server trust evaluation. You can just connect to the server and both ATS (if applicable) and RFC 2818-style server trust evaluation checks will succeed.
it would make sense for ATS to be able to be enabled (…) for our daemon.
True. Currently there’s no way for daemons to opt in to ATS, but that would make a fine enhancement request.
If you do file an enhancement request, please post your bug number here, just for the record.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"