Score:1

openssl upgrade | fail validating certificate

kr flag

I am working on CentOS7 machine, and I am trying to upgrade my machine's openssl version 1.0.2k -> 1.1.0l. It seems like the handshake process with my server(which didn't change) fails after the upgrade and I'm trying to figure out the cause.

Running the following command with both openssl version:

openssl s_client -showcerts -connect server:port

Resulted with failure with the newer one (if i provide the -CAfile validation works with both). A diff of the result:

Old 1.0.2k (handshake successful):

Server Temp Key: ECDH, P-256, 256 bits New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 New 1.1.0l (fails handshake):

Server Temp Key: X25519, 253 bits New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Verify return code: 20 (unable to get local issuer certificate) I would appreciate with help understanding the difference, and why are they different.

fyi, I started a similar threat here: https://stackoverflow.com/questions/68763253/openssl-upgrade-fail-validating-certificate?noredirect=1#comment121583146_68763253 without much luck.

Thanks :)

us flag
How did you perform the upgrade process?
Guy Tabak avatar
kr flag
I compiled openssl from the source code, couldn't get yum to install that specific version. One key difference I see in the execution of working and not working: Working openssl version certificate lookup path is /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem. Failing openssl version certificate lookup path is /var/ssl/cert.pem. Both have the same SSL_CERT_DIR env is: /etc/pki/tls/certs. So I wonder, why the new openssl version is looking at /var/ssl?
us flag
`SSL_CERT_DIR` seems to be something different than the CA root path, by looking at the differences in the paths you show.
Guy Tabak avatar
kr flag
What do you mean? SSL_CERT_DIR "Specifies the location of the trusted certificate authorities (CA) found in OpenSSL format. This is the OpenSSL environment variable."
Score:1
us flag

at Centos 7 you can fix this issue with folowing commands as well:

#Prepare to compile
yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y
yum groupinstall -y "Development Tools" "Development Libraries"

#Build from source
cd /usr/src
# --no-check-certificate because of that issue, your system will not validate letsencrypt certificate at openssl.org until finish update
wget --no-check-certificate https://www.openssl.org/source/openssl-1.1.1l.tar.gz
tar -zxf openssl-1.1.1l.tar.gz
cd openssl-1.1.1l
./config
make
make install

yum install ca-certificates -y 
Score:0
kr flag

For future reference, adding solution here.

Once starting to work with openssl version > 1.0.2k on centos7 machines, there seems to be a behavioural change in the root resolution path.

Openssl goes through a predefined list of cert store locations, however, once it encounters a cert.pem file in /val/ssl it will test it and will fail if it's not able to validate your remote.

My "good" certificate was in /etc/ssl and as it was a client's machine I couldn't ask him to remove the /var/ssl file.

My solution was to programmatically choose the correct cert.pem in case openssl fails (without altering the openssl version of the machine, which was prohibited).

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.