Even if you are using a CDN, you still need to manage certificates on your origin server (or load balancer). The common rule for CDNs is: if they receive encrypted traffic, they will transmit encrypted traffic to the origin. Fair enough.
While some CDNs offer options to send traffic to a plain HTTP port (like port 80 on Cloudflare or the deprecated “protocol downgrade” on Akamai), this is not recommended. Therefore, your origin server should be configured to handle encrypted HTTPS traffic.
This leads to the next question: which certificate should you use on the origin? One from a commercial provider like DigiCert? A free one from Let’s Encrypt? Or perhaps a self-issued certificate? The answer is that it’s mostly up to you, but security should be the priority.
Let’s look at the options using Akamai as an example.
- The certificate on your origin is issued by a trusted CA. In this case, everything is fine. Akamai will validate the certificate and its chain, and if everything is ok, it will deliver the traffic.
- The certificate on your origin is issued by an untrusted CA. This is where it gets more interesting. Since this Certificate Authority is untrusted, Akamai cannot validate the certificate and will not deliver the traffic. You will receive an error (with a reference ID like 30.xxx).
So, what are your options when using an untrusted CA?
-
Pin the specific certificate. This is straightforward: you instruct Akamai to trust that one specific certificate. However, the more properties and hostnames you manage, the more certificates you need to pin. This approach does not scale well.
-
Trust the Certificate Authority that issued the certificate. This is why this option exists. You can operate your own CA and instruct Akamai to trust any certificate issued by it. Your CA, your rules! It’s quite common for organizations to already have an integrated CA, such as one present in Microsoft AD or hosted within a Kubernetes cluster.
Nevertheless, for demonstration, let’s consider creating a CA and a certificate using OpenSSL, as it’s the most common tool for this task.
A robust CA infrastructure begins with proper key and certificate generation:
# Create CA private key
openssl genrsa -out company-ca.key 4096
# Create a self-signed CA certificate
openssl req -x509 -new -nodes -key company-ca.key \
-sha256 -days 3650 \
-out company-ca.crt \
-subj "/C=US/ST=State/L=City/O=My Organization/CN=My Custom CA"
We won’t delve into each command option here, as you can find detailed explanations in the manual. The result is a certificate and key for our own Certificate Authority, which we will use to sign our web certificates. All you need to do is copy-paste the CA certificate (company-ca.crt, never the private key) to Akamai’s trusted store in your property.
Later, when you need to create a certificate for a specific host, you must generate a private key and a Certificate Signing Request (CSR) for the CA to sign.
# Create client private key
openssl genrsa -out client.key 2048
# Create CSR (Certificate Signing Request)
openssl req -new -key client.key \
-out client.csr \
-subj "/C=US/ST=State/L=City/O=My Organization/CN=test.example.com"
Once the CSR is generated, you can sign it with your CA:
# Sign the client certificate with your CA
openssl x509 -req -in client.csr \
-CA company-ca.crt -CAkey company-ca.key -CAcreateserial \
-out client.crt -days 365 -sha256
Once the certificate is signed and issued you can check it with the next commands:
# Verify client certificate is issued by your CA
openssl verify -CAfile company-ca.crt client.crt
# Check certificate details
openssl x509 -in client.crt -text -noout
That’s it. Because this certificate is signed by your company CA, and that CA is trusted by Akamai, the connection will be validated successfully (unless the certificate has expired).
And some important notes:
Security Considerations:
- Keep your CA private key secure
- Consider certificate revocation (CRL/OCSP)
Akamai:
- You can specify multiple CA certificates in one bundle
Production Recommendations:
- Set appropriate validity periods
- Maintain proper certificate revocation mechanisms
I hope this can help someone