We have some URLs that can't get valid HTTPS certs for $internalreasons. This is the same URL that our profile images get served from. It would be nice to be able to set a config variable to ignore HTTPS errors for those sites.
For magical historical reasons we actually serve an invalid cert within our production network. That is, if you visit the site in a browser on the corporate (or outside) world it works perfectly. Within production the cert has the wrong domain. This means that even adding the CA won't help since the peer name is still verified.
You may be able to call HTTPSFuture::setBlindlyTrustDomains(...) from preamble.php as a possible workaround, although you'll have to load some libraries first and this may interfere with error handling. Alternatively, you might be able to write an event listener which only calls this method as a side effect and does not listen for events (event listeners are allowed to run registration code early in the startup process).
Generally, I'm very resistant to introduce options that work around problems like this one, where the root cause is historical/organizational and the proposed solution has a hard time standing on its own technical merit.
Large organizations have some problems caused by real technical scale, and we're eager to find solutions to these problems (even when the solutions are complex).
Large organizations have other problems which are caused by organizational scale. Sometimes, it's easier to fix a problem caused by a historical decision or a slow-moving team by spilling badness into the upstream, but I want to avoid this. Taken to the extreme, it leaves us covering for organizational problems across many organizations, and with a lot of patches that really only benefit one install, which we're stuck maintaining forever.
Earlier in the life of Phabricator we had a lot of this kind of stuff left over from Facebook, and were much worse for it. (This is why we still ship with "MetaMTA", an MTA written in PHP.) We've stripped much of it out in the modern codebase, and I want to avoid backtracking into the wilds where we get stuck compensating for badness elsewhere because we have a more general or more flexible implementation or more nimble process.
See T1969 for a "classic" example of this, where Facebook opens a request with:
Our svn masters (and other verion control systems) are in a different region from our database masters.
(The client-side version of https.blindly-trust-domains is because users love self-signing certificates and misconfiguring SSL and the net cost to us to support this option is lower than the net cost of fielding support requests to add it, but AFAIK no other installs would benefit from a server-side version of this option.)