使用链接的CA和链接的证书进行OpenSSL验证

s_server中的服务器证书/链也是如此，只是它几乎总是使用而不是很少使用.I have a certificate chain as:root CA -> intermediate CA -> org CA -> client CertWhen I verify the client cert with CA as root CA -> intermediate CA -> org CA, it works:$ cat org_1_ca/ca_crt.pem intermediate_ca/ca_crt.pem root_ca/ca_crt.pem > /tmp/test123.pem$ openssl verify -CAfile /tmp/test123.pem client/client_crt.pemclient_crt.pem: OKBut when I chained my client cert with org CA (org CA -> client Cert), and have the rest of the chain as CA (root CA -> intermediate CA), it doesn't:$ cat intermediate_ca/ca_crt.pem root_ca/ca_crt.pem > /tmp/test12.pem$ openssl verify -CAfile /tmp/test12.pem client/org1_client_crt.pemclient/org1_client_crt.pem: C = US, ST = CA, L = LA, O = PP, OU = TEST, CN = usererror 20 at 0 depth lookup:unable to get local issuer certificateIs this something that fundamentally wrong or openssl verify doesn't like that? I tried the same thing with nginx and and openssl connect and there was no luck there. Any help is appreciated. 解决方案 The openssl commandline verify operation reads only one certificate, the first one, from the file given as operand, or from each file if more than one is given. This differs from the files specified with the -CAfile -trusted -untrusted options which can (and typically do) contain multiple certs.Your file client/org1_client_crt.pem presumably contains the client cert and the 'org CA' cert, in that order. Only the client cert is used, the 'org CA' cert is ignored, and as a result you do not have a valid chain to verify.If you want to use commandline to mimic/test the validation that a receiver (for a client cert, the server) would do, supply the leaf cert as the operand and all other transmitted (chain) certs with -untrusted, and the anchor(s) plus any 'known' intermediates in the truststore either explicit or defaulted.There is no openssl connect operation; I assume you mean openssl s_client with options including -connect since that's one place it would make sense to use a client cert chain. The -cert option to s_client similarly uses only the first cert in the file. There is no option on commandline to specify the client chain except in the most recent version, 1.1.0, and even there it isn't documented so you have to read the help message carefully or the code, although the API/library has long supported this for code you write yourself.Through 1.0.2 if you want to send a client cert with full chain to the server (as you should per the RFCs), assuming the server requests client authentication which is not usual and not the default for nginx (among others), you have to use a trick: supply all the certs needed for the client chain in the truststore, in addition to the anchor(s) needed to verify the server, either using -CAfile and/or -CApath explicitly, or using (modifying if needed) the default truststore unless your openssl is an older non-RedHat version where the default truststore didn't work in s_client s_server s_time only.And the same is true about the server cert/chain in s_server except that it is used almost always instead of very rarely. 这篇关于使用链接的CA和链接的证书进行OpenSSL验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！