JDBC连接DigitalOcean托管PostgreSQL时ca-certificate.crt存放位置

ca-certificate.crt没有强制要求的固定存放路径，只要满足两个核心条件即可：

• 运行JDBC应用的进程对证书文件拥有可读权限
• 路径稳定，不会随应用迭代部署、环境重启出现文件丢失、路径变更问题
  绝对不要把CA证书提交到公共/内部源码仓库，避免证书泄露带来安全风险

本地开发阶段 #

• 推荐存放路径：放在当前项目的专属资源目录下，比如标准Maven/Gradle项目可新建src/main/resources/certs/目录存放证书，同时把certs/规则加入项目.gitignore文件，避免误提交。
• 可选配置方案：
  • 轻量调试方案：直接在JDBC连接串中指定证书路径，连接串追加参数sslmode=verify-full&sslrootcert=<证书相对路径>，比如sslrootcert=src/main/resources/certs/ca-certificate.crt。这种方案不需要修改本地JVM全局配置，随项目走，适合单项目快速开发调试，注意相对路径是相对于应用启动时的工作目录。
  • 全局复用方案：用JDK自带的keytool工具把CA证书导入本地JDK的全局信任库cacerts，执行命令：

    keytool -importcert -file <证书本地路径> -alias do-pg-ca -keystore $JAVA_HOME/lib/security/cacerts
    

    信任库默认密码为changeit，导入完成后本地所有依赖该JDK的应用连接该数据库时，都不需要单独配置证书路径。

生产部署阶段 #

• 推荐存放路径：不要把证书和应用Jar/War包打包在一起，Linux裸机部署建议统一放到服务器专属证书目录，比如/etc/ssl/private/do-postgres/，严格配置文件权限，仅给运行应用的业务账号分配只读权限，禁止其他普通用户访问。如果是K8s/容器化部署，把证书作为Secret资源以只读模式挂载到容器内固定路径，比如/run/secrets/ca-certificate.crt，绝对不要把证书打进容器镜像层。
• 可选配置方案：
  • 环境变量注入方案：JDBC连接串中通过环境变量读取证书路径，参数配置为sslmode=verify-full&sslrootcert=${DB_CA_CERT_PATH}，应用启动时通过环境变量把DB_CA_CERT_PATH指向证书的实际绝对路径即可，不同环境切换不需要修改代码或配置文件。
  • 专属信任库方案：提前把CA证书导入独立的JKS信任库文件，应用启动时通过JVM参数指定信任库路径：

    java -jar your-app.jar \
      -Djavax.net.ssl.trustStore=/path/to/prod-truststore.jks \
      -Djavax.net.ssl.trustStorePassword=<信任库密码>
    

    这种方案不需要在JDBC连接串中单独配置证书参数，也不会修改JVM全局信任库，适合对安全要求高、多应用混部的生产环境。

注意：生产环境严禁为了简化配置将sslmode设置为disable/require/verify-ca跳过证书主机名校验，否则会存在中间人攻击风险，必须使用verify-full模式完成完整的TLS证书校验。

内容的提问来源于stack exchange，提问作者Basil Bourque