The root problem might be that there's a dependency issue with the TLS libraries. Is it possible to connect to that AMT system without TLS, to test if that's the case? It should be fairly straightforward to enable http communication on the AMT system, if it isn't already. That'll help isolate whether there's just a problem with the java library and TLS on Fedora, or a more fundamental issue with the java library and the version of OpenJDK you're using.
As for java library supporting TLS, that's a little more involved. The short answer is that java library does support TLS, the samples as written will work with AMT systems configured for server TLS, and requires some tweaks to support mutual.
The long answer is that the java library supports TLS much the same way the SDK supports TLS, by leveraging the underlying infrastructure of the platform. As an aside (this will be important later), I'll touch on how the SDK handles loading the cert for mutual TLS.
The code that the SDK samples use to support mutual TLS is in the SDK, although you do have to dig for it, you can look at the getCertFromStore function in theWindows\Common\WS-Management\C#\DotNetWSManClient\DotNetWSManClient.cs file in the SDK. It's looking through the certificates in both the Current User and Local Machine cert stores in Windows, and comparing the string you pass in against the subject of those certs for a match. Of course, the DotNetWSMan library isleveraging .Net and Windows to load the cert, which of course for Fedora doesn't help you directly, but the principle (and the flow) will be similar.
Getting back to the Java library, what needs to be done is basically the same thing as was done in the SDK, loading the appropriate certificate and associating it with the WS-Man connection. The fact that you know you have a known good certificate (since you can connect to an AMT system configured for mutual TLS with the SDK, presumably by passing it a string that matches the Subject of the certificate) significantly simplifies matters for development purposes, you'll need to export the cert out of that store as a pfx file. Make sure to export it with the private key, that's necesary, and doing so will prompt for a password (that's the password mentioned in the DefaultKeyManager below).
So now you've got the cert, how do you load it and associate it with a connection? This code snippet illustrates that flow:
[java]connection = new CreateConnection(https://myamtbox:16993/wsman); // used to provide Digest Credentials to the connection DefaultAuthenticator defAuth = new DefaultAthenticator() defAuth.AddCredential(https://myamtbox:16993/wsman,digest,admin,P@ssw0rd); java.net.Authenticator.setDefault(defAuth) // create a default trust manager (this is only needed when using TLS to verify Server Certificates) DefaultTrustManager trustMgr = new DefaultTrustManager(); connection.setTrustManager(trustMgr); connection.setHostnameVerifier(trustMgr); //Create a default Key Manager (this is only needed when using Mutual TLS or Remote Configuration to send client certificates //and give the connection access to the private key) DefaultKeyManager keyMgr = new DefaultKeyManager(c:\pathToCertStore\MyClientStore.pfx,myStorePassword); connection.setKeyManager(keyMgr); [/java]
At this point, the connection will use the certificate to establish a Mutual TLS session.