SSL Sertifikası Nedir? HTTPS Nasıl Çalışır?

Bir web sitesi açtığınızda tarayıcının adres çubuğundaki küçük kilit simgesini fark etmişsinizdir. O kilit, sizinle ziyaret ettiğiniz site arasında gidip gelen verinin şifreli taşındığını anlatır ve bu şifrelemenin arkasında SSL/TLS sertifikaları durur. Bu rehberde SSL ile TLS'in ne olduğunu, şifrelemenin ve el sıkışmanın (handshake) nasıl işlediğini, sertifika otoritelerinin (CA) neden gerektiğini, DV/OV/EV ile tekil, wildcard ve çok alan adlı sertifikaların farklarını, HTTP ile HTTPS ayrımını ve bir sertifikanın nasıl alınıp sunucuya kurulacağını adım adım ele alacağız. Konuya tümüyle yabancı olsanız da sonunda kilit simgesinin arkasında neler döndüğünü net biçimde kavrayacaksınız.

SSL ve TLS Nedir?#

SSL (Secure Sockets Layer), iki bilgisayar arasındaki iletişimi şifrelemek için 1990'ların ortasında geliştirilmiş bir protokoldür. Yıllar içinde ortaya çıkan güvenlik açıkları yüzünden yerini kademeli olarak TLS (Transport Layer Security) protokolüne bıraktı. Bugün "SSL sertifikası" dediğimizde teknik olarak neredeyse her zaman TLS'ten söz ediyoruz; "SSL" ismi ise alışkanlıkla yerleşmiş, artık daha çok pazarlama diliyle yaşayan bir terim. Güncel sunucular TLS 1.2 ve TLS 1.3 kullanır; eski SSL 3.0 ile TLS 1.0/1.1 sürümleri artık güvensiz sayılır ve sunucu yapılandırmasından çıkarılması gerekir.

SSL/TLS'in çözdüğü üç temel problem vardır:

• Gizlilik (şifreleme): Aradaki verinin (parolalar, kart numaraları, form içerikleri) yol boyunca üçüncü kişilerce okunamaması.
• Bütünlük: Verinin yolculuğu sırasında değiştirilmediğinin garanti altına alınması; tek bir bitlik oynama bile fark edilir ve bağlantı reddedilir.
• Kimlik doğrulama: Bağlandığınız sunucunun gerçekten iddia ettiği site olduğunun kanıtlanması, yani araya sahte bir kopyanın girmemesi.

Bu üç özellik bir araya geldiğinde "araya girme" (man-in-the-middle) saldırılarını hayli zorlaştırır. Şifreleme, bir sitenin bütünsel güvenliğinin yalnızca bir parçasıdır; daha geniş bir çerçeve için sunucu güvenliği temelleri yazımıza da göz atmanızı öneririz.

Şifreleme Nasıl Çalışır? Simetrik ve Asimetrik#

SSL/TLS'in zekice yanı, iki farklı şifreleme türünü tek akışta birleştirmesidir.

Asimetrik şifreleme, birbirine matematiksel olarak bağlı iki anahtar kullanır: bir açık anahtar (public key) ve bir özel anahtar (private key). Açık anahtarla kilitlenen veri yalnızca eşleşen özel anahtarla açılabilir. Sunucu açık anahtarını isteyen herkese verebilir, ama özel anahtar hiçbir zaman sunucudan ayrılmaz. Bu yöntem çok güvenlidir; buna karşılık işlemci açısından ağırdır ve büyük veriyi bu yolla şifrelemek yavaş kalır.

Simetrik şifreleme ise tek bir ortak anahtar kullanır ve son derece hızlıdır. Tek sorunu şudur: iki tarafın da bu ortak anahtarı bir şekilde, hem de kimseye sızdırmadan paylaşması gerekir. İnternet gibi açık bir ortamda "gizli bir anahtarı güvenle nasıl paylaşırım?" sorusu tam da asimetrik şifrelemenin çözdüğü şeydir.

TLS bu ikisini birleştirir: asimetrik şifrelemeyi yalnızca bir simetrik oturum anahtarı üzerinde güvenle anlaşmak için kullanır, sonrasında asıl trafiğin tamamını hızlı simetrik anahtarla yürütür. Böylece hem asimetrik yöntemin güvenliğinden hem de simetrik yöntemin hızından yararlanılır. Bu anlaşmanın gerçekleştiği kritik an el sıkışmadır.

HTTPS El Sıkışması (Handshake) Adım Adım#

Bir https:// adresine girdiğinizde, tarayıcı ile sunucu veri alışverişine başlamadan önce bir "el sıkışma" gerçekleştirir. Sadeleştirilmiş bir TLS el sıkışması şöyle ilerler:

1. ClientHello: Tarayıcı sunucuya "merhaba" der ve desteklediği TLS sürümlerini, şifreleme yöntemlerini (cipher suite) listeler.
2. ServerHello + Sertifika: Sunucu ortak bir yöntemde karar kılar ve SSL sertifikasını gönderir. Sertifikanın içinde sunucunun açık anahtarı ile onu imzalayan sertifika otoritesinin (CA) imzası yer alır.
3. Sertifika doğrulama: Tarayıcı, sertifikayı güvenilir bir CA'nın imzalayıp imzalamadığını, adres çubuğundaki alan adına uyup uymadığını ve süresinin geçip geçmediğini denetler. Bir aksaklık varsa meşhur "bağlantınız gizli değil" uyarısı belirir.
4. Anahtar paylaşımı: Taraflar, asimetrik şifrelemenin gücünden yararlanarak ortak bir oturum anahtarı (simetrik) üzerinde uzlaşır. TLS 1.3'te bu adım hem daha az tur gezerek hem de "forward secrecy" (ileriye dönük gizlilik) sağlayacak biçimde tasarlanmıştır; yani sunucunun özel anahtarı ileride ele geçse bile geçmişte kaydedilmiş trafik geriye dönük olarak çözülemez.
5. Şifreli iletişim: El sıkışma tamamlanır ve bu noktadan sonra tüm HTTP trafiği ortak simetrik oturum anahtarıyla şifrelenir.

Tüm bu akış, göz açıp kapayana kadar, arka planda tamamlanır. TLS 1.3 el sıkışmayı gözle görülür biçimde hızlandırdığı için sunucunuzun TLS 1.3'ü desteklemesi hem güvenlik hem de performans açısından kayda değer bir kazanç sağlar.

Sertifika Otoritesi (CA) Nedir?#

Bir sertifikanın "güvenilir" sayılmasının arkasında sertifika otoritesi (Certificate Authority - CA) denen kuruluşlar vardır. CA, bir alan adının gerçekten başvuran kişiye veya kuruma ait olduğunu doğrular, ardından sertifikayı kendi dijital imzasıyla mühürler. Tarayıcılar ile işletim sistemleri, güvendikleri CA'ların listesini (kök sertifikalar / root store) fabrika ayarı olarak zaten içlerinde taşır.

Güven zinciri şöyle örülür: Sizin sertifikanız bir ara sertifika (intermediate) tarafından, o ara sertifika da CA'nın kök sertifikası (root) tarafından imzalanır. Tarayıcı bu zinciri kök sertifikaya kadar sorunsuz izleyebilirse sertifikanıza güvenir. İşte bu yüzden sunucunuza yalnızca kendi sertifikanızı değil, ara sertifikaları da (tam zincir / fullchain) yüklemeniz gerekir; aksi hâlde bazı tarayıcılar ve özellikle mobil cihazlar "sertifika zinciri eksik" hatası verir.

İpucu: Sertifika zincirinizin eksiksiz sunulup sunulmadığını openssl s_client -connect alanadiniz.com:443 -showcerts komutuyla ya da çevrimiçi bir SSL test aracıyla doğrulayabilirsiniz. Çıktıda ara sertifikayı da görüyorsanız zincir tamamdır.

Yaygın CA örnekleri arasında Let's Encrypt (ücretsiz ve otomatik), DigiCert, Sectigo ve GlobalSign sayılabilir. Bir alan adının hangi CA'lardan sertifika alabileceğini bir CAA DNS kaydıyla sınırlayarak izinsiz sertifika verilmesini de engelleyebilirsiniz. Ücretsiz seçenekler için Let's Encrypt ile ücretsiz SSL rehberimizi inceleyebilirsiniz.

Sertifika Doğrulama Tipleri: DV, OV, EV#

Sertifikalar, CA'nın başvuru sahibinin kimliğini ne kadar derin doğruladığına göre üç gruba ayrılır. Önemli bir nokta: şifreleme gücü üçünde de birebir aynıdır; aradaki tek fark kimlik doğrulama seviyesidir. Yani daha pahalı bir sertifika "daha güçlü şifreleme" anlamına gelmez.

• DV, en yaygın ve en hızlı tiptir. CA yalnızca alan adının sizin kontrolünüzde olduğunu (bir DNS kaydı ekleyerek ya da sunucuya bir dosya koyarak) doğrular. Let's Encrypt sertifikaları da DV kapsamındadır.
• OV, alan adına ek olarak arkasındaki şirketin gerçek bir tüzel kişilik olduğunu doğrular. Sertifika detaylarına bakıldığında şirket adı görünür.
• EV, en kapsamlı incelemeyi gerektirir. Vaktiyle tarayıcı çubuğunu yeşile boyayıp şirket adını gösterirdi; ne var ki günümüz tarayıcıları bu görsel ayrımı büyük ölçüde kaldırdı, dolayısıyla EV'nin eski "güven rozeti" etkisi bugün oldukça sönük kaldı.

Pratikte çoğu web sitesi için DV fazlasıyla yeterlidir. Ödeme alan veya hassas veri toplayan büyük kurumlar OV/EV'yi tercih edebilir; ancak bu teknik bir zorunluluk değil, daha çok kurumsal bir tercihtir, çünkü sağladıkları şifreleme aynıdır.

Kapsam Tipleri: Tekil, Wildcard ve Multi-Domain#

Doğrulama tipinden tamamen bağımsız olarak sertifikalar, kaç alan adını kapsadıklarına göre de üçe ayrışır:

• Tekil (Single-Domain): Yalnızca tek bir alan adını kapsar, örneğin clou.tr. Çoğu CA, ana adı ve onun www sürümünü birlikte kapsayacak biçimde sertifika verir; yani clou.tr ile www.clou.tr tek sertifikada geçerli olur.
• Wildcard: Bir alan adının belirli bir seviyedeki tüm alt alan adlarını kapsar. *.clou.tr sertifikası blog.clou.tr, mail.clou.tr, panel.clou.tr gibi tek seviyeli tüm alt alanlar için geçerlidir; ancak a.b.clou.tr gibi iki seviye aşağıdaki adları kapsamaz. Çok sayıda alt alan kullanan projeler için idealdir.
• Multi-Domain (SAN/UCC): Tek bir sertifikada birbirinden bağımsız birden fazla alan adını kapsar, örneğin clou.tr, cloud-tr.com ve ornek.net. Bu adların tümü sertifikanın "Subject Alternative Name" (SAN) alanında listelenir.

Hangi tipe ihtiyaç duyacağınız tümüyle mimarinize bağlıdır. Tek bir site için tekil sertifika, çok sayıda alt alan için wildcard, farklı markaları veya alan adlarını tek yerden yönetmek için multi-domain akla yatkındır. SSL çözümlerimiz bu tiplerin hepsini kapsar.

HTTP ve HTTPS Farkı#

HTTP (HyperText Transfer Protocol), verinin düz metin olarak taşındığı klasik protokoldür. Aynı ağa bağlı biri ya da kötü niyetli bir ara nokta, HTTP trafiğini olduğu gibi okuyabilir. HTTPS ise aynı protokolün TLS ile şifrelenmiş sürümüdür; sonundaki "S" harfi "Secure" (güvenli) kelimesinden gelir. Ayrıştıkları noktalardan biri de port numaralarıdır: HTTP 80 numaralı portu, HTTPS ise 443 numaralı portu kullanır.

Bir sertifika kurduktan sonra tüm HTTP trafiğini kalıcı olarak HTTPS'e yönlendirmeniz şiddetle önerilir. Nginx üzerinde tipik bir yönlendirme şöyle görünür:

# HTTP isteklerini HTTPS'e zorla
server {
    listen 80;
    server_name clou.tr www.clou.tr;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name clou.tr www.clou.tr;

    ssl_certificate     /etc/ssl/certs/fullchain.pem;
    ssl_certificate_key /etc/ssl/private/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;

    # ... diğer ayarlar
}

Buna ek olarak HSTS (HTTP Strict Transport Security) başlığını göndererek tarayıcılara "bundan sonra bu siteye her zaman HTTPS ile bağlan" talimatını verebilir, hatta kullanıcının yazdığı ilk isteği bile HTTP'ye düşmeden güvence altına alabilirsiniz:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Bu başlığı yalnızca HTTPS düzgün çalıştıktan sonra eklemeye dikkat edin; çünkü tarayıcı max-age süresince siteye HTTP ile bağlanmayı reddedecektir.

SSL'in SEO ve Güven Üzerindeki Etkisi#

HTTPS artık salt bir güvenlik konusu değil, aynı zamanda itibar ve görünürlük meselesidir:

• Tarayıcı uyarıları: Modern tarayıcılar HTTPS'siz sayfalarda, özellikle bir form veya parola alanı varsa, belirgin bir "Güvenli değil" ibaresi gösterir. Bu ibare, ziyaretçilerin çoğunu daha ilk saniyede kaçırır.
• SEO sinyali: Google, HTTPS'i uzun yıllardır hafif bir sıralama sinyali olarak kabul ediyor. Tek başına belirleyici değildir; ama iki site diğer her açıdan eşitse HTTPS kullananın az da olsa avantajı olur.
• Dönüşüm ve güven: Adres çubuğundaki kilit, kullanıcıya kart bilgisini veya parolasını içi rahat girebileceği hissini verir; e-ticarette bu duygu doğrudan dönüşüme yansır.
• Modern özellikler: HTTP/2 ve HTTP/3 gibi ciddi hız kazandıran protokoller pratikte yalnızca HTTPS üzerinden çalışır; yani SSL, performans tarafında da yeni kapılar açar.

Kısacası bugün bir web sitesi için SSL, tercihe bağlı bir "artı özellik" değil, temel bir gerekliliktir.

Sertifika Nasıl Alınır ve Kurulur?#

Süreç seçtiğiniz sertifika tipine göre ayrıntıda değişir, ama genel akış hemen her durumda aynıdır:

1. Özel anahtar ve CSR üretin. Önce sunucunuzda bir özel anahtar ve buna bağlı bir CSR (Certificate Signing Request) oluşturursunuz:

   openssl req -new -newkey rsa:2048 -nodes \
     -keyout clou.tr.key -out clou.tr.csr
   

   Burada .key dosyası özel anahtarınızdır ve asla kimseyle paylaşılmamalıdır; .csr ise CA'ya ileteceğiniz imza talebidir. Sızan bir özel anahtar, sertifikanızın güvenliğini tümüyle geçersiz kılar.

2. CA'ya başvurun ve doğrulamayı geçin. DV için alan adı sahipliğini bir DNS kaydı ya da sunucuya konan bir dosya ile kanıtlarsınız; OV/EV içinse şirketinize dair ek belgeler istenir.

3. Sertifikayı kurun. CA size sertifikanızı ve ara sertifikaları gönderir. Bunları tam zincir (fullchain) hâline getirip web sunucunuzda tanımlarsınız; yukarıdaki Nginx örneğindeki ssl_certificate satırı tam olarak bunu yapar.

Ücretsiz ve otomatik bir yol tercih ederseniz Let's Encrypt ve certbot aracı bu adımların neredeyse tamamını sizin yerinize halleder:

# Ubuntu üzerinde Certbot ile otomatik SSL
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d clou.tr -d www.clou.tr

Certbot sertifikayı sizin adınıza alır, Nginx yapılandırmasını gerekli yerlerden düzenler ve yenilemeyi otomatik olarak zamanlar. Kendi VDS veya sanal sunucunuzu yönettiğiniz durumlarda bu yaklaşım oldukça pratiktir. Yönetilen hosting paketlerinde ise SSL çoğunlukla panel üzerinden tek tıkla, hatta çoğu zaman siz hiç uğraşmadan otomatik olarak devreye girer.

Sıkça Sorulan Sorular#

SSL ile TLS aynı şey mi?#

Teknik olarak aynı değildir; TLS, SSL'in güncel ve güvenli halefidir. Ancak "SSL sertifikası" ifadesi sektörde öyle yerleşmiştir ki TLS'i kastederken bile herkes bu adı kullanır. Sonuç olarak bugün kurduğunuz her "SSL sertifikası" aslında TLS üzerinden çalışır.

Ücretsiz SSL güvenilir mi, ücretli olandan farkı var mı?#

Let's Encrypt gibi ücretsiz DV sertifikaları, ücretli DV sertifikalarıyla birebir aynı şifreleme gücünü ve tarayıcı uyumluluğunu sunar. Aradaki fark şifrelemede değil; doğrulama seviyesinde (OV/EV), sunulan garanti tutarında, teknik destekte ve sertifika ömründedir. Çoğu site için ücretsiz DV fazlasıyla yeterlidir; ayrıntılar için Let's Encrypt rehberimize bakabilirsiniz.

Wildcard sertifika mı yoksa çok sayıda tekil sertifika mı almalıyım?#

Çok sayıda alt alan adınız (blog., shop., panel. gibi) varsa ve bunlar zaman içinde artıyorsa, wildcard hepsini tek sertifikada kapsar ve yönetimi ciddi biçimde kolaylaştırır. Yalnızca birkaç sabit adresiniz varsa tekil ya da multi-domain sertifika daha ekonomik bir seçim olabilir.

Sertifikamın süresi doldu, sitem çalışmaya devam eder mi?#

Site sunucu tarafında teknik olarak ayakta kalır; ancak tarayıcı süresi dolmuş sertifikayı gördüğünde tam ekran bir güvenlik uyarısı gösterir ve ziyaretçilerin çoğu bu ekranı görünce geri döner. Pratikte bu, sitenizin erişilemez hâle gelmesi demektir. Bu yüzden yenilemeyi otomatikleştirmek (örneğin Certbot ile) en sağlıklı yoldur.

"Bağlantınız gizli değil" hatasının sebebi ne olabilir?#

En sık karşılaşılan nedenler; sertifikanın süresinin dolması, alan adıyla uyuşmaması (örneğin www sürümünün kapsanmaması), ara sertifikaların eksik kurulması ya da sunucunun sistem saatinin yanlış olmasıdır. Özellikle ara sertifika eksikliğini openssl s_client çıktısını inceleyerek veya bir SSL test aracıyla dakikalar içinde tespit edebilirsiniz.

SSL kurunca sitem otomatik olarak HTTPS'e geçer mi?#

Hayır; sertifikayı kurmak tek başına yeterli değildir. HTTP isteklerini HTTPS'e yönlendirmeniz (301 redirect) ve ideal olarak HSTS başlığını eklemeniz gerekir. Aksi hâlde siteniz hem HTTP hem HTTPS üzerinden erişilebilir kalır, bu da hem güvenlik hem de SEO açısından istenmeyen bir durumdur.

RSA yerine ECDSA sertifikası kullanmalı mıyım?#

ECDSA anahtarları, RSA ile aynı güvenlik seviyesini çok daha kısa anahtar boyuyla sağlar; bu da el sıkışmayı biraz hızlandırır ve sunucu yükünü azaltır. Modern tarayıcıların hepsi ECDSA'yı destekler. Yine de RSA 2048-bit hâlâ son derece yaygın ve güvenli bir seçimdir; çok eski istemcilerle uyum sizin için kritikse RSA tarafında kalmak da makuldür.

SSL, bugün her web sitesinin temel güvenlik katmanıdır ve kurulumu sandığınızdan çok daha kolaydır. İster otomatik yenilenen ücretsiz bir sertifikayla başlayın ister kurumsal bir çözüme geçin, esas mesele trafiğinizi baştan sona şifreli tutmaktır. Kendi sunucunuzda hızlıca SSL yapılandırmak ya da doğru sertifika tipini seçmek için SSL çözümlerimize göz atabilir, elini taşın altına sokmadan yönetilen bir kurulum isterseniz hosting paketlerimizi inceleyebilirsiniz.