WS-MAN Java Libray

[Jeffrey_R_Intel2]

Has anyone used this library with TLS (mutual authentication) turned on successfully?

I am trying this on Fedora 13 64 bit IPv4 with TLS enable and am getting the follwoing error(s):

An exception occurred getting the Audit Log Properties http://intel.com.wbem/wscim/1/amt-schema/1/AMT_AuditLog

Error sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilder

Exception: unable to find valid certification path to requested target

This makes me ask the question how does one using the Java library specifiy where the root certificate goes, or where by default does the library look for the certificate?

Thanks

[Andrew_S_Intel2]

Interesting, what version of Java (and the Java Development Toolkit) does your platform have? I'm not that familiar with Fedora 13, so not sure what version of java ships with it natively.

The reason I asked about the what java library you had on your platform is that the implementation of TLS in the WS-Man Java Library is simply extending the underlying Java support for encryption(in java.security.*, mainly x509Certificate and X509ExtendedKeyManager classes). Offhand I'm not sure if the existing java samples would natively support mutual authentication (I might be mistaken here), you might need to add the code to load theroot certificate. There is an example of loading a key from a keystore (specifically a pfx file) in the AuditLogSample you could build off of, but given the messages you posted you might already be aware of that.

As a second follow-up, do other mechanisms (WebUI, other tools) work from your Fedora systemto the AMT system that's configured for mutual TLS? I ask because (speaking from experience) it's fairly easy to configure mutual TLS in a way that's not usable, and it'd be good to validate there's not an issue there.

Andy

[Jeffrey_R_Intel2]

Java version 1.6.0.17
OpenJDK runtime environment 1.7.1
OpenJDK Client VM build 14.0.b16

As far as other mechanism I have used the AMT SDK successfully over TLS.

I was under the impression (perhaps mistakingly) that the Java library was already supporting TLS - but perhaps not.

[Andrew_S_Intel2]

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.