当 pgbouncer 尝试使用 SSL/TLS 连接 postgres 时，pgbouncer 日志中出现“tlsv1 alert unknown ca”错误答案

【问题标题】："tlsv1 alert unknown ca" error in pgbouncer logs when pgbouncer is trying to connect with postgres using SSL/TLS当 pgbouncer 尝试使用 SSL/TLS 连接 postgres 时，pgbouncer 日志中出现“tlsv1 alert unknown ca”错误
【发布时间】：2022-10-12 22:25:41
【问题描述】：

我们有一个 k8s 集群，postgres pod 正在其中运行。我们的后端服务连接到 postgres K8s 服务。我试图在连接到 postgres pod 时将 PgBouncer 作为代理引入。 Postgres 启用了 ssl 模式，我们有自己的 ROOT_CA，以及一个由 ROOT_CA 签名的中间 CA。我们为这个中间 CA 签名的 postgres 创建证书。我正在使用相同的中间 CA 为 pgbouncer 签署证书并为 pgbouncer 创建一个自签名证书。我将这些证书安装在 pgbouncer pod 上。当我将后端服务配置为将流量重定向到 pgbouncer 服务并通过 pgbouncer 到 postgres 时，我看到以下错误：

2022-10-06 11:43:13.030 1 DEBUG parse_ini_file: 'verbose' = '2' ok:1
2022-10-06 11:43:13.033 1 NOISE event: 128, SBuf: 192, PgSocket: 400, IOBuf: 4108
2022-10-06 11:43:13.033 1 LOG file descriptor limit: 1048576 (H:1048576), max_client_conn: 100, max fds possible: 110
2022-10-06 11:43:13.033 1 DEBUG pktbuf_dynamic(128): 0x55a4515583c0
2022-10-06 11:43:13.033 1 DEBUG make_room(0x55a4515583c0, 4): realloc newlen=256
2022-10-06 11:43:13.033 1 DEBUG pktbuf_dynamic(128): 0x55a4515585c0
2022-10-06 11:43:13.034 1 NOISE connect(3, unix:/tmp/.s.PGSQL.5432) = No such file or directory
2022-10-06 11:43:13.034 1 DEBUG adns_create_context: udns 0.4
2022-10-06 11:43:13.034 1 DEBUG add_listen: 0.0.0.0:5432
2022-10-06 11:43:13.035 1 NOISE old TCP_DEFER_ACCEPT on 7 = 0
2022-10-06 11:43:13.035 1 NOISE install TCP_DEFER_ACCEPT on 7
2022-10-06 11:43:13.035 1 LOG listening on 0.0.0.0:5432
2022-10-06 11:43:13.035 1 DEBUG add_listen: ::/5432
2022-10-06 11:43:13.035 1 NOISE old TCP_DEFER_ACCEPT on 8 = 0
2022-10-06 11:43:13.035 1 NOISE install TCP_DEFER_ACCEPT on 8
2022-10-06 11:43:13.035 1 LOG listening on ::/5432
2022-10-06 11:43:13.035 1 DEBUG add_listen: unix:/tmp/.s.PGSQL.5432
2022-10-06 11:43:13.036 1 LOG listening on unix:/tmp/.s.PGSQL.5432
2022-10-06 11:43:13.036 1 LOG process up: pgbouncer 1.9.0, libevent 2.1.8-stable (epoll), adns: udns 0.4, tls: LibreSSL 2.6.5
2022-10-06 11:43:16.166 1 NOISE new fd from accept=10
2022-10-06 11:43:16.167 1 NOISE resync: done=0, parse=0, recv=0
2022-10-06 11:43:16.167 1 NOISE C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 pkt='!' len=8
2022-10-06 11:43:16.167 1 NOISE C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 C: req SSL
2022-10-06 11:43:16.167 1 NOISE C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 P: nak
2022-10-06 11:43:16.167 1 NOISE resync: done=8, parse=8, recv=8
2022-10-06 11:43:16.167 1 DEBUG C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 P: got connection: 127.0.0.6:38446 -> 127.0.0.6:5432
2022-10-06 11:43:16.167 1 NOISE safe_accept(7) = Resource temporarily unavailable
2022-10-06 11:43:16.167 1 NOISE resync: done=0, parse=0, recv=0
2022-10-06 11:43:16.167 1 NOISE C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 pkt='!' len=69
2022-10-06 11:43:16.168 1 DEBUG C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 got var: user=<user_name>
2022-10-06 11:43:16.168 1 DEBUG C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 got var: database=<database_name>
2022-10-06 11:43:16.168 1 DEBUG C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 using application_name: pg_isready
2022-10-06 11:43:16.168 1 NOISE cstr_get_pair: "host"="postgres-cluster"
2022-10-06 11:43:16.168 1 NOISE cstr_get_pair: "port"="5432"
2022-10-06 11:43:16.168 1 NOISE cstr_get_pair: "auth_user"="<user_name>"
2022-10-06 11:43:16.168 1 DEBUG pktbuf_dynamic(128): 0x55a4515686c0
2022-10-06 11:43:16.168 1 LOG C-0x55a451568fb0: (nodb)/(nouser)@127.0.0.6:38446 registered new auto-database: db=<database_name>
2022-10-06 11:43:16.168 1 DEBUG C-0x55a451568fb0: <user_name>/(nouser)@127.0.0.6:38446 pause_client
2022-10-06 11:43:16.168 1 NOISE S-0x55a45156ddf0: <database_name>/<user_name>@(bad-af):0 inet socket: postgres-db-pg-cluster
2022-10-06 11:43:16.168 1 NOISE S-0x55a45156ddf0: <database_name>/<user_name>@(bad-af):0 dns socket: postgres-db-pg-cluster
2022-10-06 11:43:16.168 1 NOISE dns: new req: postgres-cluster
2022-10-06 11:43:16.168 1 DEBUG zone_register(postgres-cluster)
2022-10-06 11:43:16.168 1 NOISE udns_timer_setter: ctx=0x55a4515665e0 timeout=0
2022-10-06 11:43:16.168 1 NOISE dns: udns_launch_query(postgres-cluster)=0x55a4515688e0
2022-10-06 11:43:16.168 1 NOISE udns_timer_cb
2022-10-06 11:43:16.168 1 NOISE udns_timer_setter: ctx=0x55a4515665e0 timeout=4
2022-10-06 11:43:16.168 1 DEBUG launch_new_connection: already progress
2022-10-06 11:43:16.168 1 NOISE udns_io_cb
2022-10-06 11:43:16.168 1 NOISE udns_result_a4: postgres-cluster: 1 ips
2022-10-06 11:43:16.168 1 NOISE DNS: postgres-cluster[0] = 10.43.169.137:0 [STREAM]
2022-10-06 11:43:16.168 1 NOISE dns: deliver_info(postgres-cluster) addr=10.43.169.137:0
2022-10-06 11:43:16.168 1 DEBUG S-0x55a45156ddf0: <database_name>/<user_name>@(bad-af):0 dns_callback: inet4: 10.43.169.137:5432
2022-10-06 11:43:16.168 1 DEBUG S-0x55a45156ddf0: <database_name>/<user_name>@10.43.169.137:5432 launching new connection to server
2022-10-06 11:43:16.169 1 NOISE udns_timer_setter: ctx=0x55a4515665e0 timeout=-1
2022-10-06 11:43:16.169 1 DEBUG launch_new_connection: already progress
2022-10-06 11:43:16.169 1 DEBUG S-0x55a45156ddf0: <database_name>/<user_name>@10.43.169.137:5432 S: connect ok
2022-10-06 11:43:16.169 1 LOG S-0x55a45156ddf0: <database_name>/<user_name>@10.43.169.137:5432 new connection to server (from 10.42.2.120:54000)
2022-10-06 11:43:16.169 1 NOISE S-0x55a45156ddf0: <database_name>/<user_name>@10.43.169.137:5432 P: SSL request
2022-10-06 11:43:16.169 1 DEBUG launch_new_connection: already progress
2022-10-06 11:43:16.175 1 NOISE resync: done=0, parse=0, recv=0
2022-10-06 11:43:16.175 1 NOISE S-0x55a45156ddf0: <database_name>/<user_name>@10.43.169.137:5432 launching tls
2022-10-06 11:43:16.175 1 NOISE resync: done=1, parse=1, recv=1
2022-10-06 11:43:16.175 1 NOISE tls_handshake: err=-2
2022-10-06 11:43:16.175 1 DEBUG launch_new_connection: already progress
2022-10-06 11:43:16.183 1 NOISE tls_handshake: err=-2
2022-10-06 11:43:16.183 1 DEBUG launch_new_connection: already progress
2022-10-06 11:43:16.184 1 NOISE tls_handshake: err=-1
**2022-10-06 11:43:16.184 1 WARNING TLS handshake error: handshake failed: error:1401E418:SSL routines:CONNECT_CR_FINISHED:tlsv1 alert unknown ca**
2022-10-06 11:43:16.184 1 LOG S-0x55a45156ddf0: <database_name>/<user_name>@10.43.169.137:5432 closing because: server conn crashed? (age=0)
2022-10-06 11:43:16.184 1 NOISE tls_close

Postgres 日志显示以下错误：


    "postgres","aorsdb","authentication","connection authenticated: 
    identity=""postgres"" method=md5 
    (/home/postgres/pgdata/pgroot/data/pg_hba.conf:12) 
    "postgres","aorsdb","authentication","connection authorized: 
    user=postgres database=aorsdb application_name=pgwatch2 SSL enabled 
    (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256) "could 
    not accept SSL connection: certificate verify failed

谁能建议可能出了什么问题以及我可以查看的内容？ pgbouncer.ini 文件：

[databases]
* = host=postgres-cluster port=5432 auth_user=postgres

[pgbouncer]
listen_addr = *
listen_port = 5432
pool_mode = session
max_client_conn = 100
ignore_startup_parameters = extra_float_digits
server_tls_sslmode = require
server_tls_key_file = /etc/pgbouncer/certs/server.key
server_tls_cert_file = /etc/pgbouncer/certs/server.crt
server_tls_ca_file = /etc/pgbouncer/certs/ca.crt
verbose = 2

几个问题：

既然 postgres 和 pgbouncer 的证书都是由同一个 CA 签名的，可能是什么问题？
另外我想了解流程，所以根据日志中的 ip 地址，它是 pgbouncer 试图与 postgres 通信（如预期的那样），所以我认为过程是 postgres 无法识别 CA 并抛出这个错误，是正确的还是相反的（pgbouncer 拒绝并抛出此错误）。理想情况下，我希望这不应该发生，因为两者都是由同一个 CA 签署的。

我已经做了很多事情，比如在由 ROOT_CA 本身签名的 pgbouncer pod 中安装证书，为 pgbouncer 安装证书链（生成的证书，中间 CA，ROOT CA），但到目前为止还没有运气。

【问题讨论】：

db server自己的日志文件发现什么对应的错误？
pgbouncer 和 PostgreSQL 的版本是什么？
@jjanes pgbouncer 版本： 1.9.0 ，postgres 版本： 14.4 ，
来自 postgresql 服务器的日志："postgres","aorsdb","authentication","connection authenticated: identity=""postgres"" method=md5 (/home/postgres/pgdata/pgroot/data/pg_hba.conf:12) " postgres","aorsdb","authentication","connection authorized: user=postgres database=aorsdb application_name=pgwatch2 SSL enabled (protocol=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256) "不能接受 SSL 连接：证书验证失败的”
您应该编辑您的问题并将错误消息放在那里，以便可以正确格式化。

标签： postgresql kubernetes pgbouncer

【解决方案1】：

您正在使用客户端证书。我不知道您是否打算这样做，因为客户端证书很少见，而且您包含客户端证书和客户端密钥的文件的名称很奇怪。

也许您打算在配置中使用 client_tls_key_file 和 client_tls_cert_file，而不是相应的 server_* 属性。

假设您不打算使用客户端证书，而只是使用服务器证书，那么从 pgbouncer 的角度来看：client_tls_key_file 和 client_tls_cert_file 是您用来向传入客户端证明您是您声称的身份的东西，而 server_tls_ca_file 是您用来向自己证明真正的服务器就是它声称的身份的东西。

【讨论】：

实际上，我正在关注this doc，当后端服务连接到 pgbouncer 时我没有遇到问题，但之后当 pgbouncer 尝试连接到 postgres 时，会抛出此错误。所以在这种情况下，postgres 充当服务器，而 pgbouncer 充当客户端，对吗？所以我认为指定 server* 应该是正确的。
server_* 设置用于与服务器交互。是的，在那种情况下它是客户端，但它是用于与服务器交互的，所以它们就是所谓的。如果您不希望将客户端证书发送到服务器，则说明您使用错误。那里的命名约定对我来说并不是最直观的，但如果你仔细阅读这些文档，我想你会发现他们同意我所说的，即使它不直观。（另外，这种解释是我如何让它抛出与您报告的内容相匹配的错误。）