这是一次真实事件案例改编。用户A在部署 Cloudreve 存储策略时，集成了用户内网环境下的 MinIO S3 服务。但是当用户上传资料时发现Cloudreve无法工作，无法将资源上传到MinIO中。

我也是第一次接触Cloudreve，经过搜索发现Cloudreve是一个自托管文件管理与共享系统，支持多存储提供商。那么现在的问题就变成了Cloudreve如何配置使用了自定义证书的S3服务Minio。

由于用户的Minio服务使用了DDNS映射到公网，我首先想到的是，使用可以通过mc访问到用户的Minio服务。经过初步排查：

  1. 确认内网穿透链路正常。
  2. 使用 MinIO 客户端工具 mc 测试，发现必须带上 –insecure 参数才能正常访问，明确了核心矛盾在于 SSL 证书验证失败。
  3. 尝试将证书放置在自定义目录并使用 mc –config-dir 指定，可以连接成功，但 Cloudreve 还是无法正常工作，无法直接复用该配置，且即便在同目录下放置证书也未能生效。

经过搜索和分析，知道需要将自定义 CA 证书导入系统信任库，才能使 Cloudreve（Go 环境）能够原生识别。那么现在的问题就变成了如何在 CentOS 系统中安装并激活自定义证书？

经过一番折腾摸索，终于搞定，这里记录一下历程。

1，检查证书是否PEM格式？

Go 程序通常识别PEM格式的证书。所以需要先检查自定义证书是否是PEM格式？可以使用以下命令检查证书文件（如public.crt）：

cat public.crt
  • 如果开头是 —–BEGIN CERTIFICATE—–，则是 PEM 格式。
  • 如果是一堆乱码，则是 DER 格式。

如果是DER格式，需要转换为PEM格式，转换的命令如下：

openssl x509 -inform der -in public.crt -out public.pem

2，放置证书

在CentOS Linux中，需要将证书文件放在/etc/pki/ca-trust/source/anchors/目录下，并且后缀必须为.crt。如果文件名为public.pem，需要改为public.crt。这是血的经验和教训。

首先确认文件是否放置正确？

ls /etc/pki/ca-trust/source/anchors/

输出中应包含我们的证书，如果没有，需要重新放置。

3，激活证书

当放置好证书后，必须进行激活，否则系统不认。可以执行以下命令激活，让系统重新扫描目录并生成全局信任束，依次执行：

update-ca-trust extract
update-ca-trust

4，验证证书是否激活成功

我们需要确认是否激活成功？确认的方法就是检查系统全局证书合集ca-bundle.crt是否已包含你的证书信息：

tail -n 20 /etc/pki/tls/certs/ca-bundle.crt

可以查看最近的20行中是否包含自己的证书，如果还没有成功，则执行命令追加：

cat public.crt | sudo tee -a /etc/pki/tls/certs/ca-bundle.crt

最后，使用 grep 再次搜索证书中关键的信息

grep -i "域名信息" /etc/pki/tls/certs/ca-bundle.crt

这个时候应该就一定可以搜索到了。血的经验和教训。

5，验证在系统中使用证书

在Cloudreve所在的服务器上使用curl验证Minio服务，我们使用以下命令检验Minio是否可以使用自签名证书

curl -v https://yourdomain.com:9000

如果输出SSL证书信息，并显示Access 相关信息，则成功了。如果没有，则需要再次检查证书生成信息是否正确？例如，是否包含了正确的域名？

6，重启Cloudreve网盘服务

最后一定要重启Cloudreve网盘，只有重启之后才能加载系统自定义证书。

# 根据你的部署方式重启，例如：
systemctl restart cloudreve

到这里，基本上99%都会解决问题，如果没有解决，那么请联系我，只有我亲自坐镇了。在处理自托管服务的 TLS 问题时，系统级信任往往比应用级配置更高效。针对 Cloudreve 这种基于 Go 编写的应用，只要底层操作系统信任了 CA 证书，上层的 S3 连接问题便迎刃而解。解决问题前一定要理解运行原理和掌握解决问题方法，否则会走弯路还不一定能解决问题。