nHTTP

Topics:

The nHTTP adapter is a nonblocking HTTP with improvement in performance, connection management, and various other security features.

The nHTTP adapter provides extensive flexibility by exposing an array of configurable parameters for security, connectivity, and header manipulation. Below are descriptions of some features that have been added as part of the improvement to the nHTTP component.

nHTTP REST Support

Representational State Transfer (REST) is a simpler alternative to SOAP and Web Services Description Language (WSDL)-based web services. There are many advantages of using this simpler HEEP-based design approach to calling server-based services, and it has been widely adopted by many advanced web service providers including Amazon, Google, and Facebook. These entities have either avoided SOAP or offered REST as a simpler alternative.

A RESTful service:

  • Uses explicit HTTP methods.
  • Is stateless (no session management is allowed or required).
  • Exposes the calling URI as a directory-like structure.
  • Transfers the payload as XML, JavaScript Object Notation (JSON), or both.

iWay Service Manager (iSM) offers a group of facilities to enable the use of RESTful services when executed by process flows. The nHTTP listener for iSM complies with the HTTP 1.1 specification. This listener implements all of the available verbs used in REST-style communication, including the main verbs (GET, POST, PUT, and DELETE).

iWay Providers

Named SSL Context Provider

Since this provider uses configured keystore/truststore providers, it allows you to configure multiple SSL context providers and use them as named providers in the nHTTP configuration.

Features

  • Persistent Connection Support. The nHTTP adapter supports persistent connections, which will allow for better connection handling and management.
  • Session Resumption. Session resumption is one of the new features available for the SSL configuration.
  • Large File Limit. The nHTTP adapter contains various internal improvements to handle large file sizes. As an addition, a new option has been exposed on the nHTTP inbound processing that allows the user to limit the message size accepted by the adapter.

Configuring nHTTP Listeners

How to:

Reference:

A listener is a component that is responsible for receiving inbound messages through an assigned listener protocol. After a listener is created, it must be added to an inlet configuration. An inlet will become part of the final channel configuration that will consist of an inlet, route, and an outlet. For more information on configuring channels, see the iWay Service Manager User's Guide.

Procedure: How to Configure a nHTTP Listener

To configure a nHTTP listener:

  1. Ensure that iWay Service Manager is running.

    On Windows, you can start iWay Service Manager by clicking Start, selecting Programs, iWay 7.0 Service Manager, and then Start Service Manager for the configuration you are currently using.

    For more information on starting and stopping iWay Service Manager, see the iWay Service Manager User's Guide.

  2. Open a browser window and point to the following URL:
    http://host:port/ism

    where:

    host

    Is the host machine on which iWay Service Manager is installed.

    port

    Is the port on which iWay Service Manager is listening. The default port is 9999.

    On Windows, alternatively, you can click Start, select Programs, iWay 7.0 Service Manager, and then click Console.

    A login dialog box opens.

  3. Type a user name and password for the configuration you are using, and click OK.

    The iWay Service Manager Administration Console opens.

  4. Click Registry in the top pane, and then click Listeners in the left pane.

    The Listeners pane opens.

    The table that is provided lists all the previously configured listeners and a brief description for each.

  5. Click Add.

    The Select listener type pane opens.

  6. Select nhttp from the Type drop-down list and click Next.

    The Configuration parameters for the nHTTP listener pane opens.

    Note: The parameters prefixed with an asterisk (*) in the listener configuration pane are required.

  7. Provide the appropriate values for the nHTTP listener parameters.

    For more information, see nHTTP Listener Configuration Parameters.

  8. Click Next.

    You are returned to the Select listener type pane.

  9. Enter a name for the nHTTP listener and description (optional).
  10. Click Finish.

    You can now use this listener as part of your channel configuration where the business logic will be applied to the received messages.

Reference: nHTTP Listener Configuration Parameters

The following table lists and describes parameters for the nHTTP listener.

Parameter

Description

IP Properties

Port

The TCP port for receipt of HTTP requests.

Local bind address

The local bind address for multi-homed hosts. This parameter value is usually not specified.

Persistence

If set to true, then the connection is maintained when the client requests to do so. If set to false, the connection is closed.

Maximum Connections

This defines the maximum number of simultaneous connections that are allowed. When this threshold is reached, new connections will not be accepted until current connections are closed and the total number of connections is below the limit. Leave this field blank (default) or set a value of zero to have no maximum limit of connections.

Persistence Timeout value in Minutes

The maximum length of time that a connection persists with no activity.

Set Response No Delay

If set to true, the Nagle Algorithm is disabled on the response. This will result in a faster line turnaround at the expense of an increased number of packets.

Reuse Address

If set to true, then when a connection is closed, it immediately makes the address available, bypassing the TCP defaults.

Allowable Clients

If supplied, then only messages from this list of fully qualified host names and/or IP addresses are accepted. Accepts comma-separated list or use the FILE() function.

Secure Connection (SSL)

Secure Connection

If set to true, then a connection using secure HTTP (HTTPS) is made.

SSL Context Provider

The named iWay Security provider for SSL Context.

General Properties

GET Handling

This determines how GET requests are handled. Options include:

  • docroot. Attempts to serve a file from the document root directory.
  • error. Returns an HTTP 405 Method Not Allowed.
  • event. Generates an event message.

PUT and DELETE Handling

This determines how PUT and DELETE requests are handled. Options include:

  • unavailable. Returns an HTTP 405 Method Not Allowed.
  • event. Generates an event message.

Document Root

The base directory from which all HTTP pages are served through GET if GET Handling is enabled for page access.

Default Page

The default page displayed if no page is identified in the incoming HTTP[s] request.

Default Text

The default text sent with 200 OK, which will take configured ContentType.

Response content type

This overrides the content type of the response.

HTTP Response Code

Indicates the HTTP status code to send with the response. Usually this is left blank, which allows the channel to determine the appropriate response code.

You can specify an iWay Functional Language (iFL) expression as a value for this parameter to be evaluated during the final emit process. If you specify an iFL expression, then ensure to include a leading backtick (`) character to prevent this expression from being evaluated until it is required. For example:

`sreg(responsecode)

If you decide to use a Special Register (SREG), then ensure to set it in the Message scope. The Message scope survives the process flow that elects to set the value. For example:

message:responsecode  |  500  |

For more information on setting SREGs into scopes, see SREG Service (com.ibi.agents.XDSREGAgent) in the iWay Service Manager Component Reference Guide.

The status code from nHTTP emits during the process flow are stored in a SREG called httpstatus, which is in the defined response SREG namespace of the emit service.

Authentication Scheme

The scheme to apply when authenticating HTTP requests. Select one of the following options from the drop-down list:

  • Digest Auth
  • Basic Auth
  • None (Default)

Authentication Realm

If authentication is required, then this provides the name of the configured Realm provider to use.

Request Header Namespace

The special register namespace to which HTTP headers from the incoming requests are saved. The Default option creates HDR type special registers without a namespace prefix.

Response Header Namespace

The special register namespace from which HTTP headers for the outgoing response are taken. The Default option sends HDR type registers with no namespace prefix. If none is selected, no special registers are sent as HTTP headers.

Response Main Part Header Namespace

The special register namespace from which MIME headers for the outgoing response are taken. Provide a prefix to control the response Main BodyPart headers in the presence of attachments. Selecting none means that no special registers are sent as MIME headers. An empty namespace prefix is treated as none.

Maximum Request Entity size

When a request document is received that is larger than the specified maximum size, the listener will return HTTP 413 Request Entity Too Large and close the connection. A value of 0 specifies no maximum. The default size is 256KB.

Excluded Headers

A comma delimited list (case-insensitive) of headers that should not be sent with the response, even if they are found in the response header namespace.

Compress Response

If set to true, then the response is compressed with gzip or deflate compression when the client indicates that it can accept compressed transfer encoding.

Other

Whitespace Normalization

This specifies how the parser treats whitespace in element objects. Select preserve (default) to turn off all normalization as prescribed by the XML Specification. Select condense to remove extra whitespaces in pretty printed documents and for compatibility with earlier versions.

Accepts non-XML(flat) only

If set to true, the listener expects flat (non-XML) documents. Preparsers do not run.

Optimize Favoring

The selection of memory is useful for large input documents.

Multithreading

The number of documents that can process in parallel.

Execution Time Limit

The time limit for document execution (in seconds) before it is terminated.

Default Java File Encoding

The default encoding if incoming message is not self-declaring.

Agent Precedence

Changes the order by which iSM selects agents. This is normally set to Document overrides listener.

Always reply to listener default

If set to true, the default reply definition is used in addition to defined replies.

Error Documents treated normally

If set to true, the error documents are processed by any configured pre-emitters.

Listener in Transaction Manager

If set to true, the agents run within a local transaction managed by the listener.

Record in Activity Log(s)

If set to true, activity on this channel will be recorded in the activity logs. If set to false, the activity will not be recorded.

Note: The nHTTP listener supports streaming. Streaming is used for large documents or documents for which the application needs to split the input into sections under the same transaction. For more information on streaming and configuring streaming preparsers, see the iWay Service Manager Component and Functional Language Reference Guide.

Reference: Special Registers for the nHTTP Listener

The following table lists and describes the special registers for the nHTTP listener.

Special Register

Level

Description

...

Header

Each header value from the message.

action

Document

The action field of the post.

docroot

Document

The defined docroot from configuration.

ip

Document

The IP of the sending system.

iwayconfig

System

The current active configuration name.

iwayhome

System

The base at which the server is loaded.

iwayworkdir

System

The path to base of the current configuration.

msgsize

Document

The physical length of the message payload.

name

System

The assigned name of the master (listener).

protocol

System

The protocol on which the message was received.

requestType

Header

The type of HTTP request (GET, POST, or HEAD).

source

Document

The host name of the sending system.

url

Header

The full URL of the HTTP request (GET, POST, or HEAD).

tid

Document

Unique transaction ID.

Associating Session Information With an HTTP Interaction

Topics:

In HTTP, a session is a sequence of network request-response transactions. A session may encompass a group of console screens or web interactions for a specific purpose. In transactional HTTP, such as REST or web services, a session may represent one or more request-response activities, such as sending a group of related shipping operations.

Applications can associate session information with an HTTP interaction. The session information is not actually carried between the client and the server. Rather, a token is assigned by iSM, which is carried between interactions. The token identifies the current session, much as a transaction ID represents the action of a single transaction within the session. By not carrying the session information between interactions, security is enhanced and network traffic is reduced.

Session information is carried in Special Registers (SREGs), which are created by the application and available in the later steps where they can be referenced and changed as required. The session SREGs are carried in a SREG scope called session. The session scope is not a namespace, although namespaces can be used within the session.

Registers in a specific scope can be set using the Special Register Setting Service (com.ibi.agents.XDSREGAgent). These registers can be referenced by the syntax session:name. For example, a database key carried in the dbkey SREG would be referenced as session:dbkey. The colon identifies the register as being in a named scope.

Note: Users are cautioned that scopes (denoted by the colon) are not namespaces. It is possible to use namespaces within the session scope (as it is in any scope), but usually in session scope namespaces do not add facility.

The session registers can be assigned to a type, such as USER, METRIC, or HDR. User registers can optionally be carried between channels within a transaction. All register attributes, including marshalling control and context recording can apply to session registers.

The session key is exchanged with the client by using the standard JSESSIONID cookie. As a result, management of the session involves dealing with the treatment of this cookie.

Configuring Sessions on an nHTTP Listener

Sessions are configured on the nHTTP listener in the HTTP Session section. Set the Session Support parameter to true to enable sessions.

The details of the session definition extend beyond the scope of this document. For more information, application designers should refer to other HTTP documentation.

The values specified for the Maximum Sessions and Session Max Inactive Interval parameters are important. Either of these settings can result in the loss of the session information for the session, even though a session token is received from the client. In such a case, the application must be designed to handle the loss of the session and session restart. For example, a shopping cart might be maintained in the session information. If the session expires, the shopping cart would be deleted and the application must reacquire the information that has been eliminated. While setting the listener to prevent expiration seems to avoid this situation, application designers must be aware that clients can be abandoned, resulting in the loss of the resources used to hold the session information in the server.

Because the session information is exchanged as a cookie (JSESSIONID), the cookie attributes can be applied. The cookie attributes are a cookie domain, a path, expiration time or maximum age, secure flag, and HttpOnly flag. Browsers will not return cookie attributes to the server. They will only send the name-value pair of the cookie. Cookie attributes are used by browsers to determine when to delete a cookie, block a cookie, or whether to send a cookie (name-value pair) to the server. The default entries for these attribute fields allow the cookie (session information) to be exchanged for all interactions.

The following table lists and describes the cookie parameters in the HTTP Session section.

Parameter

Description

Cookie Path

Restricts the exchange of the cookie to the identified domain and optionally its subdomains. Most applications for iSM sessions will not need these settings.

Cookie Domain

Cookie Max Age

The number of seconds that the JSESSIONID cookie can exist. This is the total time the session can exist once it is created.

Cookie Secure

The Secure attribute is meant to keep cookie communications limited to encrypted transmissions, directing browsers to use cookies only through secure and encrypted connections.

Cookie HTTP Only

Directs browsers (or other clients) to use the JSESSIONID cookie through the HTTP protocol only (this includes HTTPS. HttpOnly is not the opposite of Secure). An HttpOnly cookie is not accessible through non-HTTP methods, such as calls using JavaScript (for example, referencing document.cookie), and therefore cannot be stolen easily through cross-site scripting

Using Session Information in an Application

Setting the session information for an application is configured by using the Special Register Setting Service (com.ibi.agents.XDSREGAgent).

From the Scope of variable drop-down list, select HTTP Session {session}, as shown in the following image.

You must have the session support configured for the channel in order for the register to automatically appear in the next client interaction.

To reference the value of the register, you can use the following function from the iWay Functional Language (iFL):

_sreg('session:dbkey')

The HTTP Session Invalidator Service (com.ibi.agents.XDHttpSessionInvalidator) can be used in a process flow to invalidate the current session. This deletes all information in the session and prevents the session from being exchanged in subsequent client-server interactions. As a best practice, you can call for invalidating (deleting) the session once it is no longer required. An example would be a console logout or a determination of a catastrophic error situation that requires the user to restart an operation.

An application might keep an event count in the session, such that a count of 0 means this is the start of a session. Using 0 as the default value of an _sreg() lookup in a process flow test, the process flow can take whatever action is needed to begin the application session. Following the test, a Special Register Setting Service (com.ibi.agents.XDSREGAgent) might set the event count to the command shown in the following table:

eventcount

_sreg('session:eventcount','0')+1

HTTP Session Invalidator Service (com.ibi.agents.XDHttpSessionInvalidator)

This service is used to terminate the session. The following table lists and describes its parameter.

Parameter

Description

Expire Cookie

Determines how the termination is to be effected.

If set to false, it removes the session information from the server. No further action is taken.

If set to true, in addition to removing the session information, it sends an instruction to the client to delete the JSESSIONID cookie itself.

The service returns the input document on the success edge.

As a good practice, you can use this service when the application has completed the session, so as to reduce server resources.

Configuring Emit Services

Topics:

How to:

Reference:

You can configure outbound processing of HTTP messages as a service that can be used within a process flow, which will become part of the route configuration or directly as a service assigned to a route. In this case, a business process can continue after an HTTP message has been sent out to the client. The following section describes how to configure an HTTP nonblocking emit service. For more information on configuring outlets and routes, see the iWay Service Manager User's Guide.

Procedure: How to Configure an HTTP Nonblocking Emit Service

To configure an HTTP nonblocking emit service:

  1. Click Registry in the top pane, and then click Services in the left pane.

    The Services pane opens.

    The table that is provided lists all the previously configured services and a brief description for each.

  2. Click Add.

    The Select Service type pane opens.

  3. Select HTTP Nonblocking Emit from the Type drop-down list.
  4. Click Next.

    The configuration parameters pane for the HTTP nonblocking emit service opens.

  5. Provide the appropriate values for the HTTP nonblocking emit service parameters.
  6. Click Next.

    The name and description pane opens.

  7. Enter a name for the service and description (optional).
  8. Click Finish.

Reference: HTTP Nonblocking Emit Service Configuration Parameters

The following table lists and describes parameters for the HTTP nonblocking emit service.

Parameter

Description

Configuration Parameters

Destination (required)

The destination URL to post information that uses the following format:

http[s]://host[:port]/action

HTTP Client Provider (required)

The HTTP client Provider that is used to manage connections for this emitter.

Action Method

Select one of the following supported methods from the drop-down list:

  • GET method with data on the URL and URL Encoded.
  • HEAD method.
  • POST method with a Content-Length header. This value is selected by default.

Request Content Type

The content type for the HTTP request sent by this emitter. Select a value from the drop-down list or provide your own. Available values from the drop-down list include:

  • application/EDI-X12
  • application/EDIFACT
  • application/XML
  • text/html
  • text/plain

User ID

The user ID for Basic Authentication challenges.

Password

The password for Basic Authentication challenges.

Domain

The domain for NTLM authentication challenges. Note that to use NTLM, you must enable connection persistence.

Request Header Namespace

The special register namespace from which HTTP headers for the outgoing request will be taken. Choose Default Namespace to send HDR type registers with no namespace prefix, or supply a namespace prefix here. None means that no special registers will be sent as HTTP headers.

  • Default Namespace to send HDR type registers with no namespace prefix.
  • Supply a namespace prefix here to indicate which headers to send.
  • none means that no special registers will be sent as HTTP headers.

Request Main Part Header Namespace

The special register namespace from which MIME headers for the outgoing request will be taken. Provide a prefix to control the request Main BodyPart headers in the presence of attachments. Selecting none means that no special registers will be sent as MIME headers.

Response Header Namespace

The special register namespace into which HTTP headers from the incoming response will be saved. Choose Default Namespace to create special registers with no namespace prefix, or supply a namespace prefix here. None means that no special registers will be created.

  • Default Namespace to create special registers with no namespace prefix.
  • Supply a namespace prefix here to indicate header namespace.
  • Empty namespace prefix will be treated as default.

Excluded Headers

A comma delimited list (case-insensitive) of headers that should not be sent with the request, even if they are found in the request header namespace.

Ask for Compressed Response

If set to true, the request will set the accept-encoding to indicate that the client can accept a compressed response. If the response has a compressed content encoding, the client will automatically inflate the response.

Compress Request

If set to true, the request entities will be compressed using the selected encoding and the content-encoding header will be set accordingly.

Replace Connection?

If set to false, the connection is not returned to the connection pool immediately. The identifier of the connection will be stored in the httpclient-key special register and the connection can be handled by the HTTP Client Manager agent.

Maximum HTTP Client Manager Delay

The maximum time for the HTTP Client Manager to handle a particular connection before it is automatically aborted. The format is [xxh][xxm]xx[s]. The default is 60 seconds.

Try Expect/Continue Handshake?

If set to true, the client will send the HTTP Expect: 100-continue header and await HTTP 100 response before sending the request body. By default, false is selected.

Chunk Encoded Request?

If set to true, the request entity will be sent with chunk encoding. By default, false is selected.

Maximum Request Size

The maximum size (after compression) of a request entity that can be sent with this emitter. A value of zero (0) means there is no maximum size limit and if no value is specified, the default value of 256KB is applied.

Maximum Response Size

The maximum size of a response entity that can be received by this emitter. A value of zero (0) means there is no maximum size limit and if no value is specified, the default value of 256KB is applied.

IP Properties

Persistence

If set to true, the server is requested to maintain the connection.

Response Timeout value in seconds

The value in seconds to wait for a response before generating an error. The default value is 60 seconds.

Agent Specific Parameters

Return

The type of return from this agent. Select input to return input document, status for an XML document with transaction parameters and status, or response to capture the output from the server.

Preemitter

If set to true, the preemitters will not run.

Response Wrapper Tag

The tag name with which to wrap the response if the response is non-XML and must be XML.

Response Base64 Encoded

If set to true, the response will use Base64 encoding.

Available Response Edges for nHTTPEmitAgent

When you connect the nHTTPEmitAgent object to an End object using the OnCustom build relation in a process flow, the available line edges are provided in the Line Configuration dialog box.

The following table lists and describes the available line edges for the nHTTPEmitAgent object.

Line Edge

Description

OnError

Error

OnSuccess

Success

OnFailure

Failure

fail_connect

fail_connect

fail_info

fail_info

fail_redirection

fail_redirection

fail_client

fail_client

fail_server

fail_server

fail_operation

fail_operation

fail_parse

fail_parse

fail_unsigned

fail_unsigned

nHTTP Samples

Topics:

This section provides additional information about the nHTTP listener and includes samples you can use as a reference.

nHTTP Listener Event Schema

The nHTTP listener allows you to configure the handling of incoming HTTP requests. For example, the available options for the GET Handling parameter include docroot, error, and event. If you select event, an event document is created for the incoming request. This document can then be used in your process to determine an action for the request. The event document corresponds to the following structure:

<http user="auto" type="GET">
  <parms>
    <parm name="ibse-port">9000</parm>
    <parm name="Host">clientbox:10000</parm>
    <parm name="Connection">Keep-Alive</parm>
    <parm name="pdm">0</parm>
    <parm name="version">1.1</parm>
    <parm name="Accept-Language">en-AU</parm>
    <parm name="action">user.req?user=999999999&account=1234567890123456&tranid=tid1234</parm>
    <parm name="Accept">text/html, application/xhtml+xml, */*</parm>
    <parm name="User-Agent">Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)</parm>
    <parm name="url">/user.req?user=999999999&account=1234567890123456&tranid=tid1234</parm>
    <parm name="ip">127.0.0.1</parm>
    <parm name="source">hostname unknown</parm>
    <parm name="Accept-Encoding">gzip, deflate</parm>
    <parm name="reqType">GET</parm>
  </parms>
  <body />
  <url secure="false">
    <host>clientbox</host>
    <port>10000</port>                                   
    <path>/user.req</path>
    <query>user=999999999&account=1234567890123456&tranid=tid1234</query>
    <queryparms>
      <queryparm name="user">99999999</queryparm>
      <queryparm name="account">1234567890123456</queryparm>
      <queryparm name="tranid">tid1234</queryparm>
    </queryparms>
    <incomingurl>	http:clientbox:1000/user=999999999&account=1234567890123456&tranid=tid1234
   </incomingurl>
  </url>
  <version>1.1</version>
</http>

The following syntax is a sample document for the GET event:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<http user="unknown" type="GET">
<parms>
   <parm name="version">1.1</parm>
   <parm name="source">beck-xp.ibi.com</parm>
   <parm name="ua-cpu">x86</parm>
   <parm name="reqType">GET</parm>
   <parm name="accept-encoding">gzip, deflate</parm>
   <parm name="accept-language">en-us</parm>
   <parm name="connection">keep-alive</parm>
   <parm name="url">/TEST?A=B&C=D</parm>
   <parm name="user-agent">Mozilla/4.0 (compatible; Win 5.1</parm>
   <parm name="host">theservercom:7777</parm>
   <parm name="ip">172.19.22.60</parm>
</parms>
<body />
<url secure="true">
   <host>theserver.com</host>
   <port>7777</port>
   <path>/TEST</path>
   <query>A=B&C=D</query>
</url>
<version>1.1</version>
</http>

Supported nHTTP Requests

The following table lists the supported HTTP requests that can be processed by the nHTTP listener. Flow refers to the generation of the event signal document that can be processed within a process flow. A Reject action causes the client request to be rejected with an HTTP 405 Method Not Allowed response.

Request Type

Available Actions

GET

From File, Flow, or Reject

POST

Flow

HEAD

Like GET

PUT

Flow or Reject

DELETE

Flow or Reject

TRACE

Echoes request as per RFC

OPTION

Reject

Maximum Allowed Connections

The nHTTP listener has a parameter that can be configured to limit the number of simultaneous connections. However, this is not related to pool sizes or persistent connections. This parameter simply limits the number of clients that can connect to the server at once, persistent or not.

The listener tracks the current number of connections. When a new connection is accepted, the count is raised. When a connection closes, the count is lowered. Before accepting a new connection, the listener checks the current number of connections against the max connections parameter. If the current number is at the threshold, the new connection is not accepted and the following error message is written to the log:

ERROR (nh2) max connection threshold exceeded

Please note that the client has no knowledge of this back-end functionality. From its point of view, the connection might just be slow. The client will continue making connection attempts until it times out. As a result, it is normal to see multiple instances of this error message when simultaneous connections are over the limit. If the client does not time out and another connection closes, the new connection will be accepted and normal processing is continued

A blank value or 0 specified for the parameter indicates no limit.

SSL Host Verification

When SSL Host Verification is enabled, the client verifies that the certificate the server is presenting in the handshake matches the server hostname.

So, in the keystore of the server SSL context, there needs to be a key pair with CN == server hostname. If there is more than one private key in this keystore, you need to specify the server key alias to point to this key.

The client needs to add the <certificate of the CA that signed the server certificate> to its truststore. In the case of a self-signed certificate, this is the server certificate itself. The server never verifies the client hostname, even if SSL client authentication is enabled.

The following shows some of the information in a self-signed certificate with the CN in the subject Distinguished Name set to the host and port as required by the host name verifier.

Owner CN=myMachine.ibi.com:7777, OU=iWay, O=IBI, L=Cranston, ST=Rhode 
Island, C=US 
Issuer CN=myMachine.ibi.com:7777, OU=iWay, O=IBI, L=Cranston, ST=Rhode 
Island, C=US 
Serial number 46141cb7 
Valid from Wed Apr 04 17:46:31 EDT 2007 until: Mon Oct 01 17:46:31 EDT 
2007 
Certificate fingerprints 
MD5 61:02:2E:F2:D6:C2:0B:A8:AF:1F:6F:86:64:23:C9:17 
SHA1 5F:7B:6C:A5:0E:FC:0C:33:F6:4C:4D:48:1B:C9:07:A4:DD:EF:54:62