Creating a TrustManagerFactory

You create an instance of this class in a similar manner to SSLContext, except for passing an algorithm name string instead of a protocol name to the getInstance method: 
public static TrustManagerFactory getInstance(String algorithm);
            
public static TrustManagerFactory getInstance(String algorithm, String provider);

public static TrustManagerFactory getInstance(String algorithm, Provider provider);

A sample algorithm name string is: PKIX

A sample call is the following: 
TrustManagerFactory tmf = TrustManagerFactory.getInstance("PKIX", "IBMJSSE2");

This call will create an instance of the IBMJSSE2 provider's PKIX trust manager factory. This factory can then be used to create trust managers which provide X.509 PKIX-based certification path validity checking.

When initializing a SSLContext, you can use trust managers created from a trust manager factory, or you can write your own trust manager, perhaps using the CertPath API. (See the Java™ Certification Path API Programmer's Guide for details.) You don't need to use a trust manager factory at all if you implement a trust manager using the X509TrustManager interface.

A newly-created factory should be initialized by calling one of the init methods: 
public void init(KeyStore ks);
public void init(ManagerFactoryParameters spec);

You should call whichever init method is appropriate for the TrustManagerFactory you are using. (Ask the provider vendor.)

For many factories, such as the IbmX509 TrustManagerFactory from the IBMJSSE2 provider, the KeyStore is the only information required to initialize the TrustManagerFactory and so the first init method is the appropriate one to call. The TrustManagerFactory will query the KeyStore for information on which remote certificates should be trusted during authorization checks.

In some cases, initialization parameters other than a KeyStore might be needed by a provider. Users of that particular provider are expected to pass an implementation of the appropriate ManagerFactoryParameters as defined by the provider. The provider can then call the specified methods in the ManagerFactoryParameters implementation to obtain the needed information.

For example, suppose the TrustManagerFactory provider requires initialization parameters B, R, and S from any application that wants to use that provider. Like all providers that require initialization parameters other than a KeyStore, the provider will require that the application provide an instance of a class that implements a particular ManagerFactoryParameters sub-interface. In our example, suppose the provider requires that the calling application implement and create an instance of MyTrustManagerFactoryParams and pass it to the second init. Here is what MyTrustManagerFactoryParams may look like: 
public interface MyTrustManagerFactoryParams extends ManagerFactoryParameters {
 public boolean getBValue();
 public float getRValue();
 public String getSValue();
}

Some trustmanagers are capable of making trust decisions without having to be explicitly initialized with a KeyStore object or any other parameters. For example, they may access trust material from a local directory service via LDAP, may use a remote online certificate status checking server, or may access default trust material from a standard local location.