Bir CSR (Certificate Signing Request), bir sertifika otoritesinden TLS sertifikası istemek için hazırlanır. CSR; açık anahtarı, talep bilgilerini ve özel anahtarla oluşturulan imzayı içerir. Özel anahtar CSR’nin içinde bulunmaz ve sertifika otoritesine gönderilmez. Tarayıcının alan adı denetiminde sertifikanın Subject Alternative Name (SAN) alanı kullanılır; yalnız Common Name (CN) yazmak yeterli değildir.
Kapsam ve hazırlık
Bu rehber OpenSSL 3.x ile alan adı için CSR üretimini ve cPanel kullanırken aynı bilgilerin nasıl ele alınacağını açıklar. Örnekler Linux terminali içindir. example.com ve www.example.com yerine kontrol ettiğiniz alan adlarını yazın. Kök alan adı, www ve diğer alt alan adlarını ayrı değerlendirin; *.example.com tek başına example.com adını kapsamaz.
Başlamadan önce sertifika sağlayıcınızın istediği alan adlarını, anahtar türünü ve doğrulama yöntemini belirleyin. DV, OV ve EV sertifikalarının kurumsal bilgi gereksinimleri aynı değildir. Gerçek şirket bilgilerini yalnız sağlayıcınız istediğinde kullanın. Alan adını doğrulayabilecek DNS veya web erişimine sahip olun.
CSR hazırlamak mevcut web sunucusu yapılandırmasını değiştirmez. Mevcut sertifikayı yeniliyorsanız eski anahtar ve sertifika dosyalarının üzerine yazmayın; erişimi sınırlı ayrı bir çalışma dizini kullanın.
Görselin metin açıklaması
- Özel anahtarı yerel ortamda koruyun; CSR ile birlikte göndermeyin.
- CSR’ye açık anahtarı ve gereken DNS SAN adlarını ekleyin, talebi yerel anahtarla imzalayın.
- CSR’yi sertifika otoritesine gönderin; CA kendi politikasına göre alan adını doğrular.
- Düzenlenen sertifikanın SAN adlarını ve özel anahtarla eşleşmesini kontrol edin.
OpenSSL ile anahtar ve SAN içeren CSR üretin
OpenSSL sürümünü denetleyin ve yalnız size açık bir dizin oluşturun:
openssl version
install -d -m 700 "$HOME/tls-example"
cd "$HOME/tls-example"
umask 077Aşağıdaki komut yeni bir RSA 3072 bit anahtar ve iki DNS adı içeren bir CSR üretir. Aynı dosya adları varsa önce durun; mevcut anahtarı yanlışlıkla değiştirmeyin.
openssl req -new -newkey rsa:3072 -sha256 -noenc \
-keyout example.com.key \
-out example.com.csr \
-subj "/CN=example.com" \
-addext "subjectAltName=DNS:example.com,DNS:www.example.com"
chmod 600 example.com.key-noenc, özel anahtar dosyasını parola ile şifrelemez. Bu tercih, hizmetin etkileşimsiz başlamasını kolaylaştırır; dosya izinleri, sunucu erişimi ve güvenli yedek bu nedenle önemlidir. Kurum politikanız şifreli anahtar gerektiriyorsa -noenc seçeneğini kaldırın ve TLS hizmetinizin parolalı anahtar yükleme yöntemini ayrıca planlayın. Parolayı komut satırına veya makale örneklerine yazmayın.
CSR’yi göndermeden önce doğrulayın
İmzayı, talep edilen SAN adlarını ve dosya izinlerini kontrol edin:
openssl req -in example.com.csr -noout -verify -text
openssl pkey -in example.com.key -check -noout
stat -c '%a %n' example.com.keyCSR çıktısında imza denetimi başarılı olmalı; X509v3 Subject Alternative Name altında yalnız istediğiniz DNS adları görünmelidir. Anahtar dosyasının izin değeri 600 olmalıdır. İzinler dosya sahibine okuma/yazma sağlar; dosyayı web köküne, herkese açık depoya veya destek mesajına koymayın.
CSR ile özel anahtarın aynı anahtar çiftine ait olduğunu, özel anahtarı göstermeden açık anahtar özetlerini karşılaştırarak denetleyebilirsiniz:
openssl req -in example.com.csr -pubkey -noout \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256
openssl pkey -in example.com.key -pubout -outform DER \
| openssl dgst -sha256İki özet aynı olmalıdır. Birbirinden farklıysa doğru anahtarla CSR’yi yeniden üretin; dosya adının benzer olması eşleşme kanıtı değildir.
cPanel kullanıyorsanız
Hesabınızdaki SSL/TLS → Certificate Signing Requests (CSR) bölümünü açın. Kullanılacak alan adlarını ve sağlayıcının istediği bilgileri girin. Panel sürümü veya yetkiler nedeniyle ekran farklı olabilir. SAN alanı görünmüyorsa CN’nin tüm adları kapsadığını varsaymayın; sağlayıcının çok alan adlı CSR yönergesini kullanın veya yukarıdaki OpenSSL yoluyla CSR hazırlayın.
Panelde üretilen anahtar, terminalde üretilen anahtardan farklıdır. Bir yöntemdeki CSR’yi diğer yöntemin anahtarıyla eşleştirmeyin. Terminalde ürettiğiniz sertifikayı cPanel’e kurarken karşılık gelen özel anahtarın güvenli biçimde aynı hesaba yüklenmesi gerekir. Başka bir müşterinin veya uygulamanın anahtarını yeniden kullanmayın.
Sertifika otoritesine gönderim ve kurulum öncesi denetim
Sağlayıcıya yalnız CSR içeriğini iletin. DNS, HTTP veya sağlayıcının izin verdiği diğer yöntemle alan adı kontrolünü tamamlayın. Sağlayıcının sertifikayı düzenlemesi, CSR’deki her alanı aynen kabul ettiği anlamına gelmez; dönen sertifikayı inceleyin.
Sağlayıcıdan aldığınız PEM biçimindeki yaprak sertifikayı server.crt adıyla çalışma dizinine kaydettiğinizi varsayalım:
openssl x509 -in server.crt -noout -issuer -dates -ext subjectAltName
openssl x509 -in server.crt -noout -checkhost example.com
openssl x509 -in server.crt -noout -checkhost www.example.com
openssl x509 -in server.crt -pubkey -noout \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256Son özet özel anahtarın açık anahtar özetiyle aynı olmalıdır. Ayrıca sertifika zincirini, geçerlilik süresini ve web sunucusunun yüklediği dosyaları doğrulayın. -checkhost yalnız ad eşleşmesini sınar; zincirin güvenilirliğini veya sitenin gerçekten bu sertifikayı sunduğunu kanıtlamaz. Kurulumdan sonra gerçek HTTPS adresini tarayıcı ve TLS istemcisiyle kontrol edin.
Sorunlar ve güvenli geri dönüş
- SAN eksik veya yanlış: Doğru DNS adlarıyla yeni CSR üretin; sağlayıcınızdan yeniden düzenleme isteyin. Yalnız CN’yi değiştirmek yeterli değildir.
- Anahtar eşleşmiyor: Sertifika, CSR ve özel anahtarın hangi işlemde üretildiğini karşılaştırın. Eşleşen çift bulunmadan hizmet yapılandırmasını değiştirmeyin.
- Özel anahtar kayboldu: CSR’den veya sertifikadan özel anahtar geri çıkarılamaz. Yeni anahtar ve CSR üretip sertifikayı yeniden düzenletin.
- Özel anahtar açığa çıktı: Eski anahtara dönmeyin. Yeni anahtar üretin, sertifikayı yeniden düzenletin ve sağlayıcının iptal sürecini izleyin.
- Kurulum sonrası hizmet çalışmıyor: Eski anahtar hâlâ güvenliyse ve sertifika geçerliyse önceki doğrulanmış yapılandırmaya dönün. Yapılandırma testini geçmeden üretim hizmetini yeniden başlatmayın.
Kaynaklar
- RFC 2986 — CSR içeriği ve imza yapısı
- RFC 9525 — TLS hizmet kimliği ve SAN doğrulaması
- OpenSSL 3.5 — req: CSR üretme, SAN ekleme ve doğrulama
- cPanel — SSL/TLS, CSR ve özel anahtar yönetimi
Teknik içerik ve kaynaklar 4 Ekim 2026 tarihinde gözden geçirildi. Sürüm veya sağlayıcı değişikliğinde ilgili resmî belgeyi yeniden kontrol edin.
Bir yanıt yazın