However, if you consider the value that using SSL between Portal and IHS provides, I'd assert that it is low. In the "best or breed" topology, IHS sits in a DMZ and Portal sits inside your company firewall. Further, firewall rules insure that only the IHS server(s) have access to the Portal inbound transports. Therefore, the value in SSL insuring the authenticity of the two servers is limited; they are who they say they are by default (since no other server can access their ports).
Likewise, the value of encryption in this scenario is dubious as well. Without physical login access to the serves, a "man in the middle" attack would be one of the few viable attacks to snoop the packets between the servers. If someone can stage a man in the middle attack from within your corporate network topology, you have bigger problems than someone snooping your Portal packets!
So, I recommend you terminate SSL between the browser and the Portal at the web server. All traffic between IHS and the browser will be SSL if using the HTTPS URL on the browser. However, traffic between IHS and Portal can be HTTP; i.e. no SSL.
In IHS 8.5+, a new custom property has been added that is needed to make this work. The custom property, "UseInsecure", allows an HTTPS inbound connection to be sent on an HTTP transport. To set it, go to "web_server_name ". Create a new property "UseInsecure" with the value "true". Save, regen the plugin and propagate the new plugin.
This is easily done by disabling both the "HttpQueueInboundDefaultSecure" and the "WCInboundDefaultSecure" transport for each application server. There is a checkbox labeled "enabled" on the panel "Application servers > WebSphere_Portal > Web container transport chains > HttpQueueInboundDefaultSecure". Likewise for "WCInboundDefaultSecure". Uncheck the box, regenerate your web server plugin and propagate the plugin. This removes the HTTPS transports from the plugin-cfg.xml file for each server. Refer to this technote for more detail.