I believe the underlying issue here is that iOS 9’s App Transport Security (ATS) is more strict in its default configuration than web browsers are. We’ve tried to relax those restrictions somewhat in OmniPresence to allow you to connect to arbitrary servers, but they’re still not as relaxed as what web browsers allow.
If you have access to OS X, you could try using
nscurl to see exactly what ATS thinks is wrong with the connection. Quoting from a useful blog post by Tim Ekl (one of our developers):
CFNETWORK_DIAGNOSTICS can be quite handy, its output can also be somewhat cryptic, and it’s a bit of a hassle to pull the log file off an iOS device. If you have access to an OS X machine running 10.11 or later, the command-line utility
nscurl provides some basic ATS debugging capabilities. Simply open a Terminal and run:
nscurl --ats-diagnostics https://example.com
The tool will run through several different combinations of ATS exceptions, trying a secure connection to the given host under each ATS configuration and reporting the result. The ATS configuration changes made by nscurl include:
- Turning on the “allow arbitrary loads” flag
- Dropping the minimum required TLS version to 1.1, then 1.0
- Removing the Perfect Forward Secrecy (PFS) requirement
--verbose flag alongside
nscurl to also output the exact ATS configuration dictionary being used for each connection, as well as the error returned in its internal NSURLSessionDelegate implementation.
If you can’t resolve this on your end (for example, if the Synology allows TLS 1.0 connections which ATS considers insecure), this might be something we need to fix OmniOutliner.