繼上篇文章 在UniFi Controller如何匯入LetsEncrypt簽署的憑證？，沒想到很快就在網路社團購入物美價廉的二手 UniFi CloudKey Gen2+，但按著上篇文章的方式，雖然也是有找到對應的 java keystore，但實際將憑證更換重新啟動之後，卻還是一樣使用原廠內建的自簽憑證，LetsEncrypt的憑證並未生效。找了一下社群的帖子(Certificate-on-Cloud-Key-GEN2-plus)，看起來原廠的回覆是 CloudKey 並不支援客製化憑證，建議直接使用 unifi.ui.com 來進行管理近端設備。不過我自己是不愛用 unifi.ui.com 進行管理，因為網頁的回應效能都沒有本地端直接管理來得快，看來得再繼續仔細深入研究一下。
首先當然要先開啟 ssh 連線以便進入 CloudKey 的作業系統裡仔細觀察，進入之後就先看看是哪個 Process 佔用了 Port 443。用 netstat 指令可以看到是 PID 1229 佔用了 Port 443，再來用 ps 指令仔細看看 PID 1229 是什麼 Process，查看就發現原來是 Node.js 佔用了，同時執行的 javascript 是 /usr/share/unifi-core/app 下面的 service.js。
再來看看 /usr/share/unifi-core/app下面有些什麼檔案，找到了一個 config/config.yaml。
再打開 config.yaml 的內容來看看就一目瞭然了。原來單獨執行 UniFi Controller 時是一個單純的 J2EE Application，但放在 UniFi CloudKey 時，由於內建多種應用程式，又要從同一個入口進入管理，所以在入口網站改採 Node.js 作為入口的管理，然後也作為其他應用程式（例如：UniFi Network也就是 UniFi Controller, UniFi Protect 等等）的反向代理程式，所以換了 UniFi Network 的 Keystore 憑證當然不會生效（因爲實際是由 Node.js 來提供 HTTPS 服務）
再往後捲動看一下，就看到了憑證的路徑，原來憑證跟私鑰檔案是放在 /data/unifi-core/config 目錄下。
再打開來看看這兩個憑證檔案看看到底是用哪種格式(PEM 或是 DER)？看起來就是一般最普遍的 PEM 格式，剛好 Synology 匯出的憑證格式也就是 PEM 格式，那就太完美了，可以省略 openssl 轉換 DER 格式，直接更換檔案就好。
重新啟動 CloudKey 測試看看，果然一切完美了。
