SSL/TLS Sertifikası Kurulum ve Sorun Giderme Rehberi

Alan Hattı editoryal ekibi · 19 Eylül 2026'da güncellendi

Günlük kullanımda “SSL sertifikası” denilse de modern HTTPS bağlantıları TLS protokolüyle kurulur. Sertifika, ziyaret edilen alan adını bir açık anahtarla ilişkilendirir ve tarayıcının güvendiği bir sertifika otoritesine uzanan imza zinciri sunar. TLS görüşmesi başarılı olduğunda istemci ile sunucu arasındaki trafik gizlilik ve bütünlük koruması kazanır. Bu, sitenin içeriğinin doğru, işletmenin güvenilir veya sunucunun saldırıya karşı tamamen güvenli olduğu anlamına gelmez; yalnızca bağlantının belirli güvenlik özelliklerini doğrular.

Sağlıklı bir HTTPS kurulumu dört parçadan oluşur: alan adını kapsayan geçerli sertifika, eksiksiz ara sertifika zinciri, modern protokol ve şifre takımı yapılandırması, ayrıca kesintisiz yenileme süreci. Bunlardan biri eksikse bazı tarayıcılarda çalışan site başka bir cihazda hata verebilir veya sertifika süresi dolduğunda aniden erişilemez hâle gelebilir.

Sertifikada hangi alan adları bulunmalı?

Tarayıcı, ziyaret edilen ana bilgisayar adını sertifikanın Subject Alternative Name (SAN) alanındaki adlarla karşılaştırır. ornek.com için düzenlenen sertifika, SAN listesinde ayrıca yoksa www.ornek.com adresini kapsamayabilir. Benzer biçimde *.ornek.com joker sertifikası genellikle bir alt alan seviyesini kapsar; kök alan adını veya a.b.ornek.com gibi daha derin adları otomatik kapsadığı varsayılmamalıdır. Sertifika talebine kullanıcıların gerçekten ziyaret edeceği her adı açıkça ekleyin.

Bir IP adresiyle HTTPS sunmak, IP'yi uygun biçimde kapsayan ayrı bir sertifika ve doğrulama süreci gerektirir; alan adı sertifikasının IP üzerinden açılan bağlantıda eşleşmesini beklemeyin. Çoğu web sitesi için ziyaretçileri doğrudan IP yerine kanonik alan adına yönlendirmek daha doğru yaklaşımdır.

Güven zinciri neden önemlidir?

Sunucu çoğunlukla son kullanıcı sertifikasıyla birlikte bir veya daha fazla ara sertifikayı gönderir. Tarayıcı bu zinciri kendi güven deposundaki kök sertifikaya bağlar. Web sunucusuna yalnızca alan adı sertifikasını yüklemek, eksik zincir hatasına neden olabilir. Geliştiricinin bilgisayarı eksik ara sertifikayı daha önce önbelleğe aldığı için sorun görünmezken temiz bir mobil cihaz bağlantıyı reddedebilir.

Kurulum panelinde “certificate” ve “certificate chain/fullchain” alanlarını ayırt edin. Özel anahtarı yalnızca yetkili sistemde saklayın; kaynak kod deposuna, e-postaya veya herkese açık destek kaydına koymayın. Sertifika ile özel anahtar eşleşmiyorsa sunucu başlatma hatası verebilir. Anahtarın sızdığından şüphelenirseniz yalnızca yeni sertifika almakla yetinmeyip ilgili sertifikayı sağlayıcı prosedürüne göre iptal edin ve yeni anahtar üretin.

Alan adı doğrulama yöntemleri

ACME kullanan sertifika hizmetleri alan adını kontrol ettiğinizi bir challenge ile doğrular. HTTP-01 yönteminde belirli bir dosya yolu üzerinden doğrulama yanıtı sunulur. DNS-01 yönteminde alan adının DNS bölgesine geçici TXT kaydı eklenir ve joker sertifikalar için de kullanılabilir. TLS-ALPN-01 ise 443 numaralı portta özel bir TLS yanıtı kullanır. Seçim, altyapınızın ağ erişimine, DNS API desteğine ve otomasyon yeteneklerine bağlıdır.

Güvenlik notu: DNS-01 otomasyonu için tüm DNS hesabına geniş yetkili, süresiz bir API anahtarı vermek risklidir. Sağlayıcı destekliyorsa yalnızca gerekli bölge ve kayıt türüyle sınırlı kimlik bilgisi kullanın; anahtarı gizli değişken deposunda saklayıp düzenli döndürün.

Adım adım güvenli kurulum

1. DNS ve sunucu hedefini doğrulayın

A ve AAAA kayıtlarının sertifikayı kuracağınız altyapıya yöneldiğinden emin olun. IPv4 yeni sunucuyu, unutulmuş IPv6 kaydı eski sunucuyu gösteriyorsa kullanıcılar farklı sertifikalar görebilir. Alan Hattı'nın domain sorgulaması ve DNS Yayılımı aracı kayıtların hangi hedefleri döndürdüğünü karşılaştırmaya yardımcı olur.

2. Sertifikayı otomatik bir istemciyle alın

Barındırma panelinizin, web sunucunuzun veya ACME istemcinizin resmî entegrasyonunu kullanın. Alan adlarını ve doğrulama yöntemini seçin, önkoşulları tamamlayın ve sertifikayı doğru sanal ana bilgisayara bağlayın. Üretim ortamında sürekli manuel dosya kopyalamak hata olasılığını artırır; mümkünse alma, kurma ve yeniden yükleme sürecinin tamamını otomatikleştirin.

3. HTTPS'i doğrudan test edin

Önce https://ornek.com ve https://www.ornek.com adreslerini ayrı ayrı açın. Alan Hattı SSL Kontrolü ile sunulan sertifikanın alan adlarını, veren kuruluşu ve geçerlilik tarihlerini inceleyin. Ardından farklı bir ağ veya temiz cihazda test yapın. Yük dengeleyici, CDN ve kaynak sunucu ayrı TLS sonlandırıyorsa her katmanın sertifika ve doğrulama ayarı kendi bağlamında kontrol edilmelidir.

4. HTTP'den HTTPS'e tek yönlendirme uygulayın

HTTPS düzgün çalıştıktan sonra HTTP isteklerini kalıcı olarak kanonik HTTPS adresine yönlendirin. http → https ve www → kök gibi kuralları tek veya az sayıda adımda birleştirin; döngü ve uzun yönlendirme zincirlerinden kaçının. Ters proxy arkasında uygulamanın gerçek protokolü doğru algılamaması sonsuz döngü yaratabilir. Proxy güven ayarını yalnızca bilinen ara katmanlar için yapılandırın.

5. Karma içeriği temizleyin

HTTPS sayfasındaki görsel, betik, stil veya iframe kaynakları http:// ile çağrılırsa tarayıcı bunları engelleyebilir ya da sayfayı güvensiz gösterebilir. HTML şablonlarını, CSS URL'lerini, veritabanındaki eski mutlak adresleri ve üçüncü taraf entegrasyonlarını tarayın. Kaynak HTTPS desteklemiyorsa güvenli bir alternatif kullanın; yalnızca uyarıyı gizlemeye çalışmayın.

6. Yenilemeyi gerçekten sınayın

“Otomatik yenileme açık” etiketi tek başına yeterli değildir. İstemcinin zamanlayıcısını, dosya izinlerini, challenge erişimini ve sertifika yenilendiğinde web sunucusunun yeni dosyaları yükleyip yüklemediğini kontrol edin. Sağlayıcının test veya dry-run seçeneği varsa kullanın. Son kullanma tarihinden önce birden fazla kanaldan uyarı oluşturun; ancak uyarının otomasyon yerine geçmediğini unutmayın.

Yaygın TLS hatalarını teşhis etme

Alan adı eşleşmiyor: Sertifikanın SAN listesini ve isteğin ulaştığı sanal sunucuyu kontrol edin. Yanlış varsayılan sertifika sunuluyor olabilir.
Sertifikanın süresi dolmuş: Yenileme günlüğünü, zamanlayıcıyı ve challenge sonucunu inceleyin; saat ayarı yanlış cihazlarda da benzer belirti görülebilir.
Güvenilmeyen sertifika: Kendinden imzalı sertifika, eksik ara zincir veya istemcinin güvenmediği otorite söz konusu olabilir.
Bazı cihazlarda çalışmıyor: Zincir eksikliği, eski istemci uyumsuzluğu, DNS'te farklı IPv4/IPv6 hedefi veya CDN düğümleri arasında tutarsız dağıtım araştırılmalıdır.
Çok fazla yönlendirme: CDN'nin ziyaretçiyle HTTPS, kaynakla HTTP konuştuğu senaryoda uygulama yanlış protokol algılıyor olabilir.
Handshake failure: Ortak protokol/şifre takımı bulunmaması, SNI sorunu, istemci sertifikası beklentisi veya ara ağ cihazı etkisi olabilir.
Sertifika doğru ama tarayıcı uyarıyor: Karma içerik, güvensiz form hedefi veya sayfadaki üçüncü taraf kaynakları geliştirici araçlarında inceleyin.

TLS sürümleri, HSTS ve güvenlik başlıkları

TLS 1.2 ve TLS 1.3 güncel genel web kullanımının temelidir; eski protokolleri açık tutma gereksinimini uyumluluk verileriyle değerlendirin. Şifre takımlarını elle rastgele sıralamak yerine web sunucusu ve platform sağlayıcısının bakımı yapılan modern profilini kullanmak çoğu küçük ekip için daha güvenlidir. Yapılandırmayı değiştirdikten sonra gerçek istemciler ve otomatik testlerle doğrulayın.

Strict-Transport-Security (HSTS), destekleyen tarayıcılara alanı belirli süre yalnızca HTTPS ile açmalarını söyler. HTTPS ve alt alanlar eksiksiz çalışmadan uzun max-age, includeSubDomains veya preload başvurusu yapmak erişim kesintisini kalıcılaştırabilir. Önce kısa süreyle test edin, alt alan envanterini çıkarın ve geri dönüş planını anlayın. Diğer HTTP başlıklarını HTTP Güvenliği aracıyla ayrı kontrol edebilirsiniz.

Bir SSL/TLS kontrol aracının sınırları

Dışarıdan yapılan test, belirli bir zamanda belirli IP'ye sunulan yapılandırmayı görür. Coğrafi CDN düğümlerinin tamamını, kurum içi uçları veya yalnızca kimlik doğrulama sonrası açılan servisleri kapsamayabilir. Sertifika notunun iyi olması uygulamadaki yetkilendirme, oturum yönetimi, veri sızıntısı ya da sunucu yamaları hakkında hüküm vermez. Sonuçları güvenlik taraması değil, taşıma katmanına odaklanan bir teşhis olarak değerlendirin.

Yayın öncesi kontrol listesi

Kök alan, www ve kullanılan tüm alt alanlar sertifikanın SAN listesinde bulunuyor.
A ve AAAA kayıtları doğru altyapıyı gösteriyor; her uç aynı beklenen sertifikayı sunuyor.
Sunucu son kullanıcı sertifikasıyla birlikte doğru ara sertifika zincirini iletiyor.
Özel anahtar erişimi sınırlı; kaynak kod ve yedeklerde açık metin olarak yer almıyor.
HTTP istekleri döngüsüz biçimde kanonik HTTPS adresine yönleniyor.
Sayfada karma içerik ve HTTP form hedefi bulunmuyor.
Otomatik yenileme dry-run/test ile doğrulandı ve son kullanma uyarısı tanımlandı.
TLS yapılandırması güncel istemcilerde test edildi; eski protokol desteği bilinçli kararla yönetiliyor.
HSTS yalnızca bütün HTTPS kapsamı ve geri dönüş etkisi anlaşıldıktan sonra etkinleştiriliyor.

Kısa SSS

Ücretsiz sertifika daha mı güvensizdir?

Bağlantı güvenliği yalnızca sertifikanın fiyatına bağlı değildir. Güven zinciri, anahtar yönetimi, protokol yapılandırması ve yenileme operasyonu belirleyicidir. Kurumsal doğrulama ve destek ihtiyaçları ürünler arasında değişebilir.

Sertifika yenilendi ama tarayıcı eskisini gösteriyor; neden?

Web sunucusu yeniden yüklenmemiş, CDN eski sertifikayı sunuyor, trafik başka IP'ye gidiyor veya IPv6 ucu güncellenmemiş olabilir. DNS hedeflerini ve her TLS sonlandırma noktasını ayrı test edin.

HTTPS siteyi saldırılara karşı tamamen korur mu?

Hayır. TLS aktarım kanalını korur; uygulama açıkları, zayıf parolalar, zararlı bağımlılıklar ve yanlış yetkilendirme için ayrı güvenlik önlemleri gerekir.

Resmî ve teknik kaynaklar

Sertifika durumunuzu kontrol ettikten sonra alan adı, DNS, e-posta ve HTTP bulgularını tek yerde görmek için Domain Sağlık Raporu'nu kullanabilirsiniz.

SSL/TLS sertifikası nasıl kurulur ve test edilir?