FileZilla Server’da CSR Nasıl Oluşturulur

Bu eğitim size FileZilla Server için nasıl CSR oluşturulacağını gösterir. En çok zaman kazandıracak kısımla başlayalım: FileZilla Server bir Certificate Signing Request oluşturamaz. Yönetim arayüzünde, hiçbir sürümde bunun için bir düğme yoktur. Sunucu, self-signed bir sertifika oluşturabilir, Let’s Encrypt’ten otomatik olarak bir tane alabilir veya sizin sağladığınız bir sertifika ile özel anahtarı yükleyebilir; ticari bir Certificate Authority’den alınan sertifika bu üçüncü seçeneğe girer. Dolayısıyla talep, FileZilla Server’ın dışında, OpenSSL ile veya çevrimiçi bir oluşturucu ile hazırlanır ve sunucuya yalnızca tamamlanmış anahtar ile sertifika teslim edilir.

Komutlardan önce sürümlerle ilgili bir not, çünkü bu, hangi terminali açacağınızı belirler. FileZilla Server, Eylül 2021’de 1.0 sürümü için yeniden yazıldı ve şu anki sürüm, Mayıs 2026’da yayınlanan 1.12.6. Debian ve macOS paketleri, Aralık 2021’de 1.2.0 sürümüyle geldi; ondan önce sunucu yalnızca Windows üzerinde çalışıyordu ve çoğu kurulum hâlâ Windows üzerinde bulunuyor. “SSH üzerinden oturum açın” diye başlayan eski talimatlar, sessizce bir Linux ana bilgisayar varsayar. Eski 0.9.x serisi, Şubat 2017’de 0.9.60.2 ile sona erdi ve o zamandan beri hiçbir güvenlik güncellemesi almadı; hâlâ bu sürümdeyseniz, yükseltmeyi sertifikayla birlikte planlayın.

FileZilla Server sertifikalarla ne yapar

Talebi oluşturmadan önce hedefi görmek faydalıdır, çünkü bu, dosyaların hangi biçimde olması gerektiğini gösterir. FileZilla Server yönetim arayüzünü açın, sunucuya bağlanın, ardından menü çubuğundan Server ve Configure… seçin (klavye kısayolu Ctrl+F‘dir). Soldaki ağaçta, Protocols settings, ardından FTP and FTP over TLS (FTPS), ardından Connection Security sekmesini açın.

Bu sayfada iki şey bulunur: v1.2 ve v1.3 sunan bir Minimum allowed TLS version menüsü ve üç seçenekten oluşan, başka hiçbir şey olmayan bir TLS credentials seçici:

• Provide a X.509 certificate and private key. İki alan, Certificate ve Private key, bunların her biri ya doğrudan arayüze yapıştırılan ham PEM verisini ya da sunucunun dosya sistemindeki bir dosya yolunu kabul eder. Anahtar alanı, anahtar bir donanım token üzerinde bulunuyorsa ayrıca bir PKCS#11 URL’sini de kabul eder. Bunların altında Private key password (stored in plaintext) bulunur. CA tarafından verilen bir sertifika buraya girer.
• Use a self-signed X.509 certificate. Sunucunun kendisinin imzaladığı bir sertifika oluşturan bir Generate new düğmesi. Kapalı bir test için kullanışlıdır, ancak hiçbir istemci buna güvenmez, bu yüzden her bağlantı bir uyarı üretir.
• Use a Let’s Encrypt® certificate. FileZilla Server 1.0’da eklenen yerleşik ACME desteği. Sunucu sertifikayı kendisi talep eder ve yeniler, sizin işleyeceğiniz herhangi bir CSR yoktur.

Bu üç seçenekten hiçbiri, bir Certificate Authority’ye gönderebileceğiniz bir certificate signing request üretmez. FileZilla Server, Let’s Encrypt alışverişinin bir parçası olarak dahili olarak bir tane oluşturur, ancak bu asla diske yazılmaz veya arayüzde gösterilmez ve o otomatik siparişe bağlıdır.

Bu ekrandan iki ayrıntının bir sonraki bölüme taşınması değerlidir. Birincisi, yol alanları yönetim arayüzünü çalıştıran makinede değil, sunucu motorunu çalıştıran makinede çözümlenir; bu önemlidir çünkü ikisi genellikle farklı bilgisayarlardır. İkincisi, arayüz sertifika ve anahtarı yapıştırılmış metin olarak da kabul ettiğinden, dosyaları sunucuya kopyalamak zorunda kalmayabilirsiniz. Her iki durumda da, oluşturmak üzere olduğunuz özel anahtarın bir şekilde o makineye ulaşması gerekir ve onu orada oluşturmak en basit yoldur.

FileZilla Server için CSR oluşturun

CSR’ınızı zaten oluşturduysanız, bu bölümü atlayın ve sertifika verildikten sonra doğrudan FileZilla Server’a SSL sertifikası yükleme bölümüne geçin. Aksi takdirde, aşağıdaki iki yoldan birini seçin. İkisi de aynı dosya çiftini üretir.

Seçenek 1: SSL Dragon CSR Oluşturucusunu kullanın

CSR Oluşturucumuz, tek bir formdan talebi ve eşleşen özel anahtarı oluşturur, bu da yalnızca tek bir komut çalıştırmak için Windows sunucusuna OpenSSL kurmayı gereksiz kılar. Ürettiği özel anahtarı kaydedin ve güvenli bir yerde saklayın. CA’nın verdiği sertifika onsuz işe yaramaz ve kimse size yerine bir yenisini gönderemez.

Seçenek 2: CSR’ı OpenSSL ile oluşturun

Komutu nerede çalıştıracağınız, FileZilla Server’ı barındıran işletim sistemine bağlıdır:

• Windows. Command Prompt veya PowerShell’i açın. Windows OpenSSL ile birlikte gelmez, bu yüzden birine ihtiyacınız var: Git for Windows, Git Bash içinde yol üzerinde bulunan bir yapı içerir, veya bağımsız bir Windows OpenSSL paketi kurabilir ya da Windows Subsystem for Linux’u kullanabilirsiniz. Hangisini seçerseniz seçin, önce openssl version komutunu çalıştırın ve yanıt verdiğinden emin olun.
• Linux. Sunucuda bir terminal açın veya SSH üzerinden bağlanın. OpenSSL ana akım dağıtımlarda varsayılan olarak kurulu gelir.
• macOS. Terminal’i açın. macOS’taki openssl komutu, OpenSSL yerine bir LibreSSL derlemesidir; bu durum aşağıda belirtilen birkaç seçenek için önemlidir. Bu eğitimdeki her komut her iki derlemede de çalıştırıldı ve ikisinde de çalışır.

Tekrar bulabileceğiniz bir dizine geçin, ardından şu tek komutu çalıştırın. Bu, özel anahtarı ve talebi birlikte oluşturur:

openssl req -new -newkey rsa:2048 -nodes -keyout ftp.yourdomain.com.key -out ftp.yourdomain.com.csr -addext "subjectAltName=DNS:ftp.yourdomain.com"

Her parçanın ne yaptığı:

• req -new yeni bir certificate signing request oluşturur.
• -newkey rsa:2048 aynı anda yeni bir 2048 bit RSA anahtarı oluşturur. Bu, genel CA’ların imzalayacağı en küçük anahtardır. Güvenlik politikanız gerektiriyorsa rsa:4096 kullanın.
• -nodes, özel anahtarı bir parola olmadan yazar, böylece FileZilla Server bunu bir yeniden başlatmadan sonra gözetimsiz okuyabilir. Bu yazımı kullanın, daha yeni olan -noenc takma adını değil: OpenSSL 3.x her ikisini de kabul eder, ancak macOS’un openssl olarak sunduğu LibreSSL derlemesi -noenc‘i reddeder ve çalışmak yerine kullanım bilgisini yazdırır.
• -keyout ve -out iki çıktı dosyasını adlandırır. Bunları ana bilgisayar adına göre adlandırmak, server.key ve server.csr’den daha iyidir, çünkü bir yıl sonra birkaç taneniz olacak.
• -addext "subjectAltName=...", ana bilgisayar adını Subject Alternative Name uzantısına yerleştirir. Bunu atlamayın. CA/Browser Forum Baseline Requirements artık Common Name’i önerilmeyen bir alan olarak tanımlıyor ve içindeki herhangi bir değerin SAN girdilerinden türetilmesini şart koşuyor, dolayısıyla yetkili olan SAN listesidir.

Birden fazla ana bilgisayar adı veya bir wildcard için, aynı seçeneği virgülle ayrılmış bir liste ile genişletin. Common Name’i içinde tekrarlayın:

-addext "subjectAltName=DNS:ftp.yourdomain.com,DNS:files.yourdomain.com"

-addext "subjectAltName=DNS:*.yourdomain.com,DNS:yourdomain.com"

Eliptik eğri tabanlı bir anahtar kullanmayı tercih ediyorsanız, eşdeğer komut aşağıdadır. Öncelikle Certificate Authority’nizin satın aldığınız ürün için ECDSA sertifikaları verip vermediğini kontrol edin, çünkü her marka bunu yapmaz.

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes -keyout ftp.yourdomain.com.key -out ftp.yourdomain.com.csr -addext "subjectAltName=DNS:ftp.yourdomain.com"

İkinci -pkeyopt süsleme değildir. OpenSSL üzerinde hiçbir şeyi değiştirmez, çünkü adlandırılmış bir eğri zaten varsayılandır, ancak macOS ile birlikte gelen LibreSSL derlemesinde bunun eksikliği, talebin eğriyi adlandırmak yerine tüm parametrelerini yazarak tanımlamasına neden olur. RFC 5480, bu formu genel sertifikalarda yasaklar ve bu şekilde oluşturulan bir talep hiçbir eğriyi tanımlamaz.

Soruları yanıtlayın

OpenSSL şimdi talebin içine girecek ayrıntıları şu sırayla sorar:

1. Country Name (2 letter code): ülkeniz için iki harfli kod, örneğin US. İşte tam ülke kodları listesi.
2. State or Province Name (full name): tam olarak yazılmış hâli. California, CA değil.
3. Locality Name (eg, city): şehrin tam adı, örneğin San Jose.
4. Organization Name (eg, company): kuruluşunuzun tam yasal adı, örneğin Example Holding LLC. Bir Domain Validation sertifikası satın alıyorsanız, CA bu alanı doğrulamaz veya kullanmaz, dolayısıyla boş bırakılabilir.
5. Organizational Unit Name (eg, section): boş bırakın. 1 Eylül 2022’den bu yana CA/Browser Forum Baseline Requirements, bu özniteliği CA’ların dahil etmemesi gereken bir öznitelik olarak listeliyor, dolayısıyla ne yazarsanız yazın atılacaktır.
6. Common Name: FTPS istemcilerinizin bağlandığı tam nitelikli ana bilgisayar adı, örneğin ftp.yourdomain.com, veya wildcard *.yourdomain.com. Bu isteğin ifadesi derlemeler arasında hafifçe farklılık gösterir, ancak varsayılan yapılandırmada bu altıncı sorudur.
7. Email Address: isteğe bağlı ve genellikle boş bırakılır.
8. A challenge password: boş bırakın. Bu, talebin kendisine ait eski bir özniteliktir, asla verilen sertifikaya ulaşmaz ve sertifika sipariş formları bunu sormaz.
9. An optional company name: bunu da boş bırakın.

Yazmaya başlamadan önce bilinmesi gereken bir tuzak. “Boş bırakın” ifadesi “Enter’a basın” anlamına gelmez. Bazı alanlar, isteğin sonunda köşeli parantez içinde gösterilen OpenSSL yapılandırma dosyasından gelen varsayılan bir değer taşır ve Enter’a basmak, alanı boş bırakmak yerine bu varsayılanı kabul eder. Standart bir OpenSSL yapılandırmasında, ilk birkaç soruda Enter’a basmak, C=AU, ST=Some-State ve O=Internet Widgits Pty Ltd yazan bir talep üretti; bu, kimsenin bir Certificate Authority’ye göndermek isteyeceği bir şey değildir. Bir alanı gerçekten boş bırakmak için tek bir nokta yazıp Enter’a basın. OpenSSL, soruların hemen üzerinde yazdırdığı girişte bunu zaten belirtir.

Son soru yanıtlandığında, mevcut dizinde iki yeni dosyanız olur:

• ftp.yourdomain.com.csr: certificate signing request. Sipariş formunuza yapıştıracağınız dosya budur.
• ftp.yourdomain.com.key: özel anahtar. Bu asla Certificate Authority’ye gitmez ve asla sizin kontrolünüzden çıkmaz. Onu elinde bulunduran herkes sunucunuzun kimliğine bürünebilir, bu yüzden kimin okuyabileceğini kısıtlayın ve üç yıl sonra hâlâ erişebileceğiniz bir yerde yedekleyin. Onu kaybederseniz verilen sertifika kullanılamaz hâle gelir: yeni bir talep oluşturup yeniden verilmesini istemeniz gerekir.

Sipariş vermeden önce CSR’ı kontrol edin

Talepteki bir yazım hatası, CA’nın kullanamayacağınız bir sertifika vermesi anlamına gelir ve bunu düzeltmek başka bir doğrulama turu maliyetine yol açar. Göndermeden önce talebi tekrar okuyun:

openssl req -noout -text -verify -in ftp.yourdomain.com.csr

Çıktıda üç şeyi kontrol edin: Subject satırının girmek istediğiniz ayrıntıları taşıdığını, Subject Alternative Name bölümünün istemcilerin kullanacağı her ana bilgisayar adını listelediğini ve imza kontrolünün geçtiğini. OpenSSL 3.x sonuncusunu Certificate request self-signature verify OK olarak bildirirken, macOS’taki LibreSSL derlemesi bunu verify OK olarak kısaltır. İkisi de aynı anlama gelir. Komut satırında çalışmayı tercih etmiyorsanız, talebi bunun yerine CSR Çözücümüze yapıştırın.

Diskteki anahtarın, özellikle birkaç tane oluşturduysanız, gerçekten bu talebin oluşturulduğu anahtar olduğunu doğrulamak da faydalıdır. Genel anahtarları karşılaştırmak, her anahtar türünde ve hem OpenSSL hem de LibreSSL üzerinde çalışır:

openssl req -noout -pubkey -in ftp.yourdomain.com.csr
openssl pkey -pubout -in ftp.yourdomain.com.key

İki blok, karakteri karakterine aynı olmalıdır. Bu, yalnızca RSA anahtarları için çalışan ve sağlıklı bir eliptik eğri çiftini uyuşmazlık olarak bildiren daha tanıdık modulus-ve-md5 karşılaştırmasının taşınabilir versiyonudur.

Son olarak, .csr dosyasını Notepad veya TextEdit gibi düz bir metin düzenleyicide açın ve ilk ve son satırlar dahil tüm bloğu kopyalayın:

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWEx
... (many lines of base64) ...
-----END CERTIFICATE REQUEST-----

Her işaretleyici satır tam olarak beş kısa çizgi, kelimeler, ardından beş kısa çizgi daha içerir. Bunları elle yeniden yazmayın ve bir kelime işlemci üzerinden yapıştırmayın; bu, kısa çizgi dizilerini tirelere dönüştürebilir ve CA’nın hatalı biçimlendirilmiş olarak reddedeceği bir talep üretebilir.

CSR’a hiç ihtiyaç duymadığınız durumlar

1.0 sürümünden bu yana, FileZilla Server, sizin oluşturmanız gereken bir talep veya içe aktarılacak dosya olmadan, ücretsiz bir Let’s Encrypt sertifikasını kendi başına alabilir ve yenileyebilir. Aynı ayarlar iletişim kutusunda, ağaçtaki Logging‘in altında üst düzey bir Let’s Encrypt® sayfası bulunur. Enable Let’s Encrypt® certificate generation kutusunu işaretleyin, Create new account‘a tıklayın ve hizmet şartlarını kabul edin, ardından How to perform the challenges altında, FileZilla Server’ın bunları kendi dahili web sunucusuyla (varsayılan olarak 80 numaralı portu önerir) mi yanıtlaması gerektiğini yoksa /.well-known/acme-challenge/ altındaki talepleri yanıtlamak için mevcut bir web sunucusunun kullandığı klasörü mü işaret edeceğinizi seçin. Bundan sonra, Connection Security sekmesinde Use a Let’s Encrypt® certificate seçeneğini seçin ve Automatically try to renew the certificate in due time seçeneğini işaretli bırakın.

Bunun sizin için gerçekçi olup olmadığını iki sınırlama belirler. Sunucu yalnızca HTTP doğrulama zorluklarını yanıtlar, dolayısıyla ana bilgisayar adının, sertifika verilirken ve her yenilendiğinde challenge portundan internetten erişilebilir olması gerekir. Ve Let’s Encrypt’ten alınan wildcard sertifikalar, FileZilla Server’ın gerçekleştirmediği DNS tabanlı doğrulama gerektirdiğinden, bu şekilde bir wildcard alamazsınız.

Dolayısıyla, bir wildcard, bir Organization Validation veya Extended Validation sertifikasına, ya da internete açık olmayan bir sunucu için bir sertifikaya ihtiyacınız varsa, yukarıdaki CSR yolu hâlâ izlenmesi gereken yoldur. ACME eğitimlerimiz, otomatik verme konusunu daha derinlemesine ele alıyor. Geriye kalan seçenek, Use a self-signed X.509 certificate altındaki Generate new düğmesi, yalnızca test içindir: FTPS’i saniyeler içinde çalıştırır, ancak her istemcinin, kullanıcıların hızla tıklayıp geçmeyi öğrendiği bir uyarı göstermesine neden olur.

Sıkça Sorulan Sorular