软件更新后出现问题：“无法设置 SSL 密码列表错误：1410D0B9：SSL 例程：SSL_CTX_set_cipher_list：无密码匹配”
几年前，我编写了一个 Perl CGI 脚本，该脚本连接到 openLDAP 服务器并在可用时启动 TLS。
该脚本在 SLES12 SP5 的 openLDAP-2.4.41 上成功运行，没有问题，但更新某些软件包后，该脚本无法再使用 $ldap->start_tls 启动 TLS。
错误信息是：
“无法设置 SSL 密码列表错误：1410D0B9：SSL 例程：SSL_CTX_set_cipher_list：没有密码匹配”
安装的更新是 (AFAIK) openldap2-2.4.41-22.5.1 以及 libopenssl1_1- 1.1.1d-2.54.1。具体来说，Perl LDAP 模块没有更新。
我的代码没有指定密码列表，但指定了 CA 路径并使用 require 进行证书验证。
输出错误消息的代码部分是：
$msg = $ldap->start_tls(%options);
if ($msg->code()) {
perr($q 'start_TLS() failed: ', $msg->error);
}
真正奇怪的是，在不同服务器（应该具有相同软件）上启动的简单测试用例使用密码 AES256-GCM-SHA384 成功。 即使我在同一台服务器上运行该脚本，它也会使用相同的密码成功。 测试用例中使用的代码基本上是：
my $m = $l->start_tls(verify => 'verify');
$m->code() || print $l->cipher(), "\n";
仔细观察时，我注意到我的 CA 路径是 /etc/ssl/certs 这是一个到 /var/lib/ca- 的符号链接certificates/pem 与其他 RPM 软件包几乎同时更新。 即使将 CGI 中的 CA 路径更改为 /var/lib/ca-certificates/pem ，我也会遇到相同的错误。
所使用的 Web 服务器也使用其他软件包进行了更新；它是apache2-2.4.51-35.7.1。 Perl 代码使用 PerlResponseHandler ModPerl::Registry 运行，apache RPM 变更日志称它是“针对 openssl 1.1 构建的”。
可能是什么问题或导致了这种情况，我该如何解决？
Several years ago I wrote a Perl CGI script that connects to an openLDAP server and starts TLS when available.
The script was running successfully with openLDAP-2.4.41 of SLES12 SP5 without a problem, but after updating some packages, the script cannot start TLS using $ldap->start_tls any more.
The error message is:
"Failed to set SSL cipher list error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list: no cipher match"
The updates installed were (AFAIK) openldap2-2.4.41-22.5.1 together with libopenssl1_1-1.1.1d-2.54.1. Specifically there was no update for the Perl LDAP modules.
My code does not specify a ciphers list, but is specifies the CA path and used require for certificate verification.
The part of the code that outputs the error message is:
$msg = $ldap->start_tls(%options);
if ($msg->code()) {
perr($q 'start_TLS() failed: ', $msg->error);
}
A truly odd thing is that a simple test case started on a different server (that should have the same software) succeeds with cipher AES256-GCM-SHA384.
Even when I run that script on the same server, it succeeds with the same cipher.
The code used in the test case basically is:
my $m = $l->start_tls(verify => 'verify');
$m->code() || print $l->cipher(), "\n";
While looking closer, I noticed that my CA path is /etc/ssl/certs which is a symbolic link to /var/lib/ca-certificates/pem updated about the same time as the other RPM packages.
Even when changing the CA path in the CGI to /var/lib/ca-certificates/pem I get the same error.
The web server being used was updated with the other packages, too; it it apache2-2.4.51-35.7.1.
The Perl code runs with PerlResponseHandler ModPerl::Registry, and the apache RPM changelog says it was "build against openssl 1.1".
What might be wrong or causing this, and how can I fix it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于我的 CGI 脚本在安装当前的 SLES 12 SP5 更新后再次神奇地工作，我必须假设有一个错误的更新导致了失败。
怀疑导致该问题的软件包可能是 apache2、perl 或 openssl，我尝试查找错误版本：
apache2-2.4.51-35.7.1
libopenssl1_1-1.1.1d-2.54.1
可能是糟糕的版本，而
libopenssl0_9_8-0.9.8j-106.33.1
阿帕奇2-2.4.51-35.13.1
openssl1_0_0-1.0.2p-3.48.1
再次修复了问题。
As my CGI script magically worked again after having installed current SLES 12 SP5 updates, I must assume that there was a bad update causing the failure.
Suspecting that the packages causing that might have been apache2, perl, or openssl, I try to find the bad versions:
apache2-2.4.51-35.7.1
libopenssl1_1-1.1.1d-2.54.1
were probably the bad versions, while
libopenssl0_9_8-0.9.8j-106.33.1
apache2-2.4.51-35.13.1
openssl1_0_0-1.0.2p-3.48.1
fixed the problem again.