Kesinti Olmadan Güvenilir Bir SSL Yenileme Süreci
18 Ekim 2026 tarihinde yayımlandı
SSL yenileme süreci, sertifika süresi dolmadan çok önce başlamalı; sertifika envanteri, DNS erişimi ve dağıtım yolu önceden kontrol edilmiş olmalıdır. Sertifika yenileme genellikle rutin bir işlemdir. Kesintiler genellikle süreç çevresinde yaşanır: unutulmuş bir alt alan adı, yanlış DNS bölgesine eklenen bir doğrulama kaydı ya da trafik hâlâ başka bir sunucuya ulaşırken yeni sertifikanın tek bir sunucuya yüklenmesi.
Üretim ortamındaki bir web sitesi için yenilemeyi, geri alma planı olan küçük bir bakım değişikliği olarak ele alın. Yedek sertifikayı oluşturun veya talep edin, doğrulamayı tamamlayın, sertifika zincirinin tamamını yükleyin, ilgili web hizmetini yeniden yükleyin ve dışarıdaki ziyaretçilerin gerçekten ne aldığını doğrulayın. Bu şekilde yapıldığında hizmet sorunsuz çalışır ve tarayıcıların şikâyet etmesi için bir neden kalmaz.
SSL yenileme sürecinde gerçekte ne yenilenir
SSL sertifikası, HTTPS bağlantısı sırasında sunucunuzun sunduğu kimlik belgesidir. Ziyaretçilerin doğru alan adına ulaştığını doğrular ve tarayıcılarıyla siteniz arasında şifreli iletişim kurulmasını sağlar.
Yenileme normalde web sitenizi, uygulamanızı veya sunucunuzun IP adresini değiştirmek anlamına gelmez. Eski sertifikanın süresi dolmadan mevcut sertifikanın yeni düzenlenmiş bir sertifikayla değiştirilmesi anlamına gelir. Kamuya açıkça güvenilen TLS sertifikalarının geçerlilik süreleri sınırlıdır; bu süre çoğunlukla yaklaşık 398 günü aşmaz. Birçok kuruluş daha kısa süreleri veya otomatik sertifika düzenlemeyi tercih eder. Sertifikadaki tarih, tarayıcının önerisi değildir. Bu tarih geçtikten sonra site kusursuz çalışıyor olsa bile ziyaretçiler süre sonu uyarısı görebilir.
Yenileme yöntemi, sertifika türüne ve sertifikayı düzenleyen kuruluşa bağlıdır. Ücretli, kuruluş doğrulamalı bir sertifika için onay e-postası, DNS kaydı veya web sitesine yerleştirilen bir dosya aracılığıyla doğrulama gerekebilir. Otomatik sertifikalarda genellikle HTTP veya DNS üzerinden ACME doğrulaması kullanılır. Operasyonel hedef aynıdır: alan adının denetiminin sizde olduğunu kanıtlamak, sertifikayı almak ve doğru şekilde dağıtmak.
Süre sonu e-postasıyla değil, envanterle başlayın
İlk iş, sertifikayı kullanan tüm uç noktaları bulmaktır. Tek bir işletmenin ana sitesi, www sürümü, müşteri portalı, API'si, posta sunucusu, hazırlık ortamı ve yük dengeleyicisi farklı sertifikalar kullanıyor olabilir. Bir ana makine adı için gelen süre sonu hatırlatması, diğerlerinin de kapsandığını göstermez.
Genellikle SAN olarak adlandırılan sertifikanın alternatif konu adlarını kontrol edin. Bunlar, sertifikaya dahil edilen alan adlarını ve alt alan adlarını gösterir. `www.example.com` dahil değilse, yalnızca `example.com` için düzenlenmiş bir sertifika onu korumaz. Joker karakterli sertifikalar `shop.example.com` gibi birinci düzey alt alan adlarını kapsar; ancak kök alan adını veya `eu.shop.example.com` gibi daha derin adları otomatik olarak kapsamaz.
Ayrıca TLS'nin nerede sonlandığını belirleyin. Basit bir VPS kurulumunda sertifika doğrudan NGINX, Apache, Caddy veya bir barındırma kontrol panelinde bulunabilir. Daha büyük bir kurulumda sertifika; ters proxy'ye, CDN'ye, bulut yük dengeleyicisine, Kubernetes ingress denetleyicisine veya trafik yük dengeleyicisinin arkasındaki birkaç düğüme yüklenmiş olabilir. Öndeki proxy hâlâ eski sertifikayı sunuyorsa uygulama sunucusundaki sertifikayı yenilemenin bir faydası olmaz. Bazen DNS düzeni pek zarif olmayabilir; ancak trafik yolu haritalandırıldığında durum denetim altına alınır.
Dahili hatırlatıcıları, herkese açık süre sonu tarihinden daha erkene ayarlayın. Sorunsuz bir sertifika için otuz gün makuldür; birden fazla ekibin, harici DNS sağlayıcılarının veya işletme doğrulamasının söz konusu olduğu durumlarda ise 45 ila 60 gün daha fazla esneklik sağlar. İzleme sistemi, örneğin 30, 14, 7 ve 3 gün kala birden fazla uyarı vermelidir. Tek bir e-posta hatırlatıcısı filtrelenebilir, gözden kaçabilir veya geçen ilkbaharda şirketten ayrılmış birine gönderilebilir.
Altyapınıza uygun bir doğrulama yöntemi seçin
Alan adı denetiminin doğrulanması, birçok yenilemenin durakladığı aşamadır. Sertifika yetkilisinin, talep edilen alan adını denetlediğinizi kanıtlamanız gerekir. En iyi yöntem, ekibinizin güvenli bir şekilde tekrarlayabileceği yöntemdir.
HTTP doğrulamasında, belirli bir herkese açık URL'ye belirli bir dosya yerleştirilir. Web sunucusuna 80 numaralı bağlantı noktasından doğrudan erişilebildiğinde ve sunucu doğru sanal konağı sunduğunda bu yöntem kullanışlıdır. Trafik alışılmadık şekilde yönlendiriliyorsa, site kısıtlayıcı bir proxy arkasındaysa veya güvenlik duvarı doğrulama isteğini engelliyorsa başarısız olabilir.
DNS doğrulaması için alan adının DNS sağlayıcısına bir TXT kaydı eklenmesi gerekir. Joker karakterli sertifikalar ve HTTP doğrulama yolunu dışarıya açamayan sistemler için genellikle daha iyi bir seçenektir. Dağıtık altyapılarda da iyi çalışır; ancak DNS yayılımı için zaman tanınmalıdır. Bazı DNS değişiklikleri saniyeler içinde görünür; diğerleri TTL ayarları, sağlayıcı davranışları ve önbelleğe alınmış çözümleyiciler nedeniyle daha uzun sürer. Sertifikanın düzenlendiği doğrulanana kadar doğrulama kaydını kaldırmayın.
E-posta doğrulaması küçük ve istikrarlı bir ortamda işe yarayabilir; ancak posta kutusuna erişime ve onaylı adreslere daha fazla bağımlıdır. Alan adı kaydındaki iletişim bilgileri güncel değilse veya rol posta kutusu artık izlenmiyorsa yenileme bu noktada durur. İş açısından kritik hizmetlerde DNS veya otomatik ACME doğrulaması genellikle insan kaynaklı darboğazları azaltır.
Sertifikayı dikkatli bir şekilde oluşturun
Elle yönetilen sertifikalarda, özel anahtarın saklanacağı sistemi kullanarak bir sertifika imzalama isteği ya da CSR oluşturun. CSR, açık anahtarı ve alan adı ayrıntılarını içerir. Özel anahtar gizli tutulmalıdır. Anahtarı e-postayla göndermeyin, destek kayıtlarına yapıştırmayın veya `final-final-use-this-one` adlı paylaşılan bir belgede saklamayın.
Yenileme sırasında mevcut bir anahtarı yeniden kullanabilirsiniz; ancak yeni bir özel anahtar oluşturmak genellikle operasyonel açıdan daha güvenli bir seçenektir. Anahtar rotasyonu, eski bir anahtar kimse fark etmeden açığa çıktıysa bunun etkisini sınırlar. Ödünleşim basittir: yeni bir anahtar, sertifikanın kullanıldığı her yerde dikkatli bir dağıtım gerektirir. Tek sunuculu kurulumların çoğunda bu ek iş azdır ve buna değer.
Sertifika düzenlendikten sonra sunucu sertifikasını ve sertifika yetkilisinin sağladığı ara sertifika zincirini indirin. Modern web sunucuları genellikle yaprak sertifika ile ara sertifikaları içeren tam zincir dosyası gerektirir. Eksik ara sertifikalar, özellikle eski cihazlarda veya daha az yaygın istemcilerde, tarayıcı güven hatalarının klasik nedenlerinden biridir.
Otomatik ACME istemcileri anahtar oluşturma, doğrulama, yenileme ve yükleme kancalarını yönetebilir. Kullanabilen sertifikalar için otomasyon kesinlikle önerilir; ancak yine de izlenmesi gerekir. DNS'ye erişemeyen, sertifika dizinine yazamayan veya NGINX'i yeniden yükleyemeyen bir otomatik yenileme görevi, ancak fazlasıyla iyimser bir anlamda otomatiktir.
Ziyaretçileri kesintiye uğratmadan dağıtım yapın
Herhangi bir şeyi değiştirmeden önce mevcut sertifikayı ve yapılandırmayı korumalı bir yedekleme konumuna kopyalayın. Yeni kurulum doğrulanana kadar önceki sertifikayı, anahtar referansını ve çalıştığı bilinen yapılandırmayı erişilebilir tutun. Böylece zincir dosyasında, izin ayarında veya sözdiziminde hata varsa ekibiniz hızlıca önceki duruma dönebilir.
Yeni sertifikayı ve eşleşen özel anahtarı beklenen konuma yükleyin. Özel anahtarı herkesin okuyabileceği hâle getirmeden web sunucusu sürecinin dosyaları okuyabildiğini doğrulayın. Linux'ta sahiplik ve izinlerin kısıtlayıcı olması önemlidir. Sertifika tasarımı gereği herkese açıktır; özel anahtarı ise değildir.
Yeniden yüklemeden önce web sunucusu yapılandırmasını doğrulayın. NGINX, Apache, HAProxy ve benzeri hizmetlerde önce ilgili ürünün yapılandırma testi komutunu kullanın. Ardından, mümkün olduğunda hizmeti yeniden başlatmak yerine yeniden yükleyin. Yeniden yükleme, mevcut çalışan süreçlerin ve etkin bağlantıların düzgünce tamamlanmasına izin verirken sertifika güncellemesini uygular. Bakım penceresinde tam yeniden başlatma kabul edilebilir; ancak birçok yaygın kurulumda buna gerek yoktur.
Hizmet birkaç sunucuda çalışıyorsa, kontrollü bir rotasyon öncesinde veya sırasında tüm düğümlere tutarlı biçimde dağıtım yapın. Yük dengeleyiciler, art arda gelen tarayıcı isteklerini farklı arka uçlara gönderebilir. Yeni sertifika yalnızca bir düğümde varsa aralıklı uyarılar görülebilir. Bu, gerçek olmadığı sanılana kadar hayal ürünü gibi görünen, özellikle can sıkıcı bir sorundur.
Sunucunun dışından doğrulayın
Kontrol paneli kurulumun başarılı olduğunu bildirdiğinde işlemi bitirmeyin. Sertifikayı harici bir ağdan doğrulayın ve ziyaretçilerin kullandığı ana makine adını inceleyin. Ortak adın veya SAN kapsamının, sertifikayı düzenleyen kuruluşun, son kullanma tarihinin ve sertifika zincirinin doğruluğunu teyit edin. Her ikisi de herkese açıksa hem kök ana makine adını hem de www ana makine adını kontrol edin.
Doğrulama noktalarından biri olarak tarayıcı kullanın; ancak yalnızca tarayıcıya güvenmeyin. Tarayıcı oturumları veya zincir bilgilerini önbelleğe almış olabilir. Herkese açık IP adresinde sunulan sertifikayı bildiren bir TLS istemcisiyle veya harici izleme denetimiyle test edin. Gelişmiş ortamlarda, barındırılan her alan adı için Sunucu Adı Belirtimi ya da SNI kullanarak doğru sertifikanın sunulduğunu doğrulayın.
Ardından uygulamanın davranışını kontrol edin: oturum açın, form gönderin, bir API uç noktasını çağırın ve HTTPS kullanan üçüncü taraf geri çağırma URL'lerini inceleyin. Sertifika yenileme uygulamanın davranışını değiştirmemelidir; ancak doğrulama ve proxy kuralları bazen ilgisiz yapılandırma sorunlarını açığa çıkarır. Hem harici sertifika denetimi hem de uygulama denetimleri başarılı olduğunda günlükler artık aynı durumu gösteriyor.
Bir sonraki yenilemeyi olaysız hâle getirin
En iyi SSL yenileme süreci, kimsenin acele etmek zorunda kalmadığı süreçtir. Sertifika sorumlusunu, yenileme yöntemini, DNS sağlayıcısını, hizmet konumunu, etkilenen ana makine adlarını ve geri alma adımlarını belgeleyin. Bu bilgileri yalnızca bir kişinin hafızasında değil, operasyon ekibinin erişebileceği bir yerde saklayın.
Yönetilen sunucularda sertifika izleme, çalışma süresi, disk, yedekleme ve hizmet denetimlerinin yanında yer almalıdır. Yaklaşan süre sonu tarihi yalnızca idari bir görev değil, operasyonel bir sinyaldir. kodu.cloud'da bu tür düzenli bakım işleri, yönetilen destek ve izleme hizmetleriyle doğal biçimde örtüşür: uç noktayı erkenden belirleyin, uygun doğrulama yöntemiyle yenileme yapın ve ardından hizmetin çalışır durumda olduğunu doğrulayın.
Sertifikanızın süresi dolmak üzereyse önce şu anda herkese ne sunulduğunu kontrol edin; ardından DNS, doğrulama ve sunucu yapılandırmasını inceleyerek ilerleyin. Genellikle ilerlemek için sorunsuz bir yol vardır. Yenileme için yeterli zaman ayırın, dışarıdan doğrulayın; ziyaretçileriniz yalnızca sitenin olması gerektiği gibi çalışmaya devam ettiğini fark edecektir.
Andres Saar Müşteri Destek Mühendisi