NGINX, ACME protokolü için yerel destek sunmaya başladı

• NGINX, SSL/TLS sertifikalarının verilmesini ve yenilenmesini otomatikleştiren ACME protokolü için yerel destek sunan bir önizleme sürümü yayımladı
• Rust tabanlı yeni modül ngx_http_acme_module sayesinde, harici araçlara gerek kalmadan yalnızca NGINX yapılandırmasıyla sertifika isteme, kurma ve yenileme mümkün hale geliyor
• Bu sayede Certbot gibi harici araçlara bağımlılık azalırken, güvenlik ve platform bağımsızlığı artıyor
• İlk sürüm HTTP-01 challenge desteği sunuyor; TLS-ALPN ve DNS-01 desteği ise gelecekte planlanıyor
• ACME desteğinin yalnızca web için değil, IoT ve edge computing ortamlarında güvenlik otomasyonu açısından da önemli bir rol oynaması bekleniyor

---

Genel Bakış ve Başlıca Değişiklikler

• NGINX, ACME protokolü desteğinin önizleme sürümünü yayımladı
• Yeni modül ngx_http_acme_module, sertifika isteme, kurma ve yenileme işlemlerinin doğrudan NGINX yapılandırmasından yönetilebilmesi için tasarlandı
• Bu ACME desteği, dahili olarak NGINX-Rust SDK kullanıyor ve Rust tabanlı dinamik bir modül olarak sunuluyor
• Bu özellikten yalnızca açık kaynak kullanıcıları değil, NGINX Plus kurumsal müşterileri de yararlanabiliyor
• Certbot gibi mevcut harici araçlara bağımlılığın azaltılması, sertifika yönetiminde güvenlik ve verimliliği artırıyor

ACME Protokolüne Giriş

• ACME (Automated Certificate Management Environment) protokolü, SSL/TLS sertifikalarının verilmesini, doğrulanmasını, yenilenmesini ve iptal edilmesini otomatikleştiren bir iletişim protokolüdür
• İstemciler, CA (Certificate Authority) ile otomatik iletişim kurarak aradaki manuel işlemlere gerek kalmadan sertifika yaşam döngüsünü yönetebilir
• Protokol, Internet Security Research Group (ISRG) tarafından 2015 yılında Let’s Encrypt projesi kapsamında geliştirildi ve yayımlandı
• ACME’den önce sertifika verme süreci daha manueldi ve maliyet ile hata olasılığı daha yüksekti
• En güncel ACMEv2, doğrulama yöntemleri ve wildcard desteği gibi çeşitli ek özelliklerle daha fazla esneklik ve güvenlik sağlıyor

NGINX’te ACME Tabanlı Sertifika Otomasyon Akışı

• NGINX’te ACME protokolüyle sertifika yaşam döngüsünün otomasyonu aşağıdaki 4 adımdan oluşuyor

• 1. ACME sunucusu yapılandırması

  • ACME özelliğini etkinleştirmek için acme_issuer ile ACME sunucusunun dizin URL’si mutlaka belirtilmeli
  • Sertifika işlemleri sırasında istemci iletişim bilgileri ve durum verilerinin saklanacağı yol gibi seçenekler de tanımlanabiliyor

• 2. Paylaşımlı bellek (zone) tahsisi

  • acme_shared_zone ile sertifikalar, özel anahtarlar ve challenge verilerini saklamak için ek bir paylaşımlı bellek zone yapılandırılabiliyor
  • Varsayılan boyut 256K ve ihtiyaçlara göre artırılabiliyor

• 3. Challenge yapılandırması

  • Mevcut önizleme sürümü yalnızca HTTP-01 challenge desteği sunuyor ve bu, alan adı sahipliğini doğrulamak için kullanılıyor
  • Bunun için NGINX yapılandırmasında 80 portu dinleyicisi ve varsayılan 404 yanıt ayarı tanımlanmalı
  • Gelecekte TLS-ALPN ve DNS-01 challenge desteği eklenecek

• 4. Sertifika verme ve yenileme

  • acme_certificate direktifinin server bloğuna eklenmesiyle ilgili alan adı için TLS sertifikası verme/yenileme otomatikleştirilebiliyor
  • Sertifikanın verileceği alan adı genellikle server_name ile belirtiliyor
  • server_name içindeki düzenli ifadeler ve wildcard kullanımı önizleme sürümünde desteklenmiyor
  • Modül içindeki $acme_certificate ve $acme_certificate_key değişkenleri üzerinden sertifika ve anahtar otomatik olarak bağlanıyor

Başlıca Avantajlar

• Dünya genelinde HTTPS kullanımındaki hızlı artışın merkezinde ACME protokolü yer alıyor
• Otomatik sertifika yönetimi sayesinde sertifika yaşam döngüsü yönetim maliyeti ve manuel işlemlerden kaynaklanan hatalar belirgin biçimde azalıyor
• Harici araçların kaldırılmasıyla saldırı yüzeyi küçülüyor ve taşınabilirlik sağlanıyor
• Farklı ortamlarda güvenlik standardizasyonunu teşvik ediyor

Gelecek Planları

• TLS-ALPN ve DNS-01 challenge desteği eklenecek
• Kullanıcı geri bildirimlerine göre özellikler genişletilecek
• IoT, API ve edge computing kullanımının artmasıyla ACME’nin gelecekte daha geniş kapsamlı otomatik güvenlik altyapılarında temel bir rol üstlenmesi bekleniyor
• NGINX’in yerel ACME desteği, web güvenliği, otomasyon ve ölçeklenebilirliği geleceğin standardı haline getiren bir temel işlevi görecek

Başlarken

• Açık kaynak kullanıcıları, NGINX Linux packages üzerinden önceden derlenmiş modülü kullanabilir
• NGINX Plus kurumsal müşterilerine F5 destekli dinamik modül olarak sunuluyor
• Modül belgeleri için NGINX Docs sayfasına bakabilirsiniz

[GN⁺]

Hacker News görüşleri

• Şu anki önizleme sürümü, istemcinin alan adı sahipliğini doğrulamak için yalnızca HTTP-01 challenge'ını destekliyor.
  DNS-01 yöntemi, genel internete açık olmayan nginx kullanıcıları için çok daha anlamlı bir özellik (örneğin Nginx Proxy Manager kullanırken). DNS-01 sadece kayıt güncellemeye dayandığı için bana her zaman en temiz yöntem gibi gelmiştir. Bu özelliğin gelmesini gerçekten bekliyorum.
  • Ancak bir DNS API anahtarına mutlaka sahip olmak gerekiyor ve birçok DNS sağlayıcısı zone bazında ayrı API anahtarı vermiyor. Ben şahsen DNS-01'i seviyorum ama pratikte can sıkıcı bir uzlaşma gerekebiliyor.
  • Beklemeye gerek yok: angie'de de destekleniyor (angie, aslında nginx geliştiricilerinin F5'ten ayrılıp yaptığı bir nginx fork'u).
  • Traefik'in ACME tarafındaki can sıkıcı yanı, DNS sağlayıcısı başına yalnızca tek bir API anahtarı kullanılabilmesi. Bu yüzden API anahtarlarını alan adına göre kısıtlamak ya da birden fazla hesabın alan adlarını kullanmak gerektiğinde çok sınırlayıcı oluyor. Nginx'in böyle bir kısıt olmadan gelmesini umuyorum.
  • Ben şahsen homelab'imde step-ca ve caddy kombinasyonuyla dns01 kullanıyorum. Deneyimden çok memnunum.
  • DNS-01 desteği çok iyi olduğu için Angie'ye geçmeyi de tavsiye ederim.
• Bu oldukça büyük bir değişiklik. Caddy bunu uzun zamandır destekliyordu ama herkes caddy'yi tercih etmiyor. Bu yükseltme, Traefik gibi yazılımların pazar payını elinden alabilir.
  • Özellikle Caddy'nin temiz sözdizimini seviyorum. Şu anda nginx'i (nginx proxy manager üzerinden) ve Traefik'i kullanıyorum ama yakın zamanda bir projeyi Caddy ile yaptım ve oldukça keyifliydi. Zaman bulursam self-hosted ortamımı Caddy'ye geçirmek istiyorum. Ya da pangolin gibi bir şey de kullanılabilir. Pangolin, Cloudflare Tunnels'a alternatif de sunuyor.
  • Kısa süre önce tamamen caddy'ye geçtim. nginx'in HTTP/1 desync sorununa karşı pasif yaklaşımı bardağı taşıran son damlaydı. Bir sorun çıkana kadar beklemek ya da auditor sorduğunda nginx'ten net bir yanıt alamamak hoşuma gitmiyor.
    Caddy, nginx'ten belirgin şekilde daha kolay. Çeşitli servisler, testler ve eğitim kurumlarına özel hizmetler için şablonlar, daha iyi loglama, benim için kusursuz sertifika yönetimi ve daha iyi metrik özellikleri sunuyor.
    Yine de eklenti tarafını hâlâ öğreniyorum; caddy'de rate limiting yok ve powerbi'daki bir bug nedeniyle belirli bir kullanıcının günde 300 bin kez görsel istemesi gibi durumlarda bu rahatsız edici olabiliyor.
  • Kesinlikle öyle düşünüyorum. Evde bir miktar traefik kullanıyorum ama artık bunu doğrudan değiştirecek gibiyim.
• Memnuniyetle karşılanacak bir değişiklik. Dokku'nun (maintainer'ıyım) Let's Encrypt eklentisiyle geçici bir çözüm kullandığı yerler var ve kullanıcılar sık sık rastgele sorunlar yaşıyor. nginx de reload sırasında bazen "takılıp" endpoint'i bulamıyor. Bu tür karmaşık değişken ne kadar az olursa o kadar iyi.
  Ancak bu özelliğin Ubuntu ya da Debian'ın stable deposuna girmesi biraz zaman alacaktır.
  Üstelik henüz DNS challenge (wildcard sertifikaları) desteği olmadığı için kısa vadede Dokku için çok yardımcı olmayabilir.
  • Merhaba! Sizi burada görmek güzel.
    dokku'yu denedim (ve hâlâ deniyorum) ama giriş eşiği oldukça yüksek geldi.
    Örneğin Coolify ile bir GitHub App oluşturunca dağıtımı hemen bağlayabiliyordum ve GH Actions ile container build/deploy deneyimim de oldu.
    dokku'nun resmi dokümantasyonu daha çok bir başvuru kaynağı gibi, ansiklopedi okuyormuşum hissi veriyor: dokku git başlatma resmi dokümanı
    Coolify'daki gibi anında dağıtıma götüren net bir başlangıç rehberinin daha faydalı olacağını düşünüyorum: coolify github entegrasyonu yardım sayfası
    Dokku için popüler OSS uygulamalarının kurulumu, adım adım hedef/tamamlanma odaklı bir başlangıç rehberi ve bare metal ortamda reverse proxy ile birkaç popüler uygulamayı bir arada ele alan eğitimler olmasını isterdim.
    Sonuçta Dokku'yu kullanma amacı Dokku'nun kendisi değil, Dokku ile kolay ve hızlı şekilde "istediğim duruma" ulaşmak.
    Nihayetinde istediğim şey, "beğendiğim bir repoya tıklayınca doğrudan kendi makineme deploy" edebilen, acısız bir süreç. Ondan sonra arka plandaki ayrıntıları kurcalamak isterim.
• İyi haber. Bilmeyenler için, dehydrated diye kolay bir çözüm vardı. vhost yapılandırmasına yalnızca birkaç satır eklemek yetiyor:

    location ^~ /.well-known/acme-challenge/ {  
      alias ;  
    }  
  

  dehydrated, uzun zamandır HTTP-01 yenilemesini otomatikleştirmek için kullanılan hafif bir araç.
  • Özellik gerçekten çok güzel ama binlerce kişinin bağımlı olduğu bir projenin sürekli Stable sürüm yayımlamaması üzücü.
    v1.0.0 resmî sürümü olmayan yazılımın arayüzü, önceden haber verilmeksizin her an değişebilir. Major sürüm 0, er ya da geç tuzağa dönüşüyor.
    Bakımcıları stable bir sürüm çıkarmaya zorlamayı tavsiye ederim.
    dehydrated 7 yıldır hâlâ major version 0 durumunda.
    0ver.org da bakmaya değer:
    "Production'da kullanılıyorsa aslında çoktan 1.0.0 olması gerekir" diyen bir sürümleme felsefesi.
    Ayrıntılar için buraya bakabilirsiniz.
• Bu sürümde küçük bir hata olmuş: ngx_http_acme_module, çeşitli Linux dağıtım paketlerine dahil edildi ama Debian stable hariç tutulmuş.
  nginx resmî paket listesine göre oldstable/oldoldstable var ama 4 gün önce çıkan Debian 13 Trixie yok.
  • Şu anda Trixie paket yükleme süreci üzerinde çalışıyoruz. Bu hafta içinde eklenecek. Debian 13 sadece 4 gün önce çıktığı için yeni işletim sistemi için altyapıyı hazırlamak biraz zaman aldı. (Ben F5 çalışanıyım.)
  • Bence bu muhtemelen Debian tarafındaki bir hata.
• Caddy'yi keşfettiğimden beri artık nginx kullanmıyorum. Geliştirici deneyimi çok daha iyi.
• Büyük açık kaynak şirketlerinin sorunu, "temel inovasyonu" anlamakta ve uygulamakta sürekli geç kalmaları.
  Caddy ve Traefik'in 5 yıl önce yaptığı şeyi nginx ancak şimdi desteklemeye başlıyor.
  Yine de bunun iyi bir değişiklik olduğunu düşünüyorum. En azından artık certbot'u elle çalıştırmak gerekmeyecek.
  • Aslında Caddy, neredeyse 10 yıl önce, 2016'da Let's Encrypt için otomatik HTTPS'i belli ölçüde destekliyordu.
    Nginx bu özelliği yaklaşık 9-10 yıl gecikmeyle getiriyor.
• Ben şahsen nginx'in sadece web içeriği sunması ve yenilemeleri certbot'un yapması modelini hiç sorunlu bulmadım.
  Tek bir işi iyi yapan ve birleştirilebilen Unix felsefesinin daha iyi olduğunu düşünüyorum.
  Her şeyi yapmaya çalışan "araçlar" kaçınılmaz olarak bir yerde yetersiz kalır.
  • certbot ile kurulum yapmak epey zahmetli bir deneyim.
    certbot otomatik yapılandırmayı denese de, ortam tam anlamıyla varsayılan değilse çoğu zaman iyi çalışmıyor.
    Her şeyi doğrudan nginx içinde halletmek bana daha iyi bir çözüm gibi geliyor.
• Yani bunu, nginx yapılandırma dosyasına birkaç satır ekleyerek artık certbot'u kurup çalıştırmaya gerek kalmayacağı şeklinde anlıyorum.
  Ayrıca Let's Encrypt dışındaki alternatifleri de daha kolay kullanmanın önü açılıyor mu, merak ediyorum.
• Heyecan verici bir değişiklik.
  Caddy, kutudan çıktığı gibi gelen kullanışlı özellikleriyle gerçekten çok yararlı.
  Benim Caddy'ye tamamen geçemememin nedeni ise nginx'in rate limiting ve geo modüllerine ihtiyaç duymam.