TLS sertifikası arızaları çoğu zaman son kullanma tarihi yaklaşınca fark edilir. Oysa yanlış alan adı, eksik zincir, hatalı yayın noktası veya yenilenip servise yüklenmeyen sertifika da aynı derecede etkili olabilir. Sertifika yönetimi bir dosyanın satın alınması ya da indirilmesi değil, hizmetin yaşam döngüsüdür.
Bu yazı tek bir web sunucusu kurulumunu değil, kurum genelinde sertifika yönetiminde sorulması gereken soruları ele alır. İnternet siteleri, iç uygulamalar, ağ cihazları ve farklı erişim katmanları ayrı sertifikalar kullanabilir. Her biri için sahibi, yenileme yolu ve kontrol yöntemi belirlenmelidir. Bir kişinin takvim hatırlatıcısı bütün kurum için yeterli bir işletim modeli değildir.
1. Kullanılan sertifikaları hizmetlerle eşleştirin
Önce hangi alan adının hangi uçta hizmet verdiğini çıkarın. CDN, yük dengeleyici, reverse proxy ve uygulama sunucusu aynı bağlantının farklı bölümlerinde sertifika sunabilir. Kullanıcının gördüğü sertifikayla origin sunucudaki sertifika aynı olmayabilir. Bir uçta doğru sonuç görmek diğer bölümün de sağlıklı olduğunu göstermez.
Envanterde alan adları, sertifika sağlayıcısı, kurulum yeri, sorumlu ekip ve otomasyon yöntemi bulunsun. Aynı sertifikanın birden fazla sunucuda kullanıldığı yerlerde yenilemenin hepsine nasıl ulaştığını belirleyin. Eski cihazda unutulan kopya, ana yayın çalışırken belirli bir kullanıcı grubunu etkileyebilir. Envanteri yalnızca dosya klasörlerinden oluşturmayın; gerçekten sunulan hizmeti de kontrol edin.
2. Sertifika alma yetkisiyle uygulama yetkisini ayırın
Alan adı doğrulaması sertifika sağlayıcısının gerekli kontrolü yapmasına yarar. HTTP veya DNS gibi yöntemler, altyapı ve otomasyon ihtiyacına göre seçilir. DNS API kullanılıyorsa ilgili hesabın yetkisini gerekli alan ve işlem kapsamıyla sınırlandırın. Bütün DNS hesabını yöneten geniş bir anahtar, yalnızca yenileme işi için gerekmeyebilir.
Özel anahtarın nerede üretildiği ve kimlerin erişebildiği ayrıca önemlidir. Destek ekibine sertifika hatası gönderirken özel anahtarı eklemek gerekmez. Anahtarın paylaşılma veya ele geçirilme şüphesi varsa sıradan yenilemeden farklı bir olay yönetimi gerekir. Teknik değişiklikle erişim ve kayıt incelemesini birlikte planlayın.
3. Yenilemenin bütün zincirini doğrulayın
Otomasyon; zamanlayıcının çalışması, doğrulamanın tamamlanması, yeni dosyanın oluşması ve ilgili servisin yeni sertifikayı sunmasına kadar uzanır. İlk aşamanın başarılı olması son aşamayı garanti etmez. Dosya izinleri, yükleme kancaları ve çoklu sunucu dağıtımı farklı noktalarda hata üretebilir.
Certbot'un Nginx yönergeleri, otomatik yenilemenin deneme komutunu da gösterir. Certbot kullanılan uygun bir ortamda aşağıdaki kontrol yenileme yolunu sınamak için değerlendirilebilir. Bu komut bütün ürün ve sertifika yöntemleri için genel bir kontrol değildir.
sudo certbot renew --dry-runDenemeden sonra gerçek hizmetin sunduğu sertifikayı ayrıca izleyin. Yalnızca sunucudaki yeni dosyanın tarihine bakmak yeterli değildir. Aynı alan adının farklı bölgelerde veya IP'lerde sunulduğu ortamlarda bütün erişim yolları kontrol edilmelidir. DNS ve yük dengeleme düzeni bu testin kapsamını belirler.
4. Alan adı, zincir ve istemci güvenini ayırın
Tarayıcıdaki sertifika uyarısı farklı nedenlerle oluşabilir. Alan adının sertifikada bulunmaması, güven zincirinin tamamlanmaması veya istemcinin ilgili CA'ya güvenmemesi aynı sorun değildir. Hata mesajının hangi durumu anlattığını belirleyin. Sertifika doğrulamasını kapatmak, hatayı çözmek yerine kontrolü ortadan kaldırır.
İç uygulamalar kurumsal CA kullanıyorsa istemci güven dağıtımı ve sertifika şablonları ayrıca yönetilir. Genel internet sertifikasıyla iç CA sertifikasının kullanım ve güven modeli farklıdır. Bir sunucuda çalışan yapılandırmanın bütün istemci türlerinde çalışacağını varsaymayın. Mobil cihaz, eski uygulama veya farklı işletim sistemi pilotta temsil edilmelidir.
5. Yönlendirme ve CDN ayarlarını birlikte inceleyin
HTTP'den HTTPS'e yönlendirme, uygulamanın ve varsa aradaki proxy'nin şema bilgisini doğru ele almasını gerektirir. Yanlış katmanda yapılan yönlendirme döngü oluşturabilir. Aynı şekilde CDN üzerinden erişimde origin bağlantısının TLS davranışı ayrıca kontrol edilir. Kullanıcı tarafında kilit işareti görülmesi, origin bağlantısı hakkında tek başına sonuç vermez.
HSTS gibi tarayıcı davranışını etkileyen kararlar, bütün alt alanlar ve geri dönüş koşulları düşünülerek uygulanmalıdır. Bir ayarın güvenli görünmesi, mevcut bütün yayınlarla uyumlu olduğunu göstermez. Önce hizmet envanteri ve HTTPS kapsamını doğrulayın; sonra politikayı kontrollü dağıtın. Değişiklik kaydı, hangi uçların değerlendirildiğini göstermelidir.
6. Süre takibi ve olay yolunu belirleyin
Sertifika süresini izleyecek bir sistem ve uyarıyı ele alacak kişi bulunsun. Alarmın yeterince erken gelmesi kadar doğru ekibe ulaşması da önemlidir. Takibi yalnızca tek bir posta kutusuna bağlamayın. Ekip veya sağlayıcı değiştiğinde sorumluluk kaydı güncellensin.
Varsayımsal bir web servisinde yenileme çalışmış ama reverse proxy yeniden yüklenmemiş olsun. Dosya kontrolü sağlıklı görünürken kullanıcı eski sertifikayı almaya devam edebilir. Hizmet üzerinden yapılan bağımsız kontrol bu boşluğu yakalayabilir. Kabul ölçütünüzü tam bu nedenle kullanıcıya sunulan sonuca bağlayın.
CieloSync ile web, ağ ve sertifika işletiminizi birlikte değerlendirebilirsiniz. Kurulum, yenileme, izleme ve sorumluluğu tek bir hizmet planında birleştirelim.