pgBackRest TLS认证配置问题分析与解决方案

问题背景

在使用pgBackRest进行PostgreSQL数据库备份时，用户遇到了TLS认证失败的问题。具体表现为当尝试从PostgreSQL服务器连接到第二个pgBackRest备份服务器(pgbackrest02)时，出现"access denied"错误，而第一个备份服务器(pgbackrest01)工作正常。

错误现象

执行pgbackrest --stanza prod0 check命令时返回错误：

ERROR: [105]: raised from remote-0 tls protocol on 'pgbackrest02.foo.bar.com': access denied

根本原因分析

根据pgBackRest的官方文档和技术细节分析，此问题主要由以下配置错误导致：

1. TLS服务器认证配置不当：在配置文件中，tls-server-auth参数设置不正确，导致证书CN(Common Name)不匹配。

2. 认证机制理解偏差：pgBackRest的TLS认证机制要求客户端和服务器端的证书CN必须严格匹配配置文件中指定的值。

详细技术解析

pgBackRest的TLS认证机制工作流程如下：

1. 客户端(PostgreSQL服务器)使用配置的证书尝试连接到pgBackRest服务器
2. 服务器端验证客户端证书的CN是否与配置的tls-server-auth参数匹配
3. 如果CN不匹配，服务器会返回"access denied"错误
4. 出于安全考虑，pgBackRest不会在日志中记录具体的认证失败原因

在用户提供的配置中，tls-server-auth参数设置为：

tls-server-auth=psqldb04.foo.bar.com=foo-bar-prod
tls-server-auth=pgbackrest0.foo.bar.com=foo-bar-prod
tls-server-auth=pgbackrest1.foo.bar.com=foo-bar-prod

而实际尝试连接的服务器主机名是pgbackrest02.foo.bar.com，这与配置中的pgbackrest0和pgbackrest1都不匹配，导致认证失败。

解决方案

要解决此问题，需要确保以下几点：

1. 证书CN与配置匹配：检查所有相关证书的CN(Common Name)字段，确保它们与tls-server-auth参数中配置的值完全一致。

2. 更新配置文件：根据实际服务器主机名更新tls-server-auth参数，例如：

   tls-server-auth=pgbackrest02.foo.bar.com=foo-bar-prod
   

3. 证书权限检查：虽然用户已确认证书文件权限为600，但仍需再次验证：

   • 证书文件(/var/lib/pgbackrest/host.crt)
   • 密钥文件(/var/lib/pgbackrest/host.key)
   • CA证书文件(/var/lib/pgbackrest/ca.crt)

最佳实践建议

1. 命名一致性：保持证书CN、服务器主机名和配置参数中的名称完全一致。

2. 调试方法：虽然pgBackRest出于安全考虑不记录详细认证信息，但可以通过以下方式验证TLS连接：

   • 使用openssl s_client测试基本连接
   • 检查网络连通性
   • 验证证书链完整性

3. 配置管理：对于多服务器环境，建议使用配置管理工具确保所有节点的配置一致。

4. 证书管理：考虑使用统一的证书颁发机构(CA)和标准的命名规范，避免因名称不一致导致的问题。

总结

pgBackRest的TLS认证是一个严格的过程，要求所有配置细节精确匹配。通过仔细检查证书CN与配置参数的对应关系，可以解决大多数TLS认证问题。在生产环境中，建议建立标准化的证书管理和命名规范，以降低配置错误的可能性。