TLS ve SSL: aynı iş, iki isim
TLS (Transport Layer Security), TCP ile HTTP arasında durur ve düz bir bağlantıyı özel bir bağlantıya çevirir. Adres https:// ile başlıyorsa onu güvenli kılan TLS'tir; aynı protokol e-postayı, DNS over TLS'i ve API'lerin çoğunu da korur.
SSL (Secure Sockets Layer) işin başladığı yerdir. Netscape SSL 2.0'ı 1995'te, SSL 3.0'ı 1996'da yayımladı. Protokolü IETF devralınca adı değişti: TLS 1.0 (1999) özünde SSL 3.1'dir. Ardından TLS 1.1 (2006), TLS 1.2 (2008) ve TLS 1.3 (2018) geldi.
SSL'in bütün sürümleri bugün yasaktır. SSL 3.0, 2014'te POODLE saldırısıyla çöktü ve 2015'te resmen yasaklandı; TLS 1.0 ve 1.1 ise tarayıcılar onları çoktan bıraktıktan sonra, 2021'de kullanımdan kaldırıldı. Bugün kullanılan TLS 1.2 ve TLS 1.3'tür.
Eski isim günlük dilde yaşıyor. "SSL sertifikası" denildiğinde kastedilen, TLS sunucusunun sunduğu sertifikadır; ayrı bir SSL sertifikası ve TLS sertifikası yoktur. İkisi de aynı X.509 dosyasıdır ve iki tarafın anlaştığı protokol sürümüyle çalışır. Sertifikanın kendisini arıyorsanız ücretsiz SSL rehberiyle başlayın.
TLS neyi garanti eder, neyi etmez
TLS bir bağlantıya üç özellik kazandırır.
Gizlilik. El sıkışmasından sonraki her şey yalnızca iki ucun bildiği anahtarlarla şifrelenir. Aynı Wi-Fi'daki biri, internet servis sağlayıcısı ya da aradaki bir hat yalnızca şifreli baytlar görür.
Bütünlük. Her kayıt bir doğrulama etiketi taşır. Yolda değiştirilen tek bir bayt bile fark edilir ve bozulmuş veri uygulamaya verilmek yerine bağlantı kapatılır.
Kimlik doğrulama. Sunucu, tarayıcının istediği ad için verilmiş bir sertifikanın özel anahtarına sahip olduğunu kanıtlar. Bir saldırganın sizin yerinize cevap vermesini engelleyen budur. İstemcinin kimliği de karşılıklı TLS (mutual TLS) ile doğrulanabilir, ama açık web'de bu nadirdir.
TLS'in yapmadıkları da bilinmeye değer. Hangi sunucuyla konuştuğunuzu gizlemez: IP adresleri görünür, SNI'daki alan adı da öyle (aşağıda anlatıyoruz). İçeriği güvenli kılmaz: bir SQL enjeksiyonu da giriş formu kadar şifreli gelir, onu durdurmak bir WAF'ın işidir. Ve veriyi yalnızca yolda korur; sunucu veriyi çözdükten sonra TLS'in rolü biter.
TLS 1.2 el sıkışması: iki gidiş-dönüş
HTTP'nin tek baytı gönderilmeden önce tarayıcı ile sunucunun bir sürüm ve şifre takımında anlaşması, sertifikayı kontrol etmesi ve ortak anahtarları türetmesi gerekir. Bu pazarlığa TLS el sıkışması (handshake) denir ve TLS 1.2'de TCP bağlantısının üstüne iki tam gidiş-dönüş sürer.
1. gidiş-dönüş. Tarayıcı ClientHello gönderir: desteklediği sürümler ve şifre takımları, rastgele bir değer ve SNI, ALPN (hangi HTTP sürümünü istediği) gibi uzantılar. Sunucu ServerHello (seçilen sürüm ve şifre), sertifika zinciri ve ECDHE kullanılıyorsa sertifikanın anahtarıyla imzalanmış anahtar değişim payıyla cevap verir.
2. gidiş-dönüş. Tarayıcı sertifikayı kontrol eder, kendi anahtar payını gönderir ve iki taraf aynı oturum anahtarlarını hesaplar. Ardından her biri Finished gönderir: o ana kadar konuşulan her şeyin özeti. Biri el sıkışmasına müdahale ettiyse iş burada patlar.
İlk istek ancak şimdi yola çıkabilir. TCP el sıkışmasını da sayınca TLS 1.2 üzerindeki yeni bir HTTPS bağlantısı, tarayıcı sayfayı isteyebilmeden önce üç gidiş-dönüş harcar. Gidiş-dönüş başına 20 ms'de bunu kimse fark etmez; ziyaretçi ile sunucu arasında 150 ms olan bir mobil bağlantıda bu yarım saniyeye yaklaşır. CDN'lerin TLS'i uzaktaki origin'de değil edge'de sonlandırmasının bir nedeni de budur: el sıkışmasının gerektirdiği gidiş-dönüşler kısalır.
TLS 1.3: tek gidiş-dönüş ve daha az hata payı
TLS 1.3 (RFC 8446, 2018) tek bir gözleme dayanır: tarayıcı tahmin edebilir. Neredeyse her sunucu aynı birkaç anahtar değişim grubunu destekler; bu yüzden tarayıcı anahtar payını sorulmasını beklemeden doğrudan ClientHello'nun içinde gönderir.
Sunucu bir şifre seçer, kendi anahtar payıyla cevap verir ve o andan itibaren iki tarafta da anahtarlar hazırdır. ServerHello'dan sonraki her şey, sertifika dahil, zaten şifrelidir. Tarayıcı sertifikayı kontrol eder, Finished'ı gönderir ve ilk isteğini hemen arkasından yollar: TLS için tek gidiş-dönüş, TCP ile birlikte toplam iki. QUIC'in TLS 1.3'ü kendi el sıkışmasının içinde taşıdığı HTTP/3'te taşıma ve şifreleme birlikte tek gidiş-dönüş sürer.
Tahmin tutmazsa, yani sunucu tarayıcının pay göndermediği bir grup isterse, sunucu HelloRetryRequest ile cevap verir ve el sıkışması bir gidiş-dönüş uzar. X25519'u pratikte her tarayıcı sunduğu için bu nadirdir.
TLS 1.3'ün öbür yarısı, protokolden çıkardıklarıdır.
RSA anahtar değişimi yok. Her el sıkışması geçici (EC)DHE kullanır, yani her bağlantı ileri gizliliğe (forward secrecy) sahiptir: seneye çalınacak bir özel anahtar, bugün kaydedilmiş trafiği çözemez.
Yalnızca AEAD şifreler kaldı: AES-GCM ve ChaCha20-Poly1305. CBC modu, RC4, 3DES, SHA-1 ve MD5 protokolde hiç yok.
Yeniden anlaşma (renegotiation) ve sıkıştırma kaldırıldı, onlarla birlikte koca saldırı aileleri de.
TLS 1.3 ayrıca sürüm düşürmeye karşı koruma taşır: eski bir sürüme itilen TLS 1.3 sunucusu cevabını işaretler, işareti gören TLS 1.3 istemcisi bağlantıyı keser. İki taraf da 1.3 konuşuyorsa 1.3 kullanılır; hatırlanması gereken bir "1.3'ü tercih et" ayarı yoktur.
0-RTT ve oturum devamı: hızlı yol ve bedeli
Daha önce bağlanmış bir ziyaretçinin tam el sıkışmasına ihtiyacı yoktur. TLS 1.3 el sıkışmasının sonunda sunucu tarayıcıya bir oturum bileti (session ticket) verebilir; tarayıcı bir sonraki sefer bu bileti gösterir ve iki taraf sertifikayı ve pahalı anahtar anlaşmasını atlar. Buna oturum devamı (session resumption) denir ve yine bir gidiş-dönüş sürer.
0-RTT (early data) bir adım daha ileri gider. Tarayıcı, biletle birlikte ilk isteğini önceki oturumun anahtarlarıyla şifreler ve ClientHello ile aynı pakette gönderir. Sunucu hemen cevap verebilir; istek hiçbir el sıkışmasını beklemez.
Bedeli tekrar oynatmadır (replay). Early data, sunucu bu bağlantıda henüz tek kelime etmeden gönderilir, yani içinde sunucudan gelen taze hiçbir şey yoktur. Bu ilk paketi kaydeden bir saldırgan onu yeniden gönderebilir ve sunucu geçerli bir isteği iki kez görür. Bir stil dosyasını çeken GET için bu zararsızdır; sipariş veren, para aktaran ya da şifre değiştiren bir POST için değildir. Ayrıca early data ileri gizliliğe sahip değildir: bilet anahtarını sonradan ele geçiren onu çözebilir.
Kurallar buradan çıkar. 0-RTT'yi yalnızca idempotent istekler için kabul edin (yan etkisi olmayan GET ve HEAD). Sunucunun ya da proxy'nin early data isteklerini işaretlemesini sağlayın; RFC 8470'teki Early-Data: 1 başlığı ve 425 Too Early durumu bunun için var, böylece uygulama bu isteklere göre işlem yapmayı reddedebilir. Ve 0-RTT'yi her yerde açılacak bedava bir hızlandırma gibi görmeyin.
CDN.com.tr edge'i 0-RTT early data kabul etmez; tekrar oynatma sorusu uygulamanıza hiç ulaşmaz. Geri dönen ziyaretçi oturumunu tek gidiş-dönüşlük bir TLS el sıkışmasıyla sürdürür.
Sertifikalar ve güven zinciri
Sunucu kimliğini sertifikayla kanıtlar. Sertifika bir açık anahtarı Subject Alternative Name alanında listelenen bir ya da daha fazla alan adına bağlar, bir geçerlilik süresi taşır ve bir sertifika otoritesi (CA) tarafından imzalanır.
Tarayıcılar sizin sertifikanıza doğrudan güvenmez. Güven deposundaki birkaç düzine kök (root) sertifikaya güvenirler ve kökler web sitesi sertifikalarını kendileri imzalamaz: ara (intermediate) sertifikaları imzalarlar, sizinkini de bir ara sertifika imzalar. Tarayıcı sizin sertifikanızdan tanıdığı bir köke kadar bir yol kurmak zorundadır: yaprak (sizin sertifikanız, www.example.com için) → ara sertifika (CA'nın sertifika veren sertifikası) → kök (güven deposunda).
Sunucunun yaprağı ve ara sertifikaları göndermesi beklenir. Ara sertifikayı unutmak klasik bozuk kurulumdur: masaüstü tarayıcılar çoğu zaman yine çalışır, çünkü eksik sertifikayı önbelleğe almışlardır ya da indirebilirler; curl, Android uygulamaları, ödeme callback'leri ve API istemcileri ise "unable to get local issuer certificate" hatasıyla düşer. Bir şey tarayıcınızda çalışıp bir sunucudan çalışmıyorsa önce zincire bakın.
Gerçek bir örnek: 7 Ekim 2026'da cdn.com.tr, YR1 ara sertifikasının imzaladığı bir Let's Encrypt sertifikası sunuyordu; zincir ISRG Root YR'ye çıkıyor ve sunucu Root YR'nin, tarayıcıların yıllardır güvendiği ISRG Root X1 tarafından çapraz imzalanmış kopyasını da gönderiyordu. Yepyeni bir kökün, onu hiç duymamış cihazlarda da çalışmasını sağlayan bu çapraz imzadır.
Geçerlilik süresi. Let's Encrypt sertifikaları 90 gün geçerlidir ve sektörün tamamı aynı yöne gidiyor: CA/Browser Forum'un 2025'te kabul ettiği kurallarla açık bir sertifikanın azami ömrü Mart 2026'da 200 güne indi, 2029'a kadar 47 gün olacak. Yenileme artık yılda bir yapılan bir iş değil, kendi kendine çalışması gereken bir süreç.
DV, OV, EV. Doğrulama seviyesi CA'nın neyi kontrol ettiğini belirler (yalnızca alan adının kontrolünü mü, kurumu da mı), şifrelemenin gücünü değil. Ücretsiz, alan adı doğrulamalı bir sertifika ile pahalı bir EV sertifikası birebir aynı TLS bağlantısını kurar.
SNI nedir? Tek IP'de çok sayıda HTTPS sitesi
İlk HTTPS'in bir tavuk-yumurta sorunu vardı. Sunucu sertifikayı el sıkışması sırasında göstermek zorunda, ama ziyaretçinin istediği alan adı HTTP Host başlığında, yani el sıkışmasından sonra geliyor. Bu yüzden her HTTPS sitesinin kendine ait bir IP adresi olması gerekiyordu.
SNI (Server Name Indication) bu sorunu alan adını ClientHello'nun içine koyarak çözer. Sunucu sertifikayı seçmeden önce onu okur; tek bir adresin her biri kendi sertifikasına sahip binlerce HTTPS sitesini barındırabilmesi böyle mümkün olur. Her CDN ve her paylaşımlı hosting buna dayanır ve son on yılın her tarayıcısı SNI gönderir.
İki sonucunu bilmekte fayda var.
SNI göndermeyen istemci varsayılan sertifikayı alır. Çok eski istemciler, bazı gömülü cihazlar ve sunucu adı vermeden IP adresine bağlanan betikler, sunucunun geri çekildiği sertifikayı alır ve ad uyuşmazlığıyla düşer. openssl ile test ederken -servername vermeyi unutmayın.
SNI şifreli değildir. Alan adı ClientHello içinde düz metin olarak gider; bir ağ sayfayı göremese de hangi siteyi açtığınızı görebilir ve buna göre filtreleyebilir. SNI tabanlı engellemeler böyle çalışır. Bunu gizleyen uzantı Encrypted Client Hello (ECH)'dir ve tarayıcılar onu sunmaya başladı; her yere yayılana kadar alan adının görünür olduğunu varsayın.
Şifre takımları (cipher suite): isimler nasıl okunur
Bir şifre takımı (cipher suite), bağlantının kullandığı algoritmaları adlandırır. TLS 1.2 dört seçimi tek bir isme sığdırır.
ECDHE-RSA-AES128-GCM-SHA256 şu demektir: anahtar değişimi ECDHE (geçici eliptik eğri Diffie-Hellman; ileri gizliliği sağlar), kimlik doğrulama RSA (sertifikanın anahtar türü), toplu şifreleme GCM modunda AES-128 (AEAD bir şifre: şifreleme ve bütünlük tek adımda) ve anahtar türetmek için SHA-256.
TLS 1.3 isimleri daha kısadır, çünkü anahtar değişimi ve imza ayrı ayrı anlaşılır; yalnızca beş takım vardır ve gerçekte üçü kullanılır: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 ve TLS_CHACHA20_POLY1305_SHA256. Hepsi AEAD'dir ve hepsi ileri gizlilikle gelir; ayarlanacak bir şey kalmaz.
İyi bir TLS 1.2 listesinin tepesinde ECDHE anahtar değişimi ve AEAD şifreler bulunur, içinde RC4, 3DES, MD5, NULL ya da EXPORT geçen hiçbir şey olmaz ve seçimi sunucu kendi sırasına göre yapar, istemcinin sırasına uymaz. Eski CBC takımları çok eski istemciler için çoğu zaman listenin sonunda tutulur; seçim sunucudaysa modern bir tarayıcı onlara hiç düşmez. Bir tarama aracı (scanner) sunucunun sunduğu her şeyi listeler; gerçek bir bağlantının neyi kullandığını görmek için anlaşılan takıma, bu rehberin sonundaki komutlarla bakın.
ChaCha20-Poly1305, donanım AES hızlandırması olmayan cihazlar için, çoğunlukla eski telefonlarda yazılımla AES-GCM'den hızlı çalıştığı için vardır.
Sık görülen TLS hataları ve gerçek anlamları
ERR_SSL_PROTOCOL_ERROR (Chrome): el sıkışması tarayıcının sınıflandıramadığı bir şekilde koptu. Olağan nedenler: 443 portunda TLS'ten başka bir şeyin cevap vermesi (düz HTTP, otel ya da kafe giriş sayfası), bağlantıya araya giren bir antivirüs ya da ağ cihazı veya o alan adı için sertifikası olmayan bir sunucu. Önce başka bir ağdan deneyin; yalnızca tek bir ağda oluyorsa sorun sunucuda değildir.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH, Firefox'ta SSL_ERROR_NO_CYPHER_OVERLAP: istemci ile sunucunun ortak bir sürümü ya da şifre takımı yok. Bugün bu neredeyse her zaman bir tarafın çok eski olduğu anlamına gelir; yalnızca TLS 1.0 konuşan gömülü bir cihaz ya da hâlâ ona göre ayarlanmış bir sunucu gibi.
ERR_CERT_COMMON_NAME_INVALID: sertifika açtığınız alan adını listelemiyor. DNS yeni bir alt alan adını henüz onun için sertifikası olmayan bir sunucuya yönlendirdiğinde ya da sertifikada www eksik olduğunda tipiktir.
ERR_CERT_DATE_INVALID: sertifikanın süresi dolmuş ya da ziyaretçinin saati yanlış. Tek bir kişi görüyorsa onun saatine bakın; herkes görüyorsa yenileme durmuştur.
unable to get local issuer certificate (curl, OpenSSL ve pek çok SDK): sunucu ara sertifikasını göndermedi. Zinciri sunucuda düzeltin, istemcinin güven deposunu değil.
Tarayıcıda kilit geçerliyken bir proxy ya da CDN'den 502: ziyaretçinin TLS'i sorunsuzdu, ama proxy'nin origin'inize kurduğu kendi bağlantısı başarısız oldu. Bu, kendi sertifikası ve sürümleri olan ayrı bir el sıkışmasıdır; 502 Bad Gateway rehberi adım adım anlatıyor.
CDN.com.tr TLS'i edge'de nasıl sonlandırır
Siteniz CDN.com.tr arkasındayken ziyaretçinin TLS bağlantısı origin'inizde değil, bir CDN.com.tr edge sunucusunda sonlanır: sertifikanızı edge tutar ve el sıkışmasını edge yapar. Bunu her alan adı için yapar; site başına unutulacak bir ayar yoktur.
Yalnızca TLS 1.2 ve TLS 1.3. TLS 1.0 ve 1.1 el sıkışmasında reddedilir, düşürülmez. Edge şifreyi kendi listesinden seçer; listenin başında ECDHE anahtar değişimi ve AEAD şifreler durur. 7 Ekim 2026'daki testimizde TLS 1.3, X25519 üzerinden TLS_AES_256_GCM_SHA384 ile anlaştı. Politika her hesap için aynıdır; güvenlik anketlerinin sorduğu ayrıntılar TLS politikası sayfasında.
Her sitede HTTP/3. HTTP/3, TLS 1.3'ü içinde taşıyan QUIC üzerinde çalışır. Tarayıcılar onu Alt-Svc başlığından öğrenir ve bir sonraki bağlantıda geçer; açılacak bir şey yoktur. Ayrıntısı HTTP/3 ve IPv6 sayfasında.
Her alan adına kendi sertifikası, SNI ile seçilir. Alan adlarınızın her biri kendi sertifikasıyla sunulur.
Let's Encrypt, sizin yerinize alınır ve yenilenir. Otomatik SSL ile alan adınız doğrulanıp DNS'i bize yönlendiğinde sertifika istenir ve süresinin dolmasına 30 gün kala otomatik yenilenir. Alan adınızın DNS'i CDN.com.tr'deyse sertifika, kök alan adını ve tüm birinci seviye alt alan adlarını kapsayan bir wildcard olabilir; doğrulama bir DNS kaydıyla yapılır. Canlı bir siteyi mi taşıyorsunuz? Kesintisiz sertifika sihirbazı, DNS'i değiştirmeden önce mevcut DNS sağlayıcınızdaki bir TXT kaydıyla bu wildcard'ı çıkarır; HTTPS ilk saniyeden çalışır.
Gerektiğinde kendi sertifikanız. Başka yerden aldığınız bir OV ya da EV sertifika bir alan adına yüklenip bağlanabilir ve birebir aynı TLS politikasını alır.
Origin'inize ayrı bir TLS bağlantısı. Varsayılan olarak HTTPS isteği origin'inizden de HTTPS ile çekilir; edge, origin'inizin HTTPS portuna kendi bağlantısını kurar. Ziyaretçi bu el sıkışmasını hiç görmez; başarısız olursa ziyaretçiye sertifika uyarısı değil 502 döner.
Hazır olduğunuzda HSTS. Her şey HTTPS ile çalışınca HSTS güvenlik ön ayarı tarayıcılara alan adınızda bir daha asla düz HTTP denememelerini söyler.
Herhangi bir sitenin TLS'ini bir dakikada kontrol edin
Beş komut TLS sorularının çoğunu cevaplar: gerçek bir bağlantı hangi sürümü ve şifreyi kullanıyor, sunucu hangi zinciri gönderiyor, sertifika ne zaman bitiyor, eski sürümler reddediliyor mu ve el sıkışması ne kadar sürüyor. www.example.com yerine kendi alan adınızı yazın ve -servername'i silmeyin; o olmadan sizinkini değil, sunucunun varsayılan sertifikasını test edersiniz.
Sürüm, şifre, zincir, bitiş tarihi ve el sıkışması süresi komut satırından
# Anlaşılan sürüm ve şifre takımı
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | grep -E "Protocol|Cipher is"
# Sunucunun gönderdiği zincir: her sertifikanın sahibi (s:) ve imzalayanı (i:)
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9]+ s:|^ *i:"
# Sertifikanın bitiş tarihi
openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -enddate
# TLS 1.1 reddedilmeli (SECLEVEL=0, kendi OpenSSL'inizin önce reddetmesini engeller)
openssl s_client -connect www.example.com:443 -servername www.example.com -tls1_1 -cipher 'DEFAULT:@SECLEVEL=0' </dev/null
# TCP'ye ve TCP + TLS'e giden süre (saniye)
curl -so /dev/null -w 'tcp %{time_connect} tls %{time_appconnect}\n' https://www.example.com/
Sık sorulan sorular
TLS ile SSL aynı şey mi?
TLS, SSL'in halefidir. IETF protokolü 1999'da devralırken adını değiştirdi; TLS 1.0 özünde SSL 3.1'dir. SSL'in bütün sürümleri bugün yasak. "SSL" denildiğinde neredeyse her zaman TLS kastedilir; "SSL sertifikası" da TLS sunucusunun sunduğu sertifikanın yaygın adıdır.
TLS 1.2 hâlâ güvenli mi?
Doğru ayarlandığında evet: ECDHE anahtar değişimi, AES-GCM ya da ChaCha20-Poly1305 gibi AEAD şifreler, RC4, 3DES ve export takımları yok. Sunucular eski istemciler için onu TLS 1.3'ün yanında sunmaya devam ediyor. Kapatılması gerekenler TLS 1.0 ve 1.1.
TLS 1.3 siteyi hızlandırır mı?
Yeni bağlantıları hızlandırır: el sıkışması iki yerine tek gidiş-dönüş sürer, yani her yeni bağlantıda bir ağ gidiş-dönüşü kazanılır; en çok yavaş mobil bağlantılarda hissedilir. Aktarımın kendisini hızlandırmaz; bağlantı açıldıktan sonra TLS 1.2 ve 1.3 veriyi pratikte aynı hızla taşır.
0-RTT'yi açmak güvenli mi?
Yalnızca zarar vermeden tekrarlanabilecek istekler için. 0-RTT verisini yakalayan bir saldırgan onu tekrar oynatabilir; bu yüzden durumu değiştiren bir istek asla early data'dan işlenmemelidir. Kabul eden sunucular onu güvenli metotlarla sınırlamalı ve bu istekleri işaretlemelidir (Early-Data başlığı, 425 durumu). CDN.com.tr edge'i early data kabul etmez.
SNI nedir, başkaları görebilir mi?
Server Name Indication, sunucunun doğru sertifikayı seçebilmesi için tarayıcının el sıkışmasının başında gönderdiği alan adıdır; tek bir IP adresinin çok sayıda HTTPS sitesine hizmet etmesini sağlayan budur. Düz metin olarak gider; ağ hangi siteyi açtığınızı görebilir, ama sayfayı ve içeriğini göremez. Onu gizleyen uzantı Encrypted Client Hello'dur (ECH).
CDN.com.tr hangi TLS sürümlerini destekliyor?
Her alan adında TLS 1.2 ve TLS 1.3, ayrıca her zaman TLS 1.3 kullanan HTTP/3. TLS 1.0 ve 1.1 reddedilir. Politika her hesap için aynıdır; otomatik Let's Encrypt sertifikası mı kullandığınıza yoksa kendi sertifikanızı mı yüklediğinize göre değişmez.
TLS 1.3 için sunucumda bir şey değiştirmem gerekir mi?
Ziyaretçileriniz için hayır. CDN.com.tr arkasında onların el sıkışması edge'de olur; origin'iniz ne çalıştırırsa çalıştırsın TLS 1.3 ve HTTP/3 alırlar. Origin'iniz yalnızca edge'den gelen ayrı bağlantıda yer alır ve orada TLS 1.2 de TLS 1.3 de çalışır.