14. Secure Delivery¶
Secure Delivery is comprised of many sub-services, depending on the desires of the customer. The CTL CDN HTTPS service consists of three service categories:
- Premium SSL
- SNI
- Shared/Basic SSL
Aliases can be configured for HTTPS only or HTTP+HTTPS. If configured for HTTPS only and a client tries to connect via HTTP, a 403 error will be returned by default. If a different error code or behavior is desired a customer configuration can be crafted.
HTTPS services can be enabled on a per-alias basis.
14.1. Basic SSL¶
The Shared/Basic SSL service uses a wildcard CenturyLink certificate under the domain of *.secure.footprint.net (or *.secure2.footprint.net for HTTP/2). To use this service, only host names under the *.secure.footprint.net can be used. The advantage of this service is simplicity – there is no need to obtain a certificate nor setup a DNS CNAME record and CenturyLink can quickly provision the service. It enjoys global deployment with ample capacity (all CenturyLink CDN edge nodes include a VIP for the Shared/Basic HTTPS service).
Basic SSL is provisioned as part of the Alias Definition, under the httpsConfig object using the serviceType attribute of Basic, as illustrated below:
"aliasDefinitions": [
{
"id": 1,
"name": "basisSSL example",
"originId": 24152,
"reportingId": 24152,
"aliases": [
"foo.secure.footprint.net"
],
"protocol": [
"HTTPS"
],
"httpsConfig": {
"serviceType": "Basic",
"ocsp": false,
"encryptionLevel": "Default",
"certInfo": {
"id": 1,
"name": "star.secure.footprint.net"
},
"http2": false
},
"signature":"987654321abcdefg"
}
]
The “signature”: attribute is calculated over the following attributes:
- aliases
- serviceType
- certInfo
- http2
Changes to any of these attributes will result in the signature verification process failing and the service image being rejected.
14.2. Server Name Indicator (SNI)¶
Server Name Indication (SNI) allows customers to use their own certificate but without requiring CenturyLink to dedicate IP addresses per certificate. This is possible by using the server name included in the client’s TLS Hello Message to determine the proper certificate to use to establish the TLS session. This feature is not supported by all client types, but is well supported by all modern OSes and browser platforms. Support for more esoteric platforms such as smartTVs or video platforms (e.g., early Roku players) may be less prevalent. If a client does not include the SNI extension in its client Hello message, the CenturyLink CDN will reject the TLS handshake request and the user will typically receive a connection error message.
SNI enjoys global deployment with ample capacity (all CenturyLink CDN edge nodes include a VIP for the SNI HTTPS service).
If the customer requires broader interoperability, the Premium SSL service can be considered - but in general, customers should be well served by the SNI service.
For more details on SNI, see: https://en.wikipedia.org/wiki/Server_Name_Indication
SNI is provisioned as part of the Alias Definition, under the httpsConfig object using the serviceType attribute of SNI:
"aliasDefinitions": [
{
"id": 1,
"name": "SNI example",
"originId": 24152,
"reportingId": 24152,
"aliases": [
"sni.example.com"
],
"protocol": [
"HTTPS"
],
"httpsConfig": {
"serviceType": "SNI",
"ocsp": false,
"encryptionLevel": "Default",
"certInfo": {
"id": 1,
"name": "sni.example.com"
},
"http2": false
}
}
]
Note
Changes to the encryptionLevel for SNI delivery will only modify the list of allowed ciphers the server can choose from. Protocols and key parameters (e.g., DHParams) are common across all SNI SSL customers.
Note
In order to enable SNI, you must have ordered HTTPS delivery. If HTTPS Delivery was not ordered, attempts to enable will result in an error when pushing to an environment.
Changed in version 19.9: removed the signature component from the schema as HTTPs SNI is now allowed via Self Service.
Before enabling SNI it is important to first upload a supporting certificate, see the Certificate Management section. When associating certificates to the HTTPS configuration, the certInfo.id must point to an existing certificate ID which contains a valid certification along with any required intermediary certificates.
14.4. Certificate Management¶
Certificates can be managed via the certificate API set. The API set allows for uploading existing certificates, private keys and intermediary certificates as well as creating Certificate Signing Requests (CSR) for obtaining new certificates.
Certificates are stored separately from the service images. Private key’s are encrypted using a two-way encryption function and are never exposed externally from the CDN. The private keys, along with the associated certificate, are distributed to the CTL CDN edge nodes via a secure communication channel. The edge nodes have the ability to decrypt the private key and load into memory for use with secure delivery services. The private key is never stored in an unencrypted format.
When providing a certificate to CTL, it must meet the following criteria:
- A key length of 2048 characters
- Use the SHA2 signature algorithm
- Encoded using the Privacy Enhanced Mail (pem) format
Note
Certificate Management is only available if you have purchased Premium SSL Delivery.
Wildcard Certificates
Customers are welcome to provide wildcard certificates to reduce the number of certificates they have to manage. When using wildcard certificates with the CTL CDN, there are a few important points that need to be considered. In particular, host name matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name), a match in any one of the set is considered acceptable. Names may contain the wildcard character * which is considered to match any single domain name component or component fragment (e.g., *.a.com matches foo.a.com but not bar.foo.a.com).
SAN Certificates
The CTL CDN supports the use of SAN certificates however it is not yet possible to create a SAN CSR via the Certificate API set.
14.4.1. CSR¶
When requesting a CSR, the following data must be provided:
{
"csr": {
"country": "United States",
"state": "California",
"location": "Newbury Park",
"organization": "CenturyLink",
"organizational_unit": "The Best Division",
"common_name": "www.werok.com",
"key_algorithm": "RSA",
"key_param": "2048"
}
}
Note that the CSR request does not require generation of a key pair. This is done in the background by the API. The created private key is immediately encrypted then stored in the data store under the certname used for the API request.
The supported key_algorithm and corresponding key_param values are: * RSA and 2048 * EC (Elliptic Curve) and “scep256r1” (aka - prime256v1)
When uploading the corresponding certificate it is important to upload using the same certname so the key pair matches.
Note
Note that the CTL CDN currently supports associating only a single certificate to an Alias. So while it is possible to create an EC certificate, its use should be considered against the expected client base and its ability to process such a certificate. In a future release, support for both EC and RSA certificates for a single Alias will be added.
14.4.2. Upload New Cert¶
It is possible to upload an existing certificate as a new cert as well as uploading a cert obtained through a CSR created by the API. In both cases it is important to upload both the host certificate and any required intermediary certificates as shown in the following example:
{
"certificate": "-----BEGIN CERTIFICATE-----<cert data>-----END CERTIFICATE-----"
"private_key_data": {
"password":"password string",
"private_key":"-----BEGIN ENCRYPTED PRIVATE KEY-----<private key data>-----END ENCRYPTED PRIVATE KEY-----"
}
"intermediate_certs": "-----BEGIN CERTIFICATE-----<cert data>-----END CERTIFICATE-----"
}
If the certificate was acquired using a CSR request, the customer will not know the private key and it should be excluded from the request body. The private key was generated as part of the CSR request and stored against the associated certID/certName.
Otherwise, the private key must be included for the certificate to be considered valid. If the private key is encrypted, the password used to decrypt must also be included so the system can decrypt and re-encrypt for secure storage and delivery.
Supported certificate formats: * pem - Privacy Enhanced Mail, a Base64 encoded DER certificate
Note
The CTL CDN does not support dual certificates at this time. Only a single certificate type (RSA or EC) can be used for an Alias definition.