[openssl-users] It reported verify error:num=20:unable to get local issuer certificate in my embedded linux device, when I used the openssl command
Michael.Wojcik at microfocus.com
Wed Dec 14 13:31:09 UTC 2016
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of ??
> Sent: Wednesday, December 14, 2016 07:53
> I get the log from the embedded linux device and my PC.
> Sorry, I don't get the deference in the platform, but there is some deference between the platform and PC.
(You want "difference" there, not "deference". Just another of English's many homonyms and orthographic peculiarities.)
I just did a quick check, and it appears curl.haxx.se sends two certificates: the server certificate (signed by Let's Encrypt) and an intermediate (signed by Digital Signature Trust).
On the PC, s_client shows a chain of three certificates, ending in the DST root. That means OpenSSL found that root certificate somewhere - it didn't get it from the server, and it's not the first certificate in cacert-2016-11-02.pem.
So: either there's more than one certificate in cacert-2016-11-02.pem, or OpenSSL on the PC is searching its default CA certificate directory in addition to cacert-2016-11-02.pem. Since we don't know what's actually in cacert-2016-11-02.pem, we can't provide much further help.
Note that if there are multiple certificates in cacert-2016-11-02.pem, you'll have to split them up into separate files and create the correct hash link for each one, if you want to use a certificate directory.
Also, there's this from your previous note:
> /tmp # ./openssl x509 -subject -noout -in cacert-2016-11-02.pem
> subject=C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
Did you actually capture that, or did you retype it? Because it's not valid openssl x509 output. Note that it doesn't match what you reported from the PC:
> subject= /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
Distinguished Engineer, Micro Focus
More information about the openssl-users