
Aynı sunucuda beş farklı alan adı barındırıyorsunuz ve hepsinin ayrı sertifikası var. Tek bir IP adresi üzerinden sunucu, hangi ziyaretçiye hangi sertifikayı vereceğini nasıl biliyor?
Bu yazı, tek IP'de çoklu şifreli site barındırmayı ele alıyor.
Tavuk-Yumurta Problemi
Şifreli bağlantıda bir sıralama sorunu vardır:
- Şifreli bağlantı önce kurulur.
- Sertifika bu aşamada sunulur.
- Hangi siteye gidildiği sonra bildirilir.
Bu sıralama temel bir çelişki üretir: sunucu hangi sertifikayı sunacağını, ziyaretçinin hangi alan adına gitmek istediğini öğrenmeden karar vermek zorundadır — çünkü o bilgi şifreli katmanın içinde gelir.
Bu nedenle uzun süre her şifreli site için ayrı IP adresi gerekiyordu.
Sunucu adı bildirimi bu sorunu çözer.
Nasıl Çözülür?
| Aşama | Ne olur |
|---|---|
| İstemci bağlanır | El sıkışma başlar |
| Hedef adı bildirir | Şifresiz, açık metin |
| Sunucu doğru sertifikayı seçer | Ada göre |
| Şifreleme tamamlanır | Normal akış |
İkinci satır çözümün kalbidir ama bir gizlilik bedeli taşır: istemci hangi alan adına gittiğini şifreleme kurulmadan önce açık metin olarak bildirir — yani ağı dinleyen biri, içeriği göremese bile hangi siteye bağlandığınızı görebilir.
Bu, HTTPS'in gizlilik açısından bilinen bir sınırıdır.
Bu bilgi, DNS sorgusuyla birlikte ziyaret geçmişini büyük ölçüde açığa çıkarır.
Yeni protokol sürümlerinde bu alanın da şifrelenmesi üzerinde çalışılmaktadır.
Uyumluluk
- Modern tarayıcıların tamamı destekler.
- Çok eski istemciler desteklemez.
- Bazı kütüphaneler yapılandırma ister.
Üçüncü madde geliştiricileri ilgilendirir ve teşhis edilmesi zor hatalar üretir: bir programın sunucu adını bildirmemesi durumunda sunucu varsayılan sertifikayı sunar ve istemci "sertifika alan adıyla uyuşmuyor" hatası verir — sertifika aslında doğrudur, bildirim eksiktir.
Bu hata, tarayıcıda çalışan bir sitenin bir betikten erişilememesine yol açar.
Çözüm, kullanılan kütüphanenin bu bildirimi gönderecek şekilde yapılandırılmasıdır.
İkinci madde ise artık pratikte önemsizdir; desteklemeyen istemcilerin payı ihmal edilebilir düzeydedir.
Varsayılan Site Davranışı
| Durum | Sunucu davranışı |
|---|---|
| Tanınan ad bildirilir | İlgili sertifika sunulur |
| Tanınmayan ad bildirilir | Varsayılan sertifika sunulur |
| Hiç ad bildirilmez | Varsayılan sertifika sunulur |
İkinci satır güvenlik açısından dikkat gerektirir: tanımlamadığınız bir alan adı sunucunuza yönlendirildiğinde varsayılan siteniz açılır — birinin kendi alan adını sizin IP'nize yönlendirmesi, sitenizin o ad altında görünmesine yol açar.
Bu, marka karışıklığı ve arama motoru sorunları üretebilir.
Çözüm, varsayılan sunucu bloğunu boş bir yanıt veya reddetme olarak tanımlamaktır.
Üçüncü satır ise eski istemcileri ve yanlış yapılandırılmış betikleri kapsar.
Ne Zaman Ayrı IP Gerekir?
- Çok eski istemci desteği zorunluysa.
- IP bazlı erişim kısıtı varsa.
- Gönderim itibarı ayrılacaksa.
- Yasal veya sözleşmesel zorunluluk varsa.
İkinci madde en yaygın gerçek gerekçedir: bir müşteriniz sizin IP adresinizi kendi güvenlik duvarında beyaz listeye alacaksa, o IP'yi başka sitelerle paylaşmamak gerekir — aksi hâlde diğer sitelerin trafiği de o listeden geçer.
Bu, kurumsal entegrasyonlarda sık karşılaşılan bir talep olur.
Üçüncü madde ise e-posta gönderimi içindir ve web sitesinden bağımsızdır.
Birinci madde ise günümüzde neredeyse hiç geçerli değildir.
Sertifika Stratejisi
| Yaklaşım | Uygunluk |
|---|---|
| Her siteye ayrı sertifika | Bağımsız yönetim |
| Çok alan adlı tek sertifika | Az sayıda site |
| Joker sertifika | Aynı alan adının altları |
İkinci satırın bir dezavantajı vardır ve gözden kaçar: tek bir sertifikada birden fazla alan adı listelemek, o sertifikayı gören herkesin diğer alan adlarınızı da öğrenmesi demektir — farklı müşterilere ait siteler birbirini görmüş olur.
Bu, bayilik veya ajans senaryolarında istenmeyen bir bilgi paylaşımıdır.
Birinci satır bu sorunu ortadan kaldırır ve modern otomasyonla yönetim yükü de düşüktür.
Üçüncü satır ise yalnızca kendi alt alan adlarınız için uygundur.
Sorun Giderme
- Yanlış sertifika geliyorsa yapılandırmaya bakın.
- Ad bildirimini test edin.
- Varsayılan siteyi kontrol edin.
Birinci madde en sık karşılaşılan sorundur ve nedeni genellikle basittir: sunucu yapılandırmasında alan adı yanlış yazılmışsa veya hiç tanımlanmamışsa, o ad tanınmaz ve varsayılan sertifika sunulur — hata sertifikada değil eşleştirmededir.
Yapılandırmadaki ad ile ziyaretçinin yazdığı ad birebir eşleşmelidir.
İkinci madde ise ad bildirimini açıkça belirterek test yapmayı sağlar ve hangi sertifikanın döndüğünü gösterir.
Bu test, tarayıcı olmadan sunucu davranışını doğrular.
Alan adlarınızın hangi IP'ye işaret ettiğini ve sertifika durumunu görmek için alan adı kayıt kontrolü ekranından inceleme yapabilirsiniz.
Sonuç
Tek IP'de çoklu şifreli site, istemcinin hedef adı önceden bildirmesiyle mümkün olur. Ama bu bildirimin bir bedeli var: hangi siteye gittiğiniz şifreleme kurulmadan önce açık metin olarak iletilir — ağı dinleyen biri içeriği göremese bile hedefi görebilir. Yapılandırmada varsayılan siteyi mutlaka tanımlayın; tanımlamadığınız bir alan adı sunucunuza yönlendirildiğinde varsayılan siteniz o ad altında görünür.
Sıkça Sorulan Sorular (SSS)
Sunucu hangi sertifikayı vereceğini nasıl biliyor?
İstemci, şifreleme kurulmadan önce hangi alan adına gitmek istediğini bildirir. Bu bildirim olmasaydı sunucunun karar vermesi imkânsız olurdu — çünkü hedef bilgisi normalde şifreli katmanın içinde gelir ve sertifika ondan önce sunulur.
Bu bildirim şifreli mi?
Hayır, açık metin gönderilir. Yani ağı dinleyen biri içeriği göremese bile hangi siteye bağlandığınızı görebilir. DNS sorgusuyla birlikte bu, ziyaret geçmişini büyük ölçüde açığa çıkarır ve HTTPS'in bilinen bir gizlilik sınırıdır.
Yanlış sertifika sunuluyor?
Genellikle yapılandırmada alan adı yanlış yazılmış veya hiç tanımlanmamıştır; o ad tanınmadığı için varsayılan sertifika sunulur. Hata sertifikada değil eşleştirmededir. Ayrıca betiklerden erişimde kullanılan kütüphane ad bildirimini göndermiyor olabilir.
Ne zaman ayrı IP gerekir?
En yaygın gerçek gerekçe, bir müşterinizin IP adresinizi kendi güvenlik duvarında beyaz listeye almasıdır — o IP'yi başka sitelerle paylaşırsanız diğerlerinin trafiği de o listeden geçer. Eski istemci desteği ise günümüzde neredeyse hiç geçerli bir gerekçe değildir.