Ana bilgisayar adlarını, bağımlılıkları ve sahipliği envanterleyin
Ziyaretçilerin veya entegrasyonların kullandığı her ana bilgisayar adını listeleyin: apex, www, alt etki alanları, API'ler, varlık barındırmaları, portallar ve bölgesel adlar. Her biri için TLS'in nerede sonlandığını, kimlerin değiştirebileceğini, sertifika kapsamasını ve sona erme tarihini, yenileme yöntemini ve URL üreten bağımlılıkları kaydedin. Bir sertifika, istenen ana bilgisayar adını Subject Alternative Name listesinde kapsamalıdır. CMS, CDN, etiket yöneticisi, nesne depolama, ödeme sağlayıcısı, e-posta şablonları ve üçüncü taraf gömümleri dahil edin; ilk HTTPS yayını sonrası bu bileşenler genellikle HTTP URL'leri getirebilir.
Bir kanonik www veya apex ana bilgisayar adı seçin ve alternatifini doğrudan HTTPS üzerinden ona yönlendirin.
Sertifikayı ve güncel TLS sürümlerini dağıtın
Kamuya gelen isteklere cevap veren web sunucusunu, ters proxy'yi, CDN'i veya yük dengeleyiciyi yapılandırın. Sertifikayı ve gereken zinciri yükleyin, bunları hedef adlara bağlayın ve barındırma ağının dışından doğrulayın. Tarayıcı zinciri, ana bilgisayarı ve tarihleri kontrol eder; genel bir uyarı yayın engelleyicisidir. Varsayılan olarak TLS 1.3 kullanın ve uyumluluk gerekmedikçe yalnızca TLS 1.2'yi tutun. SSL ile TLS 1.0 ve 1.1'i devre dışı bırakın. Kopyalanmış eski şifre listeleri yerine bakımı yapılan platform yönergelerini kullanın ve sunucu ile TLS kütüphanesini yamalı tutun.
Özel anahtarlara erişimi sınırlayın ve bir anahtarı paylaşan her sistemi kaydedin ki değiştirme tümüne ulaşsın.
HTTP'yi bir kez yönlendirin ve HTTPS'i kanonik yapın
Her HTTP URL'sinden eşdeğer HTTPS URL'sine sunucu tarafı kalıcı yönlendirme (genellikle 301 veya 308) döndürün. Zincirlerden kaçının: bunlar gecikme ve daha fazla arıza noktası ekler. Dahili bağlantılarda, canonical etiketlerinde, site haritalarında, yapılandırılmış veride, sosyal etiketlerde, e-postalarda ve uygulama tarafından oluşturulan mutlak bağlantılarda kanonik HTTPS URL'lerini yayınlayın. Ana sayfayı, derin bir sayfayı, sorgu URL'sini, hata yollarını ve ana bilgisayar değişkenlerini test edin. TLS bir proxy'de sona eriyorsa, uygulamanın HTTP ile HTTPS arasında döngüye girmemesi için güvenilen yönlendirilmiş protokol (forwarded-protocol) işleme yapılandırın.
Sadece yönlendirme veya bir sertifika meydan okumasını tamamlamak için erişilebilir bırakılabilir; ayrı bir genel site sunmamalıdır.
Karma içeriği kaynağından bulun ve düzeltin
Karma içerik, bir HTTPS sayfasının HTTP veya başka bir güvensiz protokol üzerinden bir kaynak istemesidir. Tarayıcılar bazı medya kaynaklarını HTTPS'e yükseltebilir, ancak betikler, stil sayfaları, iframe'ler, fetch çağrıları ve fontlar dahil olmak üzere birçok riskli isteği engeller. Her referansı test edilmiş bir HTTPS URL'siyle, kendi içeriğiniz için göreli bir URL ile veya onaylı bir alternatifle değiştirin. Temsili şablonları tarayın ve önemli yolculukları tamamlarken geliştirici araçlarını inceleyin. CSS, JavaScript, CMS blokları, varlık manifestoları, etiket yöneticisi girdileri, indirmeler ve satıcı gömümlerini kontrol edin. Güvenli bir sayfa HTTP indirmesi sunmamalıdır.
Tarayıcıların otomatik yükseltmesi hâlâ kullanılamayan veya desteklenmeyen üçüncü taraf bağımlılığı bırakabilir; depolanan URL'yi düzeltin.
Yenilemeyi otomatikleştirin ve sertifika kurtarmayı prova edin
Yenilemeyi takvim hatırlatıcısı değil, otomatik bir dağıtım olarak ele alın. Yenileme, her hizmet sunum katmanına dağıtılmalı ve hizmet güvenli şekilde yeniden yüklenmelidir. Üretim ortamındaki sertifikanın süresi dolmadan önce aynı doğrulama yolunu test edin. Örneğin Let's Encrypt, 90 günlük sertifikalarını 60 günde bir yenilemeyi önerir; sertifika otoritesinin ve platformunuzun yaşam döngüsünü izleyin. Sertifika adlarını, sertifika otoritesi hesap bilgilerini, doğrulama yöntemini, otomasyonu, anahtar konumunu, hedefleri ve acil durum irtibatlarını bir envanterde tutun. Kurulum sonrası halka açık uç noktadan sertifikanın geçerlilik tarihlerini doğrulayın.
Başarısız bir yenilemede DNS'i, doğrulama yönlendirmesini, izinleri, sertifika otoritesi hesabına erişimi, oran sınırlamalarını ve CDN'den kaynak sunucuya dağıtımı kontrol edin.
HTTPS altyapısı hazır olduktan sonra yalnızca HSTS kullanın
HTTP Strict Transport Security (HSTS), bir ana bilgisayara sonraki ziyaretlerde tarayıcıların HTTPS kullanmasını söyleyen bir HTTPS yanıt başlığıdır. Tarayıcılar daha sonra ziyaretçilere sertifika hataları için bir atlama seçeneği sunmaz. Bu başlığı yalnızca HTTPS üzerinden gönderin ve HTTP yönlendirmesini koruyun; çünkü HSTS, bir ön yükleme listesi uygulanmıyorsa güvenli bir yanıt alındıktan sonra öğrenilir. Başlangıçta sınırlı bir max-age kullanın; yenilemelerin ve gerekli yolların güvenilir biçimde çalıştığını doğruladıktan sonra süreyi uzatın. Her mevcut ve gelecekteki alt etki alanının geçerli HTTPS sunabileceğinden emin olana kadar includeSubDomains eklemeyin. Preload, HSTS spesifikasyonunun parçası değildir ve ayrı, uzun vadeli bir taahhüt değerlendirmesi gerektirir.
max-age=0 yalnızca bir tarayıcı geçerli bir HTTPS yanıtına ulaştıktan sonra işe yarar; erişilemeyen bir güvenli ana bilgisayarı onaramaz.
Taşıma güvenliğini zayıflatmadan yayınlayın, test edin ve geri alın
Değişiklikten önce bilinen iyi sertifikayı, kenarı (edge) ve yönlendirme yapılandırmasını kaydedin. Kimlerin geri almayı onaylayacağını tanımlayın, mümkünse aşamalar yapın ve her seferinde bir kontrol sınıfını değiştirin. Hemen birden fazla ağdan genel uç noktaları kontrol edin, yönlendirmeleri takip edin, sertifikayı inceleyin ve önemli ziyaretçi işlemlerini tamamlayın. Kitleniz için önemli tarayıcıları ve istemci gruplarını test edin. Ödeme veya düzenlemeye tabi akışlar için ödeme sağlayıcısına ve nitelikli bir güvenlik profesyoneline uygulanabilir gereksinimleri incelemesini isteyin. Bir değişiklik HTTPS'i bozarsa, doğrulanmış güvenli yapılandırmayı geri yükleyin; müşteri sayfalarını geçici olarak HTTP yapmak çözüm olmayacaktır.
Bir sonraki yenileme veya geçiş daha kolay teşhis edilebilmesi için ana bilgisayarı, zamanı, istemciyi, hatayı, değişikliği ve sonucu kaydedin.