This article will advocate that one should NOT use SSL between the web servers and the Portal servers due to high cost in CPU cycles and the relatively low level of security it ultimately provides.
By default, there are two paths that a request can be forwarded from a web Server (Apache, IHS, etc) to the Portal servers. One is unencrypted (http) and one is encrypted (ssl, https). By default, if a request from a browser arrives at IHS via SSL, it will be forwarded to the Portal server via an https,ssl transport as well.
SSL serves two main purposes. One is to authenticate that the target server is who it is expected to be. The other is to encrypt the data that flows between the two servers.
Unfortunately, you do not get something (SSL) for nothing. Encryption is CPU intensive. Ever HTTPS packet that arrives from the browser has to be decrypted at the IHS server and then re-encrypted as it flows out the IHS server, thru the plugin and on to the Portal server. It is then decrypted again at the Portal server. If you compare the CPU utilization of the IHS and Portal servers during a stress run in a pure HTTP versus an HTTPS run, the results are often dramatic.
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.
This is easily done by disabling the "HttpQueueInboundDefaultSecure" transport for each application server. There is a checkbox labeled "enabled" on the panel "Application servers > WebSphere_Portal > Web container transport chains > HttpQueueInboundDefaultSecure". 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.
Note: Do not disable the "InboundAdmin" transports.