CSR (Sertifika İmzalama İsteği) Nasıl Oluşturulur?

Ücretli bir SSL sertifikası almaya karar verdiğinizde sertifika otoritesi (CA) sizden ilk olarak bir CSR ister. CSR, açılımıyla Certificate Signing Request yani "sertifika imzalama isteği", alan adınızın kimlik bilgilerini ve bir genel anahtarı (public key) taşıyan, CA'ya gönderilmek üzere hazırlanmış şifreli bir metin bloğudur. CA bu isteği kendi kök sertifikasıyla imzalar ve size tarayıcıların güvendiği geçerli bir sertifika döndürür. Kısacası CSR, sertifikanızın resmi başvuru formudur; içindeki her satır CA'nın vereceği sertifikanın nasıl görüneceğini belirler.

Bu rehberde CSR'ı komut satırından, yani openssl ile üreteceğiz. Panel tabanlı üretim (cPanel gibi) pratik olsa da; kendi sunucusunu (VPS, VDS, dedicated) yöneten, birden fazla alan adını tek sertifikada toplamak isteyen ya da üretim sürecini otomatikleştirmek isteyen herkes için OpenSSL yolunu bilmek şarttır. CSR'ın içindeki CN, O ve SAN gibi alanları tek tek açıklayacak, openssl req -new komutunu adım adım çalıştıracak, ürettiğiniz özel anahtarı (private key) nasıl koruyacağınızı ve CA panelinde CSR'ı yapıştırırken nelere dikkat edeceğinizi kıdemli bir sistem yöneticisinin gözünden anlatacağız. Amaç, süreci bir kez doğru kurup CA reddi, yanlış alan adı ya da kayıp anahtar gibi baş ağrılarını en baştan elemeniz.

CSR Nedir ve İçinde Hangi Bilgiler Bulunur?#

Bir CSR üretildiğinde arka planda her zaman iki şey oluşur: bir özel anahtar (private key) ve o anahtarın genel eşini taşıyan CSR. Özel anahtar sunucuda kalır, asla dışarı çıkmaz; CSR ise içindeki genel anahtarı ve kimlik bilgilerinizi taşıyan, açık metin olarak paylaşılabilen kısımdır. Bu ikisi matematiksel bir çifttir: CA sertifikayı CSR'daki genel anahtara göre imzalar, sertifika ise yalnızca o CSR'ı üreten özel anahtarla eşleşir. Anahtarı kaybederseniz sertifika işe yaramaz hale gelir. Bu güven zincirinin tarayıcıda neden yeşil kilit olarak göründüğünü daha temelden anlamak isterseniz SSL sertifikası nedir yazımız iyi bir başlangıç noktasıdır.

CSR'ın içeriği, X.509 standardındaki "Subject" (özne) alanlarından oluşur. Her alanın kısa bir kodu ve bir anlamı vardır. En önemlileri şunlardır:

Bu alanların en kritiği CN ve SAN'dır. CN, sertifikanın asıl adıdır; tarayıcı adres çubuğundaki host ile CN (ya da SAN'daki adlardan biri) eşleşmezse "bu bağlantı güvenli değil" uyarısı çıkar. Modern tarayıcılar aslında artık CN'e değil SAN listesine bakar; bu yüzden bugün üretilen her CSR'da alan adının SAN içinde de bulunması gerekir. O (Organization) alanı DV (Domain Validation) sertifikalarında serbestken, OV ve EV sertifikalarında ticaret sicilindeki yasal unvanla birebir aynı olmak zorundadır. Wildcard bir sertifika üretiyorsanız CN alanına *.orneksiteniz.com biçiminde yıldızlı bir değer yazılır; ayrıntılar için wildcard SSL nedir yazımıza göz atabilirsiniz.

OpenSSL Kurulumu ve Ön Hazırlık#

OpenSSL, Linux dağıtımlarının neredeyse tamamında hazır gelir; gelmediyse tek komutla kurulur. Sürümünüzü doğrulayarak başlayın:

# Sürümü kontrol edin
openssl version
# OpenSSL 3.0.13 30 Jan 2024

# Kurulu değilse (Debian/Ubuntu)
sudo apt update && sudo apt install -y openssl

# AlmaLinux / Rocky / RHEL
sudo dnf install -y openssl

CSR ve anahtarı, web kök dizininin (public_html, /var/www) dışında, yalnızca sizin erişebileceğiniz bir klasörde üretmek en doğrusudur. Sertifika dosyaları için ayrı bir çalışma dizini açalım ve izinlerini sıkılaştıralım:

# Sertifika çalışma dizini oluştur
sudo mkdir -p /etc/ssl/orneksiteniz
sudo chmod 700 /etc/ssl/orneksiteniz
cd /etc/ssl/orneksiteniz

Bu hazırlık önemsiz görünse de, özel anahtarın en başından itibaren korunaklı bir yerde üretilmesi ileride yapılacak "anahtar sızdı mı" tartışmalarını tamamen ortadan kaldırır. Dizin izinlerini 700 (yalnızca sahibi okuyup yazabilir) yapmak, aynı sunucudaki başka bir kullanıcının anahtar dosyanıza dokunmasını engeller.

openssl req ile Adım Adım CSR Üretimi#

En temel yol, özel anahtarı ve CSR'ı tek komutta birlikte üretmektir. openssl req -new komutu, -newkey parametresiyle yeni bir RSA anahtarı da oluşturur:

# Özel anahtar + CSR'ı tek komutta üret (interaktif sorular sorar)
openssl req -new -newkey rsa:2048 -nodes \
  -keyout orneksiteniz.key \
  -out orneksiteniz.csr

Komuttaki parçaları açalım: rsa:2048 anahtar tipini ve boyutunu belirtir (2048 bit bugün için standart ve güvenlidir), -nodes (no DES) anahtarı parolasız üretir, -keyout özel anahtarın yazılacağı dosyayı, -out ise CSR dosyasını belirtir. -nodes kullanmamızın sebebi, parolalı anahtarların web sunucusunu her yeniden başlatmada parola sorması ve otomatik açılışları kilitlemesidir; sunucuda tutulacak bir web sertifikası için parolasız anahtar doğru tercihtir.

Komutu çalıştırınca OpenSSL size interaktif olarak Subject alanlarını sorar. Yanıtları şöyle doldurun:

Country Name (2 letter code) [XX]:TR
State or Province Name (full name) []:Istanbul
Locality Name (eg, city) []:Istanbul
Organization Name (eg, company) []:Acme Bilisim A.S.
Organizational Unit Name (eg, section) []:Bilgi Islem
Common Name (e.g. server FQDN) []:www.orneksiteniz.com
Email Address []:[email protected]

Please enter the following 'extra' attributes
A challenge password []:            <-- boş bırakın
An optional company name []:        <-- boş bırakın

Burada dikkat edilecek birkaç nokta var. Country her zaman iki harfli koddur (Türkiye için TR); "Turkey" ya da "TUR" yazarsanız komut hata verir. State ve Locality alanlarında kısaltma kullanmayın; "Ist." değil "Istanbul" yazın. Organization alanına Türkçe karakter içeren resmi unvanlar için ASCII karşılığını tercih edin ("A.Ş." yerine "A.S."), çünkü bazı CA'lar özel karakterleri reddeder. A challenge password alanını mutlaka boş geçin; bu, anahtar parolası değil eski ve gereksiz bir SPKAC alanıdır, dolu bırakmak bazı CA panellerinde soruna yol açar.

Soruları elle yanıtlamak yerine tek satırda geçmek isterseniz -subj parametresini kullanabilirsiniz; bu, betiklerle otomasyon için idealdir:

# Interaktif soru sormadan, tüm alanları tek satırda geç
openssl req -new -newkey rsa:2048 -nodes \
  -keyout orneksiteniz.key \
  -out orneksiteniz.csr \
  -subj "/C=TR/ST=Istanbul/L=Istanbul/O=Acme Bilisim A.S./OU=Bilgi Islem/CN=www.orneksiteniz.com"

Komut bittiğinde dizinde iki dosya oluşur: gizli tutulacak orneksiteniz.key ve CA'ya gönderilecek orneksiteniz.csr. Anahtar dosyasının izinlerini hemen kısıtlayın:

chmod 600 orneksiteniz.key
ls -l
# -rw------- 1 root root 1704 orneksiteniz.key
# -rw-r--r-- 1 root root  976 orneksiteniz.csr

SAN ile Birden Fazla Alan Adını Tek CSR'da Toplamak#

Yukarıdaki temel komut tek bir CN üretir, ama modern tarayıcılar CN'e değil SAN (Subject Alternative Name) listesine bakar. Yani www.orneksiteniz.com ve orneksiteniz.com sürümlerinin ikisini de kapsamak, ya da mail, api gibi alt alanları eklemek istiyorsanız SAN alanını doldurmanız gerekir. -subj ile SAN eklenemez; bunun için küçük bir yapılandırma dosyası kullanmak en temiz yöntemdir.

Önce san.cnf adında bir dosya oluşturun:

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
C  = TR
ST = Istanbul
L  = Istanbul
O  = Acme Bilisim A.S.
OU = Bilgi Islem
CN = www.orneksiteniz.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = orneksiteniz.com
DNS.2 = www.orneksiteniz.com
DNS.3 = api.orneksiteniz.com
DNS.4 = mail.orneksiteniz.com

Ardından CSR'ı bu dosyayı referans göstererek üretin:

# SAN'lı CSR üret
openssl req -new -newkey rsa:2048 -nodes \
  -keyout orneksiteniz.key \
  -out orneksiteniz.csr \
  -config san.cnf

Bir wildcard sertifika istiyorsanız alt_names bölümüne DNS.1 = *.orneksiteniz.com ve DNS.2 = orneksiteniz.com yazmanız yeterlidir; yıldız yalnızca tek seviyeli alt alanları (blog.orneksiteniz.com) kapsar, panel.blog.orneksiteniz.com gibi iki seviyeliyi kapsamaz. Onlarca farklı alan adını tek sertifikada toplamak istiyorsanız buna çoklu-domain (multi-domain / UCC) sertifika denir ve SAN listesine hepsini DNS.N olarak eklersiniz. Bu senaryoların hangisinin size uygun olduğuna karar veremiyorsanız wildcard SSL nedir yazımızdaki karşılaştırma tablosu yol gösterir.

CSR'ı Doğrulama ve Anahtarla Eşleştirme#

CSR'ı CA'ya göndermeden önce içeriğini bizzat okuyup doğrulamak, hatalı bir sertifika almanın önüne geçer. İçindeki tüm alanları görmek için:

# CSR'ın tüm içeriğini oku
openssl req -in orneksiteniz.csr -noout -text

Bu komutun çıktısında Subject satırını, genel anahtar boyutunu ve varsa SAN listesini görürsünüz. Özellikle SAN'ların doğru yazıldığını kontrol edin:

# Yalnızca Subject satırını gör
openssl req -in orneksiteniz.csr -noout -subject
# subject=C = TR, ST = Istanbul, L = Istanbul, O = Acme Bilisim A.S., CN = www.orneksiteniz.com

# Yalnızca SAN girdilerini süz
openssl req -in orneksiteniz.csr -noout -text | grep -A1 "Subject Alternative Name"

En sık atlanan kontrol, özel anahtarın CSR ile gerçekten eşleşip eşleşmediğidir. İkisinin modulus özetini karşılaştırın; çıktı birebir aynı olmalıdır:

# Bu iki satırın çıktısı BİREBİR AYNI olmalı
openssl req -in orneksiteniz.csr -noout -modulus | openssl sha256
openssl rsa -in orneksiteniz.key -noout -modulus | openssl sha256

Özetler farklıysa CSR ve anahtar farklı çiftlerdendir; bu durumda CA'dan geleceğin sertifikası da anahtarınızla eşleşmeyecek ve kurulumda "certificate and key do not match" hatası alacaksınız. Bu iki komutu üretim betiğinizin sonuna eklemek, yıllar içinde onlarca kez karşılaşacağınız bir hatayı tek başına eler.

CSR'ı Sertifika Otoritesine Gönderme#

CSR doğrulandıktan sonra sıra onu CA'ya yapıştırmaya gelir. orneksiteniz.csr dosyasını bir metin editöründe açın ya da terminale bastırın:

cat orneksiteniz.csr

Çıktı -----BEGIN CERTIFICATE REQUEST----- ile başlayıp -----END CERTIFICATE REQUEST----- ile biten bir bloktur:

-----BEGIN CERTIFICATE REQUEST-----
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVFIxDzANBgNVBAgMBklzdGFuYnVsMRIw
EAYDVQQHDAlLYWRpa295MRUwEwYDVQQKDAxBY21lIEEuUy4gVFIxHDAaBgNVBAMM
E3d3dy5vcm5la3NpdGVuaXouY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
...
-----END CERTIFICATE REQUEST-----

Bu bloğun tamamını, BEGIN ve END satırları dahil, CA'nın sipariş ekranındaki metin kutusuna yapıştırın. Sınır satırlarını silerseniz istek geçersiz sayılır. CA, CSR'ı ayrıştırıp içindeki alan adını, kurumu ve ülkeyi ekranda gösterir; bilgilerin doğru okunduğunu bu adımda son kez kontrol edin. CA bu noktada alan adı sahipliğini de doğrulamak ister. En yaygın üç yöntem şunlardır:

; DNS doğrulama — CA'nın verdiği TXT kaydını alan adınıza ekleyin
_acme-challenge.orneksiteniz.com.  IN  TXT  "rastgele-dogrulama-degeri"

• DNS doğrulama — CA'nın verdiği bir TXT kaydını alan adınızın DNS bölgesine eklersiniz.
• HTTP dosya doğrulama — verilen dosyayı http://orneksiteniz.com/.well-known/pki-validation/ altına yüklersiniz.
• E-posta doğrulama — [email protected] gibi yönetimsel bir adrese gelen bağlantıya tıklarsınız.

Doğrulama tamamlanınca CA size sertifikayı (genelde bir .crt dosyası) ve ara sertifikaları (.ca-bundle / chain) verir. Bunları sunucuda daha önce ürettiğiniz orneksiteniz.key ile birlikte web sunucunuza tanıtırsınız. Nginx için tipik kurulum şöyledir:

server {
    listen 443 ssl;
    server_name orneksiteniz.com www.orneksiteniz.com;

    # CA'nın verdiği sertifika + ara sertifikaları tek dosyada birleştirin
    ssl_certificate     /etc/ssl/orneksiteniz/fullchain.crt;
    # Bizim ürettiğimiz özel anahtar — sunucuda kalır
    ssl_certificate_key /etc/ssl/orneksiteniz/orneksiteniz.key;

    ssl_protocols       TLSv1.2 TLSv1.3;
}

Private Key'i Asla Göndermeyin#

Bu rehberdeki en önemli kural budur ve altını kalın çizgiyle çizmek gerekir: CA'ya yalnızca CSR gönderilir, özel anahtar asla gönderilmez. Özel anahtar, sertifikanızın kimliğini kanıtlayan tek unsurdur. Onu ele geçiren biri sitenizin şifreli trafiğini çözebilir, sizin adınıza güvenilir bir sunucu taklit edebilir. CA'nın da özel anahtara ihtiyacı yoktur; imzalama için CSR'ın içindeki genel anahtar zaten yeterlidir. Sipariş ekranında yanlışlıkla anahtarı yapıştırmayın, e-postayla göndermeyin, canlı destekte kimseye vermeyin.

Aynı disiplin sunucu üzerinde de geçerlidir. Özel anahtar dosyası web'den erişilemeyen bir dizinde durmalı ve izinleri yalnızca sahibine okuma verecek biçimde (chmod 600) kısıtlanmalıdır. Anahtarı bir sürüm kontrol deposuna (git) commit etmek, ortak bir ağ klasörüne koymak ya da yedeği şifrelenmemiş bir buluta atmak, en sık görülen ve en pahalıya patlayan hatalardır:

# Doğru: anahtar web kökünün dışında, sadece sahibine okunabilir
ls -l /etc/ssl/orneksiteniz/orneksiteniz.key
# -rw------- 1 root root 1704 orneksiteniz.key

# YANLIŞ: anahtarı public_html içine koymak — herkes indirebilir
# /home/kullanici/public_html/orneksiteniz.key   <-- ASLA

Anahtarı yalnızca sertifikayı başka bir sunucuya taşırken kopyalamanız meşrudur; o durumda bile SCP/SFTP gibi şifreli bir kanal kullanın, düz metin aktarımdan kaçının. Sunucular arası güvenli taşıma için site taşıma hizmetimiz bu aktarımı sizin yerinize güvenli biçimde üstlenir. Anahtarın herhangi bir şekilde sızdığından şüpheleniyorsanız doğru davranış paniklemek değil, sertifikayı iptal edip (revoke) yeni bir anahtar ve CSR ile yeniden düzenlemektir; sızmış bir anahtarı bir daha güvenli saymanın hiçbir yolu yoktur. Anahtarların şifreli ve düzenli yedeklenmesi için yedekleme çözümümüz anahtar dosyalarını da güvenli biçimde kapsar.

Sıkça Sorulan Sorular#

CSR oluştururken özel anahtarı ayrıca üretmem gerekir mi?#

Hayır, openssl req -new -newkey rsa:2048 -nodes komutu özel anahtarı ve CSR'ı aynı anda üretir; -keyout ile belirttiğiniz dosyaya anahtar, -out ile belirttiğiniz dosyaya CSR yazılır. Ayrı bir adıma gerek yoktur. Elinizde önceden üretilmiş bir anahtar varsa -newkey yerine -key mevcut.key yazarak o anahtarla yeni bir CSR da üretebilirsiniz. Hangi yolu seçerseniz seçin, özel anahtarı ürettikten sonra kaybetmemeye ve dışarı sızdırmamaya özen gösterin, çünkü sertifika yalnızca bu anahtarla eşleşir.

CN ile SAN arasındaki fark nedir, ikisini de yazmam şart mı?#

CN (Common Name) sertifikanın klasik "asıl adı", SAN (Subject Alternative Name) ise sertifikanın kapsadığı tüm alan adlarının listesidir. Modern tarayıcılar artık yalnızca SAN listesine bakar ve CN'i büyük ölçüde yok sayar; bu yüzden alan adınız SAN içinde mutlaka bulunmalıdır, aksi halde tek başına CN geçerli sayılmaz. Pratikte CN'e sitenizin asıl sürümünü yazar, SAN listesine ise hem www hem wwwsuz sürümü ve varsa diğer alt alanları eklersiniz. Bunun için -subj yeterli olmaz; SAN'lı bir CSR için yapılandırma dosyası (san.cnf) kullanmanız gerekir.

-nodes parametresi ne işe yarar, kullanmalı mıyım?#

-nodes (no DES), özel anahtarı parolasız üretir. Bir web sunucusunda tutulacak sertifika için bu neredeyse her zaman doğru tercihtir, çünkü parolalı anahtar sunucuyu her yeniden başlatmada parola sorar ve otomatik açılışları, panel tabanlı kurulumları kilitler. Parametreyi atlarsanız OpenSSL sizden bir "PEM pass phrase" ister ve anahtarı şifreler; bu ancak anahtar dosyasını başka bir yerde arşivleyecekseniz ek koruma olarak anlamlıdır. Sunucuda çalışacak bir sertifika üretiyorsanız -nodes kullanın.

CSR'ı yanlış bilgiyle oluşturursam ne yapmalıyım?#

Sertifikayı henüz satın almadıysanız çözüm çok basittir; komutu doğru bilgilerle yeniden çalıştırıp yeni bir CSR üretmeniz yeterlidir, eskisi hiçbir zarar vermez. Sertifikayı zaten satın aldıysanız CA'nın panelinden yeniden düzenleme (reissue) talep eder ve düzelttiğiniz yeni CSR'ı gönderirsiniz; bu işlem çoğu CA'da ücretsizdir. Hatalı bir CN ya da eksik SAN ile kurulmuş sertifikayı olduğu gibi bırakmayın, çünkü alan adı uyuşmazlığı ziyaretçilerinizde tarayıcı güvenlik uyarısına yol açar.

CA'ya CSR ile birlikte özel anahtarı da göndermem gerekir mi?#

Kesinlikle hayır. CA'ya yalnızca CSR gönderilir; özel anahtar sunucunuzda kalır ve hiçbir koşulda dışarı çıkmaz. CA'nın sertifikayı imzalamak için özel anahtara ihtiyacı yoktur, çünkü CSR'ın içinde imza için gereken genel anahtar zaten bulunur. Sizden özel anahtarı isteyen bir "CA" ya da hizmet varsa bu ciddi bir güvenlik alarmıdır; asla vermeyin. Anahtarı yalnızca kendi sunucularınız arasında, o da şifreli bir kanalla taşırsınız.

Let's Encrypt kullanırken de elle CSR üretmem gerekir mi?#

Hayır, Let's Encrypt gibi ücretsiz ve otomatik sertifikalarda CSR ile anahtarı istemci yazılım (certbot, acme.sh, cPanel AutoSSL) sizin adınıza otomatik üretir; elle bir şey doldurmanıza gerek kalmaz. Elle CSR üretme adımı esas olarak ücretli OV, EV ve wildcard sertifikaları satın alırken gereklidir, çünkü CA imzalama isteğini bizzat sizden ister. Basit siteler için otomatik yol yeterliyken, kurumsal doğrulama ya da özel anahtarı kendi kontrolünüzde tutma ihtiyacınız varsa OpenSSL ile üretim size tam kontrol sağlar.

Kapanış#

CSR üretimi ilk bakışta teknik görünse de, OpenSSL ile aslında birkaç dakikalık bir işlemdir. Aklınızda tutmanız gereken üç temel kural şudur: alan adınızı hem CN'e hem SAN listesine doğru yazın, anahtarı parolasız (-nodes) ve 2048 bit üretin, ve özel anahtarı hiçbir koşulda CA'ya ya da üçüncü bir tarafa göndermeyin. Bu üç noktaya dikkat ederseniz CA reddi, eşleşmeyen anahtar ya da tarayıcı güvenlik uyarısı gibi sorunları en baştan elemiş olursunuz. Üretilen CSR'ı göndermeden önce openssl req -in ... -noout -text ile bir kez okumayı ve modulus özetlerini karşılaştırmayı alışkanlık haline getirin.

Clou.TR olarak SSL sürecinin her adımında yanınızdayız. Kendi sunucusunu yöneten ekipler için VDS ve sanal sunucu paketlerimizde OpenSSL hazır gelir; ücretli, kurumsal doğrulamalı ya da wildcard sertifika ihtiyaçlarınız içinse SSL çözümlerimizi inceleyebilirsiniz. cPanel'li web hosting paketlerimizde AutoSSL basit siteler için otomatik çalışır; CSR üretiminden kuruluma ve yenilemeye kadar tüm döngüyü bize devretmek isterseniz sunucu yönetimi hizmetimiz devreye girer. Hangi tür sertifikanın size uygun olduğuna karar veremiyorsanız, doğru çözümü birlikte seçmek için ekibimize her zaman ulaşabilirsiniz.