SignatureDoesNotMatch

Error Description

The server-calculated signature does not match the signature you provided.

Error Cause

A mismatch between the server-generated and client-generated signatures. According to Authentication Overview, this typically occurs due to the following reasons:

1. The StringToSign generated by the server is different from the one generated by the client.

2. The Access Keys (AK/SK) used by the server are different from those used by the client.

Handling Suggestion

1. Compare the server-generated StringToSign with the client-generated StringToSign to check whether they are different.
   • Obtain the server-generated StringToSign: The following is an example response with a signature verification failure. The returned StringToSign is the StringToSign calculated by the server.

     1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

     <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Error> <Code>SignatureDoesNotMatch</Code> <Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message> <RequestId>0000019D84FF590E53066166B2E432FD</RequestId> <HostId>Z9v+cC1sRnaWw6x0vi8pxxYA0YVnKxbYHUPAFpnxkX8sLV44u5b02Z+ailn2wCnR</HostId> <AccessKeyId>HPUAOE5BNDL3VBPXXXXX</AWSAccessKeyId> <SignatureProvided>mNANUaYHwfGRo9DSYPLhLdrCitAAAA</SignatureProvided> <StringToSign>PUT Mon, 13 Apr 2026 04:00:10 +0000 /bucket01</StringToSign> <StringToSignBytes>50 55 54 0a 0a 0a 4d 6f 6e 2c 20 31 33 20 41 70 72 20 32 30 32 36 20 30 34 3a 30 30 3a 31 30 20 2b 30 30 30 30 0a 2f 62 75 63 6b 65 74 30 31</StringToSignBytes> </Error>

   • Obtain the client-generated StringToSign:
     The following Java code snippet prints the client's StringToSign. For the complete sample code, see Creating a Bucket.

     /**Calculate the signature based on the request.**/
     String contentMD5 = "";
     String canonicalizedHeaders = "";
     String canonicalizedResource = "/bucket001/";
     // Content-MD5 and Content-Type fields do not contain line breaks. The data format is RFC 1123, which is the same as the time in the request.
     String canonicalString = "PUT" + "\n" + contentMD5 + "\n" + contentType + "\n" + requesttime + "\n" + canonicalizedHeaders + canonicalizedResource;
     System.out.println("StringToSign:[" + canonicalString + "]");

2. If they are different, adjust the client's StringToSign to match the server's.
3. Check whether the AK/SK used by the client to calculate the signature matches the AK/SK used by the server.
   • Obtain the AK/SK used at the server side: Check the AccessKeyId field in the response.
   • Obtain the AK/SK used at the client side: Check the AK/SK in the client code.

4. If they are different, update the AK/SK to ensure consistency between the server and client.
5. Ensure that both StringToSign and AK/SK are consistent and then recalculate the signature.

Example: Signature Mismatch Due to Missing Element in StringToSign

Assume that the request signature is included in an authorization header. The server's StringToSign is as follows:

1
2
3
4
5
6

PUT


Mon, 13 Apr 2026 04:00:10 +0000
x-obs-acl:public-read-write
/bucket01

The client's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/bucket01

The comparison shows that the client's StringToSign is missing line 5: x-obs-acl:public-read-write.

The signature mismatch happens because the CanonicalizedHeaders element is missing when the client calculates the signature. To fix this, include all relevant headers as described in CanonicalizedHeaders of Using an Authorization Header.

Example: Signature Mismatch Due to the Missing Query Parameter

Assume that the request signature is included in an authorization header. The server's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/bucket01?acl

The client's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/bucket01

The comparison shows that ?acl is missing in line 5 of the client's StringToSign.

The signature mismatch happens because the client's signature calculation ignores the query parameter (URI parameter), resulting in incorrect CanonicalizedResource. To fix this, refer to the CanonicalizedResource description in Using an Authorization Header.

Example: Signature Mismatch Due to Domain Name Misinterpretation

Assume that the request signature is included in an authorization header. The server's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/bucket01/obj1

The client's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/bucket01.obs.cn-north-4.myhuaweicloud.com/obj1

The comparison shows that the bucket name in line 5 of the client's StringToSign differs from that of the server. It contains the domain name (endpoint) obs.cn-north-4.myhuaweicloud.com.

The signature mismatch happens because the client treats the domain name as part of the bucket name when calculating the signature. This error usually occurs when the client code fails to identify the OBS domain name obs.RegionID.myhuaweicloud.com, so it cannot output the correct bucket name for signature calculation. The correct CanonicalizedResource should not contain the domain name. To fix this, refer to the CanonicalizedResource description in Using an Authorization Header.

Example: Signature Mismatch Due to Pre-signed URL Difference

Assume that the request signature is included in a pre-signed URL. The server's StringToSign is as follows:

1
2
3
4
5

PUT


1532779451
/bucket01

The client's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/bucket01

The comparison shows that the content in line 4 of the client's StringToSign differs from that of the server. The signature mismatch happens because the server and client use different fields for signature calculation. When the request signature is included in a pre-signed URL, the Expires field should be used for signature calculation. To fix this, refer to the Expires description in Using a Pre-Signed URL.

Example: Signature Mismatch Caused by Using a Bucket Name Instead of the Required Custom Domain

Assume that the request signature is included in an authorization header. The server's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/custom_domain_name.com/obj1

The client's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/bucket01/obj1

The comparison shows that the client uses the actual bucket name instead of a custom domain name when calculating the signature. To fix this, refer to the CanonicalizedResource description in Using an Authorization Header.

Example: Signature Mismatch Due to Custom Domain Name Issues

Assume that the request signature is included in an authorization header. The server's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/obj1

The client's StringToSign is as follows:

1
2
3
4
5

PUT


Mon, 13 Apr 2026 04:00:10 +0000
/custom_domain_name.com/obj1

Error cause

The comparison shows that the CanonicalizedResource constructed by the server does not contain the custom domain name. Possible causes are as follows:

• Cause 1: The DNS configuration is incorrect. As shown in the following figure, an incorrect IP address is returned when DNS resolves the custom domain name. As a result, the request is sent to an incorrect OBS server. The server cannot identify the custom domain name in the request. As a result, the signature does not match, and the verification fails.

  

• Cause 2: The proxy configuration is incorrect. As shown in the following figure, the proxy forwards the request to an incorrect OBS server. The server cannot identify the custom domain name in the request. As a result, the signature does not match, and the verification fails.

  

• Cause 3: The custom domain name is not bound to the bucket, so the server cannot identify the custom domain name.

Handling suggestion

• For cause 1: Check whether the DNS configuration of the custom domain name is correct. You can:
  • Configure a CNAME record instead of directly resolving the domain name to an IP address. Configure the custom domain name by referring to Accessing a Bucket Using a User-Defined Domain Name.
  • Configure to resolve to a specific IP address. Ensure that the correct bucket IP address is used. If the configuration uses an incorrect one, correct it. If you use Huawei Cloud DNS, see Adding Record Sets for a Public Zone. If you use the DNS service of another cloud vendor, see the documentation of the corresponding vendor.
• For cause 2: Check whether the client request is forwarded through a proxy and whether the proxy server is correctly configured. Ensure that the request is forwarded to the correct bucket IP address. If the configuration is incorrect, correct it.
• For cause 3: Bind a custom domain name to the bucket. For details, see Accessing a Bucket Using a User-Defined Domain Name.

Related operation

Obtaining the bucket IP address

1. Start the Run dialog box. Enter cmd and press Enter.
2. Run the following command:

   ping <bucket's default domain name>

   The default domain name of a bucket is in the format of BucketName.obs.RegionID.myhuaweicloud.com, where BucketName indicates the bucket name and RegionID indicates the region ID of the bucket.

3. Obtain the bucket IP address displayed in the command output.