HTTPS

This article only applies if your account uses our Certificate Provisioning System (CPS). If you are still using our legacy HTTPS solution, then you must request a TLS certificate by contacting your CDN account manager.

A default CDN configuration allows traffic to flow over HTTP. Serving traffic over HTTPS requires a TLS certificateRefers to a certificate that allows you to use the TLS protocol to encrypt traffic between the client and our network for the purpose of delivery over HTTPS. on our network, updating your CDN configuration, and defining a CNAME record via your DNS service provider.

Delivery over HTTPS requires TLS activation and TLS certificates. Contact your CDN account manager for more information.

TLS Certificate Support

Our CDN supports the use of any certificate derived from a Certificate Authority (CA) by allowing you to bring your own certificate to our network. Additionally, you may purchase a TLS certificate that supports multiple Subject Alternative Names (SAN). We support the following levels of validationDetermines the amount of validation that the Certificate Authority will perform to verify a certificate applicant's information before issuing a certificate. for our certificates:

Quick Start

Setting up HTTPS delivery involves the following steps:

  1. Activate TLS and purchase the desired TLS certificate(s). Contact your CDN account manager for more information.

  2. Set up the desired TLS certificate(s).

  3. Enable TLS 1.3 (recommended)TLS 1.3 improves security and performance of internet communications. Specifically, it eliminates known TLS 1.2 security vulnerabilities and prevents snooping and man-in-the-middle attacks. and/or 1.2 encryption on your web server(s).

    A recommended best practice is to disable support for SSL/TLS versions 1.1 or older.

  4. Customer Origin Only

    Configure your customer origin configuration for either end-to-end or client to edge encryption.

  5. Create an edge CNAME configuration that points to a Subject Alternative Name (SAN) defined in the certificate (e.g., common name). Repeat this step as needed.
  6. Once the TLS certificate has been deployed to our network, wait 6 hours and then verify that the certificate is live.
  7. Create a CNAME record via your DNS service provider that points a SAN to the certificate's target CNAME. Repeat this step as needed.

TLS Certificate Setup

Setting up a TLS certificate requires performing the following steps:

  1. Submit a request for a TLS certificate.
  2. Prove your control over each Subject Alternative Name (SAN) defined in the certificate via a Domain Control Validation (DCV) method (i.e., email, DNS TXT, or DNS CNAME).

  3. OV and EV Certificate

    Validate your organization by following the directions provided by the Certificate Authority (CA) via phone or email.

  4. Wait until the CA has validated your request. After which, your certificate will be issued and installed on our network. Additionally, a target CNAME will be generated for each delivery platform and associated with your account.

Once a TLS certificate has been installed on our network, you will need to update your edge CNAME configuration and DNS zone before HTTPS traffic may flow through our network. If you plan on serving HTTPS traffic via your web server(s), then you will also need to update your customer origin configuration.

To set up a TLS certificate

  1. Navigate to the Certificate Provisioning System page. ClosedHow?From the main menu, navigate to More | Tools | Certificate Provisioning.
  2. Click Add Certificate. The New TLS Certificate wizard will appear.
  3. From the Certificate Label option, type a unique name that will be assigned to this request for a TLS certificate.
  4. Skip the Common Name field. This field is auto-populated by the Subject Alternative Name (SAN) option.
  5. From the Domain Control Validation (DCV) Method option, choose how you will prove your control over each domain associated with this request.
  6. From the Subject Alternative Name (SAN) option, click Add Domain and then type the desired SAN. Repeat this step as needed.

    DV and OV certificates support the use of a wildcard to secure all possible subdomains (e.g., *.example.com). However, this is not allowed for an EV certificate.

  7. If you have specified multiple SANs, then verify the common name defined in the Common Name option. Assign a different common name by clicking the Is Common Name? option next to the desired domain.
  8. From the Validation Level option, select the level of validation that will be performed by the CA.

    • Domain Validation (DV)

      Proceed to the next step.

    • Organization Validation (OV)

      Provide your organization information in the form that appears in this section. The CA will validate your organization using the provided information.

      Fill out this form with care. Misspellings or incorrect information (e.g., unregistered abbreviations) will delay your request until those issues are corrected.

    • Extended Validation (EV)

      1. Provide organization information in the form that appears in this section. The CA will validate your organization using the provided information.
      2. Add one or more contact(s) for the individuals within your organization that are responsible for approving this EV certificate.

        Add a contact by clicking + Add Contact from the Additional Contacts section and then filling out all of the fields.

      Fill out organization and contact information with care. Misspellings or incorrect information (e.g., unregistered abbreviations) will delay your request until those issues are corrected.

  9. Verify that the Auto renew option is enabled.

    Learn more.

  10. Click Submit Request to submit your certificate request to the CA.
  11. Wait approximately 15 minutes for the CA to process your request.
  12. Open your certificate request by clicking on it from the Certificate Provisioning System page. Verify that you are now on step 3. Domain Validation (DCV).
  13. Validate control over your domain according to the DCV selected in the Domain Control Validation (DCV) Method option.

    • Email

      Follow the directions for both sets of emails sent by the CA to:

      1. The registered owner(s) of the public domain as determined by the domain's WHOIS record.
      2. admin@Domain, administrator@Domain, webmaster@Domain, hostmaster@Domain, and postmaster@Domain.
    • DNS Text

      1. Click Generate for each SAN defined in your certificate request.
      2. Create a TXT record for each SAN defined in your certificate request.

        Name:

        Fully Qualified Domain

        Prepend _dnsauth. to avoid a conflict with an existing CNAME record.

        If you have requested a wildcard certificate, exclude the last level in the domain. For example, if you have requested a wildcard certificate for *.cdn.example.com, then the fully qualified domain for that certificate request would be cdn.example.com..

        Value:

        Verification Token

        Example:

        _dnsauth.cdn.example.com. 3600 IN TXT "5gh0lcx2d41n4v673kgfxlrndpd2l1n8"
    • DNS CNAME

      1. Click Generate for each SAN defined in your OV or EV certificate request.
      2. Create a CNAME record for each SAN defined in your certificate request with the following properties:

        • Name: Set it to a SAN-specific token.
        • Value: Set it to dcv.digicert.com.

    The CA performs automatic checks for DNS text and DNS CNAME DCVs for up to a week after submitting your certificate request. You may also manually request validation from the CA by clicking Validate.

  14. Once the CA is able to validate your control over the domains defined in the certificate request, your request will proceed to step 4. Other Validations. In this step, the CA performs additional validations including Organization Validation (OV).
  15. Extended Validation (EV) and Organization Validation (OV)

    In addition to other validations performed by the CA, you will be required to follow the directions provided by DigiCert (CA) via an email to the contact email.

  16. Once the CA has approved your request, they will issue your certificate. Our CDN service will then install it on our network and generate a target CNAMEIdentifies a system-defined CNAME record through which HTTPS requests will be routed. You must update your DNS configuration to point a CNAME record to this target CNAME. for each delivery platform.
  17. Wait 6 hours and then verify that the certificate is live.

    1. Dig the certificate's target CNAME. Note the IP address returned by the dig tool.
    2. Update your hosts file to point the above IP address to a SAN (e.g., common name).
    3. Point your browser to:

      https://SAN/
    4. View the certificate by clicking on the certificate icon that appears in the browser's address bar. Verify that the common name matches the one that you requested.

      If the browser returns an error, then the certificate has not been fully deployed. Please wait a few more minutes and then retry.

Adding SANs to an Existing TLS Certificate

Adding one or more SANs to an existing TLS certificateRefers to a TLS certificate that was deployed via CPS. requires domain control validation.

TLS Certificate Renewals

CPS automatically renews your certificate approximately 60 days prior to expiration when the Auto renew option has been enabled on your certificate request.

Key information:

Customer Origin Configuration

This section only applies if you would like to serve HTTPS traffic from your own web servers. This section is inapplicable when setting up HTTPS delivery for CDN storage or Azure block blob storage.

A customer origin configuration determines the scheme for communication between:

A prerequisite for delivery over HTTPS requires your customer origin to use the HTTPS scheme when serving content to your clients. This is known as client to edge encryption.

You may configure your customer origin to also use the HTTPS scheme when communicating with your web server(s). This is known as end-to-end encryption.

Setting up HTTPS support on your customer origin configuration varies according to whether you are using customer origin groups. Customer origin groups is a new capability. Setup instructions for both customer origin groups and legacy customer origin configurations are provided below.

Edge CNAME Configuration

Create or update an edge CNAME configuration for each Subject Alternative Name (SAN) defined in the certificate (e.g., common name).

To set up an edge CNAME for use with a TLS certificate

  1. Navigate to the Edge CNAMEs page corresponding to the desired platform. ClosedHow?From the main menu, navigate to [HTTP Large, HTTP Small, or ADN] | Edge CNAMEs.

  2. In the New Edge Cname option, type the desired SAN.

    This hostname should be specified in lower-case letters and should not include a protocol (i.e., http://).

  3. In the Points To option, select whether the edge CNAME will point to a customer origin or CDN origin server.
  4. In the Origin Directory option, select one of the following:

    If you point it to a customer origin, then please verify that it has been updated to leverage HTTPS.

  5. Click Add.

Traffic may only be delivered via this edge CNAME configuration once your DNS has been updated. Delivery over HTTPS requires a CNAME record that points a SAN to the certificate's target CNAMEIdentifies a system-defined CNAME record through which HTTPS requests will be routed. You must update your DNS configuration to point a CNAME record to this target CNAME..

Customer-Provided TLS Certificates

The following information is only applicable if you would like to leverage a TLS certificate purchased directly from a CA to serve HTTPS traffic over the CDN. The recommended approach for HTTPS content delivery is to request a TLS certificate via CPS.

A prerequisite for submitting a TLS certificate is to contact your CDN account manager. Your CDN account manager will enable the SSL Certificate Submission page (Tools menu | SSL Certificate Submission). Use this page to submit a TLS certificate by providing the following items:

Item Description

Intermediate Certificate

An intermediate certificate is provided by a CA.

More Information:

An intermediate certificate proves ownership over a public key and establishes a chain of trust through which the requester's device can verify that the TLS certificate can be traced back to a trusted source (i.e., Root CA). In other words, it proves that your chosen CA is trusted by one of the root CAs.

The use of an intermediate certificate is one of the security measures taken by CAs to ensure the integrity of the keys used by root certificates.

Public Key

A certificate containing a public key is provided by a CA. A public key allows a requester to verify the TLS certificate's digital signature.

Private Key

A private key should be stored on the server where the CSR was generated. This private key allows the server to encrypt/decrypt communication with the client.

PEM Format

Please provide certificate and keys in PEM format.

Key information:

To submit a TLS certificate

  1. Gather the following items:

    • Intermediate certificate
    • Public key
    • Private key
  2. Perform the following:

    • Verify that the PEM-encoded public key certificate matches the private key.

      Learn how.

    • Verify that the CA signed the public key certificate.

      Learn how.

  3. Open the intermediate certificate provided by the CA in a text editor.
  4. Navigate to the SSL Certificate Submission page. If this page is unavailable, please contact your CDN account manager. ClosedHow?From the main menu, navigate to Tools | SSL Certificate Submission.

  5. Copy and paste the intermediate certificate into the Intermediate Certificate option.

  6. Open the public key certificate provided by the CA in a text editor.
  7. Copy and paste the public key certificate into the Public Key option.

  8. Open the private key in a text editor.
  9. Copy and paste the private key into the Private Key option.
  10. Click Submit.

To verify that the public key certificate and the private key match

  1. Run the following two OpenSSL commands.

    openssl x509 -noout -modulus -in CertificateName.crtReplace this term with the public key certificate's file name. | openssl md5

    openssl rsa -noout -modulus -in private.keyReplace this term with the private key's file name. | openssl md5

  2. Verify that the above two commands generate the same result.

To verify that the CA signed the public key certificate

Run the following command:

Consider the public key certificate verified when the above command returns OK. All other results indicate that the public key certificate has not been properly signed.

To verify the public key certificate's attributes

Run the following command to verify the certificate's common name and issue\expire

openssl x509 -noout -text -in CertificateName.crtReplace this term with the public key certificate's file name. | grep -E "Subject:" && openssl x509 -noout -text -in CertificateName.crtReplace this term with the public key certificate's file name. | grep -E "Validity" -A 2 && openssl x509 -noout -text -in CertificateName.crtReplace this term with the public key certificate's file name. | grep -E "DNS:" -B 1
More Information