Posted by 
就在我們公司新網站即將上線的前一天，最終測試的階段出了個大包，最重要的結帳頁面居然被瀏覽器標上「不安全」的警告標示。
即使是這麼一個在手機上很容易被使用者忽略小小標示，對於安全性相對重要的電子商務網站而言，卻是不可容忍的致命傷。畢竟在個資相當敏感的電商網站上進行付款時，任何一個微小的安全漏洞都可能被駭客盯上。
由於事關重大，我們只好先將新網站的上線日期先延後一天，而Elena也在沉重的壓力下花了好幾個小時，最後終於讓公司渡過危機，也找到了ssl網頁中https被標示不安全的終極解決法，相信以後若再遇到類似問題，利用這套解決法應可大幅節省不少寶貴時間！
話說這次問題出現的起因，在於新網站準備上線的前一天做了網站搬家的動作，也就是在不變更域名的前提下，將網站從A伺服器搬到B伺服器。原本以為靠著「Updraftplus」這支好用的備份、還原外掛的幫忙，應該可以順利且快速地移轉資料，沒想到網站搬家後卻無預警出包，果然還真是不能趕在最後一刻做網站的搬遷，否則可能會淪落到必須延後上線時間的下場。
先前https安全連線因圖片問題而失效的時候，曾經以頁面編輯器Elementor的Replace URL功能順利解決，不過這回Elementor不管用了，因爲搬家後讓圖片產生問題的始作俑者並非Elementor，而是另有其他原因。
延伸閱讀: 如何解決圖片造成的https安全連線失效問題？
為了找出這次https安全連線被瀏覽器標示為「不安全」的原因，我試了以下3種方法：(當然前提是已經申請好SSL金鑰，無論是免費或付費的都可以)
- 利用「Really Simple SSL」外掛幫網站啟用SSL
將「Really Simple SSL」外掛安裝好之後，它就會自動偵測系統並幫網站啟用SSL，但某些伺服器可能會遇到wp-config.php檔寫入權限的問題，如下圖。
我們新網站使用的伺服器是Google雲端平台(Google Cloud Platform)，也遇到無法寫入wp-config.php檔的問題，這時就必須以FTP登入伺服器去手動修改檔案的讀寫權限。
延伸閱讀: How to Fix FTP Permission Errors on Google Cloud
修改過檔案的讀寫權限之後，SSL就能正常啟用了。但正常啟用SSL仍未解決部分網頁的https安全連線被瀏覽器標示為「不安全」的問題，仍需繼續找尋原因。
- 利用線上偵測工具「Why No Padlock?」偵錯
其實提供線上偵測SSL安全連線的網站還真不少，試了好幾個總覺得不太滿意，明明是https頁面有問題的網站，偵測結果卻一切正常，只有「Why No Padlock?」的偵測結果較精準，但還是無法真正找出問題的來源。
延伸閱讀: 10 Online Tool to Test SSL, TLS and Latest Vulnerability
- 利用Google的Chrome開發者工具偵錯
最後是無意中在WordPress的英文版官方論壇，發現其他電商網站的站長也有類似問題，有人推薦利用Chrome開發者工具(Tools for Web Developers)進行偵錯。
開發者工具已內建於Google的Chrome瀏覽器中，在瀏覽網頁時可直接以快捷鍵叫出來使用，無須額外安裝擴充外掛。由於已知https被瀏覽器標示為「不安全」的頁面，便直接在該頁面上按F12快捷鍵，果然在Console區塊就顯示了4個Mixed Content，全部都是http開頭的圖片連結。
原來，在網站搬家之後，Woocommerce的結帳頁面(Checkout Page)中部分圖片的html連結仍為http開頭，在瀏覽器中當然會被懷疑為不安全。繞了一大圈終於找出https被瀏覽器標示為「不安全」的原因，那接下來又該如何做呢？
由於結帳頁面(Checkout Page)是由Woocommerce產生的，無法像一般頁面那樣自行修改、編輯html原始碼。即使將結帳頁面刪除再重新產生一次也無解，那些有問題的http開頭連結並不會聰明的自動修改為https。
最後只好用土法煉鋼的方式，先將那些http開頭連結的圖片全部刪除，再重新上傳改過檔名的圖片(改檔名是為了保險起見)，結果就成功解決問題了！
看著那美麗的https綠色鎖頭終於重見天日，大腹便便的我都快喜極而泣了！我想這就是WordPress能讓這麼多人著迷、成為網頁界主流的其中一個原因吧。解決難題的過程固然辛苦，但克服時那種「柳暗花明又一村」的成就感實在是無與倫比的爽快，我又怎能抗拒它的魅力呢？