We have port 9000 for non-ssl connections, 8999 for ssl connections.
And I think I understood one thing wrong, I thought it’s like this:
We connect without ssl to port 9000, use a qcf for ssl that returns the url with port 8999 and only then the ssl connection is initiated.
The reality is the interface already listens on both ports, 9000 for non-ssl and 8999 for ssl,
so we connect to port 8999 already using ssl connection, then the qcf returs the real address (in this case the same) again with port 8999 and we continue.
This way we moved further, the exception is now an expected one (cos atm we have certificates for a different machine) - peer not authenticated.
What remains unclear to me is rather specific for Openedge AdminObjectFinder.class and that is the setting of PROVIDER_URL in Context and java.naming.provider.url in Properties, but for now I put the same values into both.
The way the iteration you described does not seem the same the IS uses to connect to the UM.
AFAIK [and based on the JMS Alias configuration is laid out], it makes me think that, when using the JNDI LOOKUP, the IS will connect to the service indicated in the JNDI configuration (and there is where the connection string is set). This makes me understand that the IS does not employ the 2-stage you described (1. connect to the non-SSL port (9000) to get the QCF, and then 2. connect to the SSL port (8999) to perform the rest of the operations).
The IS establishes, from the moment one, using one protocol. And taking this into your scenario, the OpenEdge should connect, from the first moment, to the SSL port.