Adam Langley'in TLS çalışmasının ve HTTPS‑varsayılanına geçişin düz Türkçe anlatımı; otomatik sertifikalar, güvenlik başlıkları ve rotasyon gibi modern HTTPS dağıtım alışkanlıkları.
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, 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'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.
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.
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ı.
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:
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.
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.
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.
Çoğu ekip ACME kullanır (popüler otomatik sertifika verenlerin ardındaki protokol). Genelde iki kontrol yönteminden birini seçersiniz:
DNS ve yönlendirmenizin gerçekte nasıl çalıştığına uygun yöntemi seçin, hayal ettiğiniz gibi değil.
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.
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.
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 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:
max-age=31536000; includeSubDomains (sadece emin olduğunuzda preload ekleyin)nosniffstrict-origin-when-cross-originDENY (veya gerçekten framing'e ihtiyacınız varsa SAMEORIGIN)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.
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.
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:
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.
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.
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.
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:
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.
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:
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.
HTTP, verileri yol üzerindeki herkesin okuyabileceği veya değiştirebileceği şekilde gönderir (herkese açık Wi‑Fi, yönlendiriciler, proxy'ler, operatörler). HTTPS şifreleme ve bütünlük ekler, böylece girişler, çerezler, formlar ve indirmeler rastgele dinlenemez veya değiştirilemez.
Pasif bir saldırgan oturum çerezlerini çalabilir ve hesapları ele geçirebilir. Aktif bir saldırgan içerik enjekte edebilir veya değiştirebilir (sahte giriş formları, değiştirilmiş indirmeler, ödeme yönlendirmeleri, istenmeyen reklamlar). Korkutucu olan nokta otomasyon: tarayıcılar ölçekli olarak HTTP sayfalarını arar.
Basit tutun:
Çoğu ekip, kripto ayarlarını elle çekiştirmektense “güvenli varsayılanları” tercih etmelidir.
Forward secrecy, geçmiş oturumları korur: sunucunuzun özel anahtarı sonradan çalınsa bile önceki kayıtlı trafiğin otomatik olarak çözülememesini sağlar. Bu, bir anahtar sızıntısının verdiği hasarı azaltır.
Certificate Transparency, sertifika düzenlemesini daha görünür hale getirir; bu, alan adınız için yanlış ya da kötü niyetli verilen sertifikaları tespit etmeyi kolaylaştırır. Pratikte, izleme ve hesap verebilirliği artırır, siz günlükleri incelemeseniz bile ekosistemde daha fazla şeffaflık sağlar.
Varsayılan tercih: HTTP-01; port 80'e ve yönlendirmeye kontrolünüz varsa en basit kurulum budur.
DNS-01: wildcard sertifikalar (*.example.com) gerektiğinde, port 80 açamıyorsanız veya karmaşık edge yönlendirmeleriniz varsa kullanın. DNS-01 mükemmeldir ama DNS güncellemelerini otomatikleştirebiliyorsanız.
En azından şu öğeleri izleyin:
Uyarılar olmayan otomasyon, kullanıcılar şikayet edene kadar sessizce başarısız olur.
İlk olarak kırma olasılığı düşük, işe yarayan bir küme ile başlayın:
Strict-Transport-Security (önce kısa bir max-age kullanın)X-Content-Type-Options: nosniffAşamalar halinde yayın:
CSP en sık üçüncü taraf betikleri, kimlik doğrulama widget'ları ve planlanmamış inline betikler yüzünden bozulur.
Rotasyon işlemini küçük bir dağıtım gibi ele alın:
Koder.ai gibi bir platformda dağıtıyorsanız, Planning Mode ile değişiklikleri aşama aşama test edin ve zincir veya başlık değişikliği kesintiye neden olursa snapshots/rollback kullanarak hızlıca geri dönün.
Referrer-Policy: strict-origin-when-cross-originX-Frame-Options: DENY (gerekiyorsa SAMEORIGIN)Permissions-PolicyHSTS'yi kademeli olarak ekleyin, böylece bir alt alan adının veya sertifikanın yanlış yapılandırılması kullanıcıları kilitlemesin.