简体   繁体   English

Openssl:在 SSL_CTX_load_verify_locations API 中使用 CApath 参数时证书验证失败

[英]Openssl: certificate verification fails when CApath argument is used in SSL_CTX_load_verify_locations API

I am trying to establish a TLS connection to a server machine.我正在尝试与服务器计算机建立 TLS 连接。 I have created the root CA certificate and the server certificate using openssl CLI commands.我已经使用 openssl CLI 命令创建了根 CA 证书和服务器证书。 I created the server certificate with common name same as its IP address.我创建了通用名称与其 IP 地址相同的服务器证书。 The common name of the root CA certificate is the FQDN of the server.根 CA 证书的通用名称是服务器的 FQDN。

I am using openssl library APIs to establish connection to the server.我正在使用 openssl 库 API 来建立与服务器的连接。 I am using the API我正在使用 API

int SSL_CTX_load_verify_locations(SSL_CTX *ctx, const char *CAfile, const char *CApath)

for setting the CA file look up path.用于设置 CA 文件查找路径。

Everything works fine when I use the CAfile argument to specify the path of my CA file, leaving the CApath argument as NULL.当我使用 CAfile 参数指定我的 CA 文件的路径时,一切正常,将 CApath 参数保留为 NULL。

But if I use the CApath argument to specify the path to the directory containing the CA files, leaving the CAfile argument as NULL, the connection fails due to certificate verification error.但是,如果我使用 CApath 参数指定包含 CA 文件的目录的路径,将 CAfile 参数保留为 NULL,则连接会因证书验证错误而失败。

When I captured the packets using wireshark, I found that my client code is sending TLS response "Unknown CA" for the "server hello" from the server.当我使用wireshark捕获数据包时,我发现我的客户端代码正在为来自服务器的“server hello”发送TLS响应“Unknown CA”。 I have used the same CA certificate file that I have used in the successful connection.我使用了在成功连接中使用的相同 CA 证书文件。

From my observation while exploring the openssl library source code, I infer that, in my case, the CA files are not being considered valid and hence not being loaded by the library APIs due to some unknown reason.根据我在探索 openssl 库源代码时的观察,我推断在我的情况下,CA 文件不被认为是有效的,因此由于某些未知原因未被库 API 加载。

Can someone tell me the reason and, if possible, a solution for this issue?有人可以告诉我原因,如果可能的话,可以解决这个问题吗?

I'm posting answer for my own question, because I spent a lot of time for finding a solution for this problem since I didn't get too much information regarding this issue from the internet.我正在发布我自己问题的答案,因为我花了很多时间来寻找这个问题的解决方案,因为我没有从互联网上获得太多关于这个问题的信息。 And I hope this will help someone else facing the similar issue.我希望这会帮助其他面临类似问题的人。

If the CApath is not null, the directory pointed by CApath should contain valid CA certificates.如果 CApath 不为空,则 CApath 指向的目录应包含有效的 CA 证书。 And the most important thing is that the CA file name should be the subject name hash value.而且最重要的是CA文件名应该是主题名哈希值。

Either the CA files can be renamed to their subject name hash values or softlinks to the CA files can be created with the name same as the CA subject name hash of the CA files.可以将 CA 文件重命名为其主题名称哈希值,或者可以使用与 CA 文件的 CA 主题名称哈希相同的名称创建指向 CA 文件的软链接。

c_rehash utility can be used to create the necessary links in the CApath. c_rehash实用程序可用于在 CApath 中创建必要的链接。 The syntax of this command is quite simple.此命令的语法非常简单。

c_rehash <CApath>

c_rehash utility may not be available in all linux distros. c_rehash 实用程序可能并非在所有 Linux 发行版中都可用。 In that case在这种情况下

openssl x509 -in <CA file name> -noout -subject_hash

can be used to generate the subject name hash(eg e5d93f80).可用于生成主题名称哈希(例如 e5d93f80)。 Just append ".0" to this value and create a softlink with this name(e5d93f80.0) to the CA file.只需将“.0”附加到此值,并使用此名称 (e5d93f80.0) 创建指向 CA 文件的软链接。 If there are more than one CA files with same the subject name hash value, their extensions should be different(eg e5d93f80.1).如果存在多个具有相同主题名称哈希值的 CA 文件,它们的扩展名应该不同(例如 e5d93f80.1)。 The search is performed in the ordering of the extension number.按照分机号码的顺序进行搜索。

opensssl has introduced this technique to reduce the the CA file look up time. opensssl 引入了这种技术来减少 CA 文件的查找时间。 Otherwise openssl may have to read all files in the CApath to find the matching CA file.否则 openssl 可能必须读取 CApath 中的所有文件才能找到匹配的 CA 文件。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM