当前位置： 文江博客话题详情

OpenSSL：无法验证 Experian URL 的第一个证书

发布于 2024-12-07 05:05:30 字数 483 浏览 1 评论 0原文

我正在尝试使用 OpenSSL 客户端验证 Ubuntu 10.10 中与 Experian 的 SSL 连接。

openssl s_client -CApath /etc/ssl/certs/ -connect dm1.experian.com:443

问题是连接关闭并显示验证返回代码：21（无法验证第一个证书）。

我检查了证书列表，用于签署 Experian 的证书（VeriSign Class 3 Secure Server CA - G3）包含在列表中。

/etc/ssl/certs/ca-certificates.crt

但我不知道为什么它无法验证第一个证书。

完整的响应可以在这里看到： https://gist.github.com/1248790

原文

I am trying to verify an SSL connection to Experian in Ubuntu 10.10 with OpenSSL client.

openssl s_client -CApath /etc/ssl/certs/ -connect dm1.experian.com:443

The problem is that the connection closes with a Verify return code: 21 (unable to verify the first certificate).

I've checked the certificate list, and the Certificate used to sign Experian (VeriSign Class 3 Secure Server CA - G3) is included in the list.

/etc/ssl/certs/ca-certificates.crt

Yet I don't know why it is not able to verify the first certificate.

The entire response could be seen here:
https://gist.github.com/1248790

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（5）

终陌 2024-12-14 05:05:30

第一条错误消息告诉您有关该问题的更多信息：

验证错误：num=20：无法获取本地颁发者证书

最终实体服务器证书的颁发证书颁发机构是

VeriSign 3 级安全服务器 CA - G3

仔细查看您的 CA 文件 - 您将找不到此证书，因为它是中间 CA - 您发现的是类似名称 VeriSign 的 G3 公共主要 CA。

但为什么另一个连接成功，而这个却不成功呢？问题是服务器配置错误（使用 -debug 选项自行查看）。 “好的”服务器在握手期间发送整个证书链，从而为您提供必要的中间证书。

但是发生故障的服务器仅向您发送最终实体证书，并且 OpenSSL 无法“即时”下载丢失的中间证书（这可以通过解释权威信息访问扩展来实现） 。因此，您的尝试使用 s_client 会失败，但如果您使用 FireFox（它确实支持“证书发现”功能）浏览到相同的 URL，它仍然会成功。

解决该问题的选择是通过让服务器也发送整个链来在服务器端修复此问题，或者将缺少的中间证书作为客户端参数传递给 OpenSSL。

The first error message is telling you more about the problem:

verify error:num=20:unable to get local issuer certificate

The issuing certificate authority of the end entity server certificate is

VeriSign Class 3 Secure Server CA - G3

Look closely in your CA file - you will not find this certificate since it is an intermediary CA - what you found was a similar-named G3 Public Primary CA of VeriSign.

But why does the other connection succeed, but this one doesn't? The problem is a misconfiguration of the servers (see for yourself using the -debug option). The "good" server sends the entire certificate chain during the handshake, therefore providing you with the necessary intermediate certificates.

But the server that is failing sends you only the end entity certificate, and OpenSSL is not capable of downloading the missing intermediate certificate "on the fly" (which would be possible by interpreting the Authority Information Access extension). Therefore your attempt fails using s_client but it would succeed nevertheless if you browse to the same URL using e.g. FireFox (which does support the "certificate discovery" feature).

Your options to solve the problem are either fixing this on the server side by making the server send the entire chain, too, or by passing the missing intermediate certificate to OpenSSL as a client-side parameter.

回复 原文
秋凉 2024-12-14 05:05:30

在浮雕的答案中添加额外的信息。

简而言之，您的证书链中有一个不正确的证书。

例如，您的证书颁发机构很可能会为您提供 3 个文件。

  • your_domain_name.crt
  • DigiCertCA.crt #（或者无论您的证书颁发机构的名称是什么）
  • TrustedRoot.crt

您很可能将所有这些文件合并到一个捆绑包中。

-----BEGIN CERTIFICATE----- 
(Your Primary SSL certificate: your_domain_name.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Your Intermediate certificate: DigiCertCA.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Your Root certificate: TrustedRoot.crt) 
-----END CERTIFICATE-----

如果您创建捆绑包，但使用旧的或不正确版本的中间证书（在我的示例中为 DigiCertCA.crt），您将得到您所描述的确切症状。

从证书颁发机构重新下载所有证书并制作新的捆绑包。

Adding additional information to emboss's answer.

To put it simply, there is an incorrect cert in your certificate chain.

For example, your certificate authority will have most likely given you 3 files.

  • your_domain_name.crt
  • DigiCertCA.crt # (Or whatever the name of your certificate authority is)
  • TrustedRoot.crt

You most likely combined all of these files into one bundle.

-----BEGIN CERTIFICATE----- 
(Your Primary SSL certificate: your_domain_name.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Your Intermediate certificate: DigiCertCA.crt) 
-----END CERTIFICATE----- 
-----BEGIN CERTIFICATE----- 
(Your Root certificate: TrustedRoot.crt) 
-----END CERTIFICATE-----

If you create the bundle, but use an old, or an incorrect version of your Intermediate Cert (DigiCertCA.crt in my example), you will get the exact symptoms you are describing.

Redownload all certs from your certificate authority and make a fresh bundle.

回复 原文
掩于岁月 2024-12-14 05:05:30

我在 Amazon Elastic Load Balancer 实例上安装签名证书时遇到了同样的问题。

所有这些似乎都是通过浏览器（Chrome）找到的，但是通过我的 java 客户端访问该站点产生了异常 javax.net.ssl.SSLPeerUnverifiedException

我没有做的是在我的 ELB 实例上安装证书时提供“证书链”文件（请参阅<一href="https://serverfault.com/questions/419432/install-ssl-on-amazon-elastic-load-balancer-with-godaddy-wildcard-certificate">https://serverfault.com/questions/419432/ install-ssl-on-amazon-elastic-load-balancer-with-godaddy-wildcard-certificate）

我们仅收到来自签名的签名公钥因此我必须创建自己的证书链文件。使用浏览器的证书查看器面板，我导出了签名链中的每个证书。 （证书链的顺序很重要，请参阅 https://forums.aws。 amazon.com/message.jspa?messageID=222086)

I came across the same issue installing my signed certificate on an Amazon Elastic Load Balancer instance.

All seemed find via a browser (Chrome) but accessing the site via my java client produced the exception javax.net.ssl.SSLPeerUnverifiedException

What I had not done was provide a "certificate chain" file when installing my certificate on my ELB instance (see https://serverfault.com/questions/419432/install-ssl-on-amazon-elastic-load-balancer-with-godaddy-wildcard-certificate)

We were only sent our signed public key from the signing authority so I had to create my own certificate chain file. Using my browser's certificate viewer panel I exported each certificate in the signing chain. (The order of the certificate chain in important, see https://forums.aws.amazon.com/message.jspa?messageID=222086)

回复 原文
浅浅 2024-12-14 05:05:30

您可以执行以下操作：-

Exim SSL 证书

默认情况下，/etc/exim.conf 将使用 cert/key 文件：

/etc/exim.cert
/etc/exim.key

因此，如果您想知道在哪里设置文件，那就在哪里。

它们由 exim.conf 的选项控制：

tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key

中间证书

如果您有 CA 根证书（ca 捆绑包、链等），您将在实际证书之后将 CA 的内容添加到 exim.cert 中。

确保您拥有其他地方所有内容的副本，以防万一出错，这可能是个好主意。

Dovecot 和 ProFtpd 也应该正确读取它，因此 dovecot 不再需要 ssl_ca 选项。
因此，对于这两种情况，无需对 exim.conf 或 dovecot.conf(/etc/dovecot/conf/ssl.conf) 进行任何更改

Here is what you can do:-

Exim SSL certificates

By default, the /etc/exim.conf will use the cert/key files:

/etc/exim.cert
/etc/exim.key

so if you're wondering where to set your files, that's where.

They're controlled by the exim.conf's options:

tls_certificate = /etc/exim.cert
tls_privatekey = /etc/exim.key

Intermediate Certificates

If you have a CA Root certificate (ca bundle, chain, etc.) you'll add the contents of your CA into the exim.cert, after your actual certificate.

Probably a good idea to make sure you have a copy of everything elsewhere in case you make an error.

Dovecot and ProFtpd should also read it correctly, so dovecot no longer needs the ssl_ca option.
So for both cases, there is no need to make any changes to either the exim.conf or dovecot.conf(/etc/dovecot/conf/ssl.conf)

回复 原文
羁客 2024-12-14 05:05:30

对于使用 Zerossl.com 证书的用户，请将所有证书（按原样）拖放到各自的文件夹中。

将文本剪切并粘贴到现有文件中可能会导致 utf8 问题 - 取决于操作系统、格式和字符间距。

For those using zerossl.com certificates, drag and drop all certificates (as is) to their respective folders.

Cut and pasting text into existing files, may cause utf8 issues - depending upon OS, format and character spacings.

回复 原文
~没有更多了~

关于作者

少年亿悲伤

暂无简介

0 文章
0 评论
23 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

已经忘了多久

文章 0 评论 0

15867725375

文章 0 评论 0

LonelySnow

文章 0 评论 0

走过海棠暮

文章 0 评论 0

轻许诺言

文章 0 评论 0

信馬由缰

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文