rusoto: Debugging SSL Errors

I’m running into a strange issue using the dynamodb client. Building/running my app on macOS works great. When I then build and run it on EC2, attempting a query yields the following error message:

HttpDispatch(
  HttpDispatchError { 
    message: "The OpenSSL library reported an error" 
  }
)

I’m able to execute the same query using the aws command-line tool from the same EC2 instance. Unfortunately I can’t seem to find a way to figure out which error the library was reporting. I’m also able to use Hyper/HyperNativeTls in a toy app to hit a bunch of different SSL webpages. Enabling logging on rusoto indicates requests that are practically identical between the macOS and EC2, so I’m sort of at my wits’ end.

Any idea how I can find out what’s going on the the SSL library?

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 17 (13 by maintainers)

Most upvoted comments

Yeah totally.

I’ve been working on a simple framework to build AWS Lambda functions as python modules. That requires linking OpenSSL statically, and I was building my modules as follows:

On an EC2 instance, build OpenSSL.

./config -fPIC --prefix=/usr/local --openssldir=/usr/local/ssl
make
make install

Build my module (which depends on rusoto) as follows:

OPENSSL_LIB_DIR=/usr/local/lib64/ OPENSSL_INCLUDE_DIR=/usr/local/include/ OPENSSL_STATIC=yes cargo build --release

The problem is that AMI Linux keeps the CA certs in /etc/pki/tls. OpenSSL looks first in the place specified in the ./configure command as openssldir (at least the version I was building). The error I was getting is that it couldn’t find the cert file, which I could change by their using SSL_CERT_FILE environment variable or changing the OpenSSL config command to:

./config -fPIC --prefix=/usr/local --openssldir=/etc/pki/tls

Then building normally.

You should probably be able to get the same results by running a Rusoto binary with SSL_CERT_FILE=/bad/path ./app.

This is one of the very many ways OpenSSL can fail though. The enhancement I’d request of Rusoto is to change the definition of HttpDispatchError to HttpDispatchError(Box<std::error::Error>) and to throw the underlying OpenSSL error into the Box, and return it as Error::cause() (or something to that effect). That way developers have more context to track down the actual OpenSSL error should something happen.

FWIW when you decide on a course of action, let me know, I’m happy to contribute a fix.

martinmroz on Apr 11, 2017

Thanks for posting your findings! Are you able to include more information on the repro so we can ensure we provide a good error message in cases like this?

matthewkmayer on Apr 11, 2017

Hey! Thanks for following up, turned out that the issue was my statically-linked OpenSSL library was anticipating the wrong filesystem location for root CAs. I was able to figure it out eventually, it was just pretty painful since no underlying error was included in the HttpDispatchError. I ended up creating a test app written solely using Hyper and HyperNativeTls to get the full details. The simplest thing to do here might be to just include the underlying HyperNativeTls error in the HttpDispatchError (maybe as a Box<Error> to avoid exposing the type itself).

martinmroz on Apr 11, 2017