Michael Kuchyt

Certificate Provisioning System Recommendations and Best Practices

Blog Post created by Michael Kuchyt Employee on Oct 27, 2017

This blog post will provide Akamai’s recommendations for settings in our Certificate Provisioning System with the goal of keeping your traffic secure and your settings up to date.


Our overall philosophy is that a brand new certificate with all Akamai defaults should be capable of achieving an A on SSL Labs. However, as our customers all differ in their ability to accept and roll out changes, we leave upgrading existing certificates to the discretion of our customers unless there is a severe vulnerability announced with any particular setting which necessitates immediate action.


If you’d like to test any changes on staging prior to pushing the change to production, please enable the “Change Management” feature that is on the “Deployment and TLS Metadata” tab; this is the Always Test on Staging feature on our Beta User Interface (UI). This setting change is immediate regardless of how you got to the Deployment and TLS Metadata tab and can even be enabled from the “View Enrollment” action.  Please note that even with "Change Management" and "Always Test on Staging" enabled, seven days before the active certificate expires, any new certificate on staging will be immediately deployed to production unless a later deployment date is set.


Certificate Creation:

Geographical Deployment:

“Excludes China & Russia” is our default option which provides global coverage but does not utilize Edge servers inside of China or Russia; those countries are served from outside the borders. Our China CDN and Russia CDN options are available to serve traffic from inside those countries. If both China and Russia CDNs are required, you will need two different certificates with our Global Traffic Manager in front to decide which certificate to present.



Server Name Indication (SNI) Only delivery allows Akamai to serve multiple certificates from shared IP addresses. SNI-Only on provides for faster service at a lower price! If SNI-Only is off, traditional VIP based delivery is used where each certificate will utilize a dedicated IP address per Akamai region. SNI only should not be used if you need to support Windows XP, Java 6 or lower, Android 2.3 or lower, or any custom application that does not support SNI. Please see this blog post for a good discussion on SNI usage.


Certificate Chain (for Akamai-managed Symantec OV):

The default chain should be used in all cases unless you know for sure that you have legacy devices such as TVs, set top boxes, printers, etc. that have a trust store that cannot be updated and must use the cross-signed 1k root option.


“Default” is the setting for new certificates.  However, Symantec certificates that were transitioned from Verizon Cybertrust have the “Cross Signed 1k root” option on. All of these should be updated to “Default” unless you have the situation above. 


The “Cross-Signed 1k root” option will cause SSL Labs and other PEN testing services to report a weak certificate chain with a SHA1 certificate. This warning can be avoided by changing this option to “Default.”


An up to date listing of all Akamai managed certificate chains can be found at this blog post.

Deployment Settings

Hostname Must Match CN

Leave this setting on unless you must CNAME a test hostname to the same edge hostname without adding the test hostname to the certificate. Also, if this is needed for testing, it is recommended that is only done on a QA/test slot. Having both production hostnames and QA/test hostnames on a single certificate is also not recommended.


Client TLS Renegotiation

This one is confusing because our default is not the same as our recommendation and our recommendation will cap the SSL Labs score at A-.


“Secure” is our platform default which allows clients to securely initiate a renegotiation of TLS session parameters, ciphers or keys. This setting will allow up to an A+ in SSL Labs.


We believe it is actually more secure to “Disallow” renegotiations all together, however, SSL Labs caps this setting at an A-. The good news is this debate goes away in the future as TLS 1.3 does not support client renegotiation.

TLS Protocol Versions

“Use Akamai Defaults” selects the Akamai defaults at the time of certificate creation.  At the time of this writing they are TLS 1.2, 1.1 and 1.0 in that order. When TLS 1.3 becomes generally available in early 2018, certificates with “Use Akamai Defaults” will include TLS 1.3 if they also have a cipher profile supporting TLS 1.3.


See this blog post for a good read on TLS 1.3 and what it takes for it to become an internet standard.  Please also see this blog post for details on our TLS 1.3 beta.


Our TLS 1.0 deprecation plans are still being finalized. Customers wishing to remove support for TLS 1.0 should use the “Disable Specific TLS Versions” option to disable TLS 1.0. In order to remain PCI compliant, for customers that need to do so, TLS 1.0 should be disabled prior to June 2018.


WARNING: At some point in the near future we will change the selection of specific TLS versions from “disable” to “enable.” Please pay attention to to the User Interface prompts when making TLS Version selections.

Enable SANs

SNI Only certificates provide an option of controlling which hostnames are actually active for that certificate. By default, all of them are enabled. This option allows you to tell Akamai to not serve this certificate even if the hostname is presented to an Edge server. This option can be useful when moving hostnames from one certificate to another. Be aware that if the same hostname is enabled on multiple SNI Only certificates, the Edge server will randomly choose which certificate to present.

Dual Stack RSA+ECDSA

Available today for Akamai-managed Symantec OV/EV and coming soon for Let’s Encrypt DV, this option provides an ECDSA copy of the certificate to be on the same slot as the RSA certificate. CPS will keep both certificates in sync with each other. The ECDSA certificate makes connections with modern devices more efficient.


Dual Stack is on by default for new certificates. Customers wishing to make use of this for existing certificates are required to specifically enable this option in CPS.  


Be careful with this option if you make use of any kind of client certificate pinning as there will be two certificates clients can connect to.  

OCSP Stapling

The OCSP Stapling option can be enabled to staple the OCSP response along with the client’s request for the certificate. This will save the client from doing an additional round trip to a 3rd party hostname to obtain the OCSP response, making initial connections faster. If no specific selection for this setting is made, OCSP stapling will be enabled the next time a certificate or deployment setting change is made.


OCSP Stapling is available for all Akamai managed certificates and is currently only available for some third-party certificates. We recommend enabling this feature as we don’t see any downsides with it.

Cipher Profiles

For cipher profiles, our latest defaults and recommendations will always be listed at http://akamai.me/CipherProfiles. Please follow that page (click on following and inbox) to keep up to date as we release new profiles. Please note that if you still require Windows XP/Server 2000 clients to connect to your site, you should choose ak-akamai-default-2016q1 which is the last cipher profile to support DES-CBC3-SHA and currently still can achieve an A on SSL Labs. ak-akamai-default-2017q3 is our current default and contains the ciphers necessary to support TLS 1.3.


Property Manager Settings that influence SSL Labs Score


The defaults described above will be sufficient to achieve an A on your SSL Labs Score. In order to achieve an A+, you need to enable HTTP Strict Transport Security (HSTS) headers with at least 6 months duration. HSTS headers tell a browser that it should only connect with HTTPS. These headers can either be set at the origin or you can utilize the "HTTP Strict Transport Security (HSTS)" behavior in Property Manager. This behavior is included by default for new secure properties, however, it is not enabled.


Please be careful when including all subdomains and using the preload option as a denial of service could result if the subdomains or any portion of the site still requires HTTP.

We do recommend using HSTS headers, but only do so if your entire site is enabled for HTTPS delivery. When enabling them, start with a shorter max age and then increase it as your confidence grows.