Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

I have a bucket belonging to another account. Using the AWS CLI I am able to access (list and read objects) this bucket. For example:

aws s3 ls s3://somebucket/foo/bar
Lists the objects.
Trying to recreate the same using the Java SDK (in Scala) I am getting the above exception (SignatureDoesNotMatch).
Here is the code:
package com.myco.sample
class TestCase() {
    val credentials = new com.amazonaws.auth.BasicAWSCredentials(
        "ACCESS_KEY_ID", 
        "SECRET_ACCESS_KEY"
    val s3 = new com.amazonaws.services.s3.AmazonS3Client(credentials)
    val endpoint = "somebucket.s3-us-west-2.amazonaws.com"
    s3.setEndpoint(endpoint)
    try {
        val objs = s3.listObjects("foo/bar")
    } catch {
        case ace: com.amazonaws.services.s3.model.AmazonS3Exception => {
            println(ace.getAdditionalDetails)
The call to listObjects throws an exception.
The output is:
com.amazonaws.services.s3.model.AmazonS3Exception: The request signature we calculated does not match the signature you provided. Check your key and signing method. (Service: Amazon S3; Status Code: 403; Error Code: SignatureDoesNotMatch; Request ID: XXXXXXXXX), S3 Extended Request ID: XXXXXXXXXXXXXXXXXXX=
{SignatureProvided=XXXXXXXXXXXXX=, StringToSign=Wed, 06 Jan 2016 04:32:38 GMT
/somebucket/foo/bar/, AWSAccessKeyId=XXXXXX, Error=XXXXXXXXXXXX=, StringToSignBytes=XXXXXXXXX}
When not providing the endpoint as above, I am getting a different error:
The bucket you are attempting to access must be addressed using the specified endpoint
After setting the endpoint, I've tried multiple ways of passing the "bucket" parameter to listObjects, all of which didn't work.
Not sure why the signature that's being generated behind the scenes is incorrect. Any ideas?
                @cchantep how do you determine the "proper" time? Generally, the same works using the AWS CLI one the same machine where the signature creation process is using the same time.
– Pasha Bitz
                Jan 6, 2016 at 19:15
                The solution we received when we reported a ticket with AWS because all the approaches failed. The scenario is we have our custom AWS KMS encryption enabled for S3 bucket, but we were trying to send "kms key" along with our request when using GeneratePresignedUrlRequest api. AWS said, we don't have to send KMS key, instead send without encrypting from client. When I say unencrypted, it is not exactly that, it is already coming in encrypted form and when we were using "AWSS3V4SinerType" to sign, it was signing an already encrypted file. Hope this makes sense.
– Arjun Kalidas
                Dec 15, 2021 at 17:04
That error typically means the credentials aren't correct.
val credentials = new com.amazonaws.auth.BasicAWSCredentials(
    "ACCESS_KEY_ID", 
    "SECRET_ACCESS_KEY"
Are you using the actual access key and secret key in your code?  Do they match the values in your ~/.aws/credentials file?
You can try creating the AmazonS3Client without explicitly providing credentials using the default constructor.  The default behavior is to use the values in ~/.aws/credentials just like the CLI.
To rule out credentials issues, you can turn on logging in the CLI and compare it with the SDK logs.  Try:
aws --debug s3 ls s3://somebucket/foo/bar
You should see something like this:
2016-01-06 13:29:01,306 - MainThread - botocore.credentials - DEBUG - Looking for credentials via: env
2016-01-06 13:29:01,306 - MainThread - botocore.credentials - DEBUG - Looking for credentials via: assume-role
2016-01-06 13:29:01,306 - MainThread - botocore.credentials - DEBUG - Looking for credentials via: shared-credentials-file
2016-01-06 13:29:01,306 - MainThread - botocore.credentials - INFO - Found credentials in shared credentials file: ~/.aws/credentials
Next, enable SDK logging as documented here: http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-logging.html.  You should just need to provide the log4j jar and the example log4j.properties file.
Here you should see this:
2016-01-06 13:26:47,621 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain -  Unable to load credentials from EnvironmentVariableCredentialsProvider: Unable to load AWS credentials from environment variables (AWS_ACCESS_KEY_ID (or AWS_ACCESS_KEY) and AWS_SECRET_KEY (or AWS_SECRET_ACCESS_KEY))
2016-01-06 13:26:47,621 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain -  Unable to load credentials from SystemPropertiesCredentialsProvider: Unable to load AWS credentials from Java system properties (aws.accessKeyId and aws.secretKey)
2016-01-06 13:26:47,636 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain -  Loading credentials from com.amazonaws.auth.profile.ProfileCredentialsProvider@42561fba
If that turns out not to be the issue, you can examine the logs in detail to further diagnose the problem.
                Hi, thanks for the answer. Yes, in the code I am using the actual credentials. Using the CLI credentials as well as no credentials (in the code) triggers the same exception.
– Pasha Bitz
                Jan 6, 2016 at 19:11
In my case, SignatureDoesNotMatch error occurred after upgraded maven dependencies without changes in my code (so credentials are correct and were not changed). After upgrading dependency org.apache.httpcomponents:httpclient from version 4.5.6 to 4.5.7 (actually it was upgrade of Spring Boot from 2.1.2 to 2.1.3, and there bom has specified httpclient version), code became throw exceptions while doing some AWS SDK S3 requests like AmazonS3.getObject.
After digging into the root cause, I found that httpclient library did breaking changes with normalized URI, that affected Java AWS SDK S3. Please take a look for opened GitHub ticket org.apache.httpcomponents:httpclient:4.5.7 breaks fetching S3 objects for more details.
                We experienced this same SignatureDoesNotMatch issue when upgrading from Spring Boot 2.0.8.RELEASE to 2.0.9.RELEASE.  Rolling back to 2.0.8.RELEASE fixed the issue.  Thanks for the info!
– Brett Cooper
                Jun 6, 2019 at 18:52
                I had to externally override the httpclient version to 4.5.6 after upgrading to Spring Boot 2.1.3 to solve the issue.
– Naveen Kumar
                Sep 2, 2019 at 11:23
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.