Verify the connector server certificate against the host over the legacy SSL connection

[vharseko]

Resolves CodeQL alert https://github.com/OpenIdentityPlatform/OpenICF/security/code-scanning/24 (java/unsafe-cert-trust, critical).

Problem

RemoteFrameworkConnection (the legacy binary-protocol client for the connector server, port 8759) wraps the socket in an SSLSocket when useSSL is on. SSLSocket validates the certificate chain but never checks the certificate against the host it connects to, so anyone holding a certificate the client trusts could sit in the middle of the connection. The connector server key is written to that connection as a GuardedString encrypted with the framework's fixed default key, i.e. readable by such an attacker, and all connector operation data flows through it as well.

With the typical setup (no custom trustManagers, the server's self-signed certificate imported into the JVM truststore next to the public CAs) any publicly trusted certificate was enough.

Change

• RemoteFrameworkConnection: enable JSSE "HTTPS" endpoint identification (SSLParameters.setEndpointIdentificationAlgorithm) before the handshake. The certificate must now name the configured host as a subjectAltName dNSName/iPAddress entry, or as CN when it has no subjectAltName (RFC 6125 rules, as HttpsURLConnection does). The check happens inside the handshake, before the key is sent, and applies to custom trust managers too — including plain X509TrustManager implementations, which JSSE wraps.
• Opt-out for deployments that need time to fix their certificates: -Dorg.identityconnectors.framework.remote.hostnameVerification=false. Only the literal false disables the check, so a typo cannot weaken it. With the check off the client still compares the certificate names with the host and logs a WARN once per server naming the certificate's subject and subjectAltName entries, so the certificate can be fixed and the check re-enabled.
• CertificateHostnameMatcher (package-private): the RFC 6125-style matcher behind that diagnostic — iPAddress entries for IP literals, dNSName entries with a wildcard standing for exactly one leftmost label, CN only when no dNSName is present.
• RemoteFrameworkConnectionInfo javadoc for useSSL documents the requirement and the property.

Tests

• RemoteFrameworkConnectionSSLTests: a CN-only certificate is rejected when connecting by IP (with a TrustManagerFactory trust manager and with a plain X509TrustManager), a SAN certificate is accepted, CN fallback works when there is no SAN, the property disables the check, off does not.
• CertificateHostnameMatcherTests: SAN/CN/wildcard/IP matching rules.
• RemoteConnectorInfoManagerSSLTests now uses KeyStore-san.jks (SAN localhost, 127.0.0.1, ::1); with the old CN-only KeyStore.jks it fails as expected, since it connects to 127.0.0.1. KeyStore.jks stays for the negative tests.

Compatibility

Deployments whose connector server certificate does not name the host used in the client configuration (self-signed certificates with an unrelated CN, connections by IP without an iPAddress SAN) will fail the handshake with SSLHandshakeException: No subject alternative names present / No name matching <host> found. The fix is a certificate that names the host; the system property above is the temporary escape hatch. Worth a release-notes entry.

Not covered here: the Grizzly WebSocket client (connector-framework-server ConnectionManager) has the same class of problem outside the CodeQL model; separate PR.