This article is for customers who want to optionally self-manage the ECDN DNS domain and SSL certificates.

For secure delivery of video streams, all communications to the ECDN servers happens over HTTPS. ECDN servers are given unique fully qualified domain names (FQDN). SSL certificate for the domain name is installed in the servers. DNS server entries are created so that ECDN server's FQDNs resolve to local IP address in your internal network. When player uses URLs containing the FQDNs of the ECDN servers, all these settings are used to resolve them to the specific ECDN server instance for secure content downloads.

For managing the ECDN server DNS domain, there are two options:

1) IBM Cloud Video managed

  • This options requires no further action from you as all aspects are managed by IBM.
  • Your ECDN account will be assigned a unique domain name <yourCompanyName>.deepcaching.net.
  • We will order the SSL wildcard certificate from a registered SSL Certificate Authority, for the domain *.yourCompanyName.deepcaching.net.
  • We will store the SSL certificate private key in your ECDN account, so that when new ECDN server instances are created, the SSL certificate private keys are also copied to the server.
  • We will create entries in the DNS servers for each ECDN server instance you define in the ECDN portal.
  • We will manage the SSL certificates in terms of tracking the expiry, renewals and updates on the servers.
  • We will also manage the DNS server entries in terms of keeping them in sync with any name changes you make in the ECDN portal.

2) Self-managed by customers

  • See below for details on what actions you need to take.
  • This option is for those customers who need to meet their corporate standards on how servers are named on their internal network.
  • We will configure your ECDN account with your company's DNS domain name, and ECDN servers will be named *.yourCompanyDomainName.
  • You will be responsible for buying the SSL certificate for this DNS domain, tracking its expiry and renewals.
  • You will need to manually copy the SSL certificate private files in a designated location on the ECDN server instance (see details below).
  • You will create DNS entries in your local DNS server to resolve the FQDNs of the ECDN server instances to their local IP address.

Video delivery via ECDN servers will be disrupted when any of the following happens:

  • SSL certificates are not issued by a registered SSL Certificate Authority.
  • There is a mismatch in the SSL certificate domain name and domain name registered in your ECDN account.
  • SSL certificate has expired.
  • SSL certificate private key files are not in the specified format.
  • SSL certificate is not installed in the designated location.
  • DNS server entries are not updated to match the names assigned to each ECDN server instance in the ECDN portal.

Any of these SSL certificate issues will usually result in viewers seeing a warning message in their browsers during playback.

Actions needed for self-managed ECDN DNS domains

Overview of installation steps

  • Define and create ECDN server instance - follow steps here: http://ibm .biz/cloud-video-ecdn-getting-started.
  • After ECDN VMs are installed, remember to log into each of them and change the default password to what you generally use in production.
  • Copy the SSL certs to these ECDN servers, and restart Nginx.
  • Run https://<ecdn-server-fqdn>/ping" to validate the SSL certs are working properly. If you get "PONG" response - all is good.

Access to SSL certificate for ECDN servers

Contact your local IT support team and request them to generate the SSL certificate for your ECDN servers. Most companies centralize SSL certificate management to a team with elevated privileges. This request may take several days to complete, and usually involves:

  • Purchasing a SSL certificate from a registered SSL Certificate Authority (CA). Most offer a 1-year or 2-year SSL certificate. Follow your company's guidelines. 2-year wildcard SSL certificates for your ECDN DNS domain usually makes management easier.
  • Generating a SSL certificate signing request (CSR). This step will generate a public and private key. The private key must be kept securely.
  • Getting your SSL certificate signed by the CA. Against the certificate purchase order, you will upload the certificate CSR file to the CA website. CA will validate your domain ownership details, and then alert you when your signed certificate is ready for download.
  • When ready, you should request the signed certificate to be given to you in PEM format (http://how2ssl.com/articles/working_with_pem_files/). You will also need the certificate private key file.

Preparing SSL certificate files before copying to ECDN servers

You will need the signed certificate in two separate files (text files):

  • Certificate private key file - (*.key)
  • Signed certificate file - (*.crt)

The text files must have unix LF line terminator. In VIM, you can open the file and enter :set ff=unix and save it to convert to this format.

You will get the certificate private key file from your IT team. This was generated when the certificate signing request was first created. Example: cert-private.key.

The signed certificate file (*.crt) is what you get from the CA site after they have completed the signing process. This .crt file should contain both your domain signed certificate and the signatures of all the intermediate certificate authorities.

If you did not get a combined .crt file, you can create combine them yourself, by just concatenating them in a text editor. On a linux system you can run:

cat myDomain.crt intermediateCA.crt > cert-combined.crt

At the end of this preparation step, you should have two text files:

cert-private.key
cert-combined.crt

You are now ready to copy these files to the ECDN servers.

Copy certificate files to ECDN server instances

Upload the two files to ECDN server to the home directory of ecdn account.

scp -p cert-private.key cert-combined.crt ecdn@ecdnserverfqdn:

 

SSH to the ECDN server.

ssh ecdn@ecdnserverfqdn

 

Verify that symlinks for the following files are present:

ls -l /etc/ssl/ecdn-box.*
lrwxrwxrwx 1 root root 34 Jan  4 18:13 /etc/ssl/ecdn-box.crt -> /var/lib/ecdn-box/ssl/ecdn-box.crt
lrwxrwxrwx 1 root root 34 Jan  4 18:13 /etc/ssl/ecdn-box.key -> /var/lib/ecdn-box/ssl/ecdn-box.key

 

Delete the symlinks, and confirm they were deleted:

sudo rm /etc/ssl/ecdn-box.*
ls -l /etc/ssl/ecdn-box.*
ls: cannot access '/etc/ssl/ecdn-box.*': No such file or directory

 

Copy the new certificate files. Verify.

sudo mv ~ecdn/cert-combined.crt /etc/ssl/ecdn-box.crt
sudo mv ~ecdn/cert-private.key /etc/ssl/ecdn-box.key
ls -l /etc/ssl/ecdn-box.*
-rw-r--r-- 1 root root 4030 Jan 10 11:51 /etc/ssl/ecdn-box.crt
-rw-r--r-- 1 root root 3242 Jan 10 11:51 /etc/ssl/ecdn-box.key

 

Restart nginx service to load the certificates:

sudo systemctl restart nginx

 

Run the following command to verify that the ECDN server is encrypting the traffic.

curl -v https://yourECDNserverFQDN/ping

Following line in the output will indicate everything is okay:

server certificate verification OK

Response should be:

pong

 

Validate using a browser on your workstation. In your browser invoke: https://yourECDNserverFQDN/ping

You should see a "green" padlock icon in the URL address bar. This indicates the browser received a valid SSL certificate from the ECDN server. This completes the setup process for this ECDN server instance.

Repeat these steps to copy the certificate files to all the remaining ECDN server instances.

Powered by Zendesk