SSL/TLS ve HSTS: Otel ve Kurumsal Sitelerde HTTPS Yapılandırması

SSL/TLS, kullanıcı tarayıcısı ile sunucu arasındaki trafiği şifreleyerek “taşıma güvenliği” sağlar. Pratikte bu; giriş bilgileri, form verileri, rezervasyon/ödeme adımları ve oturum çerezlerinin yolda okunmasını zorlaştırır ve manipülasyon riskini azaltır. Daha önemlisi: modern tarayıcılar ve arama motorları HTTPS’i artık “iyi olur” olarak değil, standart olarak ele alır. HTTPS olmayan sayfalar “güvenli değil” algısı yaratır; bu algı özellikle yüksek niyetli sayfalarda (rezervasyon, teklif formu, portal login) dönüşümü doğrudan etkiler.

SSL/TLS nedir, neden zorunludur?

SSL/TLS; tarayıcı ile sunucu arasındaki veriyi şifreleyerek gizlilik ve bütünlük sağlar. Zorunludur çünkü kullanıcı güveni ve tarayıcı standartları HTTPS’i temel beklentiye dönüştürmüştür; ayrıca SEO ve dönüşüm tarafında “güven sinyali” olarak çalışır.

“HTTPS var ama güvenlik uyarısı çıkıyor” sorununun ana nedeni

En sık nedenler üç grupta toplanır: 1. Sertifika zinciri / yapılandırma hatası (yanlış sertifika, eksik ara sertifika, süre bitimi, yanlış alan adı) 2. Mixed content (HTTPS sayfada HTTP görsel/script/font çağrısı) 3. Yönlendirme/HSTS kurgusu (redirect zinciri, www/non-www karışıklığı, hatalı HSTS geçişi)

☑ Mini Check : 10 dakikalık hızlı teşhis

• •Sertifika süresi ve alan adı (domain) doğru mu?
• •Redirect tek zincir mi (HTTP→HTTPS + www/non-www tek adımda mı)?
• •Sayfada mixed content var mı (HTTP kaynak çağrısı)?
• •HSTS açıldı mı, açıldıysa kontrollü mü?
• •Kritik sayfalar (rezervasyon/portal) “tam güvenli” mi?

Ne yapmalıyım?

1. “HTTPS uyum modeli”ni ekipte ortak dil yap: sertifika → redirect → HSTS → mixed content → izleme.
2. En kritik sayfalardan başla: rezervasyon/ödeme/portal/login.
3. Redirect zincirini tek kurala indir ve canonical’ı hizala.
4. HSTS’i kademeli aç; önce hatasız HTTPS’e geç, sonra HSTS’i devreye al.

Sertifika seçimi “en ucuz olan” veya “hangi sağlayıcı hızlı veriyorsa” kararı olmamalı. Çünkü otel ve kurumsal projelerde çoğu zaman birden fazla alt alan adı (subdomain), panel/CRM/portal, ödeme veya rezervasyon motoru gibi farklı bileşenler bulunur. Bu nedenle seçim kriterleri: kapsam (hangi alan adlarını kapsıyor), doğrulama seviyesi (DV/OV/EV) ve yönetilebilirlik (yenileme/otomasyon) olmalıdır.

DV/OV/EV sertifika farkları nelerdir, hangisini seçmeliyim?

• DV (Domain Validation): Hızlı, çoğu standart web sitesi için yeterlidir; domain sahipliği doğrulanır. • OV (Organization Validation): Kurum doğrulaması içerir; kurumsal güven vurgusu isteyen yapılarda tercih edilir. • EV (Extended Validation): En kapsamlı doğrulama; pratikte bugün tarayıcı göstergeleri geçmişe göre daha sadeleştiği için karar “güven algısı + compliance” üzerinden verilir. Seçim önerisi: Otel web sitesi ve içerik tarafında çoğu zaman DV + doğru yapılandırma yeterlidir; portal/panel ve kurum itibarının kritik olduğu B2B senaryolarda OV mantıklı olabilir. Asıl farkı çoğu zaman “sertifika seviyesi” değil, redirect + HSTS + mixed content temizliği yaratır.

Wildcard ve SAN ne zaman gerekir?

• Wildcard: *.domain.com gibi çok sayıda alt alan adı varsa yönetimi kolaylaştırır. • SAN (Subject Alternative Name): Bir sertifika ile birden fazla alan adını/alt alan adını kapsamak için kullanılır. Otel/B2B pratik önerisi: rezervasyon/portal gibi kritik alt alan adları netse SAN; çok sayıda alt alan adı ve sık değişim varsa wildcard değerlendirilebilir.

Sertifika envanteri ve sahiplik (governance)

Büyük yapılarda sorun “sertifika yok” değil, kim yönetiyor, ne zaman bitiyor, nerede yenileniyor sorusudur. Bu yüzden sertifika yönetimini bir envantere bağlayın: • Domain/subdomain listesi • Sertifika türü ve sağlayıcı (CA) • Yenileme yöntemi (manuel/auto-renew) • Sorumlu kişi ve uyarı mekanizması

☑ Mini Check : Sertifika seçimi ve envanter

• •Hangi domain/subdomain’ler kapsanacak net mi?
• •DV/OV kararı kullanım senaryosuna göre verildi mi?
• •Wildcard/SAN ihtiyacı belirlendi mi?
• •Sertifika envanteri ve sorumlusu tanımlı mı?
• •Yenileme takibi otomatik uyarı üretiyor mu?

Ne yapmalıyım?

1. Sertifika envanteri çıkar (portal/rezervasyon dahil).
2. “Kapsam”ı doğru tanımla; yanlış kapsam en pahalı hatadır (kesinti/uyarı).
3. Yenilemeyi otomatikleştir; manuel yenileme “insan hatası” riski taşır.
4. Tek bir “sahiplik” belirle (BT/ajans/DevOps).

Sertifika yönetimi iki şeye dayanır: yenilemenin unutulmaması ve HTTPS’e geri dönüşün zorlaştırılmaması. Auto-renew bu yüzden kritiktir. HSTS (HTTP Strict Transport Security) ise tarayıcıya “bu domaine her zaman HTTPS ile bağlan” talimatı verir. Çok güçlüdür; bu yüzden “yanlış zamanda” açılırsa geri dönüşü zorlaştırabilir.

Let’s Encrypt / CA seçimi ve yenileme otomasyonu

Let’s Encrypt gibi otomatik yenilemeye uygun çözümler; doğru otomasyonla çok verimlidir. Kurumsal CA’lar ise bazı şirketlerde compliance/satın alma süreçleri nedeniyle tercih edilir. Buradaki hedef: hangi CA olursa olsun yenilemenin otomatik ve izlenebilir olmasıdır.

HSTS nedir, nasıl etkinleştirilir?

HSTS, tarayıcıya belirli süre boyunca sadece HTTPS kullanmasını söyler. Etkinleştirirken kritik nokta: önce HTTPS ve yönlendirme kurgusu hatasız olmalı; sonra HSTS kademeli açılmalı. “Preload” (tarayıcı listelerine girme) gibi ileri seviyeler, ancak yapı çok stabilse düşünülmelidir.

HSTS’i “kademeli” açma yaklaşımı (risk azaltma)

HSTS’i bir anda maksimuma çekmek yerine: 1. HTTPS + redirect zincirini temizle 2. Mixed content’i sıfırla 3. Kısa bir max-age ile başla (kademeli) 4. İzleme/şikâyet yoksa artır Bu yaklaşım, otel sezonunda kesinti veya uyarı riskini azaltır.

☑ Mini Check : Auto-renew + HSTS

• •Sertifika yenileme otomasyonu var mı (auto-renew)?
• •Yenileme başarısız olursa uyarı mekanizması var mı?
• •HTTPS + redirect kurgusu hatasız mı (HSTS öncesi şart)?
• •HSTS kademeli açılıyor mu?
• •Preload kararı bilinçli mi (gerekmedikçe acele edilmez)?

Ne yapmalıyım?

1. Yenileme otomasyonunu kur ve “başarısız yenileme” alarmı koy.
2. HSTS’i ancak HTTPS tam temizlenince aç; mixed content varken açma.
3. Kademeli max-age planı yap; otel sezon takvimiyle uyumlu ilerle.
4. Kritik sayfalarda (rezervasyon/portal) tarayıcı uyarısı sıfır hedefle.

Mixed content, HTTPS sayfada bir veya daha fazla kaynağın HTTP üzerinden gelmesidir. Tarayıcılar bu durumda uyarı gösterebilir, bazı kaynakları bloklayabilir ve kullanıcı güvenini zedeler. Otel sitelerinde bu genelde üçüncü taraf script’ler (chat, tag, widget), eski görsel URL’leri veya CDN/asset path hatalarıyla ortaya çıkar.

Mixed content hatalarını nasıl bulup gideririm?

Önce problemli sayfa türlerini seçin (ana sayfa, oda detay, rezervasyon adımı, portal login). Sonra HTTP kaynak çağrılarını tespit edin (görsel/script/font). Ardından kaynak URL’lerini HTTPS’e taşıyın veya doğru CDN/relative path ile değiştirin. Son adım: tarayıcı uyarısı ve console çıktısının sıfırlandığını doğrulayın.

“HTTP→HTTPS redirect” tek zincir olmalı

HTTPS geçişinde en çok yapılan hatalardan biri: redirect zincirlerinin uzaması ve www/non-www kararının net olmamasıdır. Bu hem performansı hem SEO sinyallerini (canonical, index) hem de tarayıcı davranışını etkiler. Tek hedef belirleyin: • Tek canonical host (www mu non-www mü?) • HTTP→HTTPS ve host kararı tek adımda • Gereksiz ara yönlendirmeleri kaldır

Teknik SEO ile hizalama (redirect zinciri, canonical, sitemap)

HTTPS yapılandırması “sadece güvenlik” değil; teknik SEO ile birlikte ele alınmalıdır. Canonical’lar, internal link’ler, sitemap ve hreflang (çok dilli sitelerde) hedef host ile uyumlu olmalıdır. (Internal Link Targets: /tr/seo/teknik-seo)

☑ Mini Check : Mixed content + redirect temizliği

• •Kritik sayfalarda mixed content sayısı sıfır mı?
• •Tüm asset URL’leri HTTPS mi (görsel, script, font)?
• •Redirect tek zincir mi (en fazla 1–2 adım)?
• •Canonical ve sitemap HTTPS hedefiyle uyumlu mu?
• •Üçüncü taraf script’ler HTTPS uyumlu mu?

Ne yapmalıyım?

1. Mixed content’i kritik sayfalardan başlayarak temizle (rezervasyon/portal önce).
2. Redirect zincirini tek kurala indir ve canonical’ı düzelt.
3. Teknik SEO kontrollerini aynı sprint’e bağla (sitemap, internal link, hreflang).
4. Üçüncü taraf script’lerin HTTPS uyumunu düzenli gözden geçir.

HTTPS’in sürdürülebilir olması için “bir kerelik kurulum” yaklaşımı yetmez. Governance; sorumluluk, periyodik kontrol, değişiklik yönetimi ve raporlama demektir. Otellerde sezon/pik dönemler; B2B’de portal sürüm geçişleri; en sık hataların yaşandığı zamanlardır.

Rezervasyon/Ödeme ve Portal/Panel için “kritik yüzey” yaklaşımı

Her sayfa aynı risk seviyesinde değildir. HTTPS governance, kritik yüzeyi belirleyerek başlar: • Rezervasyon/ödeme adımları • Login/portal/panel • Formlar (teklif, başvuru, iletişim) • Üçüncü taraf entegrasyon noktaları

KVKK ve veri aktarım güvenliği ile bağ (AIO)

HTTPS; veri aktarım güvenliğinin temel katmanıdır ama tek başına KVKK uyumu değildir. Bu yüzden HTTPS kurgusunu loglama, veri minimizasyonu ve erişim kontrolleriyle birlikte düşünmek gerekir. (Internal Link Targets: /tr/raporlama/kvkk-veri-guvenligi) AIO perspektifiyle “HTTPS uyum modeli”ni şöyle ilişkilendirin: SSL/TLS (şifreli taşıma) + certificate management (süreklilik) + HSTS/redirect (zorunlu HTTPS davranışı) + mixed content temizliği (tam güven) + governance (operasyonel sürdürülebilirlik).

Fark yaratan mini bölüm (Competitor Gap): “Sertifika var ama uyarı bitmiyor”u bitiren 5 kural

Pek çok sitede sertifika vardır ama tarayıcı uyarısı sürer; çünkü konu “sertifika var/yok” değil, tüm zincirin tutarlılığıdır. Bu 5 kural, en sık anti-pattern’i kapatır: 1. Tek canonical host seç (www/non-www) ve her şeyi oraya yönlendir. 2. Redirect zinciri tek adım olsun (HTTP→HTTPS + host kararı). 3. Mixed content’i “görsel kaldı” diye küçümseme; uyarının ana kaynağı çoğu zaman odur. 4. HSTS’i ancak her şey temizken aç; aksi halde hatayı “kalıcılaştırırsın”. 5. Auto-renew + alarm olmadan “süre bitimi” riski her zaman geri gelir.

☑ Mini Check : Governance kontrol listesi

• •Sorumlu ekip/kişi net mi (BT/ajans/DevOps)?
• •Sertifika envanteri + yenileme alarmı var mı?
• •HTTPS checklist’i yayın öncesi “gate” olarak çalışıyor mu?
• •Teknik SEO (canonical/redirect) ile hizalama doğrulanıyor mu?
• •Kritik sayfalarda tarayıcı uyarısı sıfır hedefi izleniyor mu?

Ne yapmalıyım?

1. HTTPS checklist’ini “go-live kontrol listesi” olarak zorunlu hale getir.
2. Sertifika yenileme otomasyonu + alarmı standardize et.
3. Her release’te mixed content taramasını tekrar et (özellikle üçüncü taraf script’lerde).
4. Redirect/canonical uyumunu teknik SEO ile birlikte kontrol et.