使用Docker及自签署证书为Nextcloud配置Onlyoffice（三）

由于使用了自签署的证书，因此在配置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的证书。