Loading...

CDN.com.tr Help

TLS policy at the edge

The CDN.com.tr edge accepts TLS 1.2 and TLS 1.3 only, with a server-preferred list of ECDHE key exchange and AEAD ciphers. TLS 1.0, TLS 1.1, RC4, 3DES, MD5 and the export ciphers are refused.

TLS policy at the edge

The CDN.com.tr edge accepts TLS 1.2 and TLS 1.3 only, with a server-preferred list of ECDHE key exchange and AEAD ciphers. TLS 1.0, TLS 1.1, RC4, 3DES, MD5 and the export ciphers are refused.

The parts of TLS you do control

The protocol policy is ours; the certificate, and whether browsers may fall back to HTTP, are yours.

Your certificate

Auto SSL

Issue and renew certificates for your hostnames automatically.

Open the topic
No HTTP fallback

Turn on HSTS

Tell browsers never to try plain HTTP for your hostname again.

Open the topic
When it breaks

SSL status and troubleshooting

Reading certificate status when a hostname is not serving HTTPS as expected.

Open the topic

Panel path

  1. Not a panel setting
  2. Edge configuration, applied to every account

Prerequisites

  • A hostname of yours already served by the CDN.
  • openssl on your machine if you want to reproduce the evidence.

Verification

  • openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 — the handshake is refused, reporting no protocols available.
  • openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_3 — the handshake succeeds and reports TLS_AES_256_GCM_SHA384.
  • A client that offers a CBC cipher first still ends up on an AEAD cipher, because selection is server-preferred.

Use cases

A security questionnaire, a tender, or your own scanner asks which TLS versions and ciphers your site accepts. The answer is the same for every account: it is set on the edge and is not a per-account setting.

Workflow

  1. Answer the question from the policy below — it applies to every hostname served by the CDN.
  2. If you need evidence rather than a statement, run the openssl checks in the verification list against your own hostname.
  3. If a client of yours cannot connect, identify its TLS version before assuming a certificate problem.

Checks

  • Accepted: TLS 1.2 and TLS 1.3.
  • Refused: TLS 1.0 and TLS 1.1. A handshake attempt on those versions is closed, not downgraded.
  • Cipher selection is server-preferred: the edge chooses from its own ordered list rather than honouring the client order.
  • The list is ECDHE key exchange with AEAD ciphers. RC4, 3DES, MD5, NULL and the export-grade ciphers are not offered.
  • There is no per-account switch for this. It is not in Delivery Rules and not in SSL Management, because a weaker option for one customer would weaken the shared edge.
  • A very old client that speaks only TLS 1.0 cannot connect. That is the intended outcome of the policy.

Frequently asked questions

Can you enable TLS 1.0 for one legacy client of ours?

No. The protocol list is shared by every site on the edge, so an exception for one account would weaken all of them. TLS 1.0 and 1.1 are deprecated and fail every current compliance baseline — usually the same baseline that made you ask.

Our scanner reports a CBC cipher. Is that a finding?

The offered list keeps a CBC tail after the AEAD ciphers for older clients. Because selection is server-preferred, any modern client negotiates an AEAD cipher — a scanner lists what is offered, not what is used. Check the negotiated cipher of a real connection before treating it as a finding.

Does this depend on my certificate?

No. Protocol versions and ciphers are edge policy; your certificate decides identity, not handshake parameters. An Auto SSL certificate and an uploaded commercial certificate get exactly the same TLS policy.

How do I prove this to an auditor?

Run the two openssl commands in the verification list against your own hostname and attach the output. The TLS 1.1 attempt fails and the TLS 1.3 attempt reports a negotiated AEAD cipher; together they show both halves of the policy.