Type C signing

How it works

Type C signing embeds two values into the URL — an MD5 hash of the request and a hexadecimal timestamp — so the CDN server can verify both the URL's authenticity and its expiration before serving the resource.

The full flow from signing to resource delivery:

1. Your signing server generates a UNIX timestamp and computes an MD5 hash from the private key, file path, and timestamp.

2. Your application embeds the hash and timestamp into the URL (using format 1 or format 2, described below).

3. The client sends a request using the signed URL.

4. The CDN server checks whether the URL has expired. If it has, it returns an HTTP 403 error.

5. If the URL is still valid, the CDN server computes its own MD5 hash from the same inputs and compares it against the hash in the request.

6. On a match, the CDN server strips the signing parameters from the URL — improving the cache hit ratio and reducing back-to-origin traffic — and serves the resource.

URL formats

Type C signing supports two URL formats. Both carry the same two fields: md5hash and timestamp.

Format 1 — hash and timestamp embedded in the path:

http://DomainName/{<md5hash>/<timestamp>}/FileName

Format 2 — hash and timestamp as query parameters:

http://DomainName/FileName?{KEY1=<md5hash>&KEY2=<timestamp>}

The content in {} is the encrypted information that is added to the standard URL.

Field reference

How `md5hash` is calculated:

sstring  = Privatekey + URI + timestamp  (URI is the relative address of the requested object and does not contain parameters, such as /FileName)
md5hash  = md5sum(sstring)

How the validity period works:

The signed URL expires when timestamp + validity period is earlier than the current time. The validity period is the value configured for your CDN domain. To extend a URL's lifetime beyond that, set timestamp to UNIX timestamp + extension duration when generating the URL. The actual expiration time is then timestamp + configured validity period.

Authentication logic

When the CDN server receives a request:

1. It checks whether timestamp + validity period is earlier than the current time.

   • Expired: returns HTTP 403.

   • Not expired: proceeds to hash verification.

2. It constructs the same sstring from Privatekey, URI, and timestamp, and computes its own md5hash.

3. It compares the computed hash against the md5hash in the request.

   • Match: authentication succeeds. The signing parameters are removed from the URL and the resource is returned.

   • No match: returns HTTP 403.

After authentication succeeds, the CDN server uses the clean URL (without signing parameters) for both the cache key and the origin fetch:

Stripping the signing parameters means cached responses can be reused across requests, improving the cache hit ratio and reducing back-to-origin traffic.

Example

This example walks through a complete type C signing calculation.

Inputs:

Step 1: Construct the input string.

sstring = aliyuncdnexp1234/test.flv55CE8100

Step 2: Compute the MD5 hash.

md5hash = md5sum(aliyuncdnexp1234/test.flv55CE8100)
        = a37fa50a5fb8f71214b1e7c95ec7a1bd

Step 3: Build the signed URL.

Format 1:

http://domain.example.com/a37fa50a5fb8f71214b1e7c95ec7a1bd/55CE8100/test.flv

Format 2:

http://domain.example.com/test.flv?KEY1=a37fa50a5fb8f71214b1e7c95ec7a1bd&KEY2=55CE8100

When the client sends the request, the CDN server computes its own MD5 hash from the same inputs. If the result matches a37fa50a5fb8f71214b1e7c95ec7a1bd and the URL has not expired, authentication succeeds and the resource is returned.

What's next

• URL signing overview — compare all four signing methods and choose the one that fits your scenario

• Configure URL signing — enable URL signing for your CDN domain in the console