Kaçınılması Gereken 7 SSL Sertifikası Yenileme Hatası
Yayınlanma tarihi: 16 Temmuz 2026
Bir sertifika başarıyla yenilenebilir ve yine de sitenizi çevrimdışı bırakabilir. SSL sertifikası yenileme hataları ile ilgili rahatsız edici kısım şudur: yenileme bildirimi ortadan kaybolabilir, ancak yeni sertifika hiç dağıtılmadığı, özel anahtarla eşleşmediği veya her uç nokta tarafından sunulmadığı için ziyaretçiler tarayıcı uyarısı görür.
Yenilemeyi takvim görevi olarak değil, kontrollü bir üretim değişikliği olarak ele alın. Sertifikayı, doğrulama yöntemini, sunucu yapılandırmasını ve herkese açık sonucu kontrol edin. Bu genellikle kısa bir prosedürdür. Ancak küçük bir kontrolü atlamak, ekibiniz için çok uzun bir sabah yaratabilir.
1. Bitiş tarihini tek bir kişinin takviminde takip etmek
Manuel bir hatırlatıcı, hiç hatırlatıcı olmamasından iyidir, ancak kırılgandır. İnsanlar rol değiştirir, paylaşılan gelen kutuları unutulur ve bir sertifika artık olağan yenileme sürecinin parçası olmayan bir alan adını kapsayabilir. Sertifikalar, özellikle birden fazla hizmette kullanıldıklarında, ekiplerin beklediğinden daha kısa geçerlilik sürelerine de sahip olabilir.
Birden fazla sorumlu kişiyi veya ekibi uyaran bitiş tarihi izleme sistemi kullanın. Yararlı bir takvim; bitişten 30 gün önce ilk uyarı, 14 gün kala daha güçlü bir uyarı ve yedi gün kala operasyonel bir eskalasyondur. İş açısından kritik alan adları için, yalnızca bir portala kaydedilmiş bitiş tarihini değil, 443 numaralı portta herkese açık olarak sunulan sertifikayı izleyin.
Bu ayrım önemlidir. Sertifika sağlayıcınız geçerli, yenilenmiş bir sertifika gösteriyor olabilir, ancak internet hâlâ eski sertifikayı bir yük dengeleyici, CDN, ters proxy veya ikincil sunucudan alıyor olabilir.
2. Otomatik yenilemenin otomatik dağıtım anlamına geldiğini varsaymak
Otomatik yenileme mükemmeldir, ancak sınırları vardır. ACME tabanlı birçok araç, TLS kullanan her hizmete otomatik olarak kurmadan yeni bir sertifika talep edip indirebilir. Nginx, Apache, HAProxy, posta sunucuları, Kubernetes ingress denetleyicileri ve uygulama proxy'lerinin her biri yeniden yükleme, yeniden başlatma veya yapılandırma güncellemesi gerektirebilir.
Yenilemeden sonra, hizmetin gerçekte hangi dosyalara başvurduğunu doğrulayın. Yaygın bir sorun, yenileme aracının yeni sertifikayı bir dizine yazarken web sunucusu yapılandırmasının hâlâ eski bir yolu işaret etmesidir. Bir diğeri ise başarılı bir yenilemeyi, ilgisiz bir yapılandırma hatası nedeniyle başarısız bir yeniden yüklemenin takip etmesidir.
Tek bir VPS için bu, yapılandırmayı doğrulamak ve web sunucusunu kesintisiz şekilde yeniden yüklemek kadar basit olabilir. Daha büyük bir ortamda, dağıtımı yenileme iş akışının parçası hâline getirin: yenile, dağıt, yeniden yükle, ardından ağ dışından test et. Günlükler artık yalnızca herkese açık uç nokta bunu doğruladığında aynı hikâyeyi anlatıyor olur.
3. Yenileme gününden önce alan adı doğrulamasını bozmak
Alan adı denetimi doğrulaması, birçok yenilemenin başarısız olduğu yerdir. HTTP-01 doğrulaması, sertifika yetkilisinin herkese açık web üzerinden belirli bir sınama dosyasına ulaşmasını gerektirir. DNS-01 doğrulaması doğru TXT kaydını gerektirir. Her iki yöntem de çevresindeki altyapı istikrarlı kaldığında güvenilirdir.
Sorunlar; bir web sitesi taşımasından, DNS sağlayıcısı değişikliğinden, yeni bir CDN kuralından veya bilinmeyen yolları engelleyen bir güvenlik politikasından sonra ortaya çıkar. Bir yönlendirme kuralı, doğrulama isteğini beklenmedik bir yere gönderebilir. Bir web uygulaması güvenlik duvarı bunu reddedebilir. DNS kayıtları bir hesapta yönetilirken sunucu başka bir hesapta yönetiliyor olabilir; bu en güzel DNS durumu değildir, ancak sahiplik net olduğunda kontrol altındadır.
Sertifikanın süresi dolmadan çok önce doğrulama yöntemini kontrol edin. HTTP-01 kullanıyorsanız, `/.well-known/acme-challenge/` yoluna herkese açık olarak erişilebildiğini ve bir uygulama veya proxy tarafından engellenmediğini doğrulayın. DNS-01 kullanıyorsanız, otomasyon kimlik bilgilerinin gerekli kayıtları oluşturma iznine hâlâ sahip olduğunu ve DNS sağlayıcınızın yayılma süresinin yenileme pencerenize uyduğunu doğrulayın.
Wildcard sertifikalar özel dikkat gerektirir. Bunlar genellikle DNS doğrulaması gerektirir; bu nedenle, DNS erişimini elinde tutan kişi müsait değilse son dakika yenilemesi zorlaşabilir.
4. Gerçekte kullandığınız alan adları için yanlış sertifikayı yenilemek
Bir sertifika genel olarak bir sunucuyu korumaz. Kendi Subject Alternative Name, yani SAN, alanında listelenen tam adları korur. `example.com` yenilemek, `www.example.com`, `api.example.com`, `shop.example.com` veya bir uygulama tarafından kullanılan müşteri alt alan adını otomatik olarak kapsamaz.
Yenilemeden önce, sertifikanın sunduğu her ana bilgisayar adının envanterini çıkarın. Yönlendirmeleri, API'leri, yönetici panellerini, herkese açık internete açık hazırlık ortamlarını ve aynı sertifikayı kullanıyorlarsa posta ile ilgili hizmetleri dahil edin. Ajanslar ayrıca white-label alan adlarını ve yıl içinde eklenmiş olabilecek müşteri alan adlarını da kontrol etmelidir.
Wildcard sertifikalara dikkat edin. `*.example.com` gibi bir wildcard, `app.example.com` gibi alt alan adlarının tek bir seviyesini kapsar. `api.eu.example.com` kapsamaz ve apex alan adı olan `example.com` alan adını otomatik olarak içermez. İhtiyacınız olan adları açıkça ekleyin ve bunları tek tek test edin.
5. Yanlış özel anahtarı yeniden kullanmak veya sertifika dosyalarını karıştırmak
Bir TLS sertifikası ve onun özel anahtarı eşleşen bir çifttir. Yeni bir sertifika eski ve ilgisiz bir özel anahtarla kurulursa, hizmet başlatılamayabilir veya geçersiz bir yapılandırma sunabilir. Bu, en sık dosyalar sunucular arasında manuel olarak kopyalandığında veya birkaç sertifikanın benzer adları olduğunda olur.
Bir de sertifika zinciri vardır. Tarayıcılar, sunucu sertifikasına ek olarak uygun ara sertifikalara ihtiyaç duyar. Zincir dosyası eksikse, bazı ziyaretçiler güven hataları görebilirken diğerleri önbelleğe alınmış ara sertifikalar veya farklı cihaz güven depoları nedeniyle etkilenmemiş görünebilir. Bu başarılı bir dağıtım değildir. Bu gecikmeli bir destek talebidir.
Sertifika dosyalarını açık izinler ve sahiplikle birlikte öngörülebilir bir konumda tutun. Özellikle birkaç alan adı aynı ana bilgisayarı paylaşıyorsa, belgelenmiş bir adlandırma kuralı kullanın. Hizmeti yeniden yüklemeden önce, web sunucunuzun beklediği sertifika ayrıntılarını, özel anahtar eşleşmesini ve tam zinciri doğrulayın.
6. Trafik birden fazlasına ulaşırken yalnızca bir sunucuyu güncellemek
Herkese açık bir web sitesinin beklenenden daha fazla TLS uç noktası olabilir. Trafik; bir CDN, bulut yük dengeleyici, yük devretme IP'si, ters proxy, birden fazla uygulama düğümü veya coğrafi olarak dağıtılmış sunucular üzerinden geçebilir. Yalnızca bir uç nokta yenilenmiş sertifikayı alırsa, sorun kullanıcılara aralıklı görünebilir.
Bu, en fazla kafa karışıklığına neden olan SSL sertifikası yenileme hatalarından biridir. Bir mühendis ana sunucuyu test eder ve geçerli bir sertifika görür. Bir müşteri başka bir düğüme ulaşır ve süre sonu uyarısı görür. Her iki gözlem de doğru olabilir.
Yenilemeden önce tam istek yolunu haritalayın. TLS'nin nerede sonlandığını ve ana bilgisayar adı için hangi sistemlerin yanıt verebildiğini belirleyin. TLS bir CDN veya yük dengeleyicide sonlanıyorsa, origin sunucudaki sertifikayı yenilemek ziyaretçilerin aldığı şeyi değiştirmeyebilir. Origin sunucular doğrudan trafiği de kabul ediyorsa, onların da geçerli sertifikalara ihtiyacı vardır.
Kümelenmiş sistemler için, dosyaları düğüm düğüm kopyalamak yerine yapılandırma yönetimi veya orkestre edilmiş bir işlem hattı üzerinden dağıtım yapın. Ardından dış ağlardan veya izleme konumlarından tekrar tekrar test edin. Aynı özel ağ içinden yapılan bir kontrol faydalıdır, ancak herkese açık rotanın doğru olduğunu kanıtlamaz.
7. Test, izleme veya geri alma planı olmadan yenilemek
Komut bir başarı mesajı döndürdüğünde yenileme süreci tamamlanmış olmaz. Doğru ana bilgisayar adını, bitiş tarihini, sertifika zincirini ve uç nokta yanıtını herkese açık bir TLS kontrolü doğruladığında tamamlanır.
Dağıtımdan hemen sonra test edin. Hizmetin beklenen sertifikayı sunduğunu, zincirin doğrulandığını ve uygulamanızın HTTPS üzerinden erişilebilir kalmaya devam ettiğini doğrulayın. E-ticaret, SaaS ve oturum açma uç noktaları için ayrıca kısa bir işlevsel kontrol çalıştırın. Yeniden yükleme uygulamayı 502 yanıtının arkasında bıraktıysa, geçerli bir sertifikanın pek faydası olmaz.
Doğrulama tamamlanana kadar önceki, çalıştığı bilinen sertifikayı ve yapılandırmayı kullanılabilir durumda tutun. Geri alma işlemi hiç gerekmeyebilir, ancak çalışan bir durumu hızlıca geri yükleyebilmek, baskı altında değişikliği yeniden oluşturmaktan daha sakindir. Neyin yenilendiğini, nereye kurulduğunu, bunu kimin doğruladığını ve bir sonraki izleme uyarısının ne zaman tetiklenmesi gerektiğini kaydedin.
Daha güvenli bir yenileme rutini
Güvenilir bir rutin dört aşamadan oluşur: süre dolmadan önce hazırlanın, alan adı denetimini doğrulayın, her TLS uç noktasına dağıtın ve altyapınızın dışından doğrulayın. Otomasyon bu işin büyük bölümünü halledebilir, ancak DNS, barındırma veya uygulama değişikliklerinden sonra yine de izleme ve ara sıra gözden geçirme gerektirir.
Bir yönetilen VPS veya birkaç müşteri ortamı işletiyorsanız, sertifika bitişi ve dağıtım kontrollerini yedeklemeler, çalışma süresi izleme ve yama bakımı ile yan yana yerleştirin. Bunlar aynı operasyonel kategoriye aittir: görünür ve maliyetli olayları önleyen küçük rutin işler.
Bir sertifika uyarısı çok görünürdür çünkü tarayıcılar kullanıcıları koruyacak şekilde tasarlanmıştır. Yenileme süreciniz de eşit derecede koruyucu olmalıdır: erken uyarılar, net sahiplik, test edilmiş otomasyon ve altyapı değiştiğinde insan kontrolü. Böylece hizmet sakin kalır ve müşterileriniz sertifika hatalarının heyecan verici dünyasıyla tanıştırılmadan çalışmaya devam edebilir.
Andres Saar Müşteri Hizmetleri Mühendisi