SNI (Server Name Indication) Nedir?

Tek bir sunucuda onlarca, hatta yüzlerce farklı alan adını HTTPS ile barındırdığınızda ortaya ilginç bir soru çıkar: sunucu, bağlantı henüz kurulurken hangi sitenin sertifikasını sunacağını nereden bilir? Tarayıcı https://ornek1.com ile https://ornek2.com adreslerine aynı IP üzerinden bağlanıyorsa, sunucunun doğru sertifikayı seçebilmesi için tarayıcının hangi alan adını istediğini önceden söylemesi gerekir. İşte bu "önceden söyleme" işini yapan mekanizmanın adı SNI, yani Server Name Indication'dır.

SNI, TLS protokolüne eklenmiş küçük ama kritik bir uzantıdır. İstemci, şifreli oturumu kurmaya başladığı ilk mesajda hedeflediği sunucu adını (host adını) açıkça belirtir; sunucu da bu bilgiye bakarak ilgili sanal sunucunun sertifikasını ve yapılandırmasını devreye sokar. Bu sayede tek bir IPv4 adresi arkasında birbirinden bağımsız yüzlerce güvenli site çalışabilir. Modern paylaşımlı hostingden CDN'lere, load balancer'lardan reverse proxy'lere kadar bugünkü web altyapısının büyük kısmı bu mekanizmaya dayanır. Bu yazıda SNI'nin neden doğduğunu, el sıkışmanın tam olarak hangi anında devreye girdiğini, yapılandırma örneklerini, doğurduğu mahremiyet açığını ve ECH ile gelen çözümü sistem yöneticisi gözüyle anlatacağız.

SNI Neden Doğdu: Tek IP, Çok Site Problemi#

HTTP/1.1 ile birlikte web sunucuları "name-based virtual hosting" kabiliyeti kazandı. Bunun anlamı şuydu: bir sunucu, Host başlığına bakarak aynı IP üzerinde barınan farklı siteleri ayırt edebiliyordu. Tarayıcı isteğin içine Host: ornek1.com yazıyor, sunucu da o başlığa göre doğru içeriği döndürüyordu. Düz HTTP dünyasında bu kusursuz çalışıyordu çünkü Host başlığı, uygulama katmanında, bağlantı zaten kurulduktan sonra gönderiliyordu.

HTTPS devreye girdiğinde denklem bozuldu. TLS el sıkışması, herhangi bir HTTP verisi gönderilmeden önce tamamlanmak zorundadır. Sunucu, sertifikasını el sıkışmanın en başında sunar; ama o an henüz tarayıcının hangi siteyi istediğini gösteren Host başlığı ortada yoktur, çünkü o başlık şifreli tünel kurulduktan sonra gelecektir. Yani bir "yumurta-tavuk" problemi doğar: doğru sertifikayı seçmek için host adını bilmek gerekir, ama host adı ancak sertifika seçildikten sonra öğrenilebilir.

Bu kısır döngünün ilk çözümü kaba kuvvetti: her HTTPS sitesine ayrı bir IP adresi atamak. Sunucu, bağlantının hangi IP'ye geldiğine bakarak sertifikayı seçiyordu. IPv4 adreslerinin bol ve ucuz olduğu dönemde bu işe yaradı. Ancak IPv4 havuzu tükendikçe her siteye ayrı IP ayırmak hem maliyetli hem de sürdürülemez hale geldi. Paylaşımlı hosting sağlayıcıları bir sunucuda binlerce siteyi barındırıyordu; her birine ayrı IP vermek imkânsızdı. SNI tam da bu noktada, "istemci sertifika seçimini kolaylaştırmak için host adını el sıkışmanın başında, açık metin olarak söylesin" fikriyle standartlaştırıldı.

TLS El Sıkışmasında SNI'nin Tam Yeri#

SNI'yi doğru konumlandırmak için TLS el sıkışmasının ilk adımına bakmak gerekir. Bağlantıyı başlatan taraf istemcidir ve gönderdiği ilk mesaj ClientHello'dur. Bu mesaj; desteklenen TLS sürümlerini, şifre paketlerini (cipher suites), rastgele bir sayıyı ve bir dizi uzantıyı taşır. İşte SNI, bu ClientHello mesajının içindeki bir uzantıdır (server_name uzantısı). Yani sunucu adı, oturum daha şifrelenmeden, el sıkışmanın en ilk paketinde açık metin olarak gider.

Akışı adım adım özetleyelim:

İstemci  →  Sunucu : ClientHello  (server_name = "ornek1.com" [açık metin])
Sunucu   →  İstemci : ServerHello + Certificate (ornek1.com sertifikası)
İstemci  →  Sunucu : Key exchange, Finished
Sunucu   →  İstemci : Finished
--- şifreli tünel kuruldu ---
İstemci  →  Sunucu : GET / HTTP/1.1  (Host: ornek1.com [artık şifreli])

Buradaki kilit ayrıntı şu: sunucu, server_name alanını okuduğu anda hangi sanal sunucunun devrede olacağına karar verir ve buna karşılık gelen sertifika zincirini Certificate mesajıyla gönderir. Yani sertifika seçimi tamamen bu uzantıya bağlıdır. SNI olmasaydı, sunucu ancak varsayılan (default) sertifikayı sunabilir, tarayıcı da beklediği alan adıyla eşleşmeyen sertifika yüzünden "sertifika geçersiz" hatası verirdi.

TLS 1.2'de tüm ClientHello açık metin olarak gittiği için SNI'nin de açık gitmesi kimseyi şaşırtmıyordu. TLS 1.3'te el sıkışmanın büyük kısmı daha erken şifrelenmeye başlansa da SNI hâlâ ilk ClientHello içinde, şifresiz kalır. Çünkü sunucunun şifreli anahtar materyalini üretebilmesi için önce hangi sanal sunucu olduğunu bilmesi gerekir. Bu "başlangıçtaki açıklık", ilerideki bölümde ele alacağımız mahremiyet açığının da kaynağıdır.

Sunucu Tarafında SNI Nasıl Yapılandırılır#

SNI'nin güzel yanı, modern web sunucularında ayrı bir düğme açmanıza gerek olmamasıdır; her sanal sunucuya kendi sertifikasını tanımladığınızda mekanizma kendiliğinden çalışır. Nginx tarafında birden çok server bloğu, aynı IP ve portu (443 ssl) dinlese bile server_name yönergesine göre ayrışır:

# Aynı IP, aynı port, iki farklı site — SNI ayırır
server {
    listen 443 ssl;
    server_name ornek1.com www.ornek1.com;

    ssl_certificate     /etc/ssl/ornek1/fullchain.pem;
    ssl_certificate_key /etc/ssl/ornek1/privkey.pem;

    root /var/www/ornek1;
}

server {
    listen 443 ssl;
    server_name ornek2.com www.ornek2.com;

    ssl_certificate     /etc/ssl/ornek2/fullchain.pem;
    ssl_certificate_key /etc/ssl/ornek2/privkey.pem;

    root /var/www/ornek2;
}

Nginx, gelen ClientHello içindeki server_name değeriyle server_name yönergelerini eşleştirir ve doğru ssl_certificate çiftini yükler. Hiçbir eşleşme olmazsa, ilk tanımlanan server bloğu ya da açıkça default_server işaretlenmiş blok devreye girer. Bu yüzden bir "catch-all" varsayılan blok tanımlamak, SNI göndermeyen ya da yanlış host gönderen istemciler için önemlidir.

Apache tarafında da mantık aynıdır; her VirtualHost kendi sertifikasını taşır:

<VirtualHost *:443>
    ServerName ornek1.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/ornek1/cert.pem
    SSLCertificateKeyFile /etc/ssl/ornek1/privkey.pem
    DocumentRoot /var/www/ornek1
</VirtualHost>

<VirtualHost *:443>
    ServerName ornek2.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/ornek2/cert.pem
    SSLCertificateKeyFile /etc/ssl/ornek2/privkey.pem
    DocumentRoot /var/www/ornek2
</VirtualHost>

Bir sanal sunucunun SNI ile doğru sertifikayı sunup sunmadığını openssl ile test edebilirsiniz. -servername parametresi, elle SNI değerini enjekte etmenizi sağlar:

# SNI göndererek doğru sertifikayı iste
openssl s_client -connect 203.0.113.10:443 -servername ornek2.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates

# SNI olmadan bağlan — varsayılan sertifika döner
openssl s_client -connect 203.0.113.10:443 </dev/null 2>/dev/null \
  | openssl x509 -noout -subject

İki komutun döndürdüğü subject alanları farklıysa, sunucunuz SNI'yi doğru şekilde işliyor demektir. Paylaşımlı hosting kullanıyorsanız bu yapılandırma sizin için sağlayıcı tarafından yönetilir; kendi sunucunuzu yönetiyorsanız sunucu yönetimi hizmetiyle bu ayarları güvenli şekilde kurdurabilir, birden fazla sertifikayı tek makinede sorunsuz barındırabilirsiniz.

SNI, SAN ve Wildcard Arasındaki Fark#

SNI'yi çoğu zaman SAN (Subject Alternative Name) ve wildcard sertifikalarla karıştırırlar; oysa üçü farklı katmanlarda çalışır. SNI istemcinin hangi host'u istediğini bildirdiği bir protokol uzantısıdır. SAN ve wildcard ise sertifikanın kaç alan adını kapsadığıyla ilgilidir. Aralarındaki ilişkiyi tabloyla netleştirelim:

Pratikte bu seçenekler bir araya gelir. Tek bir markanın çok sayıda alt alan adı varsa, tek bir wildcard SSL sertifikası tüm alt alanları kapsar ve SNI ile birleşince sade bir kurulum sunar. Birbirinden bağımsız markalara ait siteleri aynı sunucuda barındırıyorsanız, her birine ayrı sertifika tanımlayıp SNI ile ayırmak daha temizdir. SSL sertifikalarının temel kavramlarına hâkim değilseniz önce SSL sertifikası nedir yazısını okumanızı öneririm; SNI'nin sertifika seçimindeki rolü orada anlattığımız doğrulama zinciriyle doğrudan bağlantılıdır.

Buradaki en yaygın hata, "wildcard aldım ama alt alanlarda sertifika hatası alıyorum" senaryosudur. Çoğu zaman sorun sertifikada değil, SNI'de biter: sunucu bloklarınızda server_name yönergesi ilgili alt alanı kapsamıyorsa istek yanlış sanal sunucuya düşer ve orada başka bir sertifika sunulur. Yani sertifikanın kapsamı ile SNI eşleşmesini birlikte kontrol etmek gerekir.

SNI'nin Mahremiyet Açığı#

SNI'nin en tartışmalı yanı, ziyaret ettiğiniz alan adını el sıkışmanın en başında açık metin olarak ağa yaymasıdır. Tünelin içeriği (hangi sayfaları gezdiğiniz, gönderdiğiniz veriler) TLS ile şifrelidir; ama server_name uzantısı şifrelenmeden gittiği için, bağlantı yolundaki herkes — internet servis sağlayıcınız, kurumsal güvenlik duvarı, aynı ağdaki bir dinleyici — hangi siteye bağlandığınızı görebilir. TLS 1.3'e geçmek bu belirli sızıntıyı kapatmaz; çünkü ilk ClientHello, tanım gereği henüz şifrelenmemiştir.

Bunun somut sonuçları var. Bir gözlemci, hedef IP'yi (ki paylaşımlı barındırmada tek başına anlamsızdır) ve DNS sorgularını (DoH/DoT ile şifrelense bile) tam olarak göremese de, SNI sayesinde ziyaret ettiğiniz alan adını net biçimde çözebilir. Bazı ülkelerde ve kurumsal ağlarda içerik filtreleme sistemleri, tam olarak bu açık SNI değerine bakarak belirli alan adlarına erişimi engeller. Yani SNI, hem mahremiyet açısından bir sızıntı noktası hem de sansür/filtreleme için kullanışlı bir kancadır.

Bu durumu bir trafik yakalama örneğiyle görselleştirelim; SNI değeri paketin ilk baytlarında düz metin olarak yakalanır:

# ClientHello içindeki açık SNI değerini yakalamak
sudo tcpdump -i eth0 -A 'tcp port 443' 2>/dev/null | grep -a --line-buffered -o 'ornek[0-9a-z.]*'

Uzun süre "SNI'yi de şifreleyemez miyiz?" sorusu ortada durdu. Cevabın basit olmamasının nedeni, sunucunun doğru sertifikayı seçmek için host adını el sıkışmanın en başında bilmek zorunda olmasıdır. Bu tavuk-yumurta problemini çözmek için art arda iki teknik önerildi: önce ESNI, sonra onun olgunlaşmış hâli olan ECH.

ESNI ve ECH ile Şifreli Sunucu Adı#

İlk deneme ESNI (Encrypted SNI) oldu. Fikir şuydu: sunucu, bir genel anahtarını DNS üzerinden yayımlar; istemci ClientHello içindeki SNI değerini bu anahtarla şifreleyerek gönderir. Böylece yoldaki dinleyici artık düz metin alan adını göremez. ESNI kavramsal olarak doğruydu ama pratikte eksik kaldı: yalnızca server_name alanını şifreliyordu, ClientHello'nun geri kalanını değil; ayrıca bazı sızıntı ve uygulama sorunları vardı. Bu yüzden IETF, ESNI'yi bir taslak olarak bırakıp daha bütünsel bir çözüme yöneldi.

Bu bütünsel çözüm ECH (Encrypted Client Hello) oldu. ECH, yalnızca sunucu adını değil, ClientHello'nun tamamını şifreler. Mekanizma şöyle işler: istemci "outer" (dış) bir ClientHello gönderir; bu dış mesajın SNI değeri gerçek hedefi değil, genel/ortak bir isim (örneğin CDN sağlayıcısının bir "client-facing" alan adıdır). Gerçek hedef alan adı ve el sıkışma detayları ise "inner" (iç) bir ClientHello içinde, sunucunun DNS'te yayımladığı HTTPS/SVCB kaydından alınan genel anahtarla şifrelenir ve dış mesajın içine bir uzantı olarak gömülür. Yoldaki dinleyici yalnızca ortak, jenerik dış ismi görür; gerçek hedef gizli kalır.

ECH'nin çalışması için DNS tarafında yayımlanan bir yapılandırma anahtarına ihtiyaç vardır; bu, yeni tip DNS kayıtlarıyla dağıtılır:

; ECH için istemcinin ihtiyaç duyduğu anahtar HTTPS kaydında yayımlanır
ornek1.com.  3600  IN  HTTPS  1 . alpn="h2,h3" ech="AED+DQBA..."

ECH'nin bir başka önemli bağımlılığı DNS'in kendisinin şifreli olmasıdır. Eğer istemci DNS sorgularını düz metin gönderirse, dinleyici alan adını SNI'den okuyamasa bile DNS sorgusundan çıkarabilir. Bu yüzden ECH, DoH (DNS over HTTPS) veya DoT (DNS over TLS) ile birlikte anlam kazanır. ECH bugün büyük CDN'lerde ve modern tarayıcılarda yaygınlaşmakta; ancak henüz evrensel bir zorunluluk değil. Kendi sunucunuzu yönetiyorsanız ECH desteği için ön yüzünüzdeki reverse proxy'nin ve CDN'in bu özelliği desteklemesi gerekir. Ek güvenlik katmanları için WAF ve DDoS koruma çözümlerini de değerlendirmenizi öneririm; ECH mahremiyeti güçlendirir ama uygulama katmanı saldırılarına karşı ayrı bir savunma gerektirir.

Eski İstemci Uyumluluğu ve Kenar Durumlar#

SNI, 2000'lerin ortasında standartlaşmış olsa da uzun süre eski istemcilerle uyumluluk baş ağrısı yarattı. En bilinen örnek, Windows XP üzerindeki Internet Explorer'dı; bu tarayıcı SNI göndermiyordu. Aynı şekilde çok eski Android sürümleri, bazı gömülü cihazlar ve kütüphaneler de SNI'yi desteklemiyordu. Bu istemciler paylaşımlı bir HTTPS sunucusuna bağlandığında sunucu hangi siteyi istediklerini bilemez ve varsayılan sertifikayı sunardı; sonuç, ziyaretçinin gördüğü "sertifika uyuşmuyor" hatasıydı.

Bugün bu sorun neredeyse tamamen tarihe karışmıştır. Windows XP desteği çoktan bitti, güncel işletim sistemlerinin tamamı ve tüm modern tarayıcılar SNI gönderir. Yine de sunucu yöneticisi olarak iki noktayı akılda tutmakta fayda var. Birincisi, otomatik izleme botları, eski curl/wget sürümleri veya elle yazılmış API istemcileri hâlâ SNI göndermeyi unutabilir; bu yüzden komut satırından bağlantı test ederken -servername bayrağını (openssl) ya da eşdeğerini kullandığınızdan emin olun. İkincisi, IP tabanlı tarama yapan araçlar ya da sağlık kontrolleri SNI göndermediğinden, varsayılan sunucu bloğunuzu bilinçli bir şekilde yapılandırmalısınız.

Kütüphane düzeyinde bir uyarı daha: bazı diller ve HTTP istemcileri, hedefe IP adresiyle bağlandığınızda SNI'yi otomatik olarak eklemez ve doğrulama başarısız olur. Böyle durumlarda host adını açıkça belirtmeniz gerekir. Örneğin bir istemcide SNI'yi elle ayarlamak şu şekilde görünür:

# Bir sağlık kontrolü/monitoring aracında SNI'yi elle vermek
tls:
  server_name: ornek1.com   # IP ile bağlanılsa bile ClientHello'ya bu SNI konur
  insecure_skip_verify: false

Özetle, "SNI göndermeyen istemci" senaryosu bugün olağan trafikte pratikte yok denecek kadar azdır; ama otomasyon, izleme ve eski entegrasyonlarda hâlâ karşınıza çıkabilir. Bir varsayılan sertifika/blok tanımlamak bu kenar durumları zarifçe karşılar. Sitelerinizi taşırken bu tür konuların düşünülmesini istiyorsanız site taşıma ve hosting hizmetlerimizde SNI yapılandırması standart olarak devrededir; ayrı ayrı uğraşmanıza gerek kalmaz.

SNI Sorunlarını Teşhis Etmek#

Sistem yöneticisinin masasına gelen tipik SNI şikâyeti şudur: "Sitem HTTPS'te yanlış sertifikayı gösteriyor" ya da "yeni eklediğim alan adında güvenlik uyarısı çıkıyor." Bu belirtilerin ardındaki kök neden neredeyse her zaman ya eksik bir sunucu bloğu, ya yanlış server_name eşleşmesi, ya da varsayılan sunucuya düşen bir istektir. Teşhis için önce sunucunun gelen SNI değerine hangi sertifikayla yanıt verdiğini net görmek gerekir.

En pratik yöntem yine openssl s_client'tır. Aynı IP'ye farklı SNI değerleriyle bağlanıp dönen sertifikanın subject ve SAN alanlarını karşılaştırın:

# Sorunlu alan adı için dönen sertifikanın kapsadığı isimleri incele
openssl s_client -connect 203.0.113.10:443 -servername yeni.ornek.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName

Dönen sertifikanın subjectAltName listesinde beklediğiniz alan adı yoksa iki ihtimal var: ya o alan adı için bir sunucu bloğu tanımlı değil (ve istek varsayılana düşüyor), ya da sertifika gerçekten o alanı kapsamıyor. Nginx kullanıyorsanız hangi bloğun eşleştiğini nginx -T çıktısında server_name satırlarını tarayarak doğrulayabilirsiniz. Bir başka klasik tuzak, sertifika dosyasını değiştirip servisi yeniden yüklemeyi (reload) unutmaktır; sunucu eski sertifikayı bellekte tutmaya devam eder.

Tarayıcıda "NET::ERR_CERT_COMMON_NAME_INVALID" görüyorsanız bu çoğunlukla saf SNI sorunudur: istek yanlış sanal sunucuya düşmüş ve orada başka bir alanın sertifikası sunulmuştur. CDN ya da load balancer arkasındaysanız, ön yüzün SNI'yi arka uca doğru ilettiğinden emin olun; bazı reverse proxy yapılandırmaları arka uca bağlanırken SNI'yi düşürür ve backend yanlış sertifika döner. Bu senaryoları düzenli izlemek için sitelerinizin durumunu ve sertifika geçerliliğini takip eden araçlar sayfamızdaki yardımcıları kullanabilirsiniz.

Sıkça Sorulan Sorular#

SNI olmadan HTTPS çalışır mı?#

Teknik olarak çalışır, ama önemli bir kısıtla. SNI göndermeyen bir istemci bir sunucuya bağlandığında, sunucu yalnızca varsayılan sertifikayı sunabilir; eğer o sunucuda tek bir HTTPS sitesi barınıyorsa sorun olmaz. Ancak aynı IP üzerinde birden çok site varsa, SNI olmadan sunucu hangi sertifikayı seçeceğini bilemez ve istemci büyük olasılıkla "sertifika alan adıyla eşleşmiyor" hatası alır. Bu yüzden çoklu barındırmada SNI pratikte zorunludur.

SNI ile TLS bağlantısının içeriği güvende mi?#

Evet, bağlantının içeriği tamamen şifrelidir. SNI yalnızca hangi alan adına bağlandığınızı el sıkışmanın başında açık metin olarak ifşa eder; gönderdiğiniz veriler, çerezler, form içerikleri ve ziyaret ettiğiniz sayfalar TLS tüneli içinde şifreli kalır. Yani SNI bir "gizlilik sızıntısıdır" ama "güvenlik açığı" değildir; verilerinizi çalınabilir yapmaz, sadece hedef alan adını gözlemciye gösterir.

ESNI ile ECH arasındaki fark nedir?#

ESNI, yalnızca ClientHello içindeki sunucu adı alanını şifrelemeyi hedefleyen ilk ve artık terk edilmiş bir yaklaşımdı. ECH ise onun olgunlaşmış halefi olup ClientHello'nun tamamını şifreler; gerçek hedef alan adını bir "iç" mesaja koyup jenerik bir "dış" isimle sarmalar. Bugün desteklenmesi gereken standart ECH'dir; ESNI artık üretim ortamlarında kullanılmaz.

ECH kullanmak için sunucumda ne yapmam gerekir?#

ECH, hem sunucu tarafında hem de DNS tarafında koordinasyon gerektirir. Ön yüzünüzdeki web sunucusunun veya CDN'in ECH desteklemesi, DNS bölgenizde ilgili anahtarı taşıyan bir HTTPS/SVCB kaydı yayımlamanız ve istemcilerin şifreli DNS (DoH/DoT) kullanması gerekir. Pratikte çoğu operatör bunu doğrudan ECH destekleyen bir CDN önüne geçerek elde eder; kendi başınıza tüm zinciri kurmak daha ileri düzey bir çalışmadır.

Wildcard sertifikam varken neden hâlâ SNI'ye ihtiyacım var?#

Çünkü wildcard sertifika ile SNI iki farklı işi yapar. Wildcard, tek bir sertifikanın *.ornek.com gibi tüm alt alanları kapsamasını sağlar; SNI ise istemcinin sunucuya hangi host'u istediğini bildirmesini sağlar. Aynı IP'de farklı markalara ait sertifikalar da barındırıyorsanız, sunucunun doğru sertifikayı seçebilmesi için yine SNI şarttır. Wildcard, SNI'nin yerini tutmaz; ikisi birlikte çalışır.

SNI değerini ISP'im veya güvenlik duvarım görebilir mi?#

Klasik TLS'te evet görebilir. SNI, ilk ClientHello içinde açık metin gittiği için bağlantı yolundaki servis sağlayıcılar ve ağ filtreleri hangi alan adına bağlandığınızı okuyabilir; birçok içerik filtreleme sistemi tam da buna dayanır. Bunu engellemenin yolu ECH'dir: ECH etkin bir sunucuya, şifreli DNS ile bağlandığınızda gözlemci yalnızca jenerik dış ismi görür, gerçek hedef alan adı gizli kalır.

Kapanış#

SNI, ilk bakışta protokolün derinlerinde kaybolmuş küçük bir uzantı gibi görünse de bugünkü webin ölçeklenebilirliğini mümkün kılan temel taşlardan biridir. Tek bir IP arkasında yüzlerce güvenli sitenin yaşayabilmesi, istemcinin el sıkışmanın en başında "ben şu alan adını istiyorum" demesi sayesindedir. Bu basit mekanizmayı anlamak, sertifika hatalarını teşhis etmekten ECH ile mahremiyeti güçlendirmeye kadar pek çok konuda size sağlam bir zemin verir. Özetle SNI, doğru sertifikayı doğru siteye ulaştıran görünmez trafik polisidir.

Sitelerinizi tek bir sunucuda güvenle barındırmak, SNI ve sertifika yapılandırmasıyla uğraşmadan HTTPS'i çalışır halde teslim almak istiyorsanız, Clou.TR'nin çözümleri işinizi kolaylaştırır. Çoklu SSL barındırma ihtiyaçlarınız için web hosting ve WordPress hosting paketlerimizde SNI standart olarak devrededir; kendi makinenizi yönetmek istiyorsanız VDS sunucu ve sunucu yönetimi hizmetlerimizle sertifikalarınızı güvenle kurabilir, ücretsiz ve ticari SSL seçeneklerimizle sitelerinizi baştan sona koruma altına alabilirsiniz.