Sertifika Otoritesi (CA), Sertifika Depoları ve HTTPS Proxy
Bölüm 1 – HTTPS, Dijital Sertifikalar ve Güven Zincirinin Temelleri
Giriş
İnternetin ilk yıllarında web sitelerinin büyük bölümü HTTP (HyperText Transfer Protocol) protokolünü kullanıyordu. HTTP, istemci (web tarayıcısı) ile sunucu arasındaki iletişimi sağlayan temel protokoldür. Ancak bu protokol tasarlanırken güvenlik ikinci plandaydı. Amaç, bilgisayarların birbirleriyle hızlı ve kolay haberleşmesini sağlamaktı.
HTTP üzerinden gönderilen tüm bilgiler düz metin (plain text) olarak iletilir. Ağ üzerinde bulunan herhangi bir kişi veya cihaz, uygun araçları kullanarak bu trafiği okuyabilir.
Örneğin bir kullanıcı aşağıdaki bilgileri HTTP kullanan bir web sitesine gönderdiğinde:
Kullanıcı adı
Parola
Kredi kartı bilgileri
Kimlik numarası
E-posta içeriği
Dosyalar
bu verilerin tamamı ağ üzerinde okunabilir durumdadır.
Bir saldırgan aynı kablosuz ağa bağlıysa veya ağ trafiğini dinleyebiliyorsa, Wireshark, tcpdump gibi araçlarla bu bilgileri görebilir.
Bu durum özellikle aşağıdaki ortamlarda ciddi güvenlik riski oluşturur:
Açık Wi-Fi ağları
Kafeler
Havalimanları
Üniversiteler
Oteller
İnternet kafeler
Kurumsal ağlar
İşte HTTPS'in geliştirilmesinin temel nedeni budur.
HTTP Neden Güvenli Değildir?
HTTP'nin üç temel güvenlik eksikliği vardır.
1. Gizlilik (Confidentiality) Yoktur
Gönderilen veriler şifrelenmez.
Örneğin kullanıcı aşağıdaki isteği gönderdiğinde:
POST /login HTTP/1.1
Bu paket ağ üzerinde aynen görülebilir.
Bir saldırgan şu bilgileri kolayca elde edebilir:
username=nuri
Şifreleme olmadığı için paketleri okumak son derece kolaydır.
2. Veri Bütünlüğü (Integrity) Yoktur
İletim sırasında veriler değiştirilebilir.
Örneğin kullanıcı:
100 TL
gönderdiğini düşünür.
Saldırgan bunu
10000 TL
olarak değiştirebilir.
Alıcı taraf bunun değiştirildiğini anlayamaz.
3. Kimlik Doğrulama (Authentication) Yoktur
Kullanıcı gerçekten bankaya mı bağlandı?
Yoksa saldırganın hazırladığı sahte siteye mi?
HTTP bunu doğrulayamaz.
Dolayısıyla kullanıcı:
www.bankam.com
yerine
www.bankam-secure.com
gibi sahte bir siteye yönlendirilmiş olabilir.
HTTPS Nedir?
HTTPS, HTTP'nin güvenli sürümüdür.
HTTPS;
HTTP + TLS (eski adıyla SSL)
şeklinde düşünülebilir.
Buradaki S, Secure (Güvenli) anlamına gelir.
HTTPS üç önemli güvenlik özelliği sağlar:
Gizlilik (Confidentiality)
Bütünlük (Integrity)
Kimlik Doğrulama (Authentication)
Bu üç özellik modern internet güvenliğinin temelini oluşturur.
HTTPS Nasıl Çalışır?
Bir kullanıcı tarayıcısına şu adresi yazdığında:
https://www.example.com
arka planda şu işlemler gerçekleşir:
Tarayıcı
Sunucu cevap verir:
Server Hello
Ardından sertifikasını gönderir.
Certificate
Tarayıcı bu sertifikayı incelemeye başlar.
Kontrol edilen bilgiler şunlardır:
Sertifika geçerli mi?
Süresi dolmuş mu?
Alan adı doğru mu?
Kim imzaladı?
İmzalayan kuruma güveniliyor mu?
Eğer bütün kontroller başarılı olursa ortak bir oturum anahtarı oluşturulur.
Sonrasında tüm trafik AES gibi simetrik algoritmalarla şifrelenir.
SSL ve TLS
Birçok kişi SSL ve TLS ifadelerini aynı anlamda kullanır.
Aslında günümüzde kullanılan protokol SSL değildir.
Tarihsel gelişim şöyledir:
| Protokol | Durumu |
|---|---|
| SSL 2.0 | Güvensiz |
| SSL 3.0 | Kullanımdan kaldırıldı |
| TLS 1.0 | Eski |
| TLS 1.1 | Eski |
| TLS 1.2 | Yaygın |
| TLS 1.3 | Güncel |
Bugün modern tarayıcılar çoğunlukla TLS 1.3 kullanmaktadır.
HTTPS'in En Önemli Bileşeni: Dijital Sertifika
HTTPS'in güvenliği tamamen dijital sertifikalara dayanır.
Bir dijital sertifika, bir web sitesinin kimliğini doğrulayan elektronik bir kimlik kartıdır.
Bir sertifikada şu bilgiler bulunur:
Alan adı (Domain Name)
Kuruluş adı
Ülke
Açık anahtar (Public Key)
Geçerlilik tarihi
İmzalayan Sertifika Otoritesi
Dijital imza
Algoritmalar
Uzantılar (Extensions)
Bu bilgiler uluslararası X.509 standardına göre düzenlenir.
Sertifika Otoritesi (Certificate Authority - CA) Nedir?
Bir web sitesi kendi sertifikasını oluşturabilir.
Ancak kullanıcıların bu sertifikaya güvenmesi için tarafsız bir otorite tarafından doğrulanması gerekir.
İşte bu görevi yerine getiren kuruluşlara Sertifika Otoritesi (Certificate Authority - CA) denir.
CA'ler dijital dünyadaki noterler gibi çalışır.
Bir kuruluş sertifika talep ettiğinde CA aşağıdaki doğrulamaları yapar:
Alan adının gerçekten başvurana ait olup olmadığını kontrol eder.
Başvuran kuruluşun kimliğini doğrular.
Gerekli belgeleri inceler.
Sertifikayı dijital olarak imzalar.
Bu sayede tarayıcılar, sertifikanın güvenilir bir otorite tarafından onaylandığını anlayabilir.
Sertifika Otoritesi Ne İş Yapar?
Bir CA'nın temel görevleri şunlardır:
Sertifika üretmek
Kimlik doğrulamak
Sertifika imzalamak
Sertifikaları iptal etmek (CRL)
Sertifika durumunu yayımlamak (OCSP)
Güven zincirini sürdürmek
Dünyada milyonlarca HTTPS sitesi, bu güven modeline dayanarak çalışmaktadır.
Dünyada Yaygın Sertifika Otoriteleri
İnternet üzerinde çok sayıda güvenilir Sertifika Otoritesi bulunmaktadır. Bunlardan bazıları şunlardır:
DigiCert
GlobalSign
Sectigo
Let's Encrypt
Entrust
GoDaddy
IdenTrust
Bu kuruluşların kök sertifikaları; Windows, Linux, macOS ve popüler web tarayıcılarının güvenilir sertifika depolarında önceden yüklü olarak bulunur.
Güven Zinciri (Chain of Trust)
Bir tarayıcı, bir web sitesinin sertifikasına doğrudan güvenmez. Bunun yerine, sertifikanın güvenilir bir zincire bağlı olup olmadığını doğrular.
Tipik bir güven zinciri şu şekildedir:
Root CA
Bu yapıda:
Root CA (Kök Sertifika Otoritesi): Zincirin en üstünde yer alır ve işletim sistemleri ile tarayıcılar tarafından doğrudan güvenilir kabul edilir.
Intermediate CA (Ara Sertifika Otoritesi): Root CA adına sertifika imzalar. Root anahtarının sürekli kullanılmasını önleyerek güvenliği artırır.
Sunucu Sertifikası: Web sitesinin (örneğin
www.example.com) kullandığı sertifikadır.
Tarayıcı, sunucu sertifikasından başlayarak bu zinciri adım adım doğrular. Zincirin herhangi bir halkası eksik, hatalı veya güvenilmeyen bir sertifika içeriyorsa bağlantı güvenilir kabul edilmez ve kullanıcıya sertifika uyarısı gösterilir.
Bu Bölümde Neler Öğrendik?
Bu bölümde:
HTTP'nin neden güvenli olmadığını,
HTTPS'in hangi güvenlik ihtiyaçlarını karşıladığını,
TLS'in HTTPS içindeki rolünü,
Dijital sertifikaların ne olduğunu,
Sertifika Otoritesi (CA) kavramını,
Güven zincirinin (Chain of Trust) nasıl çalıştığını
ayrıntılı olarak inceledik.
Sonraki Bölüm
Bir sonraki bölümde X.509 dijital sertifikalarının iç yapısını ayrıntılı olarak ele alacağız. Bir sertifikanın hangi alanlardan oluştuğunu, Common Name (CN), Subject Alternative Name (SAN), Public Key, Signature Algorithm, Validity, Key Usage ve diğer kritik alanların ne işe yaradığını hem teorik hem de OpenSSL komutlarıyla uygulamalı olarak inceleyeceğiz. Ayrıca laboratuvar senaryosundaki sertifikaların neden bu alanları içerdiğini de açıklayacağız.
Bölüm 2 – X.509 Dijital Sertifikalarının Yapısı
Bir önceki bölümde HTTPS'in neden geliştirildiğini, Sertifika Otoritesi (CA) kavramını ve güven zincirini ayrıntılı olarak öğrendik. Bu bölümde ise HTTPS'in temel yapı taşı olan X.509 dijital sertifikalarını inceleyeceğiz.
Laboratuvarın ilerleyen bölümlerinde OpenSSL ile sertifika indirirken ve sertifika parmak izlerini (Fingerprint) karşılaştırırken aslında bu X.509 sertifikaları üzerinde çalışacağız. Dolayısıyla sertifikanın hangi bilgilerden oluştuğunu anlamak, laboratuvarı doğru yorumlayabilmek için kritik öneme sahiptir.
Dijital Sertifika Nedir?
Dijital sertifika, internet üzerindeki bir kişi, kurum veya sunucunun kimliğini doğrulayan elektronik bir kimlik belgesidir.
Gerçek hayattaki kimlik kartları nasıl kişinin kim olduğunu gösteriyorsa, dijital sertifikalar da bir web sitesinin gerçekten iddia ettiği kuruluşa ait olduğunu kanıtlar.
Örneğin tarayıcınızda aşağıdaki adresi açtığınızda:
https://www.cisco.com
tarayıcı önce web sayfasını değil, Cisco'nun dijital sertifikasını inceler.
Bu sertifika şu soruların cevaplarını verir:
Gerçekten Cisco mu?
Sertifika kim tarafından verildi?
Sertifika geçerli mi?
Süresi dolmuş mu?
Alan adı doğru mu?
Sertifika değiştirilmiş olabilir mi?
Bu kontroller başarılı olursa HTTPS bağlantısı kurulmaya devam eder.
X.509 Standardı Nedir?
Dünyadaki HTTPS sertifikalarının neredeyse tamamı X.509 standardını kullanır.
X.509;
Sertifika biçimini
İçindeki alanları
Dijital imzayı
Anahtarları
Kimlik bilgilerini
tanımlayan uluslararası bir standarttır.
Bugün;
HTTPS
VPN
E-posta şifreleme (S/MIME)
Kod imzalama
Kurumsal PKI sistemleri
Akıllı kartlar
gibi birçok teknoloji X.509 sertifikalarını kullanmaktadır.
Bir Sertifika Nasıl Görünür?
OpenSSL ile bir sertifikayı görüntülediğinizde aşağıdakine benzer bilgiler görürsünüz:
Certificate:
İlk bakışta karmaşık görünse de her satırın önemli bir görevi vardır.
Şimdi bunları tek tek inceleyelim.
1. Version (Sürüm)
Version: 3
X.509 standardının hangi sürümünün kullanıldığını gösterir.
En yaygın sürüm:
Version 3 (X.509v3)
Bu sürüm;
Subject Alternative Name
Key Usage
Extended Key Usage
Basic Constraints
gibi gelişmiş güvenlik özelliklerini destekler.
2. Serial Number (Seri Numarası)
Örneğin:
Serial Number:
CA tarafından verilen benzersiz kimlik numarasıdır.
Hiçbir sertifikanın seri numarası aynı değildir.
Bunun kullanım alanları:
Sertifika iptali
Sertifika takibi
CRL listeleri
OCSP doğrulaması
3. Signature Algorithm (İmza Algoritması)
Örneğin:
Signature Algorithm:
Bu satır sertifikanın hangi algoritma kullanılarak imzalandığını gösterir.
Yaygın örnekler:
SHA256 with RSA
SHA384 with RSA
SHA512 with RSA
ECDSA with SHA256
Ed25519
Eskiden
SHA1withRSA
kullanılırdı.
Günümüzde güvenlik zafiyetleri nedeniyle önerilmez.
4. Issuer (Sertifikayı Veren Kuruluş)
Örneğin:
Issuer:
Bu alan sertifikayı hangi Sertifika Otoritesinin imzaladığını gösterir.
Örneğin:
DigiCert
Sectigo
Let's Encrypt
GlobalSign
Entrust
Tarayıcı önce bu kuruluşa güvenip güvenmediğini kontrol eder.
5. Subject (Sertifikanın Sahibi)
Örneğin:
Subject:
Bu bölüm sertifikanın kime ait olduğunu gösterir.
Burada;
şirket
kurum
sunucu
kişi
bulunabilir.
Subject İçindeki Alanlar
Örnek:
C=US
Ülke
ST=California
Eyalet
L=San Jose
Şehir
O=Cisco Systems
Kuruluş
OU=IT Department
Organizasyon Birimi
CN=www.cisco.com
Common Name
Common Name (CN)
CN uzun yıllar boyunca HTTPS doğrulamasında kullanılan en önemli alandı.
Örneğin:
CN=www.google.com
Tarayıcı ziyaret edilen adres ile bu alanı karşılaştırıyordu.
Ancak günümüzde tek başına yeterli değildir.
Yerini büyük ölçüde Subject Alternative Name (SAN) almıştır.
Subject Alternative Name (SAN)
Modern HTTPS'in en önemli alanlarından biridir.
Örneğin:
DNS:www.cisco.com
Tek bir sertifika;
cisco.com
support.cisco.com
gibi onlarca alan adını koruyabilir.
Tarayıcı artık öncelikle SAN alanını kontrol eder.
6. Validity (Geçerlilik Süresi)
Örneğin:
Not Before:
sertifikanın kullanılmaya başlanacağı tarihi gösterir.
Not After:
sertifikanın sona ereceği tarihtir.
Örneğin:
Not Before:
Not After:
2027 yılı geçildiğinde tarayıcı şu uyarıyı verir:
Sertifikanın süresi dolmuştur.
Sertifika Süresi Neden Kısadır?
Eskiden:
5 yıl
10 yıl
hatta
20 yıllık sertifikalar bulunabiliyordu.
Bugün ise genellikle:
90 gün (Let's Encrypt)
1 yıl
398 gün
gibi süreler tercih edilir.
Bunun nedenleri:
Anahtarların yenilenmesi
Çalınan anahtar riskinin azaltılması
Daha güncel algoritmaların kullanılması
Güvenliğin artırılması
7. Public Key (Açık Anahtar)
Her sertifikanın içinde bir açık anahtar bulunur.
Örneğin:
Public Key Algorithm:
veya
ECDSA
Ardından anahtar uzunluğu gelir.
RSA Public Key
veya
4096 bit
Günümüzde en yaygın seçenekler:
RSA 2048
RSA 3072
RSA 4096
ECC P-256
ECC P-384
Ed25519
Açık Anahtar Ne İşe Yarar?
Tarayıcı bu anahtarı kullanarak:
Anahtar değişimi yapar.
Dijital imzayı doğrular.
TLS oturumunu başlatır.
Önemli bir nokta: Açık anahtar herkes tarafından görülebilir. Güvenliği sağlayan unsur, yalnızca sunucuda bulunan ve gizli tutulan özel anahtardır (Private Key).
8. Key Usage
Bu alan sertifikanın hangi amaçlarla kullanılabileceğini belirtir.
Örnek:
Digital Signature
Anlamları:
Digital Signature: Dijital imza oluşturabilir veya doğrulayabilir.
Key Encipherment: Anahtar değişiminde kullanılabilir.
9. Extended Key Usage
Bu alan daha ayrıntılı kullanım amaçlarını tanımlar.
Örnek:
TLS Web Server Authentication
Bu sertifika web sunucusu olarak kullanılabilir.
Diğer örnekler:
Client Authentication
Code Signing
Email Protection
Time Stamping
OCSP Signing
10. Basic Constraints
Örneğin:
CA:TRUE
Bu sertifika başka sertifikaları imzalayabilir.
CA:FALSE
Bu sertifika yalnızca son kullanıcı veya sunucu tarafından kullanılabilir; başka sertifikaları imzalayamaz.
Bu alan güven zincirinin doğru kurulması açısından kritik öneme sahiptir.
11. Subject Key Identifier (SKI)
Her sertifikanın açık anahtarından türetilen benzersiz bir kimlik değeridir.
Ara sertifikalar ve kök sertifikalar arasında ilişki kurulmasını kolaylaştırır.
12. Authority Key Identifier (AKI)
Sertifikayı imzalayan üst sertifikanın kimliğini gösterir.
Tarayıcı bu alan sayesinde doğru üst sertifikayı bulabilir ve güven zincirini tamamlayabilir.
Sertifika İçeriğini OpenSSL ile Görüntüleme
Laboratuvarın ilerleyen bölümünde bir sertifikayı dosyaya kaydettikten sonra aşağıdaki komutla tüm ayrıntıları görüntüleyebilirsiniz:
openssl x509 -in cisco.pem -text -noout
Bu komut;
Sertifikanın sürümünü
Seri numarasını
İmzalayan CA'yı
Subject bilgilerini
Public Key'i
Geçerlilik tarihlerini
X.509 uzantılarını
Dijital imza algoritmasını
ayrıntılı olarak ekrana yazdırır. Laboratuvarda parmak izi (Fingerprint) hesaplamadan önce bu bilgileri incelemek, sertifikanın yapısını anlamanızı kolaylaştırır.
Bu Bölümde Neler Öğrendik?
Bu bölümde bir X.509 dijital sertifikasının tüm temel bileşenlerini ayrıntılı olarak inceledik. Artık bir sertifikanın yalnızca bir "güven belgesi" olmadığını; kimlik doğrulama, anahtar yönetimi ve güven zincirinin kurulması için gerekli birçok kritik bilgiyi içerdiğini biliyoruz.
Bir sonraki bölümde laboratuvar senaryosuna daha da yaklaşacağız ve işletim sistemleri ile web tarayıcılarında bulunan Sertifika Depolarını (Certificate Store) inceleyeceğiz. Chrome, Firefox, Windows, Linux ve Pardus üzerinde güvenilir kök sertifikaların nerede saklandığını, bu depoların nasıl yönetildiğini ve laboratuvardaki "Tarayıcınız Tarafından Güvenilen Sertifikalar" bölümünü adım adım uygulamalı olarak ele alacağız.
Bölüm 3 – Sertifika Depoları (Certificate Store) ve Tarayıcıların Güven Mekanizması
Önceki bölümde X.509 dijital sertifikalarının yapısını ayrıntılı olarak inceledik. Bir sertifikanın içinde bulunan Common Name (CN), Subject Alternative Name (SAN), Issuer, Subject, Public Key ve Validity gibi alanların HTTPS güvenliğinde nasıl kullanıldığını öğrendik.
Ancak akla önemli bir soru gelir:
Bir web tarayıcısı, karşısına çıkan bir sertifikanın güvenilir olup olmadığını nasıl anlar?
Bir tarayıcı, internette karşılaştığı milyonlarca sertifikanın hangilerine güveneceğini önceden bilemez. Bunun için işletim sistemi ve tarayıcılar, içerisinde güvenilir Sertifika Otoritelerinin (CA) bulunduğu özel veri tabanları kullanır. Bu veri tabanlarına Sertifika Deposu (Certificate Store) adı verilir.
Bu bölümde laboratuvarın ilk kısmını temel alarak sertifika depolarını ayrıntılı şekilde inceleyeceğiz.
Sertifika Deposu (Certificate Store) Nedir?
Sertifika deposu, işletim sistemi veya web tarayıcısı tarafından güvenilir kabul edilen dijital sertifikaların saklandığı güvenli bir veri tabanıdır.
Bu depoda yalnızca web sitelerinin sertifikaları bulunmaz. Aynı zamanda;
Kök Sertifika Otoriteleri (Root CA)
Ara Sertifika Otoriteleri (Intermediate CA)
Kurumsal sertifikalar
Kullanıcı sertifikaları
Akıllı kart sertifikaları
Kod imzalama sertifikaları
gibi birçok farklı sertifika saklanabilir.
Kısacası sertifika deposu, bilgisayarın "kime güveneceğini" belirleyen dijital güven listesidir.
Sertifika Deposu Neden Gereklidir?
Bir kullanıcı aşağıdaki adrese bağlandığında:
https://www.cisco.com
sunucu kendi sertifikasını gönderir.
Tarayıcı ise şu soruyu sorar:
"Bu sertifikayı imzalayan kuruluşa güveniyor muyum?"
Eğer cevap "Evet" ise HTTPS bağlantısı devam eder.
Eğer cevap "Hayır" ise kullanıcı aşağıdaki türde bir uyarıyla karşılaşır:
Bu bağlantı güvenli değil.
Sertifika güvenilir değil.
Sertifika doğrulanamadı.
NET::ERR_CERT_AUTHORITY_INVALID
Tarayıcı sertifika deposunda ilgili CA'yı bulamazsa bağlantıya varsayılan olarak güvenmez.
Sertifika Deposu Nasıl Çalışır?
Bir HTTPS bağlantısı kurulduğunda aşağıdaki doğrulama süreci gerçekleşir:
Kullanıcı
Bu işlem milisaniyeler içerisinde tamamlanır ve kullanıcı çoğu zaman arka planda neler olduğunu fark etmez.
Root CA Neden Önemlidir?
Root CA (Kök Sertifika Otoritesi), güven zincirinin en üst halkasıdır.
Bir Root CA'nın özel anahtarı (Private Key) son derece kritik bir varlıktır. Bu anahtar ele geçirilirse saldırgan, güvenilir görünen sahte sertifikalar oluşturabilir. Bu nedenle kök sertifika anahtarları çevrimdışı (offline), donanımsal güvenlik modüllerinde (HSM) ve sıkı fiziksel güvenlik önlemleri altında korunur.
Root CA'nın görevi genellikle son kullanıcı sertifikalarını doğrudan imzalamak değildir. Bunun yerine ara sertifika otoritelerini (Intermediate CA) imzalar.
Neden Ara Sertifika (Intermediate CA) Kullanılır?
Şu soru akla gelebilir:
Root CA bütün sertifikaları neden doğrudan imzalamıyor?
Bunun temel nedenleri:
Root anahtarının korunması
Yetki devri
Riskin azaltılması
Sertifika iptal işlemlerinin kolaylaştırılması
Büyük ölçekli yönetim
Tipik güven zinciri şu şekildedir:
Root CA
Tarayıcı bu zincirin her halkasını doğrular.
Tarayıcılar Sertifikalara Nasıl Güvenir?
Bir HTTPS sitesi sertifikasını gönderdiğinde tarayıcı aşağıdaki kontrolleri yapar:
Sertifika süresi dolmuş mu?
Alan adı uyuşuyor mu?
Dijital imza geçerli mi?
Sertifika iptal edilmiş mi?
Sertifika güvenilir bir CA tarafından mı imzalanmış?
Güven zinciri eksiksiz mi?
Bu kontrollerden biri başarısız olursa güvenli bağlantı kurulmaz.
Sertifika Depolarında Neler Bulunur?
Bir sertifika deposunda farklı amaçlara hizmet eden birçok sertifika yer alabilir:
| Sertifika Türü | Görevi |
|---|---|
| Root CA | En üst güven otoritesi |
| Intermediate CA | Sunucu sertifikalarını imzalar |
| Server Certificate | Web sunucusunun kimliğini doğrular |
| Client Certificate | Kullanıcı kimlik doğrulaması |
| Code Signing Certificate | Yazılım imzalama |
| Email Certificate | S/MIME e-posta güvenliği |
Bu laboratuvarda özellikle Root CA ve Intermediate CA sertifikaları üzerinde duracağız.
Laboratuvar Bölüm 1 – Chrome'da Güvenilir Kök Sertifikalarını Görüntüleme
Laboratuvarın ilk uygulaması, tarayıcınızın hangi Sertifika Otoritelerine güvendiğini incelemektir. Kaynak metinde Chrome 81 sürümü örnek alınmıştır; farklı sürümlerde menü isimleri değişebilse de mantık aynıdır.
İzlenecek genel adımlar:
Chrome'u açın.
Sağ üst köşedeki üç nokta menüsünü seçin.
Ayarlar bölümüne girin.
Gizlilik ve Güvenlik bölümünü açın.
Güvenlik sayfasına gidin.
Sertifikaları Yönet seçeneğini açın.
Güvenilir Kök Sertifika Yetkilileri sekmesini görüntüleyin.
Bu bölümde tarayıcının veya işletim sisteminin güvendiği kök sertifikalar listelenir.
Chrome Bu Sertifikaları Nereden Alır?
Chrome'un sertifika yönetimi kullandığı işletim sistemine göre değişebilir.
Windows
Chrome büyük ölçüde Windows Sertifika Deposu'nu kullanır.
Windows Certificate Store
Linux (Pardus, Debian, Ubuntu)
Çoğu Chromium tabanlı tarayıcı sistemin ortak CA deposunu kullanır.
Yaygın dizinler:
/etc/ssl/certs/
veya
/usr/share/ca-certificates/
Bu dizinlerde güvenilir kök sertifikalar bulunur.
macOS
Chrome, macOS'in Keychain Access altyapısından yararlanır.
Güvenilir Kök Sertifika Yetkilileri Sekmesi
Bu sekmede yüzlerce kök sertifika görebilirsiniz.
Her satır bir Sertifika Otoritesini temsil eder.
Örneğin:
DigiCert
GlobalSign
ISRG Root X1 (Let's Encrypt)
Entrust
Sectigo
Bu kuruluşlardan biri tarafından imzalanmış bir sunucu sertifikasıyla karşılaşıldığında, güven zinciri doğru kurulmuşsa tarayıcı bağlantıya güvenebilir.
Bir Sertifikanın Ayrıntıları Nasıl İncelenir?
Listeden bir sertifikayı seçip ayrıntılarını görüntülediğinizde genellikle şu bilgiler bulunur:
Sertifika sahibi (Subject)
Sertifikayı veren kuruluş (Issuer)
Geçerlilik tarihleri
Açık anahtar algoritması
Parmak izi (Fingerprint)
Dijital imza algoritması
Bu bilgiler, laboratuvarın ikinci bölümünde OpenSSL ile elde edeceğimiz çıktılarla büyük ölçüde aynıdır.
Firefox Neden Ayrı Bir Sertifika Deposu Kullanabilir?
Laboratuvarda ikinci adım olarak Firefox'un Sertifika Yöneticisi açılarak yetkili sertifikaların görüntülenmesi istenir. Kaynak metin, Firefox'ta Menü → Ayarlar → Gizlilik ve Güvenlik → Sertifikaları Görüntüle yolunu izleyerek bu listeye ulaşılacağını belirtmektedir.
Firefox, bazı platformlarda kendi sertifika veritabanını kullanabildiği için Chrome ile aynı CA listesine sahip olmak zorunda değildir. Bu nedenle iki tarayıcı arasında güvenilen sertifikalarda farklılıklar görülebilir.
Kurumsal Ağlarda Yeni Bir Root CA Nasıl Eklenir?
Laboratuvarın ilerleyen kısmında anlatılacağı gibi, kurumlar HTTPS trafiğini inceleyebilmek amacıyla istemci bilgisayarlara kendi Sertifika Otoritelerini ekleyebilir. Böylece kurum tarafından oluşturulan sertifikalar da güvenilir kabul edilir.
Kurumsal ortamlarda bu işlem;
Grup İlkesi (Group Policy),
MDM çözümleri,
Kurumsal yönetim yazılımları,
Linux yapılandırma araçları
gibi yöntemlerle otomatik olarak yapılabilir.
Bu mekanizma doğru amaçlarla kullanıldığında güvenlik denetimi için yararlı olsa da, kötüye kullanıldığında HTTPS trafiğinin çözümlenmesine ve kullanıcıların fark etmeden farklı bir uç noktayla iletişim kurmasına yol açabilir. Bu konu, laboratuvarın "Ortadaki Adam Kontrolü" bölümünde ayrıntılı olarak ele alınmaktadır.
Bölüm Özeti
Bu bölümde:
Sertifika deposunun ne olduğunu,
Root CA ve Intermediate CA arasındaki farkı,
Tarayıcıların HTTPS bağlantısına neden güvenebildiğini,
Chrome ve Firefox'ta güvenilir sertifikaların nasıl görüntülendiğini,
İşletim sistemlerinin sertifika depolarını,
Kurumsal ortamlarda yeni CA'ların nasıl kullanılabildiğini
laboratuvar senaryosunu temel alarak ayrıntılı şekilde inceledik.
Sonraki Bölüm
Bir sonraki bölümde TLS/SSL El Sıkışma Sürecini (TLS Handshake) paket seviyesinde inceleyeceğiz. İstemci ile sunucu arasında gerçekleşen Client Hello, Server Hello, Certificate, Key Exchange ve Finished mesajlarını adım adım açıklayacak; ardından bu sürecin laboratuvardaki HTTPS Proxy (Man-in-the-Middle) senaryosuyla nasıl ilişkilendiğini ayrıntılı olarak ele alacağız.
Bölüm 4 – TLS/SSL El Sıkışma Süreci (TLS Handshake) ve HTTPS Bağlantısının Kurulması
Önceki bölümlerde HTTPS'in temel mantığını, Sertifika Otoritesi (CA) kavramını, X.509 dijital sertifikalarını ve sertifika depolarını ayrıntılı olarak inceledik. Artık bir web tarayıcısının bir sertifikaya neden güvendiğini biliyoruz.
Ancak HTTPS bağlantısı yalnızca sertifika doğrulamasından ibaret değildir. Bir HTTPS bağlantısı kurulurken istemci (tarayıcı) ile sunucu arasında çok sayıda mesaj alışverişi yapılır. Bu sürece TLS Handshake (TLS El Sıkışması) adı verilir.
Laboratuvarın ikinci bölümünde OpenSSL ile bir web sunucusuna bağlanıp sertifikasını alacağız. Bu işlem sırasında arka planda aslında bir TLS Handshake gerçekleşmektedir. Bu nedenle bu sürecin ayrıntılı olarak anlaşılması büyük önem taşır.
TLS Handshake Nedir?
TLS Handshake, istemci ile sunucu arasında güvenli bir iletişim kanalı oluşturmak amacıyla gerçekleştirilen başlangıç iletişimidir.
Bu süreçte aşağıdaki işlemler gerçekleştirilir:
Sunucunun kimliği doğrulanır.
Sertifika kontrol edilir.
Şifreleme algoritmaları belirlenir.
Ortak oturum anahtarı oluşturulur.
Güvenli iletişim başlatılır.
Bu işlemlerin tamamı birkaç yüz milisaniye içerisinde gerçekleşir.
TLS Handshake Neden Gereklidir?
Tarayıcı aşağıdaki adrese bağlanmak istediğinde:
https://www.cisco.com
hemen veri göndermeye başlamaz.
Önce şu soruların cevaplarını arar:
Karşımdaki gerçekten Cisco mu?
Sertifikası geçerli mi?
Güvenilir bir CA tarafından mı imzalanmış?
Hangi şifreleme algoritmasını kullanacağız?
Ortak anahtar nasıl oluşturulacak?
Bu sorular cevaplanmadan güvenli iletişim başlamaz.
TLS Handshake'in Genel Akışı
Aşağıdaki diyagram tipik bir TLS 1.2 el sıkışmasını göstermektedir.
┌───────────────┐ ┌───────────────┐
Bu mesajların her biri farklı bir görevi yerine getirir.
Adım 1 – Client Hello
İlk mesaj istemci tarafından gönderilir.
Client Hello
Bu mesajın amacı şudur:
"Merhaba, güvenli bağlantı kurmak istiyorum."
Bu mesaj içerisinde aşağıdaki bilgiler bulunur:
TLS sürümü
Desteklenen şifreleme algoritmaları (Cipher Suites)
Rastgele sayı (Client Random)
Desteklenen sıkıştırma yöntemleri
Desteklenen uzantılar (Extensions)
SNI (Server Name Indication)
Client Random Nedir?
İstemci, rastgele üretilmiş 32 baytlık bir sayı gönderir.
Örneğin:
Client Random
Bu değer daha sonra oturum anahtarının oluşturulmasında kullanılır.
Her bağlantıda farklıdır.
Bu nedenle aynı kullanıcı aynı siteye iki kez bağlansa bile farklı oturum anahtarları oluşur.
Cipher Suite Nedir?
Tarayıcı şu mesajı verir:
"Ben aşağıdaki algoritmaları destekliyorum."
Örneğin:
TLS_AES_128_GCM_SHA256
Sunucu bunlardan birini seçer.
Adım 2 – Server Hello
Sunucu cevap verir.
Server Hello
Bu mesajda şunlar bulunur:
Kullanılacak TLS sürümü
Seçilen Cipher Suite
Server Random
Session ID
Örneğin:
TLS 1.3
Server Random
Sunucu da kendi rastgele sayısını üretir.
Server Random
Bu sayı da anahtar üretiminde kullanılır.
Adım 3 – Certificate
Sunucu şimdi en önemli bilgiyi gönderir:
Certificate
Bu paket içerisinde:
Sunucu sertifikası
Ara sertifika
Sertifika zinciri
bulunur.
Tarayıcı bu aşamada sertifikayı doğrulamaya başlar.
Tarayıcı Neleri Kontrol Eder?
Sunucu sertifikasını aldıktan sonra aşağıdaki kontroller yapılır:
1. Sertifika süresi dolmuş mu?
Not Before
alanları incelenir.
2. Alan adı uyuşuyor mu?
Örneğin kullanıcı
www.cisco.com
adresine bağlanıyorsa
sertifikanın SAN alanında da
www.cisco.com
bulunmalıdır.
3. Dijital imza doğru mu?
Tarayıcı CA'nın açık anahtarı ile imzayı doğrular.
4. Güven Zinciri Tam mı?
Web Sertifikası
zinciri eksiksiz olmalıdır.
5. Sertifika iptal edilmiş mi?
Tarayıcı aşağıdaki yöntemlerden biriyle kontrol yapabilir:
CRL
OCSP
Sertifika Doğrulaması Başarısız Olursa
Tarayıcı aşağıdaki uyarılardan birini gösterebilir:
NET::ERR_CERT_DATE_INVALID
NET::ERR_CERT_AUTHORITY_INVALID
NET::ERR_CERT_COMMON_NAME_INVALID
Your connection is not private
This connection is not secure
Bağlantı genellikle kullanıcının onayı olmadan devam etmez.
Adım 4 – Anahtar Değişimi (Key Exchange)
Sertifika doğrulandıktan sonra ortak oturum anahtarı oluşturulur.
Modern TLS sürümlerinde genellikle:
ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
kullanılır.
Eskiden ise:
RSA Key Exchange
yaygındı.
ECDHE sayesinde Perfect Forward Secrecy (PFS) sağlanır. Bu özellik, uzun vadeli özel anahtar daha sonra ele geçirilse bile geçmiş oturumların çözülememesini amaçlar.
Adım 5 – Session Key Oluşturulması
Artık iki tarafta aşağıdaki bilgiler bulunmaktadır:
İstemci:
Client Random
Sunucu:
Server Random
Her iki taraf:
Ortak gizli değer (Shared Secret)
Bu bilgiler kullanılarak aynı oturum anahtarı hesaplanır.
Bu anahtar ağ üzerinden gönderilmez; her iki taraf da kendi tarafında hesaplar.
Adım 6 – Change Cipher Spec
Taraflar birbirine şu mesajı gönderir:
Change Cipher Spec
Anlamı:
"Bundan sonraki tüm iletişim şifreli olacaktır."
Adım 7 – Finished
Son mesajdır.
Finished
Bu mesaj, el sıkışma sırasında yapılan tüm işlemlerin özetini içerir ve her iki tarafın aynı anahtarı hesapladığını doğrular.
Eğer bu doğrulama başarısız olursa bağlantı sonlandırılır.
Bundan Sonra Ne Olur?
Artık HTTPS bağlantısı kurulmuştur.
Tarayıcı şu isteği gönderir:
GET / HTTP/1.1
Ancak bu kez istek düz metin olarak iletilmez.
Tamamı TLS ile şifrelenmiştir.
Ağ üzerindeki bir dinleyici yalnızca şifreli paketleri görebilir.
TLS 1.2 ile TLS 1.3 Arasındaki Fark
| Özellik | TLS 1.2 | TLS 1.3 |
|---|---|---|
| El sıkışma mesaj sayısı | Daha fazla | Daha az |
| RSA Key Exchange | Desteklenir | Kaldırıldı |
| ECDHE | Desteklenir | Zorunluya yakın kullanım |
| Güvenlik | Yüksek | Daha yüksek |
| Performans | Daha yavaş | Daha hızlı |
TLS 1.3, daha az mesajla bağlantı kurduğu için gecikmeyi azaltır ve yalnızca modern, güvenli şifreleme yöntemlerine izin verir.
Laboratuvar ile İlişkisi
Laboratuvarın ikinci bölümünde aşağıdaki OpenSSL komutu kullanılacaktır:
echo -n | openssl s_client -connect cisco.com:443
Bu komut yalnızca sertifikayı indirmez.
Arka planda:
Client Hello gönderir.
Server Hello alır.
Sertifikayı alır.
Sertifika zincirini doğrular.
TLS Handshake'i başlatır.
Sunucunun kimliğini doğrular.
Daha sonra elde edilen sertifika cisco.pem dosyasına kaydedilerek parmak izi (Fingerprint) hesaplanacaktır.
OpenSSL s_client Çıktısının Ayrıntılı Analizi
Kullanılan komut:
echo -n | openssl s_client -connect cisco.com:443
Bu komut;
Cisco sunucusuna TCP 443 portundan bağlanır.
TLS Handshake işlemini gerçekleştirir.
Sunucunun gönderdiği sertifikaları gösterir.
Sertifika zincirini doğrular.
Kullanılan TLS sürümünü ve şifreleme algoritmasını görüntüler.
nuritiras@Mac ~ % echo -n | openssl s_client -connect cisco.com:443
Connecting to 72.163.4.185
CONNECTED(00000005)
depth=2 C=US, O=IdenTrust, CN=IdenTrust Commercial Root CA 1
verify return:1
depth=1 C=US, O=IdenTrust, OU=HydrantID Trusted Certificate Service, CN=HydrantID Server CA O1
verify return:1
depth=0 C=US, ST=California, L=San Jose, O=Cisco Systems Inc., CN=www.cisco.com
verify return:1
---
Certificate chain
0 s:C=US, ST=California, L=San Jose, O=Cisco Systems Inc., CN=www.cisco.com
i:C=US, O=IdenTrust, OU=HydrantID Trusted Certificate Service, CN=HydrantID Server CA O1
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Aug 22 04:22:07 2025 GMT; NotAfter: Sep 21 04:21:07 2026 GMT
1 s:C=US, O=IdenTrust, OU=HydrantID Trusted Certificate Service, CN=HydrantID Server CA O1
i:C=US, O=IdenTrust, CN=IdenTrust Commercial Root CA 1
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Dec 12 16:56:15 2019 GMT; NotAfter: Dec 12 16:56:15 2029 GMT
2 s:C=US, O=IdenTrust, CN=IdenTrust Commercial Root CA 1
i:C=US, O=IdenTrust, CN=IdenTrust Commercial Root CA 1
a:PKEY: RSA, 4096 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Jan 16 18:12:23 2014 GMT; NotAfter: Jan 16 18:12:23 2034 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHkjCCBnqgAwIBAgIQQAGY0AM06NJsb5xI3ZSsITANBgkqhkiG9w0BAQsFADBy
MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRlblRydXN0MS4wLAYDVQQLEyVIeWRy
YW50SUQgVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBTZXJ2aWNlMR8wHQYDVQQDExZIeWRy
YW50SUQgU2VydmVyIENBIE8xMB4XDTI1MDgyMjA0MjIwN1oXDTI2MDkyMTA0MjEw
N1owajELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcT
CFNhbiBKb3NlMRswGQYDVQQKExJDaXNjbyBTeXN0ZW1zIEluYy4xFjAUBgNVBAMT
DXd3dy5jaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5
ZmHLUrK41GSEtQzPUoloq7hU+DQNVAE94JUNw8Av9wjcRNlJFE7/Y3fFRiWnms83
kera8Q/cG+mYCUkK+2KDKc+MV28T1zQvTiAgLMx/FWpMNO2lwWAuT2tWoJd95Ex2
EtBBQhD6d1n85geQfNl9vSGE6eIz04PfwKtq2hV7yHbVESVLr+ZUCv5nR9ZXLZb6
3iIOJBHmcXf8Ozy0gCymPiJg9smNlHJ5mT5M9q7KB7YH9GX8bNVi2qGn4eDX19Y9
IuVu1FX5403YGTD4qrD+hLv9WQ0CJg3vABWAPEgAOKm/BLNyeLUO88L1ftfl2QBc
Jx+aPYESOT27PiK2xtTvAgMBAAGjggQqMIIEJjAOBgNVHQ8BAf8EBAMCBaAwgYUG
CCsGAQUFBwEBBHkwdzAwBggrBgEFBQcwAYYkaHR0cDovL2NvbW1lcmNpYWwub2Nz
cC5pZGVudHJ1c3QuY29tMEMGCCsGAQUFBzAChjdodHRwOi8vdmFsaWRhdGlvbi5p
ZGVudHJ1c3QuY29tL2NlcnRzL2h5ZHJhbnRpZGNhTzEucDdjMB8GA1UdIwQYMBaA
FIm4m7ae7fuwxr0N7GdOPKOSnS35MCEGA1UdIAQaMBgwCAYGZ4EMAQICMAwGCmCG
SAGG+S8ABgMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL3ZhbGlkYXRpb24uaWRl
bnRydXN0LmNvbS9jcmwvaHlkcmFudGlkY2FvMS5jcmwwggE9BgNVHREEggE0MIIB
MIIJY2lzY28uY29tgg13d3cuY2lzY28uY29tgg53d3cxLmNpc2NvLmNvbYIOd3d3
Mi5jaXNjby5jb22CDnd3dzMuY2lzY28uY29tghB3d3ctMDEuY2lzY28uY29tghB3
d3ctMDIuY2lzY28uY29tghF3d3ctcnRwLmNpc2NvLmNvbYISd3d3MS1zczIuY2lz
Y28uY29tghJ3d3cyLXNzMS5jaXNjby5jb22CEnd3dzMtc3MxLmNpc2NvLmNvbYIS
d3d3My1zczIuY2lzY28uY29tghR3d3cuc3RhdGljLWNpc2NvLmNvbYIVcmVkaXJl
Y3QtbnMuY2lzY28uY29tghZjaXNjby1pbWFnZXMuY2lzY28uY29tghh3d3cubWVk
aWFmaWxlcy1jaXNjby5jb20wHQYDVR0OBBYEFDFP0OTyhQAyI0Gmxk5JIsUWLQqE
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjCCAX8GCisGAQQB1nkCBAIE
ggFvBIIBawFpAHYA1219ENGn9XfCx+lf1wC/+YLJM1pl4dCzAXMXwMjFaXcAAAGY
0AM1RQAABAMARzBFAiEA5OMi4psAyp2o+NI6c0KxSLjM+havNi9P6TiXdltbTG8C
ICY6jYG0a+Wk1zXJdi3RH6TjRrETAp78L5GsFjVwh3vNAHYA2AlVO5RPev/IFhlv
lE+Fq7D4/F6HVSYPFdEucrtFSxQAAAGY0AM1ewAABAMARzBFAiBqw6JMTGGWNZ3i
+etSS2yfCwwIUNcssom/gG/1HgNusQIhANLjcHov5HqC9knPZimMmJ4KO1ipIe8s
Y66VvJGyvuCPAHcAyzj3FYl8hKFEX1vB3fvJbvKaWc1HCmkFhbDLFMMUWOcAAAGY
0AM1YgAABAMASDBGAiEAlUzTTvYrx4TV798tT8dycz+Hs5lUDTbCclFRsYc5IRwC
IQDe881kW5T0of8Ig2hERctGtJ3shM+T7I2bPzYgU6FaLzANBgkqhkiG9w0BAQsF
AAOCAQEACxpUAqKxezoZAfRVUFptlB3nMKYaOX3/jYsEmaDGDEoh1qhyZVwLO27G
9Vx7VgpiD7CXrK0yh37YF4hZ9qYVM7arPF+SojGgdPVtAQSNAPkb3GkKJtAH8jbH
rv88L97L1Y/gw0oRbgkLPLy5psdHzInbOQ+9TFdgeVVeL9uZXjuF0FFYeSY7z9T7
WmzTdza028qX4lxaKaVk9b4wvyN2yfbx82PWZizejZZVw1xuBwLPbA67LLzl7DTb
H+F0mhojB6pOwkl346QLwmcOvFZGVS3BTeeBpl/iOiLbpLWVoVOPnZdz1zKuICGZ
V1yv/vTxOA2H/3aXbmZIIG5TxMtfCQ==
-----END CERTIFICATE-----
subject=C=US, ST=California, L=San Jose, O=Cisco Systems Inc., CN=www.cisco.com
issuer=C=US, O=IdenTrust, OU=HydrantID Trusted Certificate Service, CN=HydrantID Server CA O1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Peer Temp Key: X25519, 253 bits
---
SSL handshake has read 5727 bytes and written 1633 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Protocol: TLSv1.2
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 01F704DE84CFC5809F0ED28D018BB7352FFEBDA16FBEC3E748D83F22990F3507
Session-ID-ctx:
Master-Key: E801C85B3CC2397A5289BE3C16BC16DFE903EAF8CEF270392228C3C0402F78810D2DBABF6160B61D7CE7B572555EA042
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 67 51 30 fb 5e cf ad da-d2 14 5a 17 66 9f 3b 3a gQ0.^.....Z.f.;:
0010 - 07 0c 92 3e 1b 9f 94 c0-89 82 ac 29 50 fd 3a 49 ...>.......)P.:I
0020 - 4e ca 83 86 d1 8e 57 62-b5 7f 8e a8 75 b7 03 0b N.....Wb....u...
0030 - 27 32 2b b7 85 67 69 4d-61 dc 7c e5 b5 6c 43 5d '2+..giMa.|..lC]
0040 - f0 13 67 8b 65 f0 5e 21-1c d9 b5 87 16 82 82 45 ..g.e.^!.......E
0050 - c4 21 40 b0 dc 7b a3 ec-a1 1a b6 27 04 7e 1f 9e .!@..{.....'.~..
0060 - 49 86 23 8b 37 f1 bc 66-ec 51 ea 38 fe ff bc b2 I.#.7..f.Q.8....
0070 - 8a a4 d0 67 b0 a0 01 73-c3 1d ad d5 b1 b6 9d ea ...g...s........
0080 - ed 63 a6 ee e9 8c 16 3c-97 ce 23 dd a5 9d e7 43 .c.....<..#....C
0090 - 17 7d 33 65 88 6c a0 2d-56 9b 11 c4 e8 6d 36 df .}3e.l.-V....m6.
00a0 - e7 ac 36 9b 06 d1 6f 19-08 66 fb 92 d6 3d 05 78 ..6...o..f...=.x
Start Time: 1785415597
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
DONE
1. TCP Bağlantısı Kuruluyor
Connecting to 72.163.4.185
CONNECTED(00000005)
Bu satırlar OpenSSL'in DNS çözümlemesi yaptığını gösterir.
cisco.com
│
▼
72.163.4.185
Ardından TCP bağlantısı başarıyla kurulmuştur.
2. Sertifika Zinciri Doğrulanıyor
depth=2
IdenTrust Commercial Root CA 1
verify return:1
Bu satır Root CA'yı göstermektedir.
Root CA
↓
IdenTrust Commercial Root CA 1
Bu sertifika işletim sisteminiz tarafından güvenilmektedir.
verify return:1
demek
Doğrulama başarılı
anlamına gelir.
Intermediate CA
depth=1
HydrantID Server CA O1
Bu sertifika
Root CA tarafından imzalanmıştır.
Root CA
↓
Intermediate CA
Sunucu Sertifikası
depth=0
CN=www.cisco.com
Bu,
web sunucusunun kullandığı gerçek sertifikadır.
3. Sertifika Zinciri
OpenSSL daha sonra zinciri özet halinde tekrar göstermektedir.
www.cisco.com
↓
HydrantID Server CA O1
↓
IdenTrust Commercial Root CA 1
Bu zincir eksiksizdir.
Bu nedenle
Verification: OK
görülmektedir.
4. Sunucu Sertifikasının Bilgileri
Subject
CN=www.cisco.com
Buradan sertifikanın
www.cisco.com
alan adına ait olduğu anlaşılır.
Issuer
HydrantID Server CA O1
Bu sertifika
Cisco tarafından değil,
CA tarafından imzalanmıştır.
Bu dijital sertifikanın temel mantığıdır.
5. Kullanılan Algoritma
PKEY: RSA, 2048 bit
Sunucu sertifikası
RSA 2048
anahtarı kullanmaktadır.
İmza Algoritması
sha256WithRSAEncryption
Bu,
sertifikanın
SHA-256
ile imzalandığını göstermektedir.
Modern ve güvenli bir algoritmadır.
6. Sertifikanın Geçerlilik Süresi
NotBefore
22 Ağustos 2025
Bu tarihten önce sertifika kullanılamaz.
NotAfter
21 Eylül 2026
Bu tarihten sonra
sertifika geçersiz olacaktır.
Tarayıcı şu hatayı verir:
NET::ERR_CERT_DATE_INVALID
7. Root CA
IdenTrust Commercial Root CA 1
Dikkat edilirse
Root CA
kendi kendisini imzalamıştır.
Subject
=
Issuer
Bu,
Self-Signed Root Certificate
özelliğidir.
Root CA'lar
başka bir CA tarafından imzalanmaz.
8. Peer Signature
Peer signature type:
rsa_pss_rsae_sha256
Bu,
TLS Handshake sırasında
RSA-PSS
imza algoritmasının kullanıldığını gösterir.
RSA-PSS, klasik PKCS#1 v1.5 imzasına göre daha modern ve daha güvenli bir imzalama yöntemidir.
9. Geçici Anahtar (Ephemeral Key)
Peer Temp Key:
X25519
253 bits
Burası çok önemlidir.
Cisco sertifikası
RSA
olmasına rağmen
Anahtar değişimi için
X25519
kullanılıyor.
Bu,
ECDHE anahtar değişimidir.
Yani
RSA
yalnızca
kimlik doğrulama için kullanılmaktadır.
Oturum anahtarı ise
X25519
ile oluşturulmaktadır.
Modern TLS'in çalışma mantığı budur.
10. TLS Sürümü
TLSv1.2
Bağlantı
TLS 1.2
ile kurulmuştur.
Günümüzde birçok sunucu TLS 1.3'ü de destekler; ancak istemci ve sunucunun ortak desteklediği sürüme göre görüşme yapılır.
11. Cipher Suite
ECDHE-RSA-AES256-GCM-SHA384
Bu ifade dört bileşenden oluşur:
| Bileşen | Açıklama |
|---|---|
| ECDHE | Geçici eliptik eğri Diffie–Hellman anahtar değişimi (Perfect Forward Secrecy sağlar). |
| RSA | Sunucunun kimliğini doğrulamak için kullanılan sertifika algoritması. |
| AES256-GCM | Oturum verilerini şifreleyen simetrik algoritma. |
| SHA384 | Bu şifre takımının kullandığı özet (hash) algoritması. |
12. Sunucu Açık Anahtarı
Server public key is
2048 bit
Bu,
Cisco'nun RSA açık anahtarının
2048 bit olduğunu göstermektedir.
13. Sertifika Doğrulaması
Verification: OK
Bu satır çok önemlidir.
Anlamı:
✔ Sertifika güvenilir.
✔ Sertifika süresi geçerli.
✔ Zincir eksiksiz.
✔ Root CA sisteminizde bulunuyor.
✔ Alan adı doğrulanmış.
14. Sonuç Kodu
Verify return code: 0 (ok)
OpenSSL'de
0
her zaman
başarılı doğrulama
anlamına gelir.
Genel Değerlendirme
Bu çıktıya göre Cisco'nun HTTPS altyapısı aşağıdaki özelliklere sahiptir:
| Özellik | Değer |
|---|---|
| Alan Adı | www.cisco.com |
| Sertifika Türü | X.509 |
| Açık Anahtar Algoritması | RSA 2048 bit |
| Sertifika İmza Algoritması | SHA-256 with RSA |
| Anahtar Değişim Algoritması | X25519 (ECDHE) |
| TLS Sürümü | TLS 1.2 |
| Şifre Takımı | ECDHE-RSA-AES256-GCM-SHA384 |
| Root CA | IdenTrust Commercial Root CA 1 |
| Ara CA | HydrantID Server CA O1 |
| Sertifika Geçerliliği | 22 Ağustos 2025 – 21 Eylül 2026 |
| Sertifika Zinciri | Eksiksiz |
| Doğrulama Sonucu | Verify return code: 0 (ok) |
Bu örnek, X.509 sertifikaları, sertifika zinciri (Certificate Chain), TLS Handshake, RSA ile kimlik doğrulama, X25519 ile anahtar değişimi, AES-256-GCM ile veri şifreleme ve SHA-256 tabanlı sertifika imzalama kavramlarının gerçek bir üretim ortamında nasıl birlikte çalıştığını gösteren başarılı bir TLS oturumudur.
Bilgi Kutusu: Wireshark ile TLS Handshake'i İzlemek
Bu süreci daha iyi anlamak için Wireshark kullanılabilir. tcp.port == 443 filtresi uygulanarak aşağıdaki paketler gözlemlenebilir:
Client Hello
Server Hello
Certificate
Certificate Verify
Finished
Application Data
Bu analiz, HTTPS'in yalnızca "şifreleme" olmadığını; kimlik doğrulama, anahtar uzlaşması ve güven zinciri doğrulamasını da içerdiğini somut olarak gösterir.
Bölüm Özeti
Bu bölümde:
TLS Handshake kavramını,
Client Hello ve Server Hello mesajlarını,
Sertifika doğrulama sürecini,
Anahtar değişimini,
Oturum anahtarının nasıl oluşturulduğunu,
TLS 1.2 ve TLS 1.3 arasındaki temel farkları,
Laboratuvarda kullanılan
openssl s_clientkomutunun arka planda hangi işlemleri gerçekleştirdiğini
ayrıntılı olarak inceledik.
Sonraki Bölüm
Bir sonraki bölümde laboratuvarın "Ortadaki Adam Kontrolü (Man-in-the-Middle Check)" kısmına geçeceğiz. HTTPS Proxy'nin çalışma mantığını, kurumsal ağlarda SSL/TLS Inspection teknolojilerini, saldırgan ile kurumsal güvenlik cihazları arasındaki farkları ve laboratuvarda anlatılan HTTPS Proxy senaryosunu adım adım analiz edeceğiz. Bu bölüm, laboratuvarın en önemli ve en öğretici kısmını oluşturacaktır.
Bölüm 5 – Ortadaki Adam (Man-in-the-Middle) Saldırıları ve HTTPS Proxy Analizi
Önceki bölümde HTTPS bağlantısı kurulurken gerçekleşen TLS Handshake sürecini ayrıntılı olarak inceledik. Tarayıcının sunucu sertifikasını doğruladığını, güven zincirini kontrol ettiğini ve güvenli bir oturum anahtarı oluşturduğunu öğrendik.
Bu noktada akla oldukça önemli bir soru gelir:
HTTPS trafiği tamamen şifreleniyorsa, şirketler çalışanların internet trafiğini nasıl inceleyebiliyor?
Ya da,
Bir saldırgan HTTPS bağlantısını gerçekten dinleyebilir mi?
Bu soruların cevabı laboratuvarın ikinci bölümünde anlatılan Ortadaki Adam (Man-in-the-Middle - MITM) senaryosunda yatmaktadır. Kaynak laboratuvar metni, HTTPS proxy kullanılarak TLS trafiğinin belirli koşullar altında nasıl incelenebileceğini ve bunun hangi güven modeline dayandığını ayrıntılı olarak açıklamaktadır.
Ortadaki Adam (Man-in-the-Middle - MITM) Nedir?
Ortadaki Adam (MITM) saldırısı, iki taraf arasında gerçekleşen iletişimin üçüncü bir taraf tarafından gizlice ele geçirilmesi, izlenmesi veya değiştirilmesi anlamına gelir.
Normal bir HTTPS bağlantısında iletişim şu şekildedir:
Tarayıcı ─────────────────────► Web Sunucusu
MITM saldırısında ise araya üçüncü bir taraf girer:
Tarayıcı ─────► Saldırgan ─────► Web Sunucusu
Bu durumda saldırgan:
Gönderilen verileri okuyabilir.
Verileri değiştirebilir.
Yeni veri ekleyebilir.
Sahte cevaplar gönderebilir.
HTTP kullanan sistemlerde bu oldukça kolaydır. Ancak HTTPS kullanıldığında işler değişir.
HTTPS MITM Saldırılarını Nasıl Engeller?
HTTPS'in en büyük amacı, istemci ile sunucu arasında güvenli bir kanal oluşturmaktır.
Tarayıcı, yalnızca güvenilir bir Sertifika Otoritesi tarafından imzalanmış sertifikalara güvenir.
Bir saldırgan sahte bir sertifika oluşturursa tarayıcı bunu fark eder ve aşağıdaki gibi uyarılar gösterir:
Bağlantınız gizli değil.
Sertifika güvenilir değil.
Sertifika doğrulanamadı.
NET::ERR_CERT_AUTHORITY_INVALID
Dolayısıyla klasik MITM saldırıları HTTPS üzerinde genellikle başarısız olur.
Peki Şirketler HTTPS Trafiğini Nasıl İnceliyor?
Kaynak laboratuvar metninin en önemli bölümlerinden biri tam olarak bunu açıklar.
Kurumsal ağlarda kullanılan güvenlik cihazları (HTTPS Proxy), kullanıcı bilgisayarlarına kurum tarafından güvenilen yeni bir Sertifika Otoritesi eklenmesi sayesinde HTTPS trafiğini çözümleyebilir.
Bu mekanizma saldırı değildir; kurum tarafından yönetilen ve kullanıcının cihazında güven ilişkisi kurulmuş bir yapı üzerine çalışır.
HTTPS Proxy Nedir?
HTTPS Proxy;
gelen HTTPS bağlantısını sonlandıran,
trafiğin şifresini çözen,
güvenlik kontrollerini yapan,
daha sonra yeniden şifreleyerek hedef sunucuya gönderen
özel bir güvenlik sistemidir.
Kurumsal ağlarda;
zararlı yazılım tespiti,
veri sızıntısı önleme (DLP),
URL filtreleme,
içerik denetimi,
yasal kayıt tutma
gibi amaçlarla kullanılabilir.
Laboratuvardaki Senaryo
Kaynak laboratuvar şu senaryoyu örnek olarak vermektedir:
Bir şirket yeni bir çalışanına dizüstü bilgisayar teslim eder.
BT departmanı;
gerekli yazılımları kurar,
güvenlik politikalarını uygular,
şirketin kendi Sertifika Otoritesini (CA) işletim sistemine veya tarayıcıya ekler.
Bundan sonra çalışan internete bağlandığında tüm HTTPS trafiği önce şirketin HTTPS Proxy sunucusuna yönlendirilir. Proxy, kullanıcıya hedef site adına kendi oluşturduğu sertifikayı sunar. Bu sertifika, şirket tarafından güvenilir olarak yüklenmiş CA tarafından imzalandığı için tarayıcı bunu geçerli kabul eder. Daha sonra proxy gerçek web sitesiyle ikinci bir TLS bağlantısı kurar ve iki bağlantı arasında trafiği çözüp yeniden şifreleyerek iletir.
HTTPS Proxy'nin Çalışma Mantığı
Aşağıdaki şema laboratuvardaki yapıyı özetlemektedir:
Şirket Ağı
Burada dikkat edilmesi gereken nokta şudur:
Proxy ile kullanıcı arasında ayrı bir TLS oturumu vardır.
Proxy ile gerçek web sitesi arasında ise ikinci ve bağımsız bir TLS oturumu bulunur.
Dolayısıyla proxy her iki oturumun da uç noktasıdır.
Laboratuvardaki 7 Adımın Ayrıntılı Analizi
Kaynak metin bu süreci yedi adımda açıklar.
Adım 1 – Kullanıcı HTTPS Sitesine Gitmek İster
Örneğin kullanıcı:
https://www.cisco.com
adresini ziyaret eder.
Tarayıcı normal bir HTTPS bağlantısı kuracağını düşünmektedir.
Adım 2 – Trafik HTTPS Proxy'ye Yönlendirilir
Şirket ağındaki yönlendirme kuralları nedeniyle bağlantı önce HTTPS Proxy'ye gider.
Proxy, hedef web sitesi adına hazırlanmış bir sertifika sunar.
Tarayıcı açısından bakıldığında her şey normal görünür.
Adım 3 – Tarayıcı Sertifikaya Güvenir
Tarayıcı sertifikayı inceler.
Sertifika, daha önce BT departmanı tarafından güvenilir depoya eklenen kurumsal CA tarafından imzalanmıştır.
Bu nedenle tarayıcı herhangi bir uyarı göstermez ve bağlantıyı kabul eder.
Adım 4 – İlk TLS Oturumu Kurulur
Artık kullanıcı ile HTTPS Proxy arasında güvenli bir TLS bağlantısı vardır.
Tarayıcı bunun gerçek web sitesiyle kurulduğunu zanneder.
Aslında bağlantının diğer ucunda proxy bulunmaktadır.
Adım 5 – Proxy Gerçek Web Sitesine Bağlanır
HTTPS Proxy bu kez gerçek sunucuya ikinci bir HTTPS bağlantısı kurar.
HTTPS Proxy
Bu bağlantı da tamamen güvenlidir.
Adım 6 – Trafik Çözülür
İşte en kritik aşama burasıdır.
Proxy;
kullanıcıdan gelen şifreli veriyi çözer,
güvenlik kontrollerini yapar,
gerekirse kayıt altına alır,
yeniden şifreler,
hedef sunucuya gönderir.
Sunucudan gelen cevaplar için de aynı işlem ters yönde uygulanır.
Bu nedenle proxy, her iki bağlantının da uç noktası olduğu için şifreli içeriği görebilir. Kaynak laboratuvar bunu özellikle vurgulamaktadır.
Adım 7 – Kullanıcı Her Şeyin Normal Olduğunu Düşünür
Tarayıcı hâlâ:
HTTPS simgesini gösterir.
Bağlantının şifreli olduğunu belirtir.
Gerçekten de bağlantılar şifrelidir; ancak kullanıcı ile hedef web sitesi arasında doğrudan tek bir TLS oturumu yoktur.
HTTPS Proxy Kötü Amaçlı mıdır?
Hayır.
Laboratuvar metni bu mekanizmayı kurumsal ağların TLS/SSL ile şifrelenmiş trafiği inceleyebilmesi için kullanılan bir yöntem olarak açıklamaktadır.
Kurumlar bunu;
zararlı yazılımları tespit etmek,
veri sızıntısını önlemek,
güvenlik politikalarını uygulamak
amacıyla kullanabilir.
Ancak aynı teknik, kullanıcının bilgisi ve güven ilişkisi olmadan uygulanmaya çalışılırsa klasik bir MITM saldırısına dönüşür ve modern tarayıcılar bunu genellikle sertifika uyarılarıyla engeller.
HTTPS Proxy ile Klasik MITM Arasındaki Fark
| Özellik | Klasik MITM | Kurumsal HTTPS Proxy |
|---|---|---|
| Güvenilir CA kullanır | Hayır | Evet (kurum tarafından yüklenmiş) |
| Tarayıcı uyarı verir | Genellikle evet | Güven ilişkisi kurulmuşsa hayır |
| Amaç | Yetkisiz dinleme veya değiştirme | Güvenlik denetimi ve politika uygulama |
| Güven zinciri | Bozulur | Kurumsal CA üzerinden yeniden kurulur |
Laboratuvarın Devamı İçin Neden Bu Konuyu Öğrendik?
Laboratuvarın sonraki adımlarında, gerçek sunucudan alınan sertifikanın parmak izi (Fingerprint) ile istemci tarafından görülen sertifikanın parmak izi karşılaştırılacaktır.
Eğer arada bir HTTPS Proxy varsa ve istemciye farklı bir sertifika sunuluyorsa, bu iki parmak izi farklı olacaktır. Kaynak laboratuvar, bu yöntemin HTTPS Proxy'nin varlığını değerlendirmek için kullanılabileceğini açıklamaktadır.
Bölüm Özeti
Bu bölümde:
Ortadaki Adam (MITM) kavramını,
HTTPS'in MITM saldırılarına karşı nasıl koruma sağladığını,
HTTPS Proxy'nin çalışma mantığını,
Laboratuvarda anlatılan yedi adımlık HTTPS Proxy senaryosunu,
Kurumsal HTTPS Proxy ile kötü amaçlı MITM arasındaki temel farkları
ayrıntılı olarak inceledik.
Sonraki Bölüm
Bir sonraki bölümde laboratuvarın uygulamalı kısmına geçeceğiz ve OpenSSL ile bir web sunucusunun sertifikasını alma, openssl s_client komutunun her parametresini satır satır açıklama, sertifikayı PEM formatında kaydetme ve ardından sertifika parmak izi (Fingerprint) hesaplama işlemlerini ayrıntılı olarak ele alacağız. Bu bölüm, laboratuvardaki komutların mantığını anlamak açısından en önemli uygulama bölümüdür.
Bölüm 6 – OpenSSL ile Sunucu Sertifikasının Alınması ve Sertifika Parmak İzinin (Fingerprint) Hesaplanması
Önceki bölümde HTTPS Proxy'nin çalışma mantığını ve Ortadaki Adam (Man-in-the-Middle - MITM) senaryosunu ayrıntılı olarak inceledik. Laboratuvar metninde de belirtildiği gibi, HTTPS Proxy'nin varlığını anlamanın en etkili yollarından biri sertifika parmak izlerini (Certificate Fingerprint) karşılaştırmaktır.
Bu bölümde laboratuvarın uygulamalı kısmına geçerek OpenSSL kullanacağız. Kullanacağımız komutlar sayesinde:
Bir HTTPS sunucusuna bağlanacağız.
Sunucunun dijital sertifikasını alacağız.
Sertifikayı PEM formatında kaydedeceğiz.
Sertifikanın SHA-1 parmak izini hesaplayacağız.
Sonuçları yorumlayacağız.
OpenSSL Nedir?
OpenSSL, açık kaynak kodlu, dünyanın en yaygın kriptografi araçlarından biridir.
Hem geliştiriciler hem de sistem yöneticileri tarafından;
TLS/SSL bağlantıları oluşturmak,
Sertifika üretmek,
CSR hazırlamak,
Sertifika doğrulamak,
Hash hesaplamak,
Dijital imza oluşturmak,
Anahtar yönetimi yapmak
amacıyla kullanılır.
Bugün;
Apache
Nginx
HAProxy
Postfix
OpenVPN
gibi birçok yazılım OpenSSL kütüphanelerinden yararlanır.
Laboratuvarda Kullanılan Komut
Laboratuvarın ilk OpenSSL komutu şöyledir:
echo -n | openssl s_client -connect cisco.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ./cisco.pem
İlk bakışta oldukça karmaşık görünmektedir.
Aslında bu komut dört farklı Linux aracının birlikte kullanılmasından oluşur.
Şimdi satır satır inceleyelim.
Komutun Genel Yapısı
echo -n
Her araç farklı bir görev yerine getirir.
1. echo -n
Komutun ilk bölümü:
echo -n
Görevi
Standart çıktıya boş bir satır gönderir.
Buradaki amaç;
OpenSSL bağlantısını başlatmak ancak kullanıcıdan ek veri beklenmesini önlemektir.
Normalde
openssl s_client
çalıştırıldığında bağlantı açık kalır.
Terminal kullanıcıdan veri girmesini bekler.
Bunu istemediğimiz için
echo -n
ile boş veri gönderiyoruz.
Neden "-n" Parametresi Kullanılıyor?
Normalde
echo
komutu satır sonuna
\n
karakteri ekler.
Ancak
echo -n
komutu bunu yapmaz.
Yani gerçekten boş veri gönderilmiş olur.
2. Pipe ( | ) Operatörü
İlk pipe:
|
Linux'un en güçlü özelliklerinden biridir.
Anlamı:
Bir komutun çıktısını diğer komutun girdisi yap.
Örneğin
Komut A | Komut B
şeklinde yazıldığında;
Komut A'nın çıktısı doğrudan Komut B'ye gönderilir.
Bu laboratuvarda tam üç adet pipe kullanılmaktadır.
3. openssl s_client
Komutun en önemli kısmıdır.
openssl s_client
Bu araç;
Bir HTTPS sunucusuna bağlanır.
TLS Handshake gerçekleştirir.
Sunucunun sertifikasını alır.
Bağlantı bilgilerini görüntüler.
s_client Nedir?
"s_client"
şu anlama gelir:
SSL/TLS Client
Yani OpenSSL'in istemci modudur.
Bir web tarayıcısı gibi davranır.
Sunucuya bağlanır.
Sertifikayı ister.
TLS bağlantısını test eder.
-connect Parametresi
Komutun devamı:
-connect cisco.com:443
Burada iki bilgi bulunmaktadır.
cisco.com
Bağlanılacak sunucu.
443
HTTPS portudur.
Port numarası yazılmasaydı:
443
varsayılan olarak kullanılabilirdi.
Ancak açıkça yazılması daha doğru bir yaklaşımdır.
Komut Çalıştırıldığında Neler Olur?
OpenSSL aşağıdaki işlemleri gerçekleştirir.
DNS Sorgusu
Laboratuvar çıktısında şu satırlar görülmektedir:
depth=2
depth=1
depth=0
Bu satırlar güven zincirini göstermektedir.
depth=2 Ne Demektir?
depth=2
En üst seviyedeki
Root CA
kontrol edilmektedir.
Örneğin:
QuoVadis Root CA
depth=1
depth=1
Ara Sertifika Otoritesidir.
Örneğin:
HydrantID SSL ICA G2
depth=0
depth=0
Gerçek web sitesi sertifikasıdır.
Örneğin:
www.cisco.com
Bu sıralama bize güven zincirinin doğru şekilde kurulduğunu gösterir.
verify return:1
Çıktıda birkaç kez aşağıdaki ifade görülür:
verify return:1
Bu ifade;
OpenSSL'in ilgili sertifikayı başarıyla doğruladığını gösterir.
Yani;
✔ İmza doğru
✔ Zincir doğru
✔ Sertifika kabul edildi
anlamına gelir.
DONE
En sonunda
DONE
yazısı görülür.
Bu,
TLS Handshake'in başarıyla tamamlandığını gösterir.
4. sed Komutu
Komutun ikinci önemli kısmı:
sed -ne
sed,
Linux'un güçlü metin işleme araçlarından biridir.
Buradaki amacı:
OpenSSL çıktısından yalnızca sertifika kısmını almaktır.
Kullanılan ifade
/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p
Anlamı:
Başlangıç satırını bul
↓
-----BEGIN CERTIFICATE-----
Bitiş satırını bul
↓
-----END CERTIFICATE-----
Aradaki tüm satırları yazdır.
Böylece OpenSSL'in uzun teknik çıktısı yerine yalnızca sertifika elde edilir.
PEM Dosyası Oluşturma
Komutun son kısmı:
> ./cisco.pem
çıktıyı
cisco.pem
isimli dosyaya kaydeder.
PEM formatı Base64 kodlanmış sertifika verisini içerir.
Dosya şu şekilde görünür:
-----BEGIN CERTIFICATE-----
Laboratuvar, istenirse bu dosyanın cat cisco.pem komutuyla görüntülenebileceğini de göstermektedir.
Sertifika Parmak İzini Hesaplama
Laboratuvardaki ikinci önemli komut şöyledir:
openssl x509 -noout -in cisco.pem -fingerprint -sha1
Bu komut, kaydedilen sertifikanın SHA-1 parmak izini hesaplar. Kaynak laboratuvarda örnek olarak aşağıdaki biçimde bir çıktı gösterilmektedir:
SHA1 Fingerprint=64:19:CA:40:E2:1B:3F:92:29:21:A9:CE:60:7D:C9:0C:39:B5:71:3E
Gerçek ortamınızda görülen değer farklı olabilir; çünkü sertifikalar belirli aralıklarla yenilenir ve işletim sistemi ya da sunucu yapılandırması da sonucu etkileyebilir.
Komutun Parametreleri
openssl x509
Bir X.509 sertifikası üzerinde işlem yapılacağını belirtir.
-in
Girdi dosyasını belirtir.
-in cisco.pem
-noout
Sertifikanın tamamını ekrana yazdırmaz.
Sadece istenen bilgiyi gösterir.
-fingerprint
Sertifikanın parmak izini hesaplar.
-sha1
Hash algoritmasını belirtir.
Bu laboratuvarda özellikle SHA-1 kullanılmıştır. Kaynak metin ayrıca parmak izi tablolarının zaman içinde değişebileceğini ve farklı işletim sistemlerinde farklı sonuçlar görülebileceğini belirtmektedir.
Parmak İzi (Fingerprint) Nedir?
Parmak izi, sertifikanın tamamı üzerinden hesaplanan sabit uzunlukta bir hash değeridir.
Bu değer:
Sertifikanın dijital özeti,
Benzersiz kimliği,
Hızlı doğrulama aracı
olarak düşünülebilir.
Sertifikanın içinde tek bir bit bile değişirse hesaplanan parmak izi tamamen farklı olur.
Bu özellik, laboratuvarın sonraki adımında HTTPS Proxy'nin varlığını değerlendirmek için kullanılacaktır.
Bölüm Özeti
Bu bölümde:
OpenSSL'in ne olduğunu,
openssl s_clientkomutunun nasıl çalıştığını,echo,pipevesedkomutlarının görevlerini,Sertifikanın PEM formatında nasıl kaydedildiğini,
openssl x509komutuyla SHA-1 parmak izinin nasıl hesaplandığını,Parmak izinin neden sertifikanın benzersiz özeti olarak kabul edildiğini
laboratuvar metnindeki uygulamaları temel alarak ayrıntılı şekilde inceledik.
Sonraki Bölüm
Bir sonraki bölümde laboratuvardaki "Parmak İzlerinin Karşılaştırılması" aşamasını ayrıntılı olarak inceleyeceğiz. Parmak izlerinin neden karşılaştırıldığı, SHA-1 ve SHA-256 parmak izleri arasındaki farklar, HTTPS Proxy'nin parmak izi analiziyle nasıl tespit edilebileceği ve laboratuvarda yer alan değerlendirme sorularının teknik gerekçeleri adım adım açıklanacaktır.
Bölüm 7 – Sertifika Parmak İzlerinin (Certificate Fingerprint) Karşılaştırılması ve HTTPS Proxy Tespiti
Önceki bölümde laboratuvarda kullanılan OpenSSL komutlarını ayrıntılı olarak inceledik. openssl s_client komutuyla bir web sunucusunun sertifikasını almayı, openssl x509 komutuyla ise sertifikanın SHA-1 parmak izini (Fingerprint) hesaplamayı öğrendik.
Bu bölümde laboratuvarın en önemli aşamasına geçiyoruz:
Sertifika parmak izleri neden karşılaştırılır?
Bu sorunun cevabı yalnızca laboratuvar için değil, aynı zamanda gerçek hayatta HTTPS bağlantılarının güvenilirliğini değerlendirmek açısından da büyük önem taşımaktadır.
Kaynak laboratuvar metni, HTTPS Proxy'nin varlığını değerlendirmek amacıyla gerçek sunucunun sertifika parmak izi ile istemcinin gördüğü sertifikanın parmak izinin karşılaştırılmasını önermektedir.
Sertifika Parmak İzi (Fingerprint) Nedir?
Her dijital sertifika benzersizdir.
Sertifikanın tamamı belirli bir hash algoritmasından geçirilerek tek bir özet değer elde edilir.
Bu özet değere;
Fingerprint
Thumbprint
Sertifika Özeti
isimleri verilir.
Örneğin:
SHA1 Fingerprint
Bu değer yalnızca o sertifikaya aittir.
Parmak İzi Neden Benzersizdir?
Hash algoritmalarının en önemli özelliği şudur:
En küçük değişiklik bile tamamen farklı bir hash üretir.
Örneğin aşağıdaki iki metni düşünelim.
Cisco
ve
cisco
Sadece ilk harf değişmiştir.
Ancak hash değerleri tamamen farklı olacaktır.
Aynı durum sertifikalar için de geçerlidir.
Sertifikada Tek Bir Bit Değişirse Ne Olur?
Örneğin sertifikanın içinde
www.cisco.com
yerine
www.cisc0.com
yazılsaydı
parmak izi tamamen değişirdi.
İşte laboratuvarın temel mantığı budur.
Laboratuvarın Temel Fikri
Kaynak laboratuvar şu yaklaşımı kullanmaktadır:
Önce gerçek sunucunun sertifikası alınır.
↓
Parmak izi hesaplanır.
↓
Yerel bilgisayarın gördüğü sertifika ile karşılaştırılır.
↓
İki değer aynı mı?
Karşılaştırma Diyagramı
Cisco Sunucusu
Parmak İzleri Aynıysa
Eğer
Gerçek sunucudan alınan sertifika
ile
Bilgisayarın gördüğü sertifika
aynıysa
parmak izleri de aynı olacaktır.
Bu durumda:
✔ Sertifika değiştirilmemiştir.
✔ Kullanıcı gerçek sunucuya bağlanmaktadır.
✔ HTTPS Proxy bulunmadığı düşünülebilir.
Parmak İzleri Farklıysa
Eğer iki parmak izi farklıysa
bunun anlamı şudur:
İstemcinin gördüğü sertifika
↓
Gerçek sunucunun sertifikası değildir.
Bu durum aşağıdaki nedenlerden biriyle açıklanabilir:
Kurumsal HTTPS Proxy
Sertifikanın yenilenmiş olması
Yanlış sunucuya bağlanılması
Sertifika zincirindeki farklılıklar
Laboratuvar metni, parmak izleri eşleşmiyorsa istemci ile doğrulanan HTTPS sitesi arasında başka bir uç nokta (örneğin HTTPS Proxy) bulunabileceğini belirtmektedir. Aynı zamanda sertifikaların zaman içinde yenilenebileceği ve bu nedenle parmak izlerinin de değişebileceği uyarısını yapmaktadır.
HTTPS Proxy Parmak İzini Neden Değiştirir?
Kurumsal HTTPS Proxy
gerçek sertifikayı kullanıcıya iletmez.
Onun yerine
kendisi yeni bir sertifika üretir.
Örneğin
Gerçek sertifika:
CN=www.cisco.com
Kurumsal Proxy de kullanıcıya yine:
CN=www.cisco.com
gösterir.
Fakat
imzalayan kuruluş farklıdır.
Dolayısıyla
sertifikanın tamamı değişmiştir.
Bu nedenle
hash değeri de değişecektir.
Sertifika Zinciri Nasıl Değişir?
Gerçek bağlantı:
Root CA
HTTPS Proxy:
Şirket Root CA
Alan adı aynı olabilir.
Fakat
sertifika tamamen farklıdır.
Laboratuvardaki Soru
Kaynak laboratuvar şu soruyu yöneltmektedir:
Parmak izleri uyuşuyor mu?
Bu sorunun cevabı tamamen laboratuvarın çalıştırıldığı ortama bağlıdır.
Örneğin:
Ev internetinde
çoğu zaman
"Evet"
cevabı alınabilir.
Kurumsal ağlarda
HTTPS Inspection açıksa
"Hayır"
cevabı görülebilir.
Parmak İzleri Aynıysa Bu Ne Anlama Gelir?
Kaynak laboratuvara göre:
İki parmak izi aynıysa
bağlantının araya farklı bir sertifika eklenmeden kurulmuş olduğu değerlendirilir.
Yani istemci ile web sitesi arasında laboratuvarın tanımladığı türde bir HTTPS Proxy bulunmadığı düşünülebilir.
Parmak İzleri Farklıysa Bu Ne Anlama Gelir?
Kaynak laboratuvara göre:
İki parmak izi uyuşmuyorsa
istemcinin gördüğü sertifika
gerçek web sitesinin sertifikası değildir.
Dolayısıyla
bağlantı farklı bir uç noktaya kurulmuş olabilir.
Bu durum laboratuvar bağlamında HTTPS Proxy'nin varlığına işaret edebilir. Ancak sertifika yenilemeleri gibi meşru nedenler de değerlendirilmelidir.
Bu Yöntem %100 Garantili midir?
Laboratuvarın son değerlendirme sorularından biri de budur.
Cevap:
Hayır.
Çünkü:
Sertifikalar düzenli olarak yenilenir.
Parmak izi zaman içinde değişebilir.
Farklı zamanlarda alınan sertifikalar aynı sunucuya ait olsa bile farklı olabilir.
Yük dengeleme (Load Balancer) kullanan büyük yapılarda farklı sunucular farklı sertifikalar sunabilir.
Bazı servislerde coğrafi bölgeye göre farklı sertifikalar kullanılabilir.
Bu nedenle yalnızca parmak izi farklılığına bakarak kesin bir sonuca varılmaz; sertifikanın geçerlilik tarihi, imzalayan CA ve sertifika zinciri de birlikte değerlendirilmelidir.
SHA-1 mi, SHA-256 mı?
Laboratuvar örneklerinde SHA-1 kullanılmıştır.
openssl x509 -fingerprint -sha1
Bunun nedeni laboratuvarın öğretim amacıyla hazırlanmış olması ve SHA-1 parmak izlerinin uzun yıllar boyunca yaygın olarak kullanılmasıdır. Günümüzde ise yeni sistemlerde sertifika parmak izleri çoğunlukla SHA-256 ile de gösterilmektedir.
SHA-256 parmak izi almak için:
openssl x509 -in cisco.pem -noout -fingerprint -sha256
Bu komutun mantığı SHA-1 ile aynıdır; yalnızca kullanılan hash algoritması değişir.
Parmak İzleri Nerelerde Kullanılır?
Sertifika parmak izleri yalnızca HTTPS Proxy tespiti için kullanılmaz.
Yaygın kullanım alanları:
HTTPS bağlantılarının doğrulanması
VPN sertifikalarının kontrolü
SSH anahtar doğrulaması
Kod imzalama doğrulaması
Mobil uygulamalarda Certificate Pinning
Kurumsal güvenlik denetimleri
Dijital adli bilişim (Forensics)
Laboratuvar Sorularının Açıklamalı Cevapları
Soru: Parmak izleri nelerdir? Neden önemlidir?
Cevap:
Parmak izi, dijital sertifikanın tamamı üzerinden hesaplanan benzersiz bir hash değeridir. Sertifikanın değişip değişmediğini hızlı bir şekilde doğrulamak için kullanılır.
Soru: Parmak izini kim hesaplar?
Cevap:
Parmak izi, sertifika dosyası üzerinde çalışan yazılım tarafından (örneğin OpenSSL veya işletim sistemi araçları) hesaplanır. Aynı sertifika kullanıldığında aynı algoritma ile her zaman aynı sonuç elde edilir.
Soru: Parmak izleri uyuşuyor mu?
Cevap:
Bu sorunun cevabı kullanılan ağ ortamına ve sertifikanın güncelliğine bağlıdır. Laboratuvarın amacı, iki değeri karşılaştırarak olası farklılıkları yorumlamaktır.
Soru: Bu ne anlama geliyor?
Cevap:
Eşleşme varsa istemcinin gördüğü sertifika ile karşılaştırılan sertifika aynıdır. Eşleşmiyorsa arada farklı bir sertifika sunulmuş olabilir veya sertifika zaman içinde yenilenmiş olabilir.
Soru: Bu yöntem %100 garantili mi?
Cevap:
Hayır. Parmak izi karşılaştırması güçlü bir göstergedir; ancak tek başına kesin kanıt değildir. Sonuçlar sertifika zinciri, geçerlilik süresi ve sertifikanın yenilenme durumu ile birlikte değerlendirilmelidir.
Bölüm Özeti
Bu bölümde:
Sertifika parmak izlerinin neden hesaplandığını,
Parmak izlerinin nasıl karşılaştırıldığını,
HTTPS Proxy'nin neden farklı bir parmak izi oluşturduğunu,
Laboratuvardaki değerlendirme sorularının teknik açıklamalarını,
SHA-1 ve SHA-256 parmak izlerinin kullanım amacını
kaynak laboratuvarı temel alarak ayrıntılı biçimde inceledik.
Sonraki Bölüm
Bir sonraki bölümde laboratuvarın "Zorluklar (Challenges)" kısmını ele alacağız. Web tarayıcılarının grafik arayüzünden sertifika ve parmak izi inceleme yöntemlerini, OpenSSL ile farklı web sitelerinin sertifikalarının analiz edilmesini ve laboratuvarın son değerlendirme sorusu olan "HTTPS Proxy'nin çalışması için ne gereklidir?" sorusunu ayrıntılı olarak açıklayacağız.
Bölüm 8 – Tarayıcı Üzerinden Sertifika İnceleme, OpenSSL ile Doğrulama ve Laboratuvarın Son Değerlendirmesi
Önceki bölümde sertifika parmak izlerinin (Certificate Fingerprint) ne olduğunu, nasıl hesaplandığını ve HTTPS Proxy tespitinde neden önemli olduğunu ayrıntılı olarak öğrendik.
Bu bölümde laboratuvarın "Zorluklar (Challenges)" kısmını uygulamalı olarak ele alacağız. Kaynak laboratuvar metni bu bölümde kullanıcıdan iki temel çalışma yapmasını istemektedir:
Web tarayıcısının grafik arayüzünü (GUI) kullanarak sertifika ve parmak izi bilgilerini incelemek.
OpenSSL kullanarak çeşitli web sitelerinin sertifikalarını doğrulamak ve karşılaştırmak.
Ayrıca laboratuvarın son değerlendirme sorusu olan "HTTPS Proxy'nin çalışması için ne gereklidir?" sorusunu ayrıntılı olarak açıklayacağız.
Laboratuvarın Challenge Bölümünün Amacı
Bu bölümün amacı yalnızca OpenSSL komutlarını çalıştırmak değildir.
Asıl amaç;
Tarayıcının gösterdiği bilgiler
OpenSSL'in gösterdiği bilgiler
Sertifika zinciri
Parmak izi
Sertifika Otoritesi
arasındaki ilişkiyi anlamaktır.
Böylece aynı sertifika farklı araçlarla doğrulanabilir.
Challenge 1
Tarayıcı Üzerinden Sertifika İnceleme
Laboratuvar kullanıcıdan, popüler web sitelerinin sertifikalarını doğrudan tarayıcı üzerinden incelemesini istemektedir.
Bu yöntem OpenSSL kullanmadan da sertifika bilgilerine ulaşılabileceğini göstermektedir.
Google Chrome'da Sertifika Görüntüleme
Bir HTTPS sitesini açın.
Örneğin:
https://www.cisco.com
Adres çubuğundaki kilit simgesine tıklayın.
Ardından;
Bağlantı Güvenli
seçeneğini açın.
Daha sonra
Sertifika
veya
Certificate is Valid
bağlantısına tıklayın.
Açılan pencerede aşağıdaki bilgiler görülebilir.
Subject
Issuer
Validity
Public Key
Signature Algorithm
Fingerprint
Certification Path
Firefox'ta Sertifika İnceleme
Firefox'ta da benzer bilgiler görülebilir.
İzlenecek yol:
Kilit Simgesi
Firefox sertifika ayrıntılarını oldukça ayrıntılı gösterir.
Özellikle
SAN
Key Usage
Extensions
bölümleri detaylı incelenebilir.
Sertifika Zincirini İncelemek
Sertifika penceresinde genellikle
Certification Path
isimli bölüm bulunur.
Örneğin
Root CA
şeklinde gösterilir.
Bu zincir sayesinde
tarayıcı neden bu sertifikaya güvendiğini açıklamaktadır.
Sertifika Parmak İzini Bulmak
Sertifika ayrıntılarında genellikle aşağıdaki alanlar bulunur.
SHA-1 Fingerprint
veya
SHA-256 Fingerprint
Bu değerler OpenSSL ile hesaplanan değerlerle karşılaştırılabilir.
Laboratuvarın amacı da tam olarak budur.
Challenge 2
OpenSSL ile Farklı Sitelerin Analizi
Laboratuvarın ikinci zorluk çalışması,
aynı işlemleri farklı web siteleri üzerinde uygulamaktır.
Örneğin
echo -n | openssl s_client -connect google.com:443
GitHub
echo -n | openssl s_client -connect github.com:443
Wikipedia
echo -n | openssl s_client -connect wikipedia.org:443
OpenAI
echo -n | openssl s_client -connect openai.com:443
Her komutta;
Sertifika zinciri
Issuer
Subject
Public Key
Sertifika süresi
karşılaştırılabilir.
Sertifika Zincirleri Aynı mı?
Hayır.
Her web sitesi
aynı Sertifika Otoritesini kullanmak zorunda değildir.
Örneğin
Site A
DigiCert
kullanabilir.
Site B
Let's Encrypt
kullanabilir.
Site C
Sectigo
kullanabilir.
Buna rağmen
hepsi güvenilir olabilir.
Çünkü
bu CA'ların Root Sertifikaları
işletim sisteminizde bulunmaktadır.
Aynı CA Her Zaman Aynı Sertifikayı mı Üretir?
Hayır.
Bir CA
aynı alan adı için
farklı zamanlarda
tamamen farklı sertifikalar oluşturabilir.
Örneğin
2025 yılında alınan sertifika
ile
2026 yılında alınan sertifika
aynı olmayabilir.
Dolayısıyla
Fingerprint
de değişecektir.
OpenSSL ile Sertifikanın Ayrıntılı Analizi
Aşağıdaki komut
bir sertifikanın tamamını gösterir.
openssl x509 -in cisco.pem -text -noout
Bu komut sayesinde
şunlar görülebilir.
Version
Serial Number
Issuer
Subject
Public Key
SAN
Key Usage
Basic Constraints
Signature Algorithm
Extensions
Bu komut
bir sistem yöneticisinin
en sık kullandığı OpenSSL komutlarından biridir.
Sertifika Zincirini Doğrulama
OpenSSL
yalnızca sertifikayı göstermekle kalmaz.
Aynı zamanda
sertifika zincirini de doğrulayabilir.
Örneğin
openssl verify cisco.pem
çıktısı
cisco.pem: OK
şeklindeyse
sertifika
doğru yapılandırılmıştır.
Not: Bu komutun doğru sonuç verebilmesi için doğrulamada kullanılacak güvenilir CA deposunun veya gerekli ara sertifikaların erişilebilir olması gerekir. Aksi hâlde doğrulama hatası alınabilir.
Sertifika Analizi Yaparken Nelere Bakılmalıdır?
Bir sistem yöneticisi
yalnızca
Fingerprint'e bakmaz.
Aşağıdaki alanların tamamını inceler.
| Kontrol | Açıklama |
|---|---|
| Subject | Sertifika kime ait? |
| Issuer | Kim imzalamış? |
| Validity | Süresi dolmuş mu? |
| SAN | Alan adı doğru mu? |
| Public Key | Güvenli mi? |
| Signature Algorithm | SHA-256 mı? |
| Key Usage | Doğru amaç için mi? |
| Basic Constraints | CA mı? |
| Fingerprint | Beklenen sertifika mı? |
Laboratuvarın Son Sorusu
Kaynak laboratuvarın değerlendirme sorusu şöyledir:
HTTPS Proxy'nin çalışması için ne gereklidir?
Bu sorunun cevabını artık rahatlıkla verebiliriz.
HTTPS Proxy'nin Çalışabilmesi İçin Gerekenler
Bir HTTPS Proxy'nin kullanıcı tarafından güvenilir kabul edilmesi için aşağıdaki şartların sağlanması gerekir:
1. Güvenilir Bir Sertifika Otoritesi
Proxy,
istemciye sunacağı sertifikaları
bir Sertifika Otoritesi kullanarak imzalamalıdır.
2. Bu CA'nın Kullanıcının Sertifika Deposunda Bulunması
En kritik şart budur.
Eğer
Proxy'nin kullandığı CA
Windows
Linux
Firefox
Chrome
tarafından güvenilmiyorsa
bağlantı kurulmaz.
Tarayıcı
sertifika uyarısı verir.
Kaynak laboratuvarın HTTPS Proxy senaryosunun temel dayanağı da budur: Kurumun CA sertifikasının istemcinin güvenilir sertifika deposuna eklenmiş olması.
3. Trafiğin Proxy Üzerinden Geçmesi
Ağ yönlendirmesi
Proxy'yi
zorunlu kılmalıdır.
Aksi durumda
istemci
doğrudan
web sunucusuna bağlanacaktır.
4. Proxy'nin Gerçek Siteyle Ayrı Bir TLS Oturumu Kurması
Proxy
hem istemciyle
hem de
gerçek sunucuyla
ayrı TLS bağlantıları kurar.
Bu sayede
iki oturum arasında
veriyi inceleyebilir.
Gerçek Hayatta Nerelerde Kullanılır?
Kurumsal ağlarda HTTPS inceleme özelliği şu amaçlarla kullanılabilir:
Zararlı yazılım analizi
Virüs taraması
Veri sızıntısı önleme (DLP)
URL filtreleme
Güvenlik politikalarının uygulanması
Kayıt (log) tutma
Yasal uyumluluk gereksinimleri
Bu işlemler yalnızca kurumun yönetimindeki cihazlarda ve ilgili politika ile mevzuata uygun şekilde gerçekleştirilmelidir.
Bölüm Özeti
Bu bölümde;
Tarayıcı üzerinden sertifika incelemeyi,
OpenSSL ile farklı HTTPS sitelerinin analiz edilmesini,
Sertifika zincirinin yorumlanmasını,
Sertifika doğrulama sürecini,
Laboratuvarın "Challenge" bölümündeki uygulamaları,
"HTTPS Proxy'nin çalışması için ne gereklidir?" sorusunun ayrıntılı cevabını
kaynak laboratuvar temelinde ayrıntılı olarak ele aldık.
Sonraki Bölüm (Ek Uzmanlık Bölümü)
Laboratuvarın zorunlu kısmı burada tamamlanmaktadır. Ancak makaleyi kapsamlı bir eğitim kaynağına dönüştürmek için bir sonraki bölümde "Sertifika Hataları ve Sorun Giderme (Certificate Troubleshooting)" konusunu ele alacağız. Bu bölümde;
NET::ERR_CERT_AUTHORITY_INVALIDNET::ERR_CERT_DATE_INVALIDERR_CERT_COMMON_NAME_INVALIDEksik ara sertifika (Intermediate CA)
Zincir doğrulama hataları
OpenSSL ile hata analizi
Windows, Linux ve Pardus'ta sertifika sorunlarının giderilmesi
gibi gerçek sistemlerde sık karşılaşılan problemleri uygulamalı örneklerle inceleyeceğiz. Bu bölüm, özellikle sistem yöneticileri ve siber güvenlik uzmanları için pratik bir başvuru kaynağı niteliğinde olacaktır.
Bölüm 9 – Sertifika Hataları ve Sorun Giderme (Certificate Troubleshooting)
Önceki bölümde laboratuvarın "Challenge" çalışmalarını tamamladık ve HTTPS Proxy'nin çalışabilmesi için gerekli koşulları ayrıntılı olarak inceledik.
Gerçek sistemlerde ise her HTTPS bağlantısı sorunsuz çalışmayabilir. Sistem yöneticileri ve siber güvenlik uzmanları, zaman zaman tarayıcıların gösterdiği sertifika hatalarıyla karşılaşırlar. Bu hataların doğru yorumlanması, hem güvenliğin korunması hem de hizmet sürekliliğinin sağlanması açısından kritik öneme sahiptir.
Bu bölümde en sık karşılaşılan sertifika hatalarını, nedenlerini ve OpenSSL kullanarak nasıl analiz edileceğini ayrıntılı olarak inceleyeceğiz.
Sertifika Hataları Neden Oluşur?
HTTPS bağlantısı kurulurken tarayıcı birçok doğrulama yapar.
Aşağıdaki kontrollerden herhangi biri başarısız olursa kullanıcıya sertifika hatası gösterilir.
Kontrol edilen başlıca alanlar:
Sertifikanın geçerlilik tarihi
Alan adı doğrulaması
Sertifika zinciri
Güvenilir Sertifika Otoritesi
Dijital imza
İptal (Revocation) durumu
Bu kontrollerden yalnızca biri bile başarısız olursa HTTPS bağlantısı güvenli kabul edilmez.
Sertifika Doğrulama Süreci
HTTPS Bağlantısı
1. NET::ERR_CERT_AUTHORITY_INVALID
En sık görülen sertifika hatalarından biridir.
Chrome'da genellikle şu şekilde görünür:
NET::ERR_CERT_AUTHORITY_INVALID
Anlamı
Tarayıcı
sertifikayı imzalayan
Sertifika Otoritesine güvenmiyor.
Muhtemel Sebepler
Self-Signed Certificate kullanılması
Kurumsal CA'nın yüklenmemiş olması
Sahte sertifika
Eksik Root CA
Yanlış yapılandırılmış HTTPS Proxy
Nasıl Çözülür?
Sunucu tarafı
✔ Güvenilir CA kullanın.
✔ Sertifika zincirini doğru yükleyin.
İstemci tarafı
✔ Root CA'nın güvenilir sertifika deposunda bulunduğunu doğrulayın.
✔ Kurumsal CA'nın doğru şekilde dağıtıldığını kontrol edin.
OpenSSL ile Kontrol
openssl s_client -connect example.com:443
Çıktıda
Verify return code: 20
görülüyorsa
istemci ilgili CA'yı bulamamıştır.
2. NET::ERR_CERT_DATE_INVALID
Bu hata
sertifikanın geçerlilik tarihinin uygun olmadığını gösterir.
Sertifika Süresi
Her sertifikada iki kritik alan bulunur.
Not Before
ve
Not After
Örneğin
Not Before
Hata Nedenleri
Sertifikanın süresi dolmuş olabilir.
Sertifika henüz geçerli olmayabilir.
Bilgisayarın tarihi yanlış olabilir.
Sunucu tarihi yanlış olabilir.
OpenSSL ile Kontrol
openssl x509 -in cisco.pem -dates -noout
Örnek çıktı
notBefore=Jan 1 00:00:00 2026 GMT
3. ERR_CERT_COMMON_NAME_INVALID
Bu hata
alan adının
sertifikayla uyuşmadığını gösterir.
Örneğin
Kullanıcı
https://example.com
adresine gider.
Fakat sertifikada
www.example.com
bulunuyorsa
uyumsuzluk oluşabilir.
Modern sertifikalarda bu kontrol çoğunlukla Subject Alternative Name (SAN) alanı üzerinden yapılır.
SAN Alanını Görüntüleme
openssl x509 -text -noout -in cisco.pem
çıktısında
Subject Alternative Name
bölümü incelenmelidir.
4. Eksik Intermediate CA
Bu hata
sunucu yalnızca kendi sertifikasını gönderdiğinde oluşabilir.
Doğru zincir
Root CA
olmalıdır.
Bazı sunucular
Intermediate CA'yı göndermeyi unutabilir.
Sonuç
Tarayıcı
sertifikayı doğrulayamaz.
OpenSSL ile Kontrol
openssl s_client -connect example.com:443
çıktısında
Certificate chain
bölümü incelenmelidir.
Eksik halka varsa
zincir tamamlanamaz.
5. Self-Signed Certificate
Bazı kurumlar
kendileri sertifika üretir.
Subject
Bu durumda
Issuer
ile
Subject
aynıdır.
OpenSSL
openssl x509 -in server.pem -text
çıktısında
Issuer
görülebilir.
Kullanılmalı mı?
Laboratuvar ortamlarında
evet.
İnternet üzerindeki gerçek web sitelerinde
hayır.
Çünkü
tarayıcı güvenmeyecektir.
6. Sertifika Zinciri Hatası
OpenSSL
zinciri doğrulayamazsa
şöyle bir çıktı verebilir.
Verify return code: 21
veya
unable to verify the first certificate
Bu hata
çoğunlukla
eksik Intermediate CA
anlamına gelir.
7. Zayıf İmza Algoritması
Eski sertifikalarda
SHA1
kullanılmış olabilir.
Modern tarayıcılar
artık
SHA-1 ile imzalanmış yeni sertifikalara güvenmez.
Bunun yerine
SHA-256
veya daha güçlü algoritmalar tercih edilir.
8. Anahtar Uzunluğu Çok Küçük
Eski sertifikalarda
RSA 1024
bulunabilir.
Günümüzde önerilen minimum değer
RSA 2048
veya
ECC P-256
kullanılmasıdır.
OpenSSL ile Anahtar Uzunluğu
openssl x509 -text -noout -in cisco.pem
çıktısında
Public-Key
bölümü incelenir.
Örneğin
Public-Key: (2048 bit)
OpenSSL ile Tam Analiz
Bir sistem yöneticisinin en çok kullandığı komutlardan biri
openssl x509 -text -noout -in cisco.pem
komutudur.
Bu komutla;
Version
Serial Number
Issuer
Subject
Validity
SAN
Extensions
Public Key
Signature Algorithm
Fingerprint
tek ekranda görülebilir.
Linux'ta Sertifika Sorunlarını İnceleme
Linux sistemlerde güvenilir sertifikalar genellikle aşağıdaki dizinlerde bulunur.
Debian, Ubuntu ve Pardus tabanlı sistemlerde:
/etc/ssl/certs/
ve
/usr/share/ca-certificates/
Güvenilir CA deposu güncellendikten sonra aşağıdaki komut çalıştırılabilir:
sudo update-ca-certificates
Bu işlem yeni eklenen CA sertifikalarının sistem tarafından kullanılmasını sağlar.
Windows'ta Sertifika Yönetimi
Windows'ta sertifikalar
certmgr.msc
aracıyla görüntülenebilir.
Burada;
Trusted Root Certification Authorities
Intermediate Certification Authorities
Personal
Trusted People
gibi depolar incelenebilir.
Gerçek Hayatta Sorun Giderme Adımları
Bir HTTPS bağlantısı çalışmıyorsa aşağıdaki sırayla inceleme yapmak faydalıdır.
| Adım | Kontrol |
|---|---|
| 1 | Alan adı doğru mu? |
| 2 | Sertifika süresi geçerli mi? |
| 3 | Sertifika güvenilir bir CA tarafından mı imzalanmış? |
| 4 | Intermediate CA eksik mi? |
| 5 | Sertifika zinciri tamam mı? |
| 6 | Anahtar uzunluğu yeterli mi? |
| 7 | SHA-256 veya daha güçlü algoritma kullanılıyor mu? |
| 8 | OpenSSL ile doğrulama başarılı mı? |
En Faydalı OpenSSL Komutları
| Komut | Açıklama |
|---|---|
openssl s_client -connect host:443 | Sunucuya TLS bağlantısı kurar ve sertifikayı gösterir. |
openssl x509 -text -noout -in cert.pem | Sertifikanın tüm ayrıntılarını görüntüler. |
openssl x509 -dates -noout -in cert.pem | Geçerlilik tarihlerini gösterir. |
openssl x509 -fingerprint -sha256 -noout -in cert.pem | SHA-256 parmak izini hesaplar. |
openssl verify cert.pem | Sertifika doğrulaması yapar (uygun CA deposu sağlandığında). |
Bölüm Özeti
Bu bölümde:
En yaygın HTTPS sertifika hatalarını,
Bu hataların teknik nedenlerini,
OpenSSL ile sertifika analizini,
Sertifika zinciri sorunlarını,
Self-Signed sertifikaları,
Windows, Linux ve Pardus sistemlerinde sertifika yönetimini,
Gerçek hayatta izlenebilecek sistematik sorun giderme adımlarını
ayrıntılı olarak inceledik.
Sonraki Bölüm
Bir sonraki bölümde "Laboratuvar Sonuçları, Gerçek Hayat Senaryoları ve En İyi Güvenlik Uygulamaları (Best Practices)" konusunu ele alacağız. Bu bölümde HTTPS, Sertifika Otoriteleri, TLS, HTTPS Proxy ve OpenSSL kullanımını gerçek kurum senaryolarıyla ilişkilendirerek laboratuvarın genel değerlendirmesini yapacak ve sistem yöneticileri ile siber güvenlik uzmanları için uygulanabilir güvenlik önerilerini ayrıntılı olarak sunacağız.
Bölüm 10 – Laboratuvar Sonuçları, Gerçek Hayat Senaryoları ve En İyi Güvenlik Uygulamaları (Best Practices)
Bu makalenin önceki bölümlerinde HTTPS'in çalışma mantığını, X.509 dijital sertifikalarını, Sertifika Otoritelerini (CA), TLS Handshake sürecini, HTTPS Proxy mimarisini ve OpenSSL ile sertifika analizini ayrıntılı olarak inceledik.
Bu son bölümde laboratuvar boyunca öğrendiğimiz bilgileri bir araya getirerek gerçek hayatta nasıl kullanıldıklarını değerlendirecek, sistem yöneticileri ve siber güvenlik uzmanları için en iyi uygulamaları (Best Practices) ele alacağız.
Laboratuvarın Temel Kazanımları
Bu laboratuvar yalnızca birkaç OpenSSL komutunun çalıştırılmasını öğretmez.
Asıl amaç;
HTTPS'in nasıl çalıştığını anlamak
Sertifikaların neden gerekli olduğunu öğrenmek
Tarayıcıların güven mekanizmasını kavramak
HTTPS Proxy mantığını anlamak
Sertifika analizini uygulayabilmek
Güvenlik sorunlarını teşhis edebilmektir.
Bu nedenle laboratuvar, hem sistem yöneticileri hem de siber güvenlik uzmanları için temel seviyede önemli bir altyapı sağlar.
Öğrenilen Kavramların Birbiriyle İlişkisi
HTTPS
Bu diyagram laboratuvar boyunca işlenen tüm konuların birbirleriyle olan ilişkisini göstermektedir.
Gerçek Hayatta HTTPS Nerelerde Kullanılır?
HTTPS günümüzde internet üzerindeki hemen hemen tüm kritik servislerde kullanılmaktadır.
Örneğin;
İnternet bankacılığı
E-devlet hizmetleri
E-ticaret siteleri
Sosyal medya platformları
Kurumsal portallar
Bulut hizmetleri
VPN yönetim panelleri
Web API servisleri
HTTPS sayesinde kullanıcı bilgileri ağ üzerinde şifreli olarak taşınır.
Kurumsal Ağlarda HTTPS Proxy Kullanımı
Büyük kurumlarda ağ güvenliği yalnızca güvenlik duvarı ile sağlanmaz.
HTTPS trafiğinin de belirli güvenlik politikalarına uygun olup olmadığı kontrol edilir.
Kurumsal HTTPS Proxy çözümleri aşağıdaki amaçlarla kullanılabilir:
Zararlı yazılım (Malware) analizi
Fidye yazılımı tespiti
Veri sızıntısını önleme (DLP)
URL filtreleme
İçerik denetimi
Kimlik avı (Phishing) koruması
Güvenlik olay kayıtlarının tutulması
Mevzuat ve politika gereksinimlerinin karşılanması
Bu yapılandırmalar yalnızca kurumun yönetimindeki cihazlarda, kullanıcıların bilgilendirilmesi ve ilgili yasal düzenlemelere uygun şekilde uygulanmalıdır.
Bir Sistem Yöneticisi Sertifika Sorunu Yaşadığında Ne Yapmalıdır?
Deneyimli bir sistem yöneticisi aşağıdaki kontrol listesini izleyebilir.
1. Sunucuya TLS Bağlantısı Kur
openssl s_client -connect sunucu.example:443
Bağlantının kurulup kurulmadığını ve sertifika zincirini kontrol et.
2. Sertifikayı Kaydet
echo -n | openssl s_client -connect sunucu.example:443 \
3. Sertifikayı Ayrıntılı İncele
openssl x509 -text -noout -in server.pem
Kontrol edilmesi gereken alanlar:
Subject
Issuer
SAN
Public Key
Signature Algorithm
Validity
Extensions
4. Parmak İzini Hesapla
openssl x509 -fingerprint -sha256 -noout -in server.pem
Beklenen sertifika ile karşılaştır.
5. Sertifika Zincirini Kontrol Et
Root CA doğru mu?
Intermediate CA eksik mi?
Zincir tam mı?
6. Alan Adını Doğrula
Örneğin kullanıcı:
https://www.example.com
adresine bağlanıyorsa, sertifikanın Subject Alternative Name (SAN) alanında da bu alan adının yer alması gerekir.
7. Sertifika Süresini Kontrol Et
openssl x509 -dates -noout -in server.pem
8. Sertifika Doğrulaması Yap
openssl verify server.pem
Doğrulamanın başarılı olması için istemcinin güvenilir CA deposunda ilgili kök ve ara sertifikaların bulunması gerekir.
Güvenli Bir HTTPS Altyapısı İçin En İyi Uygulamalar
Aşağıdaki öneriler hem laboratuvarın kavramlarını pekiştirir hem de gerçek sistemlerde güvenliği artırır.
| Öneri | Açıklama |
|---|---|
| Güvenilir CA kullanın | Kendi kendine imzalanmış (self-signed) sertifikaları üretim ortamında kullanmayın. |
| Sertifikaları zamanında yenileyin | Süresi dolan sertifikalar hizmet kesintisine neden olabilir. |
| Ara sertifikaları eksiksiz yükleyin | Zincirin tamamlanması tarayıcı uyumluluğu için önemlidir. |
| SHA-256 veya daha güçlü algoritmalar tercih edin | Güncel güvenlik standartlarına uyum sağlar. |
| Güçlü anahtarlar kullanın | En az RSA 2048 bit veya güvenli eliptik eğri algoritmaları tercih edilmelidir. |
| Özel anahtarları koruyun | Özel anahtarlar yalnızca yetkili sistemlerde ve güvenli şekilde saklanmalıdır. |
| Sertifikaları düzenli olarak denetleyin | Süre, algoritma ve yapılandırma düzenli olarak kontrol edilmelidir. |
| İstemci güven deposunu yönetin | Kurumsal CA'lar yalnızca gerekli cihazlara güvenli yöntemlerle dağıtılmalıdır. |
Siber Güvenlik Uzmanları İçin Çıkarımlar
Bu laboratuvarda öğrenilen bilgiler aşağıdaki alanlarda doğrudan kullanılabilir:
Ağ güvenliği
Web uygulama güvenliği
Dijital adli bilişim (Forensics)
Olay müdahalesi (Incident Response)
Penetrasyon testleri sırasında TLS analizi
Kurumsal PKI altyapılarının değerlendirilmesi
Sertifika ve güven zinciri denetimleri
Sık Yapılan Hatalar
Uygulama sırasında sık karşılaşılan hatalardan bazıları şunlardır:
Sertifika ile özel anahtarın eşleşmediğini fark etmemek.
Ara sertifikaları sunucuya yüklememek.
Sertifika süresini takip etmemek.
Test ortamındaki self-signed sertifikaları üretim ortamına taşımak.
HTTPS Proxy kullanımında istemci güven deposunu doğru yapılandırmamak.
Sertifika doğrulama uyarılarını incelemeden geçici olarak devre dışı bırakmak.
Laboratuvarın Genel Değerlendirmesi
Bu laboratuvar sayesinde aşağıdaki konular uygulamalı olarak öğrenilmiştir:
✅ HTTPS'in çalışma mantığı
✅ TLS Handshake süreci
✅ X.509 sertifikalarının yapısı
✅ Sertifika Otoriteleri (CA)
✅ Root ve Intermediate CA kavramları
✅ Sertifika depoları
✅ OpenSSL ile sertifika analizi
✅ Sertifika parmak izi hesaplama
✅ HTTPS Proxy çalışma mantığı
✅ Ortadaki Adam (MITM) kavramı
✅ Sertifika doğrulama hatalarının analizi
✅ Güven zincirinin doğrulanması
Sonuç
HTTPS, yalnızca verileri şifreleyen bir teknoloji değildir. Aynı zamanda kimlik doğrulama, bütünlük denetimi ve güven zinciri prensiplerini bir araya getirerek istemci ile sunucu arasında güvenli bir iletişim kanalı oluşturur.
Bu laboratuvarda kullanılan OpenSSL araçları ve sertifika inceleme yöntemleri, HTTPS altyapısının nasıl çalıştığını somut olarak görmeyi sağlamaktadır. Sertifika Otoriteleri, güvenilir sertifika depoları ve TLS Handshake sürecinin anlaşılması; sistem yöneticileri, ağ uzmanları ve siber güvenlik profesyonelleri için temel bilgi alanlarından biridir.
HTTPS Proxy ve sertifika parmak izi karşılaştırmaları ise, kurumsal ağlarda TLS trafiğinin nasıl yönetildiğini ve sertifika doğrulamasının neden kritik olduğunu anlamaya yardımcı olur.
Makale Serisinin Tamamlanan Bölümleri
Bu eğitim serisinde aşağıdaki konular ayrıntılı olarak ele alınmıştır:
HTTPS ve Dijital Sertifikalara Giriş
X.509 Sertifikalarının Yapısı
Sertifika Depoları (Certificate Store)
TLS/SSL Handshake Süreci
HTTPS Proxy ve Man-in-the-Middle Analizi
OpenSSL ile Sertifika Alma ve Parmak İzi Hesaplama
Parmak İzlerinin Karşılaştırılması
Tarayıcı Üzerinden Sertifika Analizi ve Challenge Çalışmaları
Sertifika Hataları ve Sorun Giderme
Gerçek Hayat Senaryoları ve En İyi Güvenlik Uygulamaları
Bu on bölüm birlikte değerlendirildiğinde, laboratuvar içeriğinin ötesine geçen, hem teorik hem de uygulamalı kapsamlı bir HTTPS, PKI ve sertifika yönetimi eğitim kaynağı oluşturulmuştur.
Yorumlar