背景与问题描述

Cloudreve是一个自托管文件管理与共享系统，支持多存储提供商。

在部署 Cloudreve 存储策略时，我们需要集成内网环境下的 MinIO S3 服务。由于 MinIO 部署在内网并配合内网穿透暴露至公网，且使用了自签名证书，我们在配置完成后发现客户端无法正常上传文件。

初步排查：

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

最终方案：

将自定义 CA 证书导入系统信任库，使 Cloudreve（Go 环境）能够原生识别。

解决方案：在 CentOS 系统中安装并激活自定义证书

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

Go 程序通常识别PEM格式的证书。
使用以下命令检查证书文件（如public.crt）：

cat public.crt
  • 如果开头是 —–BEGIN CERTIFICATE—–，则是 PEM 格式。
  • 如果是一堆乱码，则是 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

查看是否是自己的证书，如果还没有成功，执行命令追加：

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是否可以使用自签名证书

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

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

6，重启Cloudreve网盘服务

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

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

在处理自托管服务的 TLS 问题时，系统级信任往往比应用级配置更高效。针对 Cloudreve 这种基于 Go 编写的应用，只要底层操作系统信任了 CA 证书，上层的 S3 连接问题便迎刃而解。