Origin Server

An origin server is a physical location that houses your deliverable content like a site or app. This is a mandatory behavior and you can't delete this behavior from the Default Rule. An error message is revealed if you delete it, and you need to re-add it. However, you can additionally include the Origin Server behavior in lower-level or nested custom rules, to override the Default Rule in favor of an alternate origin, and set different match criteria to be met to apply this behavior. This solution can be helpful with things like these:

  • Authorization requests
  • Redirects for downloads and for special user agents
  • Access-denials and failover settings
  • Redirects for special user agents
  • Language settings

How it works

Use this behavior to define specific settings so ‚ÄčAkamai‚Äč edge servers can contact your origin server to get your deliverable content.

Before you begin

Several types of origin server are supported and there are various prerequisites you need to meet before you can use this behavior to define your origin. What's here is primarily descriptions of the available options. See Add an origin server to your property for complete details on setting up your origin.

Select your Origin Type

The options available in this behavior vary, based on what you've selected as your Origin Type.

Origin Type: NetStorage

This is ‚ÄčAkamai‚Äč's secure, cloud-based storage service. It integrates directly with several ‚ÄčAkamai‚Äč delivery products, making it easy to add NetStorage as your origin to your property. You can use a NetStorage origin for any static content, including static HTML/JS/CSS, fonts, images and binary files.

Origin Type: Your Origin

You'll select this and use these options if you want to use your own unique origin server to house the original version of the content for delivery. For example, this applies if you host your website on your own web server. Once you've configured these settings, this is where ‚ÄčAkamai‚Äč edge servers will go to get your content.

Origin Server Hostname

Enter the Origin Server Hostname that you established when you set up your origin sever. You should‚Äôve created a new hostname for your origin to use in a DNS record. The DNS record tells edge servers where they need to go to get your content to serve over the ‚ÄčAkamai‚Äč network. See Configure the DNS record for more details.

Origin server hostnames typically use a common naming format such as {origin}-{content-origin} where the following apply:

  • {origin}. This is what we refer to as the "origin A record." As a best practice, you should use a random string for this value (for example, 1hkeh1g76). This serves to conceal your origin server.
  • {content-origin}. If you were serving content from your origin before you onboarded to ‚ÄčAkamai‚Äč, this should be the initial hostname of your origin server, for example www.akamaicustomer.com . Otherwise, you can use any valid domain name, as long as the Origin Server Hostname, including the random string, resolves to your origin server through and external DNS.

For example, your origin server hostname that you enter into this behavior field could look like this: 1hkeh1g76-www.akamaicustomer.com.

ūüďė

Variable support

This field supports variable expression syntax. Typing {{ in the option field triggers a list of objects to select. Additional details on this support are available by mousing over this option in the UI. Also see Variables overview.

Forward Host Header

Select which Host header you want your selected ‚ÄčAkamai‚Äč product to pass to your origin server. This is referred to as the Forward Host Header because it is the hostname the product "forwards" to the origin server in the HTTP Host request header.

The web server on your origin uses this value to determine what content to send. Typically, the expected host is the same name as the hostname received in the request from the client, but you can also customize it.

OptionDescription

Incoming Host Header (Default)

When selected, the product sends what you've set as the Hostname in the property hostname to edge hostname association. Typically, it's the end-user-facing hostname for your site or app, and it's used in the connection between the client and ‚ÄčAkamai‚Äč edge servers. This is a generic option that varies depending on the Hostname received in the request. For example, a client request for your website at www.mymedia.com sends www.mymedia.com in the Host header to the origin.

Origin Hostname

When selected, the product sends what you've set as your Origin Server Hostname. Select this if you configured your origin to listen for this specific value, The hostname needs to be public or over-internet that resolves to an IP address. You can't use private, internal, or intranet IP addresses (including localhost). For example, assume your origin's hostname is hkeh1g76-www.mymedia.com and this is what you've defined in the Origin Server Hostname field. A client request for your website at www.mymedia.com sends hkeh1g76-www.mymedia.com in the Host header to the origin.

Custom Value

Select this option if you want to send a custom value in the Host header to the origin. Define the appropriate value in the Custom Forward Host Header field. This applies if you've configured your origin to listen for a hostname other than what was included in the Host header in the incoming request, or what you set up as its assigned Origin Server Hostname. For example, an end-user request for www.mymedia.com could send www.mymedia.com.akamaized.net in the Host header to the origin.

Cache Key Hostname

The cache key is the information your ‚ÄčAkamai‚Äč product uses to identify the content in caches. This assumes your application includes at least some cacheable content‚ÄĒthe edge network uses keys based on the entire origin URI path and query string, if there is one.

Specify the hostname to use when forming a cache key:

OptionDescription

Origin Hostname

All objects requested using this origin hostname and the same path and query string are treated as the same object, including the content served from any other configuration with the same origin hostname. For example, once cached, these objects would be treated as the same object:

http://www.mymedia.com/logo.gif
http://www.mymedia.co.uk/logo.gif

Incoming Host Header (Virtual Server Option)

Objects requested with the same path and query string are given a unique cache key by digital property. Select this option if your origin is a virtual server. For example, once cached, these objects would be treated as different objects:

http://www.mymedia.com/logo.gif
http://www.mymedia.co.uk/logo.gif

ūüöß

Be careful with new versions of a property

If you have an active property and you create a new version of it that uses a different cache key for all target content, you can create problems for your origin when you activate the new version on production. Any change to the cache key invalidates the cached content using the existing cache key. ‚ÄčAkamai‚Äč edge servers will request new objects from your origin at a level that can create severe spikes in bandwidth.

IPv6 Origin Support

Select the Internet Protocol (IP) version you want to use when getting content from the origin:

  • IPv4-Only
  • Dual Stack ‚Äď supports both IPv4 and IPv6 connections.
  • IPv6-Only ‚Äď to use this version, you need to add the Origin IP Access Control List behavior to the same rule.

Gzip Compression

Compression can be important in optimizing performance. Verify if it applies to your environment.

Disable this only if your origin server doesn't support delivery of content using Gzip compression, or if you to need to serve it uncompressed. When enabled, ‚ÄčAkamai‚Äč sends an Accept-Encoding: gzip header in requests to your origin server to support Gzip compression.

ūüďė

Are you using Ion?

A new Ion property automatically enables Gzip compression via the Minimize Payload sub-rule. If you disable Gzip Compression here, requests will ignore what's set in the Minimize Payload rule. For best performance, you should leave Gzip Compression enabled.

True Client IP Header

If you enable the Send True Client IP Header option, edge servers pass the original client IP address to the origin.

Normally, the client IP is passed in the X-Forwarded-For header that is routinely modified by proxies along the way. With this option enabled, the default header name True-Client-IP is used unless you set a custom name for the header in the True Client IP Header Name field. Additionally, with the Allow Clients To Set True Client IP Header toggle you can determine if the client name for this header is passed through and accepted, or whether to apply the value you defined in the True Client IP Header Name field instead.

Verification Settings

Use the Origin SSL Certificate Verification options to control how your origin server is authenticated. The verification prevents 'man-in-the-middle' (MITM) attacks, where a malicious entity directs end-user traffic to the attacker's server, instead of your origin.

When an edge server sends a request to your origin, it first establishes a secure connection through an SSL handshake‚ÄĒyour origin provides the ‚ÄčAkamai‚Äč edge server with a certificate for validation. If the validation succeeds, the request goes forward. If the certificate is not valid, the connection fails.

ūüďė

These options don't apply if you've set up your property to deliver via HTTP‚ÄĒyour property hostname uses HTTP and your origin server uses HTTP for transfer, too. Secure (HTTPS) delivery is the industry standard and what ‚ÄčAkamai‚Äč recommends.

Option Details

Platform Settings

Select this if you want to use the settings that the ‚ÄčAkamai‚Äč Secure Network platform applies for Origin SSL certificate verification.

This is the default value for this option that instructs edge servers to trust any certificate signed by the authorities listed in the ‚ÄčAkamai‚Äč Certificate Store. The Common Name (CN) or Subject Alternate Name (SAN) in your origin certificate must also match what you've set in the Forward Host Header field in this behavior.

ūüďė

The platform settings may automatically change at any time.

If you enable the SNI TLS Extension, the Server Name Indication (SNI) header is sent in the SSL request to the origin. The SNI header value is the same as value you have set for the Forward Host Header. The use of this certificate type is fully covered in the custom origin (publicly trusted certificate) topic.

Choose Your Own

Select this to control exactly which certificates or certificate authorities ‚ÄčAkamai‚Äč edge servers should trust when connecting with your origin.

This method offers the least vulnerability to man-in-the-middle attacks in case a certificate authority gets compromised. For example, if a common certificate authority is compromised, but you directly provided a certificate, your certificate still remains secure.

With this option selected, several other fields appear.

Use SNI TLS Extension

If you enable the SNI TLS Extension, the Server Name Indication (SNI) header is sent in the SSL request to the origin. The SNI header value is the same as value you have set for the Forward Host Header.

Match CN/SAN To

Specify the values ‚ÄčAkamai‚Äč edge servers should look for in your origin certificate's Common Name (CN) or Subject Alternate Name (SAN) fields. When a Subject Alternate Name field is present in the certificate, the Common Name field is ignored. These values are included by default:

  • {{Origin Server}}: The edge server scans either a CN or SAN for the value you've set as the Origin Server Hostname .

  • {{Forward Host Header}}: The edge server scans either a CN or SAN for the value you've set as the Forward Host Header.

Additional considerations:

  • The values you provide can contain an asterisk (*) character, but it's treated as a literal character and not as a wildcard. For example, if the certificate's CN or SAN value is www.example.com, a match value of _.example.comwon't work. However, wildcards in the certificate's CN or SAN value are still honored. For example, if the CN or SAN value is *.example.com, a match value of either *.example.com or www.example.com will work.

  • The values must include all of the CN or SAN match values from an Auxiliary Certificates List (aux-list), if it exists for your property. If one of these values is missing, a certificate normally trusted from the aux-list may not be trusted and result in a service outage. To include all of these values, import them directly from the aux-list using the Import aux-list button.

Trust

Decide what type of certificate or certificate authority the edge server should trust. The process varies depending on your selection:

  • ‚ÄčAkamai‚Äč-managed Certificate Authority Set: Your origin certificate only needs to be trusted by a supported certificate authority (CA). You're not including the specific origin certificate in the property. The sub-options include:

    • ‚ÄčAkamai‚Äč Certificate Store: The CAs tested and known to be trusted for use with ‚ÄčAkamai‚Äč. Click View CA Set to see a complete list.

    • Third Party Certificate Store: The CAs associated with third party origins that are currently trusted for use. Click View CA Set to see a complete list.

  • Custom Certificate Authority Set: Identify the specific CAs that should be used in validation. Click Add Certificate and in the pop-up window select how to apply the certificate authorities:

    • Retrieve for Origin: The edge server retrieves existing certificate authorities from your origin. You need to provide the applicable Hostname / IP for your origin, and the applicable HTTPS Port, typically 443.

    • Paste (PEM-encoded): Paste the PEM-encoded certificate directly into the box provided to add a certificate authority associated with the pasted certificate as a trusted CA. You may need to convert another format into PEM.

  • Specific Certificate (pinning): Use this trust method to "pin" a specific certificate to the property for validation. Either enter your origin's hostname so the edge server can retrieve the specific certificate for you, or paste the PEM-encoded certificate directly into the box provided. You can add multiple certificates, as necessary. See the custom origin (pinned certificate) topic for more details.

  • Satisfies any of the trust options below: This allows you to incorporate both custom CAs, as well as pin specific certificates. If any are sent in the connection, the edge server trusts the origin. Follow the instructions previously listed for each of the corresponding fields.

Third Party Settings

Select this for Verification Settings if you're using a supported third-party origin, such as Amazon AWS. The use of this method is fully covered in the third-party origin topic.

‚ÄčAkamai‚Äč creates a separate certificate authority (CA) set for these third parties, and manages the certificate for you. You don't have to do anything to upgrade your verification settings.

If you enable the SNI TLS Extension, the Server Name Indication (SNI) header is sent in the SSL request to the origin. The SNI header value is the same as value you have set for the Forward Host Header.

Ports

Specify the ports on your origin server you want edge servers to connect to for HTTP and HTTPS requests, respectively.

The standard ports are 80 for HTTP and 443 for HTTPS.

Acceptable port numbers

72; 80-89; 443; 488; 591; 777; 1080; 1088; 1111; 1443; 2080; 7001; 7070; 7612; 7777; 8000-9001; 9090; 9901-9908; 11080-11110; 12900-12949; 45002;

Origin TLS Version

This lets you secure the connection between ‚ÄčAkamai‚Äč edge servers and your origin server using transport layer security (TLS).

When an edge server connects to it, your origin server communicates the highest TLS version it supports and attempts the TLS handshake to secure the connection. Any TLS versions that are higher than what your origin server communicates are ignored.

Before you begin

You need to configure your origin server to support the desired level of TLS. ‚ÄčAkamai‚Äč supports TLS versions 1.1, 1.2, and 1.3 for connections to your origin server.

Set options

With the appropriate TLS version enabled on your origin server, set these options:

  • TLS 1.3 support (Beta). TLS version 1.3 offers significant improvements over earlier versions in both performance and security. If you've configured your origin server to support it, enable this protect the connection between ‚ÄčAkamai‚Äč edge servers and your origin, with TLS 1.3.

  • Minimum TLS version. Select the minimum TLS version to use for connections to your origin server. ‚ÄčAkamai‚Äč supported offers support for all versions of TLS that are available to you. This can't be higher than what you've set as the Maximum TLS version. As a best practice, you should configure your environment to use at least TLS 1.2, and select it here.

  • Maximum TLS version. Select the maximum TLS version to use for connections to your origin server. Use ‚ÄčAkamai‚Äč supported to automatically apply the latest supported version. This can't be lower than what you've set as the Minimum TLS version.

ūüďė

TLS 1.3 support is Beta

Talk to your account team to see if you're eligible to participate in the beta program. If you're participating, the Minimum TLS version and Maximum TLS version options will also include TLS 1.3.

Caveats and known issues

Consider these points before setting up this support:

IssueDetail

TLS 1.3 doesn't support renegotiation

This can be an issue if your property has been configured to support mutual authentication (mTLS). With mTLS, a requesting client and the ‚ÄčAkamai‚Äč edge server each present a TLS cert to the other, with each side verifying the certificate during what's called the "TLS handshake." Once both certificates are validated, the connection is allowed.

If you're using mTLS and you're restricting requests to certain folders, based on a URL path in the request‚ÄĒrather than all content on your origin server‚ÄĒa TLS renegotiation may be triggered. Connections using TLS 1.3 don't support renegotiation because it's a potential cyber threat. The renegotiation is just one more point in the transaction that a hacker can exploit.

TLS 1.3 support may not be available if you're using advanced metadata

If you have the Custom Override rule or Advanced behavior in your property and it includes the <forward-handshake-version-secure.protocols> entry to support or limit TLS to your origin server, you can't enable TLS 1.3 support. You'll need to work with your ‚ÄčAkamai‚Äč account team to remove this advanced metadata.

Origin Type: Media Services Live

This is a unique use case that involves the use of ‚ÄčAkamai‚Äč's Media Services Live product in conjunction with ‚ÄčAkamai‚Äč‚Äč's Adaptive Media Delivery to deliver live streaming media. To incorporate this use case, you'll need to set up your Media Services Live streams and an origin for them first. See the Media Services Live documentation for complete details on this process.

Origin Type: SaaS dynamic origin

If you're a software as a service (SaaS) customer, you'll need to create a SaaS dynamic origin.