Custom origin prerequisites
A custom origin is a physical server that you maintain to house your deliverable content. There are some prerequisites you need to meet before you can add a custom origin to your property.
Set your origin server hostname
Typically, your end users reach your origin server using your primary domain—what we refer to as your "hostname." After you go live on Akamai, your hostname will point to Akamai edge servers, so you'll need to create a new hostname for your origin in your DNS record. This new name will tell edge servers where they need to go to get your content to serve over the Akamai network.
Define the origin hostname
Origin server hostnames typically use a common formula 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,[1]hkeh1g76
). This serves to conceal your origin server. -
{content origin}
. This is the actual hostname of your origin server.
Here are some examples:
Primary domain | Origin server hostname |
---|---|
www.mysitecontent.com | [1]hkeh1g76-www.mysitecontent.com |
app.resources.com | [1]hkeh1g76-app.resources.com |
Once established, make note of this value for future use.
IP addresses as origin server hostnames
You can use the IPv4 address that applies to your specific origin, but this isn't recommended. You'll need to closely monitor any address changes or reassignments. A change could render your domain unreachable and result in a denial of service. Currently, IPv6 format is not supported.
Configure the DNS record
Create the DNS record for your origin server hostname on your authoritative name servers, using the same method you'd use for any other DNS record. The IP address should be exactly the same as the IP in the DNS record for your production content origin hostname, before switching to the edge network. For example, in this change, the IP 192.0.2.0
is the same before and after switching to the Akamai edge network:
Original name in DNS | Origin server Hostname in DNS |
---|---|
www.mysitecontent.com. IN A 192.0.2.0 | [1]hkeh1g76-www.mysitecontent.com. IN A 192.0.2.0 |
app.resources.com. IN A 192.0.2.0 | [1]hkeh1g76-app.resources.com. IN A 192.0.2.0 |
Create an origin certificate
With the second phase of the Akamai request flow, you need a certificate on your origin server to secure the connection between it and Akamai edge servers. There are multiple ways you can set up and install this certificate.
Non-secure HTTP origins
If you're using HTTP, you don't need an origin certificate. While Akamai supports non-secure HTTP connections, this isn't recommended because HTTPS is now the industry norm.
Use a publicly trusted certificate authority
Akamai uses Let's Encrypt as the default certificate authority and you can obtain and configure a certificate for your origin from Let's Encrypt. Take a look at the Let's Encrypt guidelines on setting up certificates for your origin server.
You can also install a certificate obtained from another trusted certificate authority. See the Digicert documentation for other popular trusted authorities, for example:
Review the "Akamai Certificate Store" to see a list of certificate authorities that have been tested and are trusted for use:
-
Use Property Manager to create a brand new property.
-
Scroll down to the Property Configuration Settings and locate the Origin Server behavior. (It's typically in the Default Rule for Akamai products.) Apply settings as follows:
- Origin Type. Set to Your Origin.
- Verification Settings. Set to Choose Your Own.
- Trust. Set to Akamai-managed Certificate Authorities Sets.
-
Click View CA Set next to the Akamai Certificate Store switch.
-
In the Akamai Certificate Store window, review the list of certificate authorities to see if the one you want is supported.
-
Make note of the associated Expiration Date and the SHA-1 Fingerprint for use in creating your cert and applying it on your origin server.
-
You can Cancel the creation of the property. This process just serves to get you a list of supported certificate authorities. There are several other things you need to do before you create a new property.
What's next for a publicly trusted certificate authority
Later, you'll configure the Origin Server behavior in your property, to apply Verification Settings. You can select Use Platform Settings to apply default verification or customize verification by selecting Choose Your Own.
Advantages and disadvantages with a publicly trusted certificate authority
There are pros and cons to using this certificate method:
Advantages | Disadvantages |
---|---|
|
|
Use a custom certificate authority
You can specify which certificate authorities you want Akamai to trust for your site. This can even be a certificate authority that you set up yourself.
-
Provision an origin certificate using a custom certificate authority, and install it on your origin server. If you want to set up your own and sign the origin certificate yourself, you can do that using multiple tools, for example:
-
Install the certificate on your origin server, very similar to how you'd install a certificate from any other certificate authority, for example Apache or Nginx.
What's next with a custom certificate authority
Later, you'll configure the Origin Server behavior in your property, to customize Verification Settings by selecting Choose Your Own and setting Trust to Custom Certificate Authority Set. You'll also add your SSL certification list by telling your property to either retrieve it from your origin server or include a privacy-enhanced mail (PEM)-encoded version of it, directly in your property.
Advantages and disadvantages to a custom certificate authority
There are pros and cons to using this certificate method:
Advantages | Disadvantages |
---|---|
|
|
Pin an exact certificate
You can create and—later on, in your property—specify the exact certificate(s) that Akamai should trust for your origin, including self-signed certificates. This is also known as "pinning" a certificate.
In this case, edge servers check that the origin sent the right certificate and skip other usual checks, such as the signature, the SAN list of sites the cert is valid for, and the expiration date.
-
If you want to create a self-signed certificate, you can do that using multiple tools, for example:
-
Install that certificate on your origin server, very similar to how you'd install a certificate from any other CA, for example Apache or Nginx.
What's next when pinning an exact certificate
Later, you'll configure the Origin Server behavior in your property, to customize Verification Settings by selecting Choose Your Own and setting Trust to Specific Certificates (pinning). You'll also add your pinned certificate to your property by telling it to either retrieve it from your origin server or include a privacy-enhanced mail (PEM)-encoded version of it, directly in your property.
Advantages and disadvantages to pinning an exact certificate
There are pros and cons to using this certificate method:
Advantages | Disadvantages |
---|---|
|
|
Rotate your origin certificate
Based on how you created and applied your origin certificate, you may need to rotate to a new one.
Before you begin
-
If applicable, make changes to your Property Manager property file settings so that both the old and new certificates are trusted.
-
You can optionally set up a second instance of your origin using the new origin certificate, and set up your property to use that origin for a particular test URL. Make sure to use the same trust settings on the test origin as the actual origin. For example, both properties should check for the same hostnames on the certificate.
-
Push the property changes to the Staging network and test that your current origin certificate is still trusted on this network.
-
You can optionally use the test URL pointing to the second instance of your origin to test that your new origin certificate is trusted on Staging network, too.
-
Push your property changes to the Production network and test that your current origin certificate is still trusted on this network.
-
If you set up the optional second instance of your origin, you can use the test URL pointing to this instance of your origin to test that your new origin certificate is trusted on Production.
Switch the certificate on your origin
Switch your origin server to the new certificate, and test that your new origin certificate is still trusted on Production.
Perform some clean-up
-
If applicable, make any required changes to your property settings so that the old certificate is no longer trusted.
-
Push property changes to the Staging network, and test that your new origin certificate is still trusted on this network.
-
Push property changes to the Production network, and again test that your new origin certificate is still trusted on this network.
Pinned certificate rotation
If you have a specific leaf certificate pinned and it's expiring:
- Add your new certificate to the list.
- Push your property to Production.
- Change your origin certificate to the new one.
Create custom certs beforehand
If you're rotating a pinned certificate, you need to complete the process in this order. Otherwise, edge servers won't trust the new certificate and may cause a service outage.
Updated about 1 year ago