Have you tried specifying the location and name of the SSLDefs.ini file with the ISC_SSLconfigurations environment variable?  This is an alternate way of specifying where the configuration file is.

The two places that I would look for more information on a <PROTECT> error are the audit log and the line of code the error is coming from.   The audit entry for a <PROTECT> error sometimes has more information about why the error was generated.  The line of code can also help as it can show you whether there was an explicit permission check, a reference to a particular global, etc.

There isn't support for EC keys in Cache.  If you haven't already, you could ask for an enhancement to add support in IRIS.  That's a long term solution though.  For now, the only solutions I can think of are workarounds like your CPIPE and cURL method or stunnel around %Net.Httprequest.