Modern HTTPS Dağıtımı: Adam Langley ve TLS İyileştirmeleri

Neden HTTP kabul edilebilir olmaktan çıktı

Düz HTTP, postayla gönderilen bir kartpostala benzer. Yolda ona el atan herkes içeriği okuyabilir. Daha kötüsü, bazen karşı tarafa ulaşmadan önce içeriği değiştirebilirler. Bu nadir bir uç durum değil. Trafik Wi‑Fi ağlarından, ofis yönlendiricilerinden, mobil operatörlerden veya paylaşılan barındırmadan geçerken her zaman var olan bir risktir.

İnsanların kaybettiği şey sadece “gizlilik” değil. Kontrolü kaybedebilirler. Birisi trafiği okuyabiliyorsa, giriş bilgilerini, oturum çerezlerini, e‑postaları ve form girişlerini toplayabilir. Birisi trafiği değiştirebiliyorsa, reklam enjekte edebilir, bir indirmeyi kötü amaçlı yazılımla değiştirebilir veya ödemeleri sessizce yönlendirebilir. Basit bir iletişim formu bile ziyaretçilerin yabancılarla paylaşmasını istemediği isimleri, telefon numaralarını ve ticari bilgileri açığa çıkarabilir.

“Sadece küçük bir site” güvenli bir bölge değildir. Saldırganlar hedefleri tek tek seçmez; tarar ve otomasyon kullanırlar. Herhangi bir HTTP sayfası, çerez hırsızlığı, sahte giriş kutuları, güveni zedeleyen içerik enjeksiyonu ve benzer sitelere yönlendirme için kolay bir fırsattır.

Küçük, gerçekçi bir örnek: birisi halka açık Wi‑Fi üzerinde bir kafeterya menüsü sitesine bakıyor. O sayfa HTTP üzerinden yüklendiyse, yakındaki bir saldırgan sayfayı değiştirip “özel teklif” butonu ekleyebilir ve şüpheli bir uygulama kurdurabilir. Site sahibi bunu asla görmeyebilir, ama müşteriler görebilir.

İşte modern HTTPS dağıtımının hedefi basit: korumayı varsayılan yapın. HTTPS bir "güvenlik projesi" olarak daha sonra planlanacak bir şey olmamalı. Her ortam, her alan ve her sürüm için başlangıç noktası olmalı, böylece kullanıcılar düşünmeden şifreleme ve bütünlük elde etsin.

Adam Langley'in daha güvenli TLS için itici rolü

Adam Langley, tarayıcı ekiplerinde, özellikle Google'da Chrome üzerinde yapılan sessiz güvenlik çalışmalarının en bilinen isimlerinden biridir. Bu önemliydi çünkü tarayıcılar web'in bekçileridir. "Yeterince güvenli"nin nasıl göründüğüne, neye uyarı verileceğine ve hangi eski seçeneklerin kapatılacağına onlar karar verir.

Bir site adresi yazdığınızda, tarayıcınız ve sunucu gerçek içerik yüklenmeden önce kısa bir selamlaşma konuşması yapar. Şifreli bir bağlantı üzerinde anlaşırlar, sunucu bir sertifika ile kimliğini kanıtlar ve tarayıcı gösterilecek güvenilir sayfadan önce bu kanıtı kontrol eder.

Bu el sıkışma çoğu insan için sihir gibidir, ama eskiden kırılgandı. Her iki taraf da eski ayarları kabul ediyorsa, saldırganlar bazen bağlantıyı düşürebilir veya eski, zayıf davranışlardan faydalanabilirdi.

Langley, güvenli yolu kolay yol yapan iyileştirmeleri desteklemeye yardımcı oldu; modern TLS'nin tasarımını ve tarayıcılarda nasıl dağıtıldığını etkileyen çalışmalara katkı sağladı. Ayrıca yanlış verilen veya şüpheli sertifikaların gizlenmesini zorlaştıran fikirleri destekledi; böylece HTTPS “sistemin çalışmasını ummak”tan “sistemi doğrulamak ve izlemek”e kaydı.

Protokol ve politika düzeyindeki küçük değişiklikler büyük güvenlik kazanımları üretebilir. Kriptografinin matematiğini anlamanız gerekmez; sonuçları hissedersiniz: zayıf seçeneklere düşme ihtimali azalır, güvenli bağlantılar daha hızlı olur ve HTTPS neredeyse “bedava” gibi hissedilir, sertifika kontrolleri daha nettir ve insan hatasını azaltan daha güçlü varsayılanlar gelir.

Bu değişim, modern HTTPS dağıtımının varsayılan beklenti haline gelmesinde büyük rol oynadı. Tarayıcı HTTPS'i bir bonus olarak değil, temel olarak ele almaya başladı; bu da sunucuları, barındırmaları ve dağıtım araçlarını takip etmeye zorladı.

HTTPS'e güveni kolaylaştıran TLS değişiklikleri

HTTPS'in normalleşmesinin bir kısmı, TLS'in varsayılan olarak daha güvenli ve işletmesi daha az zahmetli hale gelmesi sayesindedir. Detaylar hızla derinleşebilir, ama günlük ekipler için pratik fark yaratan birkaç değişiklik var.

Bir anahtar sızsa bile daha güvenli oturumlar

Forward secrecy şunu ifade eder: birisi sunucunuzun özel anahtarını yarın çalsa bile, geçen ay kaydedilmiş trafiği çözememelidir. Her bağlantı, oturumdan sonra atılan kısa ömürlü anahtarlar kullanır.

Operasyonel olarak bu, sizi anahtar hijyenine yönlendirir: düzenli rotasyon, makul sertifika süreleri ve "sonra değiştireceğiz" durumlarının azalması. Ayrıca bir sızıntının etki alanını azaltır, çünkü kaydedilmiş eski trafik otomatik olarak açığa çıkmaz.

Daha hızlı, daha basit, yanlış yapılandırması zor

TLS el sıkışmaları zaman içinde daha hızlı ve daha basit hale geldi. Hız önemlidir çünkü HTTPS'ten kaçınmak için sık kullanılan bir mazereti ortadan kaldırır ve riskli performans numaralarını sürdürme isteğini azaltır.

TLS 1.3 aynı zamanda bir temizleme yaptı. Yanlış yapılması kolay ve saldırıya açık birçok eski seçeneği kaldırdı. Daha az düğme-demek yanlış zayıf ayarlar için daha az hata.

Certificate Transparency farklı bir şekilde güveni destekledi. Bir alan adı için şüpheli sertifikaları fark etmeyi kolaylaştırdı; böylece kötü veya yanlış verilen sertifikalar daha erken fark edilir.

Tarayıcılar bunların hepsini daha güvenli varsayılanlara doğru iterek pekiştirdi. Uyarılar daha yüksek sesli oldu, güvensiz seçenekler devre dışı bırakıldı ve "varsayılan olarak güvenli" en kolay yol haline geldi.

Özel bir alan adı üzerinde bir uygulama yayıyorsanız, bu iyileştirmeler kriptoyu elle incelemek için daha az zaman harcamanız ve bunun yerine gerçekten kesintileri ve olayları önleyen temel konulara odaklanmanız anlamına gelir: otomatik sertifika yenileme, mantıklı güvenlik başlıkları ve anahtar/sertifika rotasyon planı.

HTTPS'in varsayılan beklenti haline gelmesi

Yıllarca HTTPS bir yükseltme gibi görüldü: girişler ve ödemeler için iyi, diğer her şey için isteğe bağlı. Bu zihniyet, tarayıcılar düz HTTP'i bir risk olarak ele almaya başlayınca bozuldu. Adres çubuğu insanlara uyarı vermeye başlayınca, kullanıcıların TLS'yi anlaması gerekmezdi; sadece kırmızı bir bayrak görüp ayrıldılar.

Arama ve platform politikaları da baskı yaptı. Ekipler "HTTPS'i sonra ekleyeceğiz" dediğinde bunun destek biletlerine, dönüşümün düşmesine ve ortaklardan gelen rahatsız edici sorulara dönüştüğünü öğrendi. İç araçlar bile HTTP üzerinde yanlış hissettirmeye başladı, çünkü aynı ağ riskleri uygulama herkese açık olsun ya da VPN arkasında olsun geçerli.

Sonuç yeni bir temel: varsayılan olarak şifreleme, kendini yenileyen sertifikalar ve müşteriler fark etmeden önce sorunları yakalayan izleme. Büyük değişiklik tek bir özellik değil. Kültürel bir kayış. HTTPS artık "uygulama çalışıyor"un bir parçası, tıpkı yedeklemeler veya çalışma süresi gibi.

Pratikte "beklenen" genellikle şunları içerir:

• Her ortam HTTPS kullanır, sadece üretim değil.
• Sertifika yenileme otomatik, başarısız olursa uyarı verir.
• Süre sonu tarihlerini ve el sıkışma hatalarını normal metrikler olarak izlersiniz.
• Alan, CDN veya yük dengeleyici değiştirdiğinizde TLS ve yönlendirme ayarlarını gözden geçirirsiniz.
• TLS ve sertifikalar için açık bir sahibi vardır; "kim zaman bulursa" değil.

Yaygın bir başarısızlık senaryosu şöyle görünür: bir ekip özel bir alanda pazarlama sitesi başlatır. Site yüklenir, ama sertifika zinciri yanlış olduğu için bazı tarayıcılar uyarı gösterir. Ziyaretçilerin çoğu ilerleyebilir olsa bile, güven kaybolur. Otomasyon ve izleme ile bu bir olay olmaz: doğru sertifika verilir, programlı olarak yenilenir ve bir şey saparsa uyarı tetiklenir.

Güvenlik tek seferlik bir kurulum değildir. Her dağıtımda, altyapı rotasyonu yaptığınızda veya yeni bir alan eklediğinizde sürdürdüğünüz bir alışkanlıktır.

Adım adım: otomatik sertifikalar kurma

Otomatik sertifikalar "HTTPS bugün çalışıyor" ile "gelecek ay da güvenilir HTTPS" arasındaki farktır. Hedef basittir: her ana bilgisayar adına bir sertifika, yenilemeler insan müdahalesi olmadan gerçekleşir ve bir şey bozulduğunda hızlıca haberiniz olur.

1) Tam bir alan envanteriyle başlayın

Kullanıcıların erişebileceği her alan ve alt alan adını yazın; "www", API ana bilgisayarları ve önizleme/tenant alt alanlarını dahil edin. Hangi adların şimdi kaplanması gerektiğine ve hangilerinin engellenebileceğine veya yönlendirilebileceğine karar verin.

2) Alan kontrolünü nasıl kanıtlayacağınıza karar verin

Çoğu ekip ACME kullanır (popüler otomatik sertifika verenlerin ardındaki protokol). Genelde iki kontrol yönteminden birini seçersiniz:

• HTTP challenge: sunucunuz özel bir dosyayı düz HTTP üzerinden yanıtlar. Basit, ama port 80 ve yönlendirmeyi kontrol etmeniz gerekir.
• DNS challenge: kısa ömürlü bir DNS kaydı eklersiniz. Wildcard sertifikalar ve kilitli ağlar için daha iyidir, ama DNS otomasyonu gerektirir.

DNS ve yönlendirmenizin gerçekte nasıl çalıştığına uygun yöntemi seçin, hayal ettiğiniz gibi değil.

3) Yenilemeyi otomatikleştirin ve üretimde önce test edin

Yenilemeyi bir takvime bağlayın (örneğin günlük bir iş) ve önce staging veya dry‑run modunda test edin. Bir dağıtımdan, yapılandırma değişikliğinden ve yeniden başlatmadan sonra işin hala çalıştığını doğrulayın. Yalnızca dizüstü bilgisayarınızda çalışan bir yenileme süreci bir süreç değildir.

4) TLS'nin nerede sonlandığına karar verin

TLS kenarda (CDN), bir yük dengeleyicide veya uygulama sunucusu içinde sonlanabilir. Tutarlı tutun. Kenarda sonlanıyorsa, kenardan origin'e olan bağlantının da özellikle girişler ve API'ler için şifreli olduğundan emin olun.

5) Sıkıcı hatalar için günlük ve uyarılar ekleyin

Yenilemeleri, yenileme hatalarını ve yaklaşan süresi dolmaları takip edin. Pratik bir kural: 30 gün, 7 gün ve 1 gün kala uyarı verin. API sertifikanız bir DNS token güncellemesi bozulduğu için yenilenemezse, bu uyarının kapanış anında değil, ilk günden itibaren gelmesini istersiniz.

HTTPS ile birlikte ayarlanması gereken güvenlik başlıkları

HTTPS trafiği şifreler, ama tarayıcının neye izin verileceği ve neyin yasaklanacağı konusunda hâlâ yönlendirmeye ihtiyacı var. İşte güvenlik başlıkları devreye girer. Bunları kenarda (yük dengeleyici, ters proxy, barındırma yapılandırması) ayarlayın ki her dağıtıma gönderilsin ve belirli bir uygulama yapısına bağlı olmasın.

Nadiren sürpriz çıkaran küçük bir küme:

• Strict-Transport-Security (HSTS): max-age=31536000; includeSubDomains (sadece emin olduğunuzda preload ekleyin)
• X-Content-Type-Options: nosniff
• Referrer-Policy: strict-origin-when-cross-origin
• X-Frame-Options: DENY (veya gerçekten framing'e ihtiyacınız varsa SAMEORIGIN)
• Permissions-Policy: kullanmadığınız özellikleri devre dışı bırakın (örneğin kamera, mikrofon, konum)

HSTS ekstra özen gerektirir. Bir tarayıcı bir kez bunu öğrendiğinde, kullanıcılar max‑age süresi dolana kadar o alan için HTTPS'e zorlanır. Açmadan önce her yönlendirmenin HTTPS'e gittiğini (döngü yok), eğer includeSubDomains kullanacaksanız tüm alt alanların HTTPS hazır olduğunu ve sertifika kapsamınızın alan planınızla (www ve API alt alanları dahil) eşleştiğini doğrulayın.

İçerik Güvenlik Politikası (CSP) kırılmadan

CSP güçlüdür, ama aynı zamanda oturum açmaları, ödeme sayfalarını, analitikleri veya gömülü widget'ları kırma olasılığı en yüksek olan başlıktır. Adım adım uygulayın: staging'de rapor‑modu ile başlayın, neyin engelleneceğini izleyin, sonra kuralları kademeli olarak sıkılaştırın.

Pratik bir örnek: uygulamanız üçüncü taraf bir kimlik doğrulama widget'ı ve birkaç script paketi yüklüyorsa, sıkı bir CSP kimlik doğrulama akışını engelleyebilir ve sadece belirli sayfalarda girişin başarısız olmasına neden olabilir. Bunu staging'de tam giriş yolculuğunu, şifre sıfırlamayı ve gömülü içerikleri test ederek yakalayın.

Başlık ayarlarını TLS ve alan adlarını yönettiğiniz aynı yerde tutun. Eğer özel alan dağıtmak için Koder.ai gibi bir platform kullanıyorsanız, başlıkları uygulama kodunun içinde gizli bir şey değil, sürüm kontrolü listesinin bir parçası olarak ele alın.

Dağıtımın bozulmaması için rotasyon planları

Bir rotasyon planı güvenliği herkesin unuttuğu bir takvim hatırlatıcısına dönüştürmez. Ayrıca sertifika süresi dolduğunda veya bir anahtar sızdığında saat 02:00'deki kesintiyi önlemeye yardımcı olur.

İlk olarak neyi döndürdüğünüz konusunda net olun. Ekipler genellikle TLS sertifikalarına odaklanır, ama özel anahtar kadar uygulamanın arkasındaki gizli anahtarlar da önemlidir.

Tipik bir rotasyon listesi: TLS sertifikaları ve özel anahtarları, API anahtarları ve webhook imzalama gizleri, veritabanı parolaları ve servis hesapları, oturum imzalama ve şifreleme anahtarları, üçüncü taraf jetonları (ödeme, e‑posta, analitik).

Sonra sahipliği ve basit bir takvim belirleyin. Bir kişiyi (ve bir yedeğini) sorumlu seçin. Takvimi gerçekçi yapın: riski azaltacak kadar sık, ama insanların atlayacağı kadar sık değil. Mümkün olduğunda kısa ömürlü kimlik bilgilerini tercih edin ve otomatik olarak yenilensin. Kısa süreli yapılamayan birkaç istisnayı not edin.

Bir rotasyon ancak işe yaradığını kanıtlayabiliyorsanız işe yarar. Her rotasyonu küçük bir dağıtım gibi ele alın: yeni değerin kullanıldığını doğrulayın ve eski değerin artık kabul edilmediğini teyit edin.

Kısa bir çalışma kitabı tekrarlanabilir tutar:

• Yeni kimliği oluşturun ve onaylı gizli sisteme koyun.
• Değişikliği güvenli şekilde dağıtın (kısa bir örtüşme ile eski ve yeni birlikte çalışsın).
• Gerçek bir kontrol ile doğrulayın (giriş, API çağrısı, handshake, veritabanı sorgusu).
• Eski kimliği iptal edin ve artık çalışmadığını doğrulayın.
• Ne değişti, neden ve kim onayladı notunu kaydedin.

Son olarak, başarısızlığı prova edin. Kötü rotasyonlar olur: yanlış sertifika zinciri, eksik ara sertifika, gizli adında yazım hatası. Hızlı ve sıkıcı bir geri alma seçeneğiniz olsun. Koder.ai gibi anlık görüntüleri ve geri almayı destekleyen bir platformda dağıtım yapıyorsanız, son bilinen iyi sürümü geri yüklemeyi prova edin ve TLS el sıkışmasını yeniden kontrol edin. Bu alışkanlık modern HTTPS dağıtımını tek seferlik bir kurulumdan stabil bir rutine dönüştürür.

Ekiplerin hâlâ yaptığı yaygın HTTPS ve TLS hataları

Modern araçlarla bile ekipler birkaç yineleyen hataya takılmaya devam ediyor. Çoğu "zor kripto" problemi değil. Güvenli kurulumları kırılgan hale getiren günlük alışkanlıklar.

Karışık içerik klasik örnektir: sayfa HTTPS ile yüklenir ama bir script, resim, font veya analitik hâlâ HTTP üzerinden geliyordur. Tarayıcılar bunu engelleyebilir veya yükleyip bir saldırı yüzeyi yaratabilir. Tarayıcı konsolunda hızlı bir kontrol ve üçüncü taraf gömülerinin taranması bunu erken yakalar.

Sessiz bir başka başarısızlık ise istemcilerde sertifika doğrulamasını “şimdilik kapatmak”. Bu geçici bayrak genellikle bir mobil build veya arka plan servisine girer. Test etmeniz gerekiyorsa, güven zincirini düzgün düzeltin (doğru hostname, geçerli sertifika ve doğru saat ayarları) ve doğrulamayı pazarlık konusu yapmayın.

Sertifika süresi dolması hâlâ yaygındır çünkü yenilemeler otomatik ama izlenmiyor. Otomasyonun bir emniyet bloğu olmalı: yenileme başarısız olduğunda uyarılar ve alan başına kalan gün sayısını görmeyi sağlayan basit bir yol.

Sıkı politikalarla dikkatli olun: HSTS'yi çok erken etkinleştirmek, bir alt alan adı veya sertifika yanlış yapılandırıldığında kullanıcıları kilitleyebilir. Kademeli olarak uygulayın, önce kısa bir max‑age ile başlayın ve bir kurtarma planınız olsun.

Son olarak, her yerde tek bir wildcard sertifika kullanmaktan kaçının. Eğer sızarsa veya acil değiştirme gerekirse, her şey bir anda gider. Daha güvenli varsayılan, uygulama veya ortam başına sertifikaları ayırmaktır.

Koder.ai'dan yeni bir uygulama dışa aktarıp özel bir alana dağıtıyorsanız, aynı disiplini koruyun: üçüncü taraf varlıkların HTTPS olduğunu doğrulayın, istemci doğrulamasını açık tutun ve yenilemeler ile değişikliklerin sizi şaşırtmaması için uyarılar ayarlayın.

Yayınlamadan önce hızlı kontrol listesi

Son mil, HTTPS hatalarının saklandığı yerdir. Bir site sizin ana tarayıcınızda iyi görünebilir ama gerçek kullanıcılar, tarayıcı tarayıcıları veya mobil uygulamalar için hâlâ bozuk olabilir. Bir sürümü tamamlandı olarak işaretlemeden önce modern HTTPS dağıtımınızın parçası olarak birkaç kontrol çalıştırın.

Son mil kontrolleri

Bu listeyi alan başına bir kez, ve her CDN, yük dengeleyici veya DNS değişikliğinden sonra tekrar çalıştırın:

• Sertifika zincirini uçtan uca doğrulayın ve beklenen her ismin kapsandığını onaylayın (apex vs www ve gerçekte hizmet verdiğiniz alt alanlar).
• Yönlendirmelerin tam olarak istediğiniz gibi davrandığını doğrulayın: HTTP her zaman HTTPS'e gitmeli ve tek bir kanonik host kazanmali (yönlendirme döngüsü yok, çift atlama yok).
• Güvenlik başlıklarının nihai HTTPS yanıtında mevcut olduğunu ve katmanlar arasında çoğaltılmadığını kontrol edin (hem uygulama hem edge başlığı ekliyorsa yaygın problem).
• Temiz bir tarayıcı profiliyle test edin (önbelleksiz HSTS veya eski sertifika durumu yok) ve gerçek bir mobil cihazda hücresel veriyle doğrulayın.
• İzlemenin yerinde olduğunu doğrulayın: yaklaşan süresi dolma uyarıları, ani handshake hataları ve TLS veya yönlendirme sorunlarını gizleyebilecek 4xx/5xx sıçramaları için uyarılar.

Basit bir senaryo: özel bir alan ekliyorsunuz ve sertifika onu kapsıyor, ama yönlendirme hâlâ kullanıcıları example.com'dan www.example.com'a HTTP üzerinden gönderiyor. Bir URL'de "güvenli" görünüyor her şey, ama ilk adım düşürüyor ve giriş çerezlerini bozuyor.

Koder.ai gibi barındırılan bir platformda dağıtırsanız, aynı kontrolleri yine yapın. Barındırma ve otomatik sertifikalar çabayı azaltır, ama kullanıcıların göreceği tam alan adlarını, yönlendirmeleri ve başlıkları doğrulamayı yerine getirmez. Bir şey başarısız olduğunda, anlık görüntüler ve geri alma hazırsa kenar ayarlarını düzeltirken uzun bir kesintiden sizi kurtarabilir.

Örnek: özel bir alanda yeni bir uygulama başlatmak

Küçük bir SaaS lansmanını düşünün: halka açık bir açılış sayfası (pazarlama sitesi) ve müşterilerin hesaplarını yönettiği giriş yapılan bir pano. app.yourbrand.com gibi temiz bir özel alan adı istiyorsunuz ve HTTPS'in ilk günden itibaren varsayılan olmasını istiyorsunuz.

Önce özel alan adını barındırma ayarınıza bağlayın ve her isteğin HTTPS üzerinde bittiğinden emin olun. Her iki çıplak alanı ve www versiyonunu test edin (kullanıyorsanız), ayrıca pano alt alanınızı da kontrol edin. Hedef bir kanonik URL ve diğer tüm versiyonların ona yönlendirilmesi.

Sonra karışık içeriğe dikkat edin. Bu, HTTPS'in sessizce bozulma yoludur: sayfa HTTPS ile yüklenir ama bir script, resim, font veya API çağrısı hâlâ http:// kullanır. Tarayıcınız bunu engelleyebilir veya uyarılarla yükleyebilir. Açılış sayfanızın varlıklarını, analitik parçacıklarını ve panonuzun çağırdığı API uç noktalarını kontrol edin.

Yönlendirmeler doğru ve tüm alt alanlar bilindikten sonra HSTS'yi etkinleştirin. Dikkatli yayınlayın: önce kısa bir max‑age ile başlayın, hiç HTTP'ye ihtiyaç duymadığını doğrulayın, sonra artırın. Subdomain'leri dahil etmeyi planlıyorsanız, önce her alt alanın HTTPS hazır olduğunu onaylayın.

Modern HTTPS dağıtımı için sertifikaları takvim hatırlatıcısı değil otomatik tesisat olarak görün. Otomatik yenileme kurun ve yaklaşan süresi dolma ve yenileme hataları için en az bir uyarı (e‑posta veya pager) ayarlayın. Koder.ai gibi bir platform kullanıyorsanız, "yenileme doğrulandı"yı sürüm rutininizin parçası yapın.

İyi bir haftalık bakım rutini kısa ama düzenlidir:

• Ana sayfalarda (açılış, giriş, pano) karışık içerik için tarama yapın.
• Sertifika süresinin rahatça uzak olduğunu doğrulayın (ve uyarıların çalıştığını kontrol edin).
• Yönlendirme ve proxy kurallarında son değişiklikleri gözden geçirin.
• Tarayıcıda ana sayfalar için güvenlik başlıklarını spot‑check yapın.
• Sertifika veya TLS değişikliklerini kaydedin ki rotasyon sonrasında bir gizem olmasın.

Sonraki adımlar: güvenli varsayılanları her dağıtıma dahil edin

Güvenli HTTPS, sıkıcı olduğunda en kolay sürdürülen haline gelir. Amaç bu uygulamaları her seferinde otomatikleşmiş alışkanlıklara dönüştürmek, özel bir projeye bağlı bırakmamak.

Kontrol listenizi bir sürüm şablonuna dönüştürün. Aynı adımları her ortam için (staging ve üretim) kullanın, böylece modern HTTPS dağıtımı hangi uygulamayı gönderirseniz gönderin aynı görünür.

Pratik bir şablon genellikle otomatik sertifika yenilemesini ve uyarıları doğrulamayı, ana başlıkların (HSTS, mümkünse CSP ve nosniff) varlığını kontrol etmeyi, yönlendirmeler ve TLS ayarlarının politikanıza uygun olduğunu teyit etmeyi, temiz bir tarayıcıda hızlı bir post‑deploy testi ve temel bir TLS kontrolü yapmayı ve ne değiştiğini ve nasıl doğruladığınızı kaydetmeyi içerir.

Hatalar bekleyin ve hızlı toparlanmayı planlayın. Kötü bir başlık veya TLS ayarı girişleri, gömülü içerikleri veya API çağrılarını bozabilir; bu yüzden geri alma birinci sınıf bir adım olsun. Koder.ai ile Planning Mode, dağıtım ve barındırma, anlık görüntüler ve geri alma değişiklikleri aşamalamak ve bilinen iyi duruma hızlıca dönmek için yardımcı olabilir. Dışa aktarılabilir kaynak kodu da aynı kurulumu başka yerde yeniden üretmeniz gerekirse işe yarar.

Kısa dağıtım notlarını her seferinde aynı yerde tutun. Ne değiştirdiğinizi yazın (ör. "HSTS preload etkinleştirildi" veya "ara zincir döndürüldü"), beklentilerinizi ve sürüm sonrası çalıştırdığınız kesin kontrolleri kaydedin.

Son olarak, sertifikalar ve rotasyon planlarının sürüklenmemesi için aylık kısa bir gözden geçirme planlayın. Yenileme olaylarına ve yakın‑süreli uyarılara, başlık değişikliklerine ve ilgili hata raporlarına, sertifika rotasyon günlüklerine ve izlemede beklenmeyen TLS handshake hatalarına göz atın.

Küçük, düzenli kontroller Cuma gecesi acil düzeltmelerinden daha iyidir.