Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SUSE 12 OpenSSL certificate verification issue #1046

Closed
pcaswell opened this Issue Jan 17, 2019 · 14 comments

Comments

Projects
None yet
4 participants
@pcaswell
Copy link

pcaswell commented Jan 17, 2019

What platform/OS are you using?

CentOS 6.6 (build) and SUSE 12 (run)

What compiler are you using? what version?

gcc 7.2.0

What's your CMake arguments?

cmake ../../${AWS_SDK_BASENAME} -G "Unix Makefiles"
-DSIMPLE_INSTALL=OFF
-DAUTORUN_UNIT_TESTS=OFF
-DCMAKE_INSTALL_PREFIX="${AWS_SDK_DIR}"
-DCMAKE_BUILD_TYPE=Release
-DCPP_STANDARD=17
-DCURL_INCLUDE_DIR="${CURL_DIR}/include"
-DCURL_LIBRARY="${CURL_DIR}/lib/libcurl-7_51_0.so"
-DOPENSSL_INCLUDE_DIR="${OPENSSL_DIR}/include"
-DOPENSSL_CRYPTO_LIBRARY="${OPENSSL_DIR}/lib/libcrypto-1_0_2.so"
-DOPENSSL_SSL_LIBRARY="${OPENSSL_DIR}/lib/libssl-1_0_2.so"
-DBUILD_ONLY="s3;dynamodb;lambda;iam;autoscaling;application-autoscaling;sts"

We are building with SDK version 1.6.25.

Can you provide a TRACE level log? (sanitize any sensitive information)

trace.txt

openssl-s_client-output.txt

Hello Forum,
I've come across a strange problem in that trying to execute our application on SUSE 12 it fails (It works on almost all other distros). Looking at the trace (attached) I thought this might be a TLS/SSL verification problem. I have confirmed this by setting the 'verifySSL' flag to false in the ClientConfiguration and now the application can connect successfully and create a bucket.

I don't think this is a machine issue as this openssl command "openssl s_client -showcerts -connect sts.eu-west-2.amazonaws.com:443 succeeds (see attached text file). The system installed certificates are in /etc/ssl/certs

So, does anyone have any idea on what might be going wrong? Any suggestions/help much appreciated.
P

@singku

This comment has been minimized.

Copy link
Contributor

singku commented Jan 17, 2019

Could you try setting client
Configuration.caPath to the directory where your certs are located?

@pcaswell

This comment has been minimized.

Copy link
Author

pcaswell commented Jan 17, 2019

I will give that a go and come back to you.

@JonathanHenson

This comment has been minimized.

Copy link
Contributor

JonathanHenson commented Jan 17, 2019

PKI between linux distros is madness. There could be any miriad of problems.

1st your version of curl may be linked against something other than OpenSSL.

2nd if you built and installed OpenSSL it often can’t find the installed certs.

So likely you’ll just need to take the above suggestion.

@JonathanHenson

This comment has been minimized.

Copy link
Contributor

JonathanHenson commented Jan 17, 2019

Oh, also, do you have a “.” In your bucket name?

@singku singku added the help wanted label Jan 18, 2019

@pcaswell

This comment has been minimized.

Copy link
Author

pcaswell commented Jan 18, 2019

Unfortunately setting the CA path seemed to have no effect, I get the same error:
aws_s3_2019-01-18-07.log

@pcaswell

This comment has been minimized.

Copy link
Author

pcaswell commented Jan 18, 2019

Hello Jonathan,
I agree with your comment on PKI and Linux distros - it's a nightmare. We have our own build of OpenSSL that we build and link against (version 1.0.2 currently). We build libcurl (version 7.51.0) with this version of OpenSSL. We build and link the AWS SDK with these libraries (you can see this in our cmake arguments). I do have a period "." in the bucket name - I'll give it a go without.

@pcaswell

This comment has been minimized.

Copy link
Author

pcaswell commented Jan 18, 2019

Same problem without periods "." in the bucket name.

@JonathanHenson

This comment has been minimized.

Copy link
Contributor

JonathanHenson commented Jan 18, 2019

So... dirty secret. Deep in the file that hits libcurl, I left a commented out verbose output flag.... I’ll bet it’s still there. Uncomment it, rebuild and run and we can probably nail down the problem.

@JonathanHenson

This comment has been minimized.

Copy link
Contributor

JonathanHenson commented Jan 18, 2019

Anywho, last time I built OpenSSL, none of the pki paths and symlinks were setup properly and I had to set the caPath manually to get anything working.

@singku

This comment has been minimized.

Copy link
Contributor

singku commented Jan 18, 2019

Also, does your application have the read access to those certs?

@singku

This comment has been minimized.

Copy link
Contributor

singku commented Jan 18, 2019

//curl_easy_setopt(connectionHandle, CURLOPT_VERBOSE, 1);

These two lines can be turned on to debug

@pcaswell

This comment has been minimized.

Copy link
Author

pcaswell commented Jan 18, 2019

Thanks for the reminder about the dirty secret :-) I noticed that a while ago but forgot it was there. Interestingly I set the 'caFile' value to the certificate (pem file) that I figured was the root certificate and our code got past talking to sts but then failed when trying to talk to s3. Using the openssl s_client -showcerts etc. command above they both have different certificate chains. I'll give the verbose curl output a go and see what comes up.

@pcaswell

This comment has been minimized.

Copy link
Author

pcaswell commented Jan 18, 2019

I have managed to make this work. This knowledge base article helped:
https://www.suse.com/support/kb/doc/?id=7021187
I set the 'caFile' value to '/var/lib/ca-certificates/ca-bundle.pem' having first executed the 'update-ca-certificates' command. I still can't get the 'caPath' value to work though.

@singku

This comment has been minimized.

Copy link
Contributor

singku commented Jan 18, 2019

Glad you managed this out. Looks like there are similar certs problems that can't be easily resolved for other people. This is a good example for them to follow. So I am going to pin this issue.

@singku singku closed this Jan 18, 2019

@singku singku pinned this issue Jan 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.