SSL Sertifikası Otomatik Yenileme: ACME ve Certbot ile Kesintisiz HTTPS

Son Güncelleme: Ekim 2026

SSL sertifikası otomatik yenileme, web sitelerinin HTTPS üzerinden erişilebilir kalması için sertifika alma, doğrulama ve dağıtım işlemlerinin birlikte yönetilmesini gerektirir. Bu rehberde ACME, Certbot ve alan adı doğrulama yöntemlerini ele alarak hosting, VPS ve VDS ortamlarında yenileme hatalarını önlemeye yönelik uygulanabilir bir çalışma planı oluşturacağız.

İçindekiler

• Sertifika Yenileme: Neden önemlidir?
• ACME: Otomatik yenileme nasıl çalışır?
• Doğrulama Yöntemleri: HTTP-01 ve DNS-01 karşılaştırması
• Hosting Yönetimi: AutoSSL kontrolleri
• Certbot: Mevcut sertifikaları ve yenileme testini kontrol etme
• Dağıtım: Yenilenen sertifikayı servise yükleme
• Sorun Giderme: Yaygın yenileme hataları
• İzleme: Uçtan uca kontrol planı
• Uygulama Senaryoları: Farklı altyapılarda doğru yaklaşım
• SSS: Sıkça sorulan sorular
• Sonuç: Sürdürülebilir sertifika yönetimi

SSL Sertifikası Yenileme Neden Önemlidir?

Günlük kullanımda SSL sertifikası olarak adlandırılan sertifikalar, modern web bağlantılarında TLS (Taşıma Katmanı Güvenliği) ile kullanılır. TLS, iletişimin gizliliğini ve bütünlüğünü korurken sunucunun kimliğinin doğrulanmasını da sağlar. Sunucunun geçerli bir sertifika sunması, güvenli bağlantının temel parçalarından biridir; sertifika yönetimi bu nedenle yalnızca ilk kurulumdan ibaret değildir.

Sertifika geçerlilik tarihinin aşılması, kullanıcıların güvenli bağlantı uyarılarıyla karşılaşmasına neden olabilir. Ayrıca HSTS (HTTP Katı Aktarım Güvenliği) kullanan sitelerde tarayıcılar sertifika hatalarını daha sıkı ele alabilir ve kullanıcıya hatayı atlayarak devam etme olanağı sunmayabilir. Dolayısıyla yenileme sürecinin çalıştığını varsaymak yerine düzenli olarak doğrulamak gerekir.

Bu rehber için önerilen işletim yaklaşımı, sertifika yenilemeyi ayrı bir bakım görevi değil, uygulamanın erişilebilirlik planının parçası olarak değerlendirmektir. Sorumlu kişi, kullanılan istemci, doğrulama yöntemi, dağıtım hedefi ve alarm alıcısı aynı kayıt içinde tutulmalıdır. Böylece bir hata oluştuğunda ekip yalnızca sorunu görmekle kalmaz; hangi bileşene müdahale edeceğini de bilir.

ACME ile Otomatik Sertifika Yenileme Nasıl Çalışır?

ACME (Otomatik Sertifika Yönetim Ortamı), sertifika istemcisi ile sertifika otoritesi arasındaki işlemleri otomatikleştirmek için kullanılır. Alan adı kontrolü, challenge (doğrulama sınaması) adı verilen işlemlerle kanıtlanır. Bu sınamalar çoğunlukla istemci tarafından otomatik yürütülür; ancak web sunucusu ve DNS yapılandırmasının seçilen yönteme uygun olması gerekir.

Operasyon açısından yenilemeyi dört kontrol noktasına ayırmanızı öneririz: yenileme girişiminin başlatılması, alan adı doğrulamasının tamamlanması, yeni sertifikanın ilgili servise dağıtılması ve dışarıdan sunulan sertifikanın kontrol edilmesi. Kontrol listesini bu şekilde düzenlemek, başarılı bir sertifika üretiminin neden her zaman başarılı bir yayın anlamına gelmediğini görünür kılar.

Özellikle birden fazla web sunucusunun bulunduğu ortamlarda sertifikanın alınması ile doğru düğümlere ulaştırılması farklı görevlerdir. Merkezi yönetim, yenileme zamanlarının dengelenmesi ve dağıtımın açıkça tanımlanması büyük ölçekli yapılarda önem taşır. Yenileme işlemlerini son ana bırakmamak, geçici doğrulama veya servis sorunları için müdahale payı sağlar.

HTTP-01 ve DNS-01 Doğrulama Yöntemleri

HTTP-01 hangi yapılara uygundur?

HTTP-01, alan adının web sunucusunda belirli bir doğrulama dosyası yayımlanmasına dayanır. İstemcinin hazırladığı içerik /.well-known/acme-challenge/ altında erişilebilir olmalıdır. Bu yöntemde doğrulama port 80 üzerinden yapılır; wildcard (joker alan adı) sertifikası alınamaz. Birden fazla web sunucusu varsa ilgili içerik doğrulama isteğini karşılayabilecek bütün sunucularda bulunmalıdır.

DNS-01 hangi yapılara uygundur?

DNS-01, _acme-challenge adı altında bir TXT kaydıyla alan adı kontrolünü kanıtlar ve wildcard sertifikalarını destekler. Otomasyon için DNS sağlayıcısının API (Uygulama Programlama Arayüzü) erişimi önemlidir. Kullanılan kimlik bilgilerinin mümkün olduğunca dar yetkili olması, web sunucusu ele geçirildiğinde DNS yönetiminin de etkilenmesi riskini sınırlar.

Bu karşılaştırmayı seçim için kullanın: tek web sunuculu ve dışarıdan erişilebilir bir site için HTTP-01 ile başlayabilirsiniz; wildcard veya internetten erişilemeyen web hizmetleri için DNS-01 daha uygun olabilir. Seçimi yalnızca ilk kurulum kolaylığına göre değil, gelecekte yenilemenin nasıl sürdürüleceğine göre yapın.

Hosting Ortamında AutoSSL Yenileme Kontrolleri

Paylaşımlı hosting kullanırken işletim sistemine ayrı bir sertifika istemcisi kurmak yerine mevcut kontrol panelinin yönetim mekanizmasını değerlendirin. cPanel ve WHM ortamında AutoSSL, etkinleştirildiği kullanıcıların alan adları için alan adı doğrulamalı sertifikaların kurulmasını yönetebilir. WHM tarafındaki yönetim ekranı kullanıcı ayarlarını, işlem kayıtlarını ve bekleyen görevleri incelemeye olanak verir.

Kontrol sırasında önce ilgili hesabın kapsamını ve hangi alan adlarının korunduğunu belirleyin. Ardından panelde bildirilen doğrulama sorunlarını okuyun. Bir sertifikanın mevcut olması, her alt alan adının aynı sertifikayla kapsandığı anlamına gelmez; inceleme alan adı bazında yapılmalıdır. AutoSSL durumu, dışlanan alan adları ve doğrulama sorunları panelin ilgili işlevleri üzerinden değerlendirilebilir.

1. Kapsam kontrolü: Ana alan adını, kullanılan alt alan adlarını ve ilgili sertifika durumlarını kaydedin.
2. İşlem kontrolü: AutoSSL kayıtlarında başarısız doğrulama veya bekleyen işlem olup olmadığını inceleyin.
3. Yetki kontrolü: Özelliğin hesap için etkin olduğunu yönetim ekranından doğrulayın.
4. Sonuç kontrolü: Yenileme sonrasında ziyaretçinin gördüğü sertifikayı ayrıca test edin.

Bu listeyi hosting sağlayıcınızla iletişim kurarken de kullanabilirsiniz. Destek talebine alan adı, hata zamanı ve panelde görünen hata metnini eklemeyi öneririz. Corelux Linux Hosting seçeneklerini değerlendirirken sertifika yönetimi ve yenileme sorumluluğunun nasıl paylaşıldığını ayrıca netleştirebilirsiniz.

VPS ve VDS Üzerinde Certbot Yenilemesini Test Etme

Certbot ile yönetilen bir sunucuda önce mevcut sertifika adlarını inceleyin. Aşağıdaki örnekler, Certbot'un önceden kurulmuş ve sertifikaların bu istemciyle yönetiliyor olduğu Linux ortamları içindir. Alan adı örneklerini kendi sertifika adınızla değiştirin; panel tarafından yönetilen bir sunucuda aynı sertifikaya ikinci bir yönetici eklemeyin.

sudo certbot certificates

Ardından kayıtlı yenileme ayarlarını denemek için test çalıştırın. --dry-run, yenilemenin başarılı olup olmayacağını test etmek amacıyla kullanılır. Belirli bir sertifikayı seçmek için --cert-name parametresi verilebilir.

sudo certbot renew --dry-run
sudo certbot renew --cert-name example.com --dry-run

Test ortamı ile canlı ortamı ayırın

Deneme ortamında üretilen sertifikalar, canlı ortam sertifikaları gibi tarayıcılar tarafından güvenilir kabul edilmez. Testlerin bu ortamda yapılması, yapılandırmayı doğrularken canlı sertifika üretim sınırlarına gereksiz yere yaklaşma riskini azaltır. Test sertifikalarını üretim ziyaretçilerine sunacak şekilde yerleştirmeyin.

Başarılı testin sınırlarını bilin

Certbot testinde dağıtım kancaları varsayılan olarak çalışmaz; bunların çalıştırılması ayrıca etkinleştirilebilir. Bu nedenle başarılı bir test sonucunu, web servisinin yeni sertifikayı yüklediğinin kanıtı olarak değerlendirmeyin. Test sırasında bazı ön ve son işlem kancaları çalışabileceğinden, üretim ortamındaki denemeyi bakım prosedürünüzle uyumlu şekilde planlayın.

Önerilen kayıt formatı basittir: test tarihi, hedef sertifika, sonuç, görülen hata ve yapılan değişiklik. Bu kayıt, web kökü veya DNS sağlayıcısı değiştiğinde önceki yapılandırmayla karşılaştırma yapmayı kolaylaştırır.

Yenilenen Sertifikanın Web Servisine Yüklenmesi

Sertifikayı alan istemci ile HTTPS bağlantısını karşılayan servis arasındaki ilişki açık olmalıdır. Certbot, başarılı yenileme sonrasında bir işlem çalıştırmak için deploy hook (dağıtım kancası) desteği sunar. Bu mekanizma, yenileme girişiminden bağımsız olarak her zaman çalışan bir komut yerine başarılı yenilemeye bağlı dağıtım işlemi tanımlamanızı sağlar.

Nginx kullanan, systemd ile yönetilen ve sertifikaları doğrudan bu web sunucusunun okuduğu bir ortam için aşağıdaki komut bir örnektir. Mevcut Certbot eklentiniz yeniden yüklemeyi zaten gerçekleştiriyorsa aynı işlemi gereksiz yere ikinci kez tanımlamayın.

sudo certbot renew --deploy-hook 'nginx -t && systemctl reload nginx'

Örnekte önce yapılandırma kontrol edilir, yalnızca kontrol başarılıysa servis yeniden yüklenir. Nginx yeniden yükleme sırasında yeni yapılandırmayı uygulamaya çalışır; uygulama başarılı olduğunda yeni çalışan süreçleri başlatır ve eski süreçlerin mevcut bağlantıları tamamlamasına olanak tanır. Bu, gereksiz servis durdurma yerine kontrollü yeniden yükleme yaklaşımını destekler.

Bu komutu bir kez elle çalıştırmak kalıcı otomasyonun tamamlandığını göstermez. Dağıtım işlemini mevcut zamanlanmış yenileme akışına veya uygun kanca yapılandırmasına dahil edin. Konteynerli yapılarda sertifikanın doğru dosya bağlantısı üzerinden görünmesi ve yeniden yükleme işleminin doğru serviste yürütülmesi de ayrıca planlanmalıdır.

SSL Sertifikası Yenileme Hataları Nasıl Giderilir?

IPv4 çalışırken IPv6 doğrulamasının başarısız olması

Alan adı hem A hem AAAA kaydına sahipse IPv6 yönlendirmesini de kontrol edin. Doğrulama sistemi ilk bağlantıda IPv6'yı tercih edebilir; yanlış içerik döndüren bir IPv6 sunucusu, IPv4 tarafı doğru çalışsa bile doğrulamayı başarısız kılabilir. Eski bir AAAA kaydını yalnızca var olduğu için korumayın; kaydın gerçekten hizmet veren doğru sunucuya yöneldiğini doğrulayın.

Üretim ortamında gereksiz tekrar denemeleri

Hata nedeni değişmeden sertifika isteğini tekrar tekrar çalıştırmak uygun bir tanılama yöntemi değildir. Sertifika otoriteleri istek ve doğrulama sınırları uygulayabilir. Önce hata mesajının hangi aşamaya işaret ettiğini belirleyin, düzeltmeyi test ortamında doğrulayın ve canlı işlemi bundan sonra tekrarlayın. Yenileme algılama yöntemleri de sınırlara ilişkin davranışı etkileyebilir.

DNS kaydının her yerde aynı görünmemesi

DNS-01 hatalarını incelerken yalnızca yerel bilgisayarınızdan görülen sonucu yeterli kabul etmeyin. DNS güncellemesinin sağlayıcının bütün yetkili sunucularında erişilebilir hale gelmesi zaman alabilir. TXT kaydı oluşturulduktan hemen sonra doğrulamaya geçmek yerine istemcinin yayılım bekleme davranışını sağlayıcınızın özellikleriyle uyumlu hale getirin.

Tabloyu bir müdahale sırası olarak kullanın; tek bir belirtiden kesin neden çıkarmayın. Her değişiklikten sonra aynı testi tekrar ederek sorunun hangi adımla giderildiğini kaydedin.

Sertifika Yenilemesi İçin Uçtan Uca İzleme Planı

Harici sertifika izleme, süresi dolmak üzere olan sertifikaların fark edilmesi için ayrı bir güvence katmanıdır. Yenileme istemcisinin çalışması ile kullanıcıya sunulan sertifikanın durumu farklı kontrol noktaları olduğundan, yalnızca yerel görev kayıtlarına güvenmeyin. Sertifika sona erme izleme seçeneklerini işletim planınızın parçası haline getirin.

Sunulan sertifikanın tarihlerini kontrol edin

Aşağıdaki örnek, uzaktaki sunucunun sunduğu sertifikayı alıp başlangıç ve bitiş tarihleriyle birlikte temel kimlik alanlarını görüntüler. SNI (Sunucu Adı Göstergesi) için alan adı verilmesi, aynı IP üzerinde birden fazla site bulunan yapılarda ilgili sunucu adının seçilmesini sağlar. Bu çıktı inceleme amaçlıdır; tek başına kapsamlı güven doğrulaması değildir.

openssl s_client -connect example.com:443 -servername example.com < /dev/null | openssl x509 -noout -subject -issuer -dates

Zincir ve alan adı doğrulamasını ayrıca yapın

Bir sonraki örnek, sertifika doğrulama hatalarında işlemin hata vermesini ve sertifikanın beklenen alan adı için kontrol edilmesini ister. Sonucun kullanılan sistemin güven deposuna da bağlı olduğunu unutmayın; çıktıyı bütünüyle inceleyin.

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com -verify_return_error < /dev/null

İşletim planı için şu alarm ayrımını öneririz: yaklaşan son kullanım tarihi, başarısız yenileme ve başarısız dağıtım ayrı olaylar olarak kaydedilsin. Alarm eşiklerini sertifikanın gerçek süresine ve ekibinizin müdahale hızına göre belirleyin. Ekip değişikliklerinde bildirim adreslerini de kontrol listesine ekleyin.

Farklı Altyapılar İçin Pratik Uygulama Senaryoları

Tek sunucuda kurumsal web sitesi

Örnek olarak tek Nginx sunucusunda çalışan bir kurumsal siteyi düşünün. Burada önerilen plan, mevcut HTTP doğrulama yolunu korumak, Certbot yenilemesini test etmek, başarılı yenileme sonrasındaki yeniden yüklemeyi doğrulamak ve dış sertifika kontrolünü tamamlamaktır. Web kökü değişikliği gibi uygulama yayın kararlarının sertifika doğrulamasını etkileyip etkilemediği de bakım kontrolüne dahil edilmelidir.

Wildcard kullanan uygulama altyapısı

Çok sayıda alt alan adı kullanan bir projede DNS-01 otomasyonunu değerlendirin. Önerilen görev paylaşımı, DNS kimlik bilgilerinin yönetimini belirli bir sorumluya vermek, yetki kapsamını sınırlandırmak ve sertifika dağıtımını ayrı izlemektir. Web sunucusuna geniş DNS yetkisi vermek yerine dar yetkili erişim veya ayrı doğrulama sunucusu yaklaşımı kullanılabilir.

Birden fazla sunucu düğümü

Yük dengeleyicili bir uygulamada önce TLS bağlantısının nerede sonlandığını belirleyin. Önerilen envanter; bağlantı katmanı, sertifika dosyasının bulunduğu konum, dağıtım hedefleri ve her hedefin kontrol yöntemi alanlarını içermelidir. HTTP doğrulaması farklı düğümlere ulaşabiliyorsa doğrulama içeriğinin tutarlı sunulması, merkezi sertifika yönetimi kullanılıyorsa dağıtımın tamamlanması gerekir.

Altyapı seçimi yaparken Corelux Türkiye VDS Sunucu ve Bulut Sunucu seçeneklerini proje gereksinimlerinizle birlikte değerlendirebilirsiniz. Satın alma öncesi hazırlık listesine sertifika yönetiminin kimin sorumluluğunda olacağını ve ihtiyaç duyduğunuz yönetim erişimini de ekleyin.

Sıkça Sorulan Sorular

Sonuç: Yenilemeyi Değil, HTTPS Sürekliliğini Yönetin

SSL sertifikası otomatik yenileme için önerilen temel yaklaşım, işlemi dört ayrı kontrolle yönetmektir: başlatma, doğrulama, dağıtım ve dış erişim testi. Bu rehberdeki kontrol listesini sunucu envanterinize uyarlayın; her sertifika için bir sorumlu, test kaydı ve müdahale yolu belirleyin.

Projenize uygun çözümleri değerlendirmek için Corelux SSL Sertifikası, Hosting ve Sanal Sunucu hizmetlerini inceleyebilirsiniz. Seçiminizi yalnızca ilk kuruluma göre değil, sertifika yönetimini uzun vadede nasıl sürdüreceğinize göre yapın.