Edgio requires a TLS certificate hosted on our network to serve HTTPS traffic for:
-
Your Hostnames: You may either:
-
Allow Edgio to autogenerate a TLS certificate for each of your hostnames.
-
You may use a wildcard certificate across multiple environments once it has been uploaded to one of your environments. Learn more.
It may take up to 6 hours to install a new TLS certificate across our entire network. -
-
Edgio Domains: Edgio provides a wildcard TLS certificate for the domains that we automatically generate when you deploy to your property. This certificate is managed by Edgio and it does not require configuration.Sample domain:
my-organization-my-property-feature-a-1234.edgio.link
Apply additional security to your encrypted traffic by enabling mTLS.
Autogenerating TLS Certificates
Edgio can automatically generate TLS Certificates on your behalf using Let’s Encrypt. These certificates are free, valid for 3 months, and automatically renewed as long as the following technical requirements remain met:
- Hostnames: Register the hostnames that will serve traffic for each environment.
- Certificate Authority Authorization: The Let’s Encrypt certificate authority (CA) must be allowed to issue certificates for each registered hostname.
- Domain Control Validation: Prove your control over that domain by adding an
_acme-challenge
CNAME record to it. - Web Server(s): Enable or verify that your web servers support TLS 1.3 (recommended) or 1.2 encryption.
Certificate Authority Authorization
The Let’s Encrypt certificate authority (CA) must be allowed to issue certificates for each registered hostname. It is allowed to issue certificates when either of the following conditions are true:
-
A CAA record has not been issued for that hostname or a parent hostname (i.e., the main domain or at any depth of subdomain). This DNS configuration means that any CA is allowed to generate certificates for that hostname.CAA validation follows CNAME records. For example, if your
www.example.com
CNAME record points towww-origin.example.com
, then the CA will first request CAA records forwww.example.com
. Upon detecting a CNAME record, it will request CAA records forwww-origin.example.com
instead. -
A CAA record explicitly allows the Let’s Encrypt CA to generate certificates for that hostname.This sample CAA record indicates that the Let’s Encrypt CA is allowed to issue certificates for
cdn.example.com
:cdn.example.com. CAA 0 issue "letsencrypt.org"
-
By default, some DNS service providers add
CAA
DNS record(s), while others do not allow the creation ofCAA
DNS records and therefore allow any CA to generate certificates.
To add a CAA record to allow Let’s Encrypt to generate certificates for your domains
-
Verify the value of the CAA records for your domain from the command line.Bash1# Run the following command2dig caa +short <your-apex-domain>34# Example5dig caa +short mywebsite.xyzThe following sample response for a CAA query shows that only specific CAs are allowed to generate certificates for that domain:Bash10 issue "amazon.com"20 issue "digicert.com"30 issue "globalsign.com"40 issue "letsencrypt.org"If the result of the CAA DNS query is empty, it means that any CA is allowed to generate certificates on that domain. If so, proceed to domain control validation.
-
If there are
CAA
DNS entries defined on your hostname or parent hostname, and if the Let’s Encrypt’s CAA entry is not among those, you will have to add an additionalCAA
entry for Let’s Encrypt.From your DNS service provider, add the followingCAA
DNS record:- Type:
CAA
- Name: empty or
@
(depending on the DNS provider) - Flags:
0
- Tag:
issue
- Value:
letsencrypt.org
or"letsencrypt.org"
Learn how to add a CAA record:Verify your CAA configuration. We recommend the following CAA lookup tools: - Type:
Domain Control Validation
Before Edgio may issue a certificate request on your behalf, we require that you validate your control over each of your hostnames by adding a CNAME record. From your DNS service provider, add the following CNAME DNS entry for each desired hostname:
-
Host:
_acme-challenge.<HOSTNAME>
Example:If your hostname iscdn.example.com
, then you would set it to_acme-challenge.cdn.example.com
. -
Value:
_acme-challenge.xdn-validation.com
GoDaddy Example:
Gandi Example:
Verify each CNAME record using your preferred tool. For example, you can use any of the following tools:
-
Command line: Run the following command:Bash1# Run the following 'dig' command to verify the presence of the '_acme-challenge.' CNAME :2dig +short cname _acme-challenge.<your-domain>34# For example:5dig +short cname _acme-challenge.mywebsite.xyzExpected result for the DNS query:1_acme-challenge.xdn-validation.com.
If you use multiple domains for your website, like
mywebsite.xyz
and www.mywebsite.xyz
, you will have to make sure that the _acme-challenge
DNS record has been added for both domains:1_acme-challenge.mywebsite.xyz -> _acme-challenge.xdn-validation.com.2_acme-challenge.www.mywebsite.xyz -> _acme-challenge.xdn-validation.com.
If you have previously used Let’s Encrypt to generate certificates for your hostnames, you should verify that all
_acme-challenge.<HOSTNAME>
TXT records have been removed.TLS Certificate Verification
Once the above requirements are met, you should verify that a TLS certificate for each of your hostnames has been generated.
To verify TLS certificate creation
-
Load the TLS Certificate page.
- From the Edgio Console, select the desired private space or organization.
- Select the desired property.
- From the left-hand pane, select the desired environment from under the Environments section.
- From the left-hand pane, select TLS Certificate.
-
Review the TLS status for each of your hostnames.
-
If a TLS certificate has not yet been generated, you may manually generate it by clicking under the ACME Challenge Record column.Edgio will generate a TLS certificate for that hostname within a few minutes.It may take up to 6 hours to install a new TLS certificate across our entire network.
-
Wait a few minutes and then verify that a certificate was created for that hostname.
Manually Creating a TLS Certificate
Skip this section if you plan on using autogenerated TLS certificate or if you already have an existing TLS certificate that you plan to upload.
TLS certificates are issued by Certificate Authorities (CA) based on your Certificate Signing Request (CSR). Although a single command generates a CSR and a private key, you should only share your CSR with the CA. You should also securely store your private key.
The following procedure indicates how to create a CSR and a private key with OpenSSL. OpenSSL is an open-source toolkit for the TLS protocol. We recommend using OpenSSL because it ensures that your private key will only be stored locally on your infrastructure.
Review your CA’s documentation to check for additonal requirements or a custom certification workflow.
To generate a CSR and a private key
-
From the command line, verify that OpenSSL is installed:
- MacOS: Install it by using
brew
package manager (e.g.,brew install openssl
). - Windows: Install it by using
Chocolatey
package manager (e.g.,choco install openssl
). - Linux/Unix: Install it by running the built-in OS package manager (e.g.,
apt-get install openssl
,apk add openssl
, and so on).
- MacOS: Install it by using
-
Go to the directory of your choice and create a configuration file (e.g.,
edgio_cert.conf
) based on this template:1[req]2default_bits=20483distinguished_name = req_distinguished_name4req_extensions = v3_req56[req_distinguished_name]7countryName=Country Name (2 letter code)8countryName_default=US9stateOrProvinceName=State or Province Name (full name)10stateOrProvinceName_default=California11localityName=Locality Name (e.g., city)12localityName_default=San Francisco13organizationName=Organization Name (e.g., company)14organizationName_default=YourCompanyName15commonName=Fully Qualified Domain Name (FQDN) e.g., www.your-company-name.com16commonName_default=www.your-company-domain.com1718[v3_req]19subjectAltName=@alt_names2021[alt_names] # Other domains: apex domain, wildcard domain for staging and dev, and so on22DNS.1=*.your-main-domain.com23DNS.2=*.your-dev-domain.com24DNS.3=your-apex-domain.com25# And so onReplace the country, state/province, locality, organization name, and Common Name (CN). Set the CN to your hostname’s fully qualified domain name (e.g.,cdn.example.com
).Edgio strongly encourages the use of wildcard certificates. However, if you are not using a wildcard certificate, then you will need to add the remaining hostnames into thealt_names
section. -
Run the following command:Bash1openssl req -out edgio.csr -newkey rsa:2048 -nodes -keyout edgio.key -config edgio_cert.conf -batchThis should generate your CSR in
edgio.csr
and private key inedgio.key
.If you want OpenSSL to ask you for each different input, remove the-batch
option and re-run the command. -
Verify your CSR contains the expected domains by running the following command:Bash1openssl req -in edgio.csr -noout -text | grep DNS
-
Read the CSR (e.g.,
cat edgio.csr
) or copy it to your clipboard (on OSX,cat edgio.csr | pbcopy
) and send it to your CA for certification.
Uploading Your Certificate
If you prefer to use your own TLS certificate, then you may upload it to our network.
Key information:
-
You may upload a TLS wildcard certificate, which allows you to secure multiple hosts with the same base domain (e.g.,
*.example.com
allows you to securewww.example.com
,images.example.com
,cdn.example.com
, etc.). By default, you only need to upload a wildcard certificate a single time. After which, it will be available for use across all of your organization’s properties and environments.If you have requested the use of our PCI-compliant network, then the wildcard certificate will only be applicable for environments that use the same network as the environment on which it was uploaded. You can check whether your environments use the same network from the Organization DNS Configuration section of your organization’s Settings page. -
Uploading a TLS certificate requires:
- The
Admin
role within your organization. - A certificate issued by a CA.
- The intermediate certificates (IC) used by the CA, including the CA’s signing certificate.
- The private key that was generated with the CSR.
- The
-
Edgio does not automatically renew TLS certificates that have been manually uploaded to our network. As a result, you will need to upload a new TLS certificate before your current TLS certificate expires. Failure to do so before the expiration of your TLS certificate will impact your client’s experience. For example, a browser may display a page warning users that their connection is not private.
To upload your TLS certificate
-
Load the TLS Certificate page.
- From the Edgio Console, select the desired private space or organization.
- Select the desired property.
- From the left-hand pane, select the desired environment from under the Environments section.
- From the left-hand pane, select TLS Certificate.
-
Clear the Automatically create an TLS certificate for my custom domains. option.
-
Copy the certificate, intermediate certificates, and the private key into the corresponding options.The private key is non-public data and must not be shared with parties other than Edgio. Edgio securely stores your private key. It is never shown in the Edgio Console and it is only used to provision parts of the infrastructure that are used to terminate TLS connections.
-
Click Changes Saved. Certificate activation typically takes a few minutes.Contact technical customer support if the status does not become Active within an hour.
mTLS
The Mutual TLS feature requires Edgio Premier. Contact your account manager or our sales department at 1 (866) 200 - 5463 to upgrade your account.
TLS requires a server to authenticate to the client before a connection can be established. Mutual TLS (mTLS) builds upon TLS by also requiring the client to provide a X.509 certificate to the server for the purpose of authentication. The following diagram provides a high-level overview of how a client can establish a secure connection to an edge server through mTLS.
Our mTLS implementation provides flexibility when determining when and how a client will authenticate to an edge server.
-
By default, mTLS is disabled. Enable it by defining how certificates will be validated.
-
Once mTLS has been enabled, the default behavior is to request a client certificate for all requests. However, you may instruct Edgio to only request a client certificate for specific hostname(s) through the Request Client Certificates for Hostnames option. Regardless of this option, the Client Certificate Validation option determines how a client certificate will be validated for all requests.
-
Send headers to your origin containing mTLS metadata by enabling the Send Client Certificate Detail to Origin option.
-
The TLS handshake fails when Edgio cannot validate a client certificate.Permissive mode is an exception to this behavior. By default, Permissive mode allows traffic regardless of whether client certificate validation fails. However, you may override this behavior for Permissive mode and return a
403 Forbidden
response by enabling the Return Status Code 403 for Validation Failures option.
mTLS Validation
Determine whether and how Edgio will validate certificates through the Client Certificate Validation option. The available validation modes are described below.
- Required: Set this option to
Required
to require the client to provide a certificate issued by a certificate authority (CA) within your custom chain of trust. - Optional: If you choose to make client certificates optional, then you must define how Edgio will validate a certificate when provided by a client. Set this option to one of the following modes:
-
Permissive: Recommended. By default, this mode instructs Edgio to allow traffic regardless of whether the client provides a valid certificate. If provided, Edgio will still process the client certificate. You may choose to send this metadata to the origin server.Permissive is the recommended validation mode for your initial setup, since it allows you to verify your configuration through mTLS metadata sent to the origin. Once you have verified your configuration, you may block unverified traffic by enabling the Return Status Code 403 for Validation Failures option.
-
Optional without CA validation: If the client provides a certificate, it must be a valid X.509 certificate that is either self-signed or signed by a CA.
-
Optional: If the client provides a certificate, it must be issued by a CA within your custom chain of trust.
-
- Disabled: Disables mTLS.
mTLS Depth of Validation
If you have configured the Client Certificate Validation option to either
Required
, Optional
, or Permissive
, then the Chain of Trust Depth Validation option determines the maximum depth for certificate validation.-
0: Restricts validation to self-signed certificates.
-
1: Restricts validation to self-signed certificates or a certificate signed by a CA in the chain of trust defined under the Certificate Chains section.
-
2 or more: Allows levels 0 (i.e., self-signed certificates) through the specified number. The specified number determines the maximum depth to which Edgio will validate a client certificate. For example, setting it to 2 allows a client certificate that satisfies level 0, 1, or 2.Edgio will validate up to the specified number of CA certificates.
- If the client certificate is backed by fewer CA certificates, then Edgio will validate all of those CA certificates.
- If the client certificate is backed by additional CA certificates, then Edgio will ignore the CA certificates that exceed the specified depth.
Example: If you set the depth to 2, then Edgio will validate self-signed certificates or it will check up to 2 CA certificates that back the client certificate. Edgio can validate a client certificate for all three of the following scenarios:Intermediate Certificate(s) Root Certificate(s) Total CA Certificate(s) Valid Client Certificate 0 0 0 Yes 1 1 2 Yes 3 1 4 Yes Notice that the last scenario exceeds the specified depth by 2. In that scenario, Edgio will validate the client certificate and check the first 2 intermediate CA certificates. If those certificates are valid, then it will consider the client certificate valid and ignore the third intermediate CA certificate and the root certificate.
Chain of Trust
Set up a chain of trust by uploading a PEM file that contains an ordered list of intermediate and root certificates for the desired hostname. Use a line break to separate each certificate as shown below.
pem
1-----END CERTIFICATE-----2-----BEGIN CERTIFICATE-----
Prior to the expiration of the certificates in your chain of trust, you must upload a PEM file that contains renewed certificates.
If a PEM file should no longer be used (e.g., it contains expired certificates), then you should delete it from the Certificate Chains section.
mTLS Setup
Set up mTLS by defining how Edgio will validate certificates.
To set up mTLS
-
Navigate to the TLS Certificate page.
- From the Edgio Console, select the desired private space or organization.
- Select the desired property.
- From the left-hand pane, select the desired environment from under the Environments section.
- From the left-hand pane, select TLS Certificate.
-
From the Client Certificate Validation option, select how Edgio will validate certificates that will be performed.We strongly recommend that you set this option to
Permissive
for your initial setup. This mode allows unverified traffic while you fine-tune your mTLS configuration. -
From the Request Client Certificates for Hostnames option, determine whether Edgio will request a certificate for all requests or solely for specific hostnames.
- All Requests: Verify that this option is set to blank.
- Specific Hostnames: Select each desired hostname from this option.
-
From the Chain of Trust Depth Validation option, select the depth to which Edgio will validate a client certificate with the chain of trust defined in the Certificate Chains section.
-
If you set the Chain of Trust Depth Validation option to a value of
1
or higher, then you should add a PEM file that contains a chain of trust for each desired hostname. Perform the following steps to add a PEM file:- Click + Add Certificate Chain.
- Paste the PEM file for the desired X.509 certificate(s).
- Click Add Chain.
-
Optional. Toggle the Send Client Certificate Detail to Origin option to send headers containing client certificate metadata and validation status to your origin servers.
-
Optional. If you are using Permissive mode, then you can override the default behavior and return a
403 Forbidden
response for client certificate validation failures by enabling the Return Status Code 403 for Validation Failures option.We recommend that you leave this option disabled until you have verified that your mTLS configuration will not block legitimate traffic. -
Click Save to apply your changes.
To update your mTLS configuration
-
Navigate to the TLS Certificate page.
- From the Edgio Console, select the desired private space or organization.
- Select the desired property.
- From the left-hand pane, select the desired environment from under the Environments section.
- From the left-hand pane, select TLS Certificate.
-
Update the desired setting(s). Common tasks are listed below.
- Update your chain of trust by:
- Uploading a PEM file for each desired hostname. Make sure to upload renewed certificate(s) before the existing certificate(s) expire.
- Deleting the PEM file for expired certificate(s). From the Certificate Chains section, click the icon corresponding to the chain that will be deleted.
- Update your chain of trust by:
-
Click Save.
To disable mTLS
-
Navigate to the TLS Certificate page.
- From the Edgio Console, select the desired private space or organization.
- Select the desired property.
- From the left-hand pane, select the desired environment from under the Environments section.
- From the left-hand pane, select TLS Certificate.
-
Set the Client Certificate Validation option to
Disabled
.This configuration disables client certificate validation for all requests to this environment. If a client provides a certificate, Edgio will not validate it. -
Click Save.
Origin Request Headers
Edgio can send request headers containing mTLS metadata to the origin when the Send Client Certificate Detail to Origin option is enabled. The selected client certificate validation mode determines when these request headers are sent.
- Permissive Mode: These headers are sent for all requests, including requests that result in a failed TLS handshake or a
403 Forbidden
response. This behavior allows you to use those headers to troubleshoot client authentication issues. - All Other Modes: These headers are only sent to your origin for requests for which we were able to establish a secure connection. Edgio will not provide these headers when the request results in a failed TLS handshake.
Mutual TLS request headers are described below:
Header | Type | Description |
---|---|---|
x-ssl-client-cert | Client Certificate | Contains the client certificate in PEM format. Example: -----BEGIN%20CERTIFICATE----- ... %0A-----END%20CERTIFICATE-----%0A |
x-ssl-client-i-dn | Distinguished Name - Issuer | Identifies the Distinguished Name (DN) for the client certificate’s issuer. Example: CN=ACME INTERMEDIATE CLIENT CA,OU=Security,O=ACME Inc.,L=Los Angeles,ST=California,C=US |
x-ssl-client-s-dn | Distinguished Name - Subject | Identifies the Distinguished Name (DN) for the client certificate’s subject. Example: CN=www.example.com,OU=Security,O=ACME Inc.,L=Los Angeles,ST=California,C=US |
x-ssl-client-serial | Client Certificate’s Serial Number | Indicates the client certificate’s serial number. Example: 655603895D3E8ECC4DF507FB33A1171A53F37CAF |
x-ssl-client-sha1 | Client Certificate’s Fingerprint | Contains the client certificate’s SHA1 fingerprint. Example: 7C2E166156E2D165AD7468B0E0145411B655F041 |
x-ssl-client-v-end | Client Certificate’s Expiration Date | Indicates the date and time (GMT) at which the client certificate will expire. Example: Aug 7 18:54:27 2033 GMT |
x-ssl-client-verify | Client Certificate’s Validation Status | Indicates the result for the validation of the client certificate. Valid values are:
|
x-ssl-client-v-remain | Client Certificate’s Days to Expiration | Indicates the number of days until the client certificate will expire. Example: 123 |
x-ssl-client-v-start | Client Certificate’s Issued Date | Indicates the date and time (GMT) at which the client certificate was issued. Example: Aug 10 18:54:27 2023 GMT |
Troubleshooting TLS
If your origin returns a
502 Bad Gateway
or a 504 Gateway Timeout
response when served through Edgio, then your origin configuration’s TLS settings may be improperly configured. View troubleshooting steps.