先前在測試藉由https連線至IHS，再透過IHS轉發request至WebSphere時，
有發生IHS無法成功對WebSphere建立連線的問題，
當時有猜測該不會是因為在IHS使用自簽憑證導致的，
不過透過昨天成功換上符合規範的SSL憑證後，問題仍然沒解決，
可見問題不是出在IHS的憑證，
馬後炮一下，現在想想IHS連線至WebSphere有問題，
怎麼樣也不會跟IHS自己掛載在:443使用的憑證有關

那麼問題出在哪裡呢?
透過這幾天與SSL憑證的糾纏，算是對SSL憑證有了更多的理解，也大概有了新的方向，
首先，IHS連線至WebSphere是透過IHS上面安裝的WebSphere Plug-in運作的，
因此當SSL連線有問題時，應該要先查Plug-in裡面的kdb是否有問題，
從WebSphere console中可以看到WebSphere會將kdb傳送到以下路徑

連進去IHS的server裡面驗證一下，

#列出kdb內含的憑證
cd /opt/IBM/WebSphere/Plugins/config/webserver1/
gskcapicmd -cert -list -db plugin-key.kdb -stashed

結果可以看到回應是

CTGSK2016W An invalid database password was encountered.

正常情況下

.kdb旁邊會有個.sth檔案是用來儲存.kdb的密碼的，
我們前面在下指令時加上的參數 -stashed 就是藉由讀取.sth檔來取代手動輸入密碼

plugin-key.kdb的預設密碼是WebAS，如果刪掉-stashed，手動輸入密碼，是可以讀取的kdb的

gskcapicmd -cert -list -db plugin-key.kdb

表示plugin-key.sth中儲存的密碼是有問題的，

透過指令把密碼改成123456，加上-stash ，讓新密碼重新覆蓋.sth

gskcapicmd -keydb -changepw -db plugin-key.kdb -new_pw 123456 -stash

再次下指令列出kdb內含的憑證，就成功了

重啟webserver1讓IHS重新讀取plugin-key.kdb資訊之後，
再試試看使用https連線

這次果然成功連線，沒有回應Internal Error了
再看看access_log

172.17.0.1 to 172.17.0.2:9443 - - [19/Oct/2022:18:16:01 +0000] "GET /Iron30/DemoServlet?action=testConn HTTP/1.1" 200

確認是透過SSL加密連線的port 9443連到WebSphere的

終於成功讓IHS將request轉送到WebSphere了!

在此要還自簽憑證一個清白，
用自簽憑證根本不影響IHS與WebSphere的SSL連線

最後沒想到竟然是kdb的密碼檔有問題，
雖然繞了一大圈，不過這幾天也多學到了一點東西，
總之，解決問題的感覺真好