Tarayıcının adres çubuğundaki kilit simgesi aslında perde arkasında işleyen oldukça katmanlı bir güven mekanizmasının görünen yüzü. Bir ziyaretçi sitenize bağlandığında, gönderdiği parola ya da kredi kartı bilgisi sunucuya ulaşana kadar onlarca ağ düğümünden geçer; bu trafiğin okunamaz hale gelmesini sağlayan şey de sunucunuza yüklü olan sertifikadır. Aşağıda bu yapının temelini, kriptografik işleyişini ve pratikte nasıl kurulduğunu adım adım ele alıyoruz.

SSL ve TLS Arasındaki Fark

Günlük konuşmada herkes "SSL" der ama teknik olarak bugün kullandığımız protokolün adı TLS (Transport Layer Security). SSL 3.0 sürümü güvenlik açıkları nedeniyle yıllar önce terk edildi; yerini sırasıyla TLS 1.0, 1.1, 1.2 ve günümüzde tercih edilen TLS 1.3 aldı. Yine de sektörde sertifikalara hâlâ "SSL sertifikası" denmesi yerleşmiş bir alışkanlık. Pratikte siz bir sertifika satın aldığınızda, o sertifika TLS el sıkışmasında kullanılır.

  • SSL: Artık devre dışı bırakılmış eski protokol ailesi; modern sunucularda kapatılması önerilir.
  • TLS 1.2: Hâlâ yaygın, geniş uyumlu ve güvenli kabul edilen sürüm.
  • TLS 1.3: Daha az tur gerektiren el sıkışmasıyla genellikle daha hızlı ve daha sade bir şifre paketine sahip.

Sertifikanın Temel Görevi

Bir TLS sertifikası iki işi aynı anda üstlenir. Birincisi kimlik doğrulama: ziyaretçinin bağlandığı sunucunun gerçekten o alan adına ait olduğunu kanıtlar. İkincisi şifreleme anahtarı paylaşımı: tarafların güvenli bir oturum anahtarı üzerinde anlaşmasını sağlar. Sertifikanın içinde alan adı, geçerlilik tarihleri, sunucunun açık anahtarı ve bunları imzalayan sertifika otoritesinin (CA) bilgisi yer alır.

Bu iki görevin ayrılmaz olması önemli. Yalnızca trafiği şifreleseydiniz, saldırgan araya girip kendi sunucusunu sizinmiş gibi gösterebilir ve veriyi yine de okuyabilirdi. Kimlik doğrulama katmanı, işte tam da bu tür ortadaki adam (man-in-the-middle) saldırılarını engellemek için CA imzasına dayanır. Tarayıcılar, işletim sistemleriyle birlikte gelen güvenilir kök sertifika deposunu temel alarak bir sertifikanın gerçekten yetkili bir otorite tarafından imzalanıp imzalanmadığını saniyeler içinde denetler.

TLS El Sıkışması Adım Adım

Şifreli bir oturum kurulurken yaşanan süreç "handshake" olarak bilinir. TLS 1.2 üzerinden basitleştirilmiş haliyle akış şöyle işler:

  • ClientHello: Tarayıcı desteklediği TLS sürümlerini ve şifre paketlerini sunucuya bildirir.
  • ServerHello ve sertifika: Sunucu uygun şifre paketini seçer ve sertifikasını gönderir.
  • Doğrulama: Tarayıcı, sertifikanın imzasını güvendiği kök CA zincirine kadar takip ederek geçerliliğini sınar.
  • Anahtar değişimi: Çoğu modern yapılandırmada ECDHE kullanılarak her oturum için ayrı bir gizli anahtar üretilir; bu sayede ileri gizlilik (forward secrecy) sağlanır.
  • Finished: Her iki taraf da artık simetrik anahtarla şifreli konuşmaya geçer.

TLS 1.3 bu adımları kısaltır ve el sıkışmayı genellikle tek tur gidiş-dönüşte tamamlar, bu da ilk bağlantı gecikmesini hissedilir biçimde azaltır.

Simetrik mi Asimetrik mi?

İşin can alıcı noktası burası. El sıkışma sırasında asimetrik kriptografi (açık/özel anahtar çifti) kullanılarak taraflar bir sır üzerinde anlaşır. Ardından asıl veri trafiği, çok daha hızlı olan simetrik şifreleme (örneğin AES-256-GCM) ile taşınır. Yani asimetrik yapı yalnızca anahtarı güvenle paylaşmak için kullanılır; veri akışının kendisi simetrik anahtarla şifrelenir çünkü bu yöntem büyük veriyi işlerken çok daha az kaynak tüketir.

Modern donanımlarda AES işlemleri için özel komut setleri (AES-NI) bulunduğundan, simetrik şifrelemenin getirdiği ek yük genellikle gözle görülür bir yavaşlamaya yol açmaz. Asıl maliyet el sıkışma anındaki asimetrik hesaplamalarda yoğunlaşır; bu yüzden oturumların yeniden kullanımı (session resumption) ve TLS 1.3'ün kısaltılmış akışı, yoğun trafik alan sitelerde önemli bir performans kazancı sağlar.

Sertifika Türleri ve Doğrulama Seviyeleri

Tüm sertifikalar aynı düzeyde güven sunmaz. Doğrulama yöntemine ve kapsadıkları alan adına göre kabaca şu gruplara ayrılırlar:

TürDoğrulamaTipik KullanımDüzenlenme Süresi
DV (Domain Validation)Yalnızca alan adı sahipliğiBloglar, kişisel sitelerGenellikle dakikalar
OV (Organization Validation)Şirket kaydı kontrolüKurumsal sitelerÇoğunlukla birkaç gün
EV (Extended Validation)Detaylı kurumsal denetimBanka, e-ticaretYaklaşık birkaç gün
WildcardDV veya OVTüm alt alan adları (*.site.com)Türüne bağlı

Hangi türü seçeceğiniz büyük ölçüde projenizin ölçeğine bağlı. Bireysel bir site için DV fazlasıyla yeterliyken, ödeme alan bir kurumsal yapı için doğrulama düzeyi yüksek bir sertifika daha uygun olur. İhtiyacınıza uygun seçenekleri SSL sertifikaları sayfamızdaki paketleri inceleyerek karşılaştırabilirsiniz.

Sunucuda Kurulum ve Yapılandırma

Bir sertifika kurmadan önce özel anahtarınızı ve sertifika imzalama isteğinizi (CSR) üretmeniz gerekir. OpenSSL ile bu işlem oldukça doğrudandır:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout ornek.com.key \
  -out ornek.com.csr \
  -subj "/C=TR/ST=Istanbul/L=Istanbul/O=Ornek/CN=ornek.com"

Üretilen CSR dosyasını sertifika otoritesine gönderir, karşılığında imzalı sertifikanızı alırsınız. Nginx tarafında sunucu bloğu tipik olarak şöyle yapılandırılır:

server {
    listen 443 ssl;
    server_name ornek.com;

    ssl_certificate     /etc/ssl/certs/ornek.com.crt;
    ssl_certificate_key /etc/ssl/private/ornek.com.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
}

Yapılandırmayı kaydettikten sonra nginx -t ile söz dizimini sınamayı ve ardından systemctl reload nginx ile servisi yeniden yüklemeyi ihmal etmeyin. Kurulumun doğruluğunu komut satırından hızlıca şöyle test edebilirsiniz:

openssl s_client -connect ornek.com:443 -servername ornek.com

Bogahost Önerisi: Sertifikalarınızın süresi dolmadan kesintiye uğramaması için yenilemeyi otomatikleştirin. Let's Encrypt kullanıyorsanız certbot renew komutunu bir cron görevine bağlamak, çoğu durumda manuel takip derdini tamamen ortadan kaldırır.

Sık Karşılaşılan Hatalar

Kurulum sonrası ortaya çıkan sorunların büyük bölümü birkaç tipik nedene dayanır:

  • Eksik ara sertifika: Zincir dosyası (chain/bundle) sunucuya eklenmezse bazı tarayıcılar güven hatası verir.
  • Karışık içerik (mixed content): Sayfa HTTPS üzerinden gelirken görsel veya script'lerin http ile çağrılması kilit simgesini bozar.
  • Alan adı uyuşmazlığı: Sertifika www içermiyorsa ya da yanlış CN ile üretildiyse tarayıcı uyarı gösterir.
  • Süresi dolmuş sertifika: Yenileme atlandığında site tamamen erişilemez hale gelebilir.

Barındırma altyapısı sertifika yönetimini kolaylaştıran panellerle geliyorsa bu hataların çoğu kendiliğinden önlenir; nitekim web hosting paketlerimizde sunduğumuz yönetim araçları kurulum ve yenileme adımlarını büyük ölçüde otomatik hale getirir.

Özetle

Bir sertifika, kimlik doğrulama ile şifrelemeyi tek bir mekanizmada birleştirerek hem ziyaretçinin doğru sunucuya bağlandığını kanıtlar hem de aradaki trafiği okunamaz kılar. Doğru türü seçmek, TLS 1.2 ve 1.3'ü etkinleştirmek, zincir dosyasını eksiksiz yüklemek ve yenilemeyi otomatikleştirmek bu güvenin sürekli kalmasını sağlayan dört temel adımdır. Bu adımları yerine getiren bir site, hem arama motorları hem de kullanıcılar nezdinde güvenilir bir izlenim bırakır.

Reklam Alanı

İçerik Altı (728x90)

Etiketler:
şifreleme web hosting https SSL sertifika güvenlik TLS OpenSSL
İlgili İçerikler

Yorumlar (0)

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Yorum Yap

Maksimum 2000 karakter

İlgili Yazılar