The following problems are common in signature verification. You can cooperate with Signature Troubleshooting Tool to troubleshoot signature problems online, or use the following troubleshooting instructions to check them one by one:

• Can't distinguish URI part and QueryString part in URL correctly
• "/" Inconsistent at the end of the URI
• Host header domain port is inconsistent
• Problem of x-bce-date header
• Used the wrong ak/sk
• Customer requests based on StsCredential but the service does not pass security_token correctly
• Precautions during signature generation

Incorrect Distinction between URI Part and QueryString Part in URL

Suppose the requested URL is / v1/settings/region/list? type=public, where URI should be / v1/settings/region/list, andtype=public is the querystring. But the client did not distinguish them correctly; when calculating the signature, take the / v1/settings/region/listType=public as the PATH, and get the CanonicalRequest, so there is a problem with the transmitted signature. And the server is using

	 # CanonicalRequest requested by the client: 
	GET
	/v1/settings/region/list%3ftype%3dpublic
	host:settings.bce-internal.baidu.com
	x-bce-date:2017-02-15T08%3A52%3A48Z

When the server constructs the verification request to IAM, it passes the correct URI and QueryString part:

	{
	  "auth" : {
	    "authorization" : "bce-auth-v1/f3e1f5c2ef9c4d25b7f8b936861cd175/2017-04-05T08:29:50Z/3600/host;x-bce-date/9a48ec83ffb6c486892c4985df7dc6bc20f7c7bebb483f8f355592b8503a3f59",
	    "request" : {
	      "method" : "GET",
	      "uri" : "/v1/settings/region/list",
	      "headers" : {
	        "host" : "settings.bce-internal.baidu.com",
	        "x-bce-date": "2017-02-15T08:52:48Z"
	      },
	      "params": {
	        "type": "public"
	      }
	    }
	  }

Furthermore, for the request information provided by IAM based on the service. When calculating the signature, the URI is inconsistent with the client, and the obtained signature must be different from the requested value.

Inconsistent "/" at the End of the URI

Client request:

	 # CanonicalRequest requested by the client: 
	GET
	/v1/settings/region/list
	host:settings.bce-internal.baidu.com
	x-bce-date:2017-02-15T08%3A52%3A48Z

When the server constructs the signature verification request to the IAM, it incorrectly writes a trailing "/" in the URI:

	{
	  "auth" : {
	    "authorization" : "bce-auth-v1/f3e1f5c2ef9c4d25b7f8b936861cd175/2017-04-05T08:29:50Z/3600/host;x-bce-date/9a48ec83ffb6c486892c4985df7dc6bc20f7c7bebb483f8f355592b8503a3f59",
	    "request" : {
	      "method" : "GET",
	      "uri": "/ v1/settings/region/list /", #ends with an additional '/' 
	      "headers" : {
	        "host" : "settings.bce-internal.baidu.com",
	        "x-bce-date": "2017-02-15T08:52:48Z"
	      }
	    }
	  }

Furthermore, for the request information provided by IAM based on the service. When calculating the signature, the URI is inconsistent with the client, and the obtained signature must be different from the requested value.

Host Header Field Ports are Inconsistent

Client request:

	 # CanonicalRequest requested by the client: 
	GET
	/v1/settings/region/list
	host:settings.bce-internal.baidu.com%3A80
	x-bce-date:2017-02-15T08%3A52%3A48Z

When the server constructs the verification request to IAM, the host field does not add a port:

	{
	  "auth" : {
	    "authorization" : "bce-auth-v1/f3e1f5c2ef9c4d25b7f8b936861cd175/2017-04-05T08:29:50Z/3600/host;x-bce-date/2671990529b9c46c95e688f1a2809db185c608ee3716a731a8fdde6bb2028d84",
	    "request" : {
	      "method" : "GET",
	      "uri" : "/v1/settings/region/list/",
	      "headers" : {
	        "host": "settings.bce-internal.baidu.com", #host has no port 
	        "x-bce-date": "2017-02-15T08:52:48Z"
	      }
	    }
	  }

The host is inconsistent, and the obtained signature must be inconsistent with the requested value.

Problem with x-bce-date Header

By default (when SignedHeaders is not specified in the authorization), x-bce-date will participate in signing. The client needs to ensure: This field when computing the signature is consistent with this field when the request was finally made.

For example, the time used to calculate the signature is 2017-02-15T08: 52: 48Z

	GET
	/v1/settings/region/list
	host:settings.bce-internal.baidu.com
	x-bce-date:2017-02-15T08%3A52%3A48Z

But when the request was made, x-bce-date became 2017-02-15T08: 52: 49Z

	GET /v1/settings/region/list HTTP/1.1
	User-Agent: curl/7.33.0
	Host: settings.bce-internal.baidu.com
	Accept: */*
	authorization: bce-auth-v1/f3e1f5c2ef9c4d25b7f8b936861cd175/2017-04-05T08:29:50Z/3600/host;x-bce-date;x-bce-request-id/9a48ec83ffb6c486892c4985df7dc6bc20f7c7bebb483f8f355592b8503a3f59
	x-bce-date: 2017-02-15T08:52:49Z

The x-bce-date field is inconsistent with the client when IAM calculates the signature, and the obtained signature must be inconsistent with the requested value.

Wrong ak/sk

The following two situations are prone to low-level errors that cause the signature to fail:

• Based on the configuration program, ak is correct in the configuration, but sk is wrong. In this case, IAM does not return that ak does not exist, but a signature error. One feature is the inconsistency of the signingKey and IAM calculations.
• The ak/sk is automatically obtained from API, but it was passed wrong when constructing the business client. For example, the construction parameters may be ak and sk, but both parameters use ak when the code is called.

The Client Requested Based on StsCredential but the Service did not Pass the Security_token Correctly

Client request:

 # CanonicalRequest requested by the client: 
GET
/v1/settings/region/list
host:settings.bce-internal.baidu.com
x-bce-date:2017-02-15T08%3A52%3A48Z
x-bce-security-token: ZGZiM2M3MmU4Mjk4NGQ2MGEzYTNhYTAyMDE3NTZmZmV8AAAA...

When the server constructs the signing request to the IAM, the security_token is not extracted and placed in a special field for the well-known IAM client to use temporary credentials:

{
  "auth" : {
    "authorization" : "bce-auth-v1/f3e1f5c2ef9c4d25b7f8b936861cd175/2017-04-05T08:29:50Z/3600/host;x-bce-date/9a48ec83ffb6c486892c4985df7dc6bc20f7c7bebb483f8f355592b8503a3f59",
    "request" : {
      "method" : "GET",
      "uri" : "/v1/settings/region/list",
      "headers" : {
        "host" : "settings.bce-internal.baidu.com",
        "x-bce-date": "2017-02-15T08:52:48Z",
        "x-bce-security-token": "ZGZiM2M3MmU4Mjk4NGQ2MGEzYTNhYTAyMDE3NTZmZmV8AAAA..."
      }
    }
  }

IAM did not know that ak/sk was checked out temporarily. The corresponding ak could not be found from the long-lived ak/sk table, so it reported "Could not find credential".

Note During Signature Generation

1. Check if HTTP Method is correct

2. CanonicalURI part

   • Note that there is no need to add host in front, it must start with "/", and those which does not start with "/"it must be supplemented with it, and the empty path is "/";
   • Note that there should be no "/" at the end;
   • Note: the uriEncodeExceptSlash encoding shall be made.

3. CanonicalQueryString part

   • Note that they should be sorted in lexicographic order;
   • whether "=" is also retained for key without value;
   • When there is no queryString, a spliced\n is also added to the final CanonicalRequest.

4. CanonicalHeaders part

   • Baidu AI Cloud's default signedHeaders: Host, Content-Length, Content-Type, Content-MD5, all headers that start with x-bce-;
   • Note that the content of the header here must be exactly the same as the content of the header in the actual request. In particular, pay attention to whether the host has a port number and whether the x-bce-date has changed.
   • Are any headers deleted by third-party database in the actual request?
   • If the {signedHeaders} field is left blank in the request, is it calculated exactly according to the default signedHeaders of Baidu AI Cloud?

5. Signature prefix information

   • timestamp is the time when the authentication string was created, it cannot be too early or too late;
   • SK and AK entered shall be corresponding.