SSL Sertifikası Otomasyonu: ACME, API'ler ve Tüm Yaşam Döngüsü

SSL Sertifikası Otomasyonu Neden Artık Şart Haline Geliyor

SSL sertifikası otomasyonu eskiden yalnızca büyük altyapı ekipleri için "olsa iyi olur" bir konuydu. Artık herkes için neredeyse zorunlu hale geliyor; çünkü CA/Browser Forum'un kabul ettiği SC-081 oylaması, herkese açık güvenilir sertifikaların maksimum geçerlilik süresini kademeli olarak kısaltıyor: 15 Mart 2026'dan itibaren 200 gün, 2027'den itibaren 100 gün ve 2029'a kadar 47 gün — önceki 398 günlük üst sınırdan aşağı. Bu takvimi SSL sertifika süresinin neden kısaldığını anlattığımız yazımızda ayrıntılı olarak ele alıyoruz.

Alan adı doğrulaması (DCV) yeniden kullanım süreleri de paralel şekilde kısalıyor; 2029'a kadar bu süre 10 güne kadar inebiliyor. Bu da bir sertifika otoritesinin bir alan adını artık uzun süre "zaten kanıtlanmış" sayamayacağı anlamına geliyor — her yenilemede alan adı kontrolünü tekrar kanıtlayabilecek, tekrarlanabilir bir yönteme ihtiyacınız olacak.

47 günde, bir sertifika kabaca altı-yedi haftada bir ilgi ister. Tek bir alan adı için bu elle yönetilebilir. Ama onlarca veya yüzlerce sertifikayı yöneten bir hosting firması, ajans veya kurum için değil — bu yüzden SSL sertifikası yenilemesini otomatikleştirmek, sadece hatırlamak değil, artık bir tercih değil varsayılan beklenti haline geliyor.

Otomasyonda İki Yol: ACME Protokolü ve REST API'ler

Bugün SSL sertifikası verilişini ve yenilemesini otomatikleştiren iki ana yaklaşım var ve bunlar örtüşen ama tam olarak aynı olmayan sorunları çözüyor:

ACME, RFC 8555 ile standartlaştırılmış bir protokoldür: sunucunuzdaki veya altyapınızdaki bir istemci, alan adı kontrolünü kanıtlamak ve sertifika almak için doğrudan sertifika otoritesiyle konuşur; bir kez yapılandırıldıktan sonra hiçbir manuel adım gerekmez. Let's Encrypt'in ücretsiz, kısa ömürlü DV sertifikalarının arkasındaki protokol budur; giderek artan sayıda ticari sertifika otoritesi de bunu destekliyor, genellikle bir ACME talebini belirli bir ücretli hesaba bağlamak için External Account Binding ile birlikte.

Bir sertifika otoritesi veya bayilik platformunun REST API'si farklı bir şekil alır: standart bir protokol yerine, ürün ve fiyatları listelemek, sipariş vermek, doğrulama ve sertifika durumunu takip etmek ve verilen dosyaları indirmek için belgelenmiş uç noktaları çağırırsınız. Bu yol; ACME'nin genellikle kapsamadığı doğrulama seviyeleri dahil olmak üzere DV, OV ve EV ürünlerinde çalışır ve mevcut sağlama betiklerinize veya bir bayilik platformunun kendi sipariş yönetimi iş akışına doğal olarak uyar.

SSL Otomasyonunun Anahtarı: DNS Tabanlı Alan Adı Doğrulaması

Hangi yolu otomatikleştirirseniz otomatikleştirin, alan adı doğrulaması (DCV) genellikle geri kalanının insan müdahalesi olmadan çalışıp çalışamayacağını belirleyen adımdır. DNS tabanlı doğrulama — sertifika otoritesinin kontrol edeceği bir CNAME veya TXT kaydı yayınlamak — en temiz şekilde otomatikleştirilebilen yöntemdir; çünkü kayıt bir kez oluşturulduktan sonra genellikle her yenilemede kimse dokunmadan yeniden kontrol edilebilir.

HTTP dosyası ve e-posta doğrulaması da otomatikleştirilebilir, ama genellikle daha özel araçlar gerektirir: bir HTTP dosyasının doğru yolda tutulması gerekir, e-posta doğrulaması ise bir betiğin güvenilir şekilde okuyabileceği bir posta kutusuna bağlıdır. DNS sağlayıcınız bir API sunuyorsa — çoğu büyük sağlayıcı sunuyor — bir betik, sertifika talebiyle aynı işin parçası olarak doğrulama kaydını otomatik olarak oluşturabilir veya güncelleyebilir ve döngüyü uçtan uca kapatabilir. Mevcut yöntemleri alan adı doğrulama (DCV) rehberimizde daha ayrıntılı ele alıyoruz.

Otomatikleştirilmesi Gereken Tam SSL Sertifikası Yaşam Döngüsü

Yalnızca talep adımını otomatikleştirmek hâlâ boşluklar bırakır. Eksiksiz bir SSL sertifikası otomasyonu kurulumu genellikle şunları kapsar:

• Veriliş ve yenileme. ACME veya bir API kullanarak, mevcut sertifikanın süresi dolmadan önce yeni veya reissue edilmiş bir sertifika talep etmek — her seferinde birinin tarayıcıdan tıklamasına gerek kalmadan.
• Alan adı doğrulaması. Sertifika otoritenizin istediği DNS kaydını, HTTP dosyasını veya diğer kontrol kanıtını oluşturmak ve gerektiğinde yenilemek — mümkünse doğrudan DNS sağlayıcınızın kendi API'si üzerinden.
• Dağıtım. Yeni sertifikayı ve zincirini ihtiyaç duyan her sunucuya, yük dengeleyiciye veya CDN uç noktasına göndermek ve yeni dosyanın gerçekten devreye girmesi için ilgili servisi yeniden başlatmak.
• Bitiş tarihini ve zinciri izlemek. Her sertifikanın kalan geçerlilik süresini takip etmek; bir yenileme başarısız olursa, zincirde bir ara sertifika eksikse veya bir dağıtım tamamlanmadıysa — bir ziyaretçi tarayıcı uyarısı görmeden önce — uyarı almak.

Bunlardan herhangi birini atlamak, zaman baskısı altında unutulabilecek manuel bir adım bırakır — otomasyonun ortadan kaldırması gereken tam olarak bu hata biçimidir.

Hosting Firmaları ve Ajanslar İçin Pratik Bir Uygulama Planı

Manuel yenilemeden tam otomasyona geçiş nadiren tek adımda olur. İşe yarayan bir uygulama planı genellikle şöyle işler:

1. Önce envanter çıkarın. Herhangi bir otomasyon yazmadan önce her alan adını, sertifika otoritesini, doğrulama yöntemini ve bitiş tarihini listeleyin — haritalamadığınız bir şeyi otomatikleştiremezsiniz.
2. Mümkün olduğunda DNS tabanlı doğrulamada standartlaşın. Müşterileri veya alan adlarını HTTP dosyası ya da e-posta yerine DNS CNAME/TXT doğrulamasına yönlendirmek, en büyük manuel darboğazı ortadan kaldırır.
3. Tek seferde bir iş akışını otomatikleştirin. En yüksek hacimli sertifika türünüzle veya kendi altyapınızla başlayın, veriliş, doğrulama ve dağıtımı uçtan uca çalışır hale getirin, ardından diğer alan adlarına ve ürünlere genişletin.
4. İzlemeyi otomasyonun kendisinden bağımsız tutun. Ayrı bir bitiş tarihi kontrolü, otomasyonun kendisinin sessizce başarısız olduğu durumu yakalar.
5. İstisnaları belgeleyin. Bazı alan adları — üçüncü taraf barındırılan siteler, alışılmadık sunucu kurulumları, kurumsal inceleme gerektiren OV veya EV sertifikaları — daha uzun süre manuel bir adım gerektirebilir; her şeyin kapsandığını varsaymak yerine bunları açıkça takip edin.

Hosting firmaları için bu aynı zamanda bir müşteri iletişimi fırsatıdır: "çok yıllık" bir sertifikanın aslında arka planda otomatik olarak yenilenen bir abonelik olduğunu açıklamak, sessiz kalmaktan genellikle daha iyi karşılanır. Bu konuyu hosting firmaları için SSL satışı rehberimizde ele alıyoruz; bayilik tarafını ise hosting firmaları için çözümler sayfamızda bulabilirsiniz.

Küçük Bir Hosting Firması İçin 30 Günlük Otomasyon Planı

Otomasyona nereden başlayacağını bilmeyen küçük bir hosting firması için basit, zaman çizelgesine bağlı bir plan şöyle görünebilir:

1. 1-7. gün: Envanter ve önceliklendirme. Tüm müşteri alan adlarını, sertifika otoritelerini, doğrulama yöntemlerini ve bitiş tarihlerini tek bir listede toplayın; en çok sertifikaya sahip veya bitiş tarihi en yakın müşterilerle başlayın.
2. 8-14. gün: Doğrulama yöntemini standartlaştırın. Mümkün olan müşterileri DNS tabanlı doğrulamaya (CNAME/TXT) geçirin; DNS sağlayıcınızın API desteği varsa bu kaydı otomatik oluşturacak veya güncelleyecek şekilde ayarlayın.
3. 15-21. gün: Tek bir iş akışını uçtan uca kurun. En yüksek hacimli sertifika türünüzde veya kendi altyapınızda, ACME ya da bir REST API üzerinden veriliş, doğrulama ve dağıtımı deneyin; bir bayilik API'si kullanıyorsanız sipariş oluşturma ve durum takibini bu aşamada test edin.
4. 22-26. gün: İzleme ve uyarıları ekleyin. Otomasyondan bağımsız bir bitiş tarihi takibi kurun ve expiry hatırlatma e-postalarının açık olduğundan emin olun, böylece otomasyon sessizce başarısız olursa bunu fark edersiniz.
5. 27-30. gün: Genişletin ve belgeleyin. Çalışan iş akışını diğer müşteri alan adlarına yayın; manuel kalması gereken istisnaları — örneğin kurumsal inceleme gerektiren OV veya EV hesapları — ayrı olarak not edin.

SSLCipher API'siyle SSL Sertifika Yönetimini Otomatikleştirmek

SSLCipher'ın REST API'si tam olarak bu tür bir iş akışı için tasarlandı: ürün ve fiyatları listelemenize, sipariş oluşturmanıza, sertifika ve doğrulama durumunu takip etmenize ve verilen sertifikaları programatik olarak indirmenize imkân tanır; böylece veriliş ve yenilemeyi bayilik panelinde elle yapmak yerine bir betik veya kendi sağlama araçlarınız üstlenebilir. API anahtarları, yalnızca onayladığınız sunucuların kullanabilmesi için, izin verilen (allow-list) sunucu IP adresleriyle sınırlıdır. Kullanılabilir uç noktalar için geliştiriciler sayfamıza ve API dokümantasyonumuza göz atabilirsiniz.

Açıkça belirtmekte fayda var: SSLCipher'ın API'sinde bir ACME uç noktası bulunmuyor. İş akışınız özellikle ACME protokolüne bağlıysa, o adım için ACME destekleyen bir sertifika otoritesi kullanmanız gerekir; SSLCipher'ın API'si bunun yerine DV, OV, EV, Wildcard ve Multi-Domain ürünlerinde sipariş, doğrulama takibi ve sertifika teslimini otomatikleştirir.

SSL Sertifika Yaşam Döngünüzü Otomatikleştirmeye Başlayın

Maksimum geçerlilik süreleri kısalmaya devam ettikçe, SSL sertifikası otomasyonu bir kolaylık olmaktan çıkıp bir zorunluluğa dönüşüyor — önce büyük altyapı ekipleri için, kısa süre sonra da birkaç alan adından fazlasını yöneten herkes için. İster ACME üzerine, ister bir REST API üzerine, ister ikisi üzerine birden kurun, hedef aynı: veriliş, doğrulama, dağıtım ve izlemenin bir hatırlamaya değil, bir takvime bağlı çalışması.

Kendi altyapınız veya müşterileriniz için sertifika yönetiyorsanız, SSLCipher'ın API'sinin bu iş akışına nasıl uyduğuna bakın; otomasyonun yerini alması gereken manuel adımlar için ise SSL sertifikası yenileme rehberimize göz atabilirsiniz.

Sık sorulan sorular