由於使用了自簽署的證書，因此在配置nextcloud與onlyoffice互聯過程中，遇到了很多的問題，踩了很多坑，現記錄如下：
1. NAT帶來的問題
比筆者的環境中，nextcloud與onlyoffice部署在同一個子網的兩臺虛擬機上，二者都通過端口映射向互聯網提供服務。由此就帶來了，互聯網上的用戶和nextcloud訪問的onlyoffice時地址不相同的問題，具體說來就是：互聯網上的用戶訪問onlyoffice時，使用的是公網IP，而nextcloud訪問onlyoffice時使用的是私有地址。
解決該問題的方法是，使用域名訪問，而非地址訪問。外部互聯網上，將onlyoffice的域名解析到公網IP上，而內部局域網上，將域名解析到內部私有地址上。
2. 自簽署證書帶來的問題
在nextcloud訪問onlyoffice時，由於使用的是https協議，因此nextcloud需要驗證onlyoffice的證書，由於是自簽署的證書，所以會導致驗證失敗，具體表現爲curl命令返回代碼爲60的錯誤。解決問題的方法是，將自制根證書導入到nextcloud容器中。另一方面，onlyoffice在驗證nextcloud的證書時，也會遇到同樣的問題，解決的方法是關閉掉相應的身份檢查（onlyoffice好像使用了nodejs，而nodejs無法添加授信根證書，因此解決問題的最便捷的方法就是關掉相應的身份檢查）。上述的解決方法，都已經在前文中具體記述。
3. 有關自簽署證書的其他問題
由於nextcloud和onlyoffice都使用了自簽署的證書，因此在瀏覽器訪問的時候都會彈出相應的安全警告。這一問題，可以通過將自制的根證書導入系統或瀏覽器來解決。但是不幸的是，目前，PC端chrome瀏覽器即使導入了相應的根證書，仍然會報common name不符的安全警告，原因未明；安卓平臺，似乎自安卓7之後，已經不能導入自制根證書了。
總之，由於使用了自簽署證書，會帶來很多意向不到的問題，因此，爲了迴避這些問題，還是應該儘量優先選擇外部受信證書，比如let's encrypt的證書。