Kendinden İmzalı (Self-Signed) SSL Sertifikası Oluşturma

Bir web uygulamasını yerel makinenizde ya da iç ağınızda HTTPS üzerinden test etmek istediğinizde ilk karşınıza çıkan engel genellikle sertifikadır. Let's Encrypt ya da ticari bir sertifika otoritesinden alacağınız sertifikalar herkese açık, gerçek bir alan adına ihtiyaç duyar; oysa https://localhost:8443 gibi bir adres ya da DNS'te hiç yayınlanmamış bir iç servis için bunların hiçbiri işe yaramaz. İşte tam bu noktada "kendinden imzalı" yani self-signed sertifikalar devreye girer: kendi özel anahtarınızla kendi kendinize verdiğiniz, hiçbir dış otoriteye başvurmadan saniyeler içinde ürettiğiniz sertifikalardır.

Bu rehberde self-signed bir sertifikanın ne olduğunu, hangi senaryolarda son derece uygun (geliştirme, test, iç servisler) hangilerinde ise kesinlikle uygunsuz (halka açık üretim siteleri) olduğunu netleştireceğiz. Tek bir openssl req komutuyla anahtar ve sertifikayı birlikte üretmeyi, üretilen dosyaları Nginx'e tanımlamayı, tarayıcının neden "güvenli değil" uyarısı verdiğini ve bu uyarıyı yerel güven ekleyerek nasıl susturabileceğinizi adım adım göstereceğiz. Konuya yeni başlıyorsanız önce SSL sertifikası nedir yazımızı okumanız, buradaki kavramları yerine oturtmanıza yardımcı olacaktır.

Self-Signed Sertifika Nedir?#

Normal bir SSL sertifikasında güven zinciri şöyle işler: sizin sertifikanızı bir sertifika otoritesi (CA) imzalar, o CA'nın kök sertifikası da tarayıcıların ve işletim sistemlerinin fabrika ayarında gelen güvenilir kök deposunda (root store) zaten kayıtlıdır. Tarayıcı bu zinciri güvenilir bir köke kadar izleyebildiği için kilidi gösterir. Self-signed sertifikada ise bu zincir yoktur; sertifikayı imzalayan özel anahtar ile sertifikanın içindeki açık anahtar aynı anahtar çiftine aittir. Yani sertifika kendi kendini imzalar, arada bağımsız bir otorite bulunmaz.

Teknik açıdan bakıldığında self-signed sertifika, gerçek bir CA sertifikasıyla tamamen aynı şifrelemeyi sağlar. Trafik yine TLS ile şifrelenir, araya giren biri veriyi okuyamaz, bütünlük korunur. Eksik olan tek şey kimlik doğrulamadır: tarayıcının "bu sertifikayı tanıdığım güvenilir bir otorite mi verdi?" sorusuna verecek bir yanıtı yoktur. Bu yüzden self-signed sertifikalar şifrelemeyi verir ama "karşımdaki sunucunun gerçekten iddia ettiği sunucu olduğunu" bağımsız biçimde kanıtlayamaz. Bu ayrımı akılda tutmak, ilerideki tüm kararların temelini oluşturur.

Ne Zaman Uygun, Ne Zaman Uygunsuz?#

Self-signed sertifikanın yeri, kim tarafından ve nasıl kullanılacağına bağlıdır. Kısaca kural şudur: sertifikaya güvenecek istemcileri siz kontrol ediyorsanız self-signed uygundur; internetteki rastgele ziyaretçiler güvenecekse uygun değildir.

Üretim ortamı için self-signed kullanmanın hiçbir haklı gerekçesi kalmamıştır, çünkü Let's Encrypt ile ücretsiz ve otomatik SSL almak dakikalar sürer ve tarayıcı hiçbir uyarı göstermez. Self-signed'ı yalnızca "istemcinin güven deposuna müdahale edebildiğiniz" kapalı devre senaryolarda düşünün. Halka açık bir sunucuda gerçek bir sertifika istiyorsanız bir VDS sunucu üzerinde Certbot ile ya da yönetilen bir hosting paketinde tek tıkla ilerlemek çok daha doğru bir yaklaşımdır.

Tek Satırda Anahtar ve Sertifika Üretmek#

OpenSSL, self-signed sertifikayı ve ona ait özel anahtarı tek komutta üretebilir. Aşağıdaki satır, 2048 bit'lik bir RSA özel anahtarı ile 365 gün geçerli bir sertifikayı birlikte oluşturur:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout ozel.key -out sertifika.crt \
  -days 365 -subj "/CN=localhost"

Komuttaki bayrakların anlamı şöyledir:

• -x509: Bir CSR (imza talebi) yerine doğrudan self-signed sertifika üret.
• -newkey rsa:2048: Yeni bir 2048 bit RSA anahtar çifti oluştur.
• -nodes: Özel anahtarı parola ile şifreleme (aksi hâlde sunucu her açılışta parola sorar).
• -keyout / -out: Sırasıyla özel anahtar ve sertifika dosyalarının adları.
• -days 365: Geçerlilik süresi (test için istediğiniz kadar uzun tutabilirsiniz).
• -subj "/CN=localhost": İnteraktif soruları atlayıp ortak adı (Common Name) doğrudan belirt.

Modern tarayıcılar artık CN alanına bakmaz; sertifikanın SAN (Subject Alternative Name) alanındaki adı ararlar. Bu yüzden yalnızca CN içeren bir sertifika Chrome'da ERR_CERT_COMMON_NAME_INVALID hatası verebilir. Doğru yol, SAN'ı da eklemektir. OpenSSL 1.1.1 ve sonrasında bunu tek satırda -addext ile yapabilirsiniz:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout ozel.key -out sertifika.crt -days 365 \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,DNS:dev.test,IP:127.0.0.1"

Daha modern ve daha hızlı bir anahtar isterseniz RSA yerine ECDSA (eliptik eğri) kullanabilirsiniz. ECDSA, çok daha kısa anahtar boyuyla aynı güvenliği verir ve el sıkışmayı hafifletir:

# ECDSA (prime256v1) anahtarıyla self-signed sertifika
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
  -nodes -keyout ozel.key -out sertifika.crt -days 365 \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Ürettikten sonra sertifikanın içeriğini doğrulamak için şu komut çıktısına bakın; özellikle Subject Alternative Name satırının beklediğiniz adları içerdiğinden emin olun:

openssl x509 -in sertifika.crt -noout -text | grep -A1 "Subject Alternative Name"

Birden Fazla Ad İçin Yapılandırma Dosyası#

Tek bir SAN yeterli olsa da, birden çok alan adı, alt alan adı ve IP'yi düzenli biçimde yönetmek istediğinizde bir yapılandırma dosyası kullanmak çok daha temizdir. Aşağıdaki gibi bir san.cnf dosyası oluşturun:

[req]
default_bits       = 2048
prompt             = no
distinguished_name = dn
x509_extensions    = v3_ext

[dn]
CN = dev.test

[v3_ext]
subjectAltName   = @alt_names
basicConstraints = CA:FALSE
keyUsage         = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

[alt_names]
DNS.1 = dev.test
DNS.2 = api.dev.test
DNS.3 = localhost
IP.1  = 127.0.0.1
IP.2  = 192.168.1.50

Ardından sertifikayı bu dosyaya dayanarak üretin:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout ozel.key -out sertifika.crt -days 365 \
  -config san.cnf -extensions v3_ext

Bu yaklaşımın avantajı, ihtiyaç duydukça alt_names bölümüne yeni satır ekleyip sertifikayı yeniden üretebilmenizdir. extendedKeyUsage = serverAuth satırı da sertifikanın açıkça sunucu kimlik doğrulaması için olduğunu belirtir; bazı katı istemciler bu uzantıyı arar.

Üretilen Dosyaları Sunucuya Tanımlamak#

Elinizde ozel.key (özel anahtar) ve sertifika.crt (sertifika) olduğuna göre, bunları web sunucunuza tanıtabilirsiniz. Nginx üzerinde tipik bir yapılandırma şöyledir:

server {
    listen 443 ssl;
    server_name dev.test localhost;

    ssl_certificate     /etc/ssl/cloutr/sertifika.crt;
    ssl_certificate_key /etc/ssl/cloutr/ozel.key;
    ssl_protocols       TLSv1.2 TLSv1.3;

    root /var/www/dev;
    index index.html;
}

# HTTP'yi HTTPS'e yönlendir (test için isteğe bağlı)
server {
    listen 80;
    server_name dev.test localhost;
    return 301 https://$host$request_uri;
}

Anahtar dosyasının izinlerini daraltmayı unutmayın; özel anahtar hiçbir zaman herkese okunabilir olmamalıdır:

sudo mkdir -p /etc/ssl/cloutr
sudo cp ozel.key sertifika.crt /etc/ssl/cloutr/
sudo chmod 600 /etc/ssl/cloutr/ozel.key
sudo nginx -t && sudo systemctl reload nginx

Nginx'i sıfırdan kuruyorsanız ya da yapılandırma temellerini tazelemek isterseniz Ubuntu üzerinde Nginx kurulumu rehberimiz adım adım ilerler. Apache tarafında ise aynı iş SSLCertificateFile ve SSLCertificateKeyFile yönergeleriyle yapılır; mantık birebir aynıdır, yalnızca yönerge adları değişir.

Tarayıcı Neden Uyarır?#

Self-signed sertifikayı kurup adrese girdiğinizde tarayıcı büyük olasılıkla tam ekran bir uyarı gösterecektir: Chrome'da NET::ERR_CERT_AUTHORITY_INVALID, Firefox'ta SEC_ERROR_UNKNOWN_ISSUER. Bu bir hata değil, tam olarak beklenen davranıştır. Tarayıcının yaptığı şey basittir: sertifikayı imzalayan otoriteyi kendi güvenilir kök deposunda arar, bulamaz ve "bu sertifikanın arkasında tanıdığım bir otorite yok, kullanıcıyı uyarmalıyım" der.

Burada dikkat edilmesi gereken kritik nokta şudur: bu uyarı, sertifikanın şifrelemesinin zayıf olduğu anlamına gelmez. Bağlantı yine de TLS ile şifrelidir. Uyarının söylediği tek şey, "karşı tarafın kimliğini doğrulayamıyorum" mesajıdır. Yani veriniz yolda okunmaz ama teorik olarak birisi araya girip kendi self-signed sertifikasını sunmuş da olabilir; tarayıcı bunu ayırt edemez, o yüzden ihtiyatlı davranır. İşte tam da bu belirsizlik, self-signed sertifikaları halka açık siteler için uygunsuz kılan şeydir: ziyaretçileriniz her seferinde bu ekranı görür ve büyük çoğunluğu geri döner.

Geliştirme ortamında bu uyarıyı "Gelişmiş → Yine de devam et" diyerek geçebilirsiniz. Ancak uyarıyı her seferinde tıklayarak geçmek hem sinir bozucudur hem de bazı tarayıcı özellikleri (örneğin HSTS zorlaması altındaki bir alan adında) devam etme seçeneğini tamamen kaldırır. Kalıcı çözüm, sertifikayı bilinçli biçimde güvenilir kılmaktır.

Yerel Güven Eklemek#

Uyarıyı ortadan kaldırmanın doğru yolu, self-signed sertifikanızı kendi makinenizin güvenilir kök deposuna eklemektir. Böylece o cihaz "bu sertifikayı ben zaten tanıyorum" der ve kilidi gösterir. Bu işlemi yalnızca kontrol ettiğiniz test makinelerinde yapın; asla rastgele bir kullanıcıdan sertifikanızı güven deposuna eklemesini istemeyin.

Linux (Debian/Ubuntu) tarafında sertifikayı sistem geneli güven deposuna eklemek için:

sudo cp sertifika.crt /usr/local/share/ca-certificates/cloutr-dev.crt
sudo update-ca-certificates

RHEL/AlmaLinux/Rocky ailesinde ise komutlar biraz farklıdır:

sudo cp sertifika.crt /etc/pki/ca-trust/source/anchors/cloutr-dev.crt
sudo update-ca-trust

macOS'ta sertifikayı sisteme güvenilir olarak tanıtmak için:

sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain sertifika.crt

Bu komutlar sertifikayı işletim sisteminin deposuna ekler; curl, wget ve çoğu uygulama bunu okur. Ancak Firefox kendi güven deposunu kullanır, sistem deposunu değil; Firefox'ta sertifikayı Ayarlar → Gizlilik ve Güvenlik → Sertifikalar → Yetkililer bölümünden elle içe aktarmanız gerekir. Chrome ve Edge ise sistem deposunu kullandığı için yukarıdaki komutlardan sonra genellikle yeniden başlatmak yeterlidir.

Birden çok geliştiricinin olduğu ekiplerde her makineye tek tek sertifika dağıtmak yerine kendi mini CA'nızı kurmak çok daha ölçeklenebilir bir yöntemdir; bir sonraki bölümde buna bakalım.

Kendi Sertifika Otoritenizi (CA) Oluşturmak#

Tek bir self-signed sertifika yerine, önce bir kök CA üretip sonra tüm iç sertifikalarınızı bu CA ile imzalamak, iç ağlarda çok daha zarif bir çözümdür. Nedeni şudur: geliştiricilerin cihazlarına yalnızca bir kere kök CA sertifikasını güvenilir olarak eklersiniz; ondan sonra o CA ile imzaladığınız her yeni sertifika, hiçbir ek işlem gerektirmeden otomatik olarak güvenilir sayılır.

Önce kök CA'nızın anahtarını ve sertifikasını oluşturun:

# 1) Kök CA özel anahtarı
openssl genrsa -out cloutrCA.key 4096

# 2) 10 yıllık kök CA sertifikası
openssl req -x509 -new -nodes -key cloutrCA.key \
  -sha256 -days 3650 -out cloutrCA.crt \
  -subj "/CN=Cloutr Dev Root CA"

Sonra, güvenilir kılmak istediğiniz her servis için bir anahtar + CSR üretip bu CSR'ı kök CA ile imzalayın:

# 3) Servis anahtarı ve imza talebi
openssl req -newkey rsa:2048 -nodes \
  -keyout dev.test.key -out dev.test.csr \
  -subj "/CN=dev.test"

# 4) CSR'ı kök CA ile imzala (SAN dosyasıyla)
openssl x509 -req -in dev.test.csr \
  -CA cloutrCA.crt -CAkey cloutrCA.key -CAcreateserial \
  -out dev.test.crt -days 365 -sha256 \
  -extfile san.cnf -extensions v3_ext

Artık geliştiricilerin cihazlarına yalnızca cloutrCA.crt dosyasını güven deposuna eklemeniz yeter (yukarıdaki update-ca-certificates adımı). Bu kökle imzaladığınız dev.test.crt, api.dev.test.crt ve gelecekte üreteceğiniz tüm sertifikalar tarayıcıda otomatik olarak yeşil kilit gösterir. Kök CA'nızın özel anahtarını (cloutrCA.key) çok iyi korumanız gerekir; onu ele geçiren biri, cihazlarınızın güvendiği geçerli sertifikalar üretebilir. Bu yüzden mümkünse çevrimdışı, erişimi kısıtlı bir yerde saklayın. İç ağınızdaki bu tür yapılandırmaları kalıcı ve güvenli tutmak için sunucu yönetimi hizmetimizden de faydalanabilirsiniz.

Self-Signed, Kendi CA'nız ve Let's Encrypt Karşılaştırması#

Üç yaklaşımı yan yana koyduğunuzda hangisinin nereye uyduğu netleşir:

Karar özeti şudur: makinenizde tek seferlik hızlı bir HTTPS testi mi yapacaksınız, tekil self-signed yeter. İç ağınızda birden çok servisi kalıcı olarak güvenilir kılmak mı istiyorsunuz, kendi CA'nızı kurun. Halka açık, gerçek bir alan adında yayına çıkıyorsanız hiç tereddüt etmeyin, Let's Encrypt kullanın. Konuya bütünsel bakmak için SSL sertifikası nedir yazısı ile SSL çözümlerimizi birlikte değerlendirebilirsiniz.

Sıkça Sorulan Sorular#

Self-signed sertifika güvenli mi, verilerim şifreleniyor mu?#

Evet, self-signed sertifika de trafiği gerçek bir sertifika kadar güçlü şekilde şifreler; aradaki fark şifrelemede değil, kimlik doğrulamadadır. Tarayıcının verdiği uyarı "veri şifresiz gidiyor" demek değil, "bu sertifikayı imzalayan otoriteyi tanımıyorum" demektir. Yani veriniz yolda okunmaz, ancak tarayıcı karşı sunucunun kimliğinden bağımsız olarak emin olamaz.

Neden CN yerine SAN kullanmam söyleniyor?#

Modern tarayıcılar sertifikadaki Common Name alanına artık bakmıyor; alan adı eşleşmesini yalnızca Subject Alternative Name alanından yapıyorlar. Bu yüzden sadece CN içeren bir self-signed sertifika Chrome gibi tarayıcılarda ERR_CERT_COMMON_NAME_INVALID hatasıyla reddedilir. Sertifikayı üretirken -addext "subjectAltName=..." bayrağını ya da bir yapılandırma dosyasındaki alt_names bölümünü mutlaka ekleyin.

Uyarıyı kalıcı olarak nasıl kaldırırım?#

Sertifikanızı ya da onu imzalayan kök CA sertifikasını, kullandığınız cihazın güvenilir kök deposuna eklemeniz gerekir. Linux'ta bu update-ca-certificates ya da update-ca-trust, macOS'ta security add-trusted-cert komutuyla yapılır; Firefox ise sistem deposunu kullanmadığı için sertifikayı kendi ayarlarından ayrıca içe aktarmanızı ister. Bu işlemi yalnızca kendi kontrol ettiğiniz test cihazlarında yapın.

Üretim sitemde self-signed sertifika kullanabilir miyim?#

Kullanmamalısınız; halka açık bir sitede self-signed sertifika, her ziyaretçiye tam ekran güvenlik uyarısı gösterir ve ziyaretçilerin çoğu bu ekranı görünce geri döner. Üstelik ücretsiz ve otomatik Let's Encrypt mevcutken buna hiç gerek de yoktur. Gerçek bir alan adınız varsa Certbot ile dakikalar içinde uyarısız bir sertifika alabilir, güveni ve SEO değerini koruyabilirsiniz.

Self-signed sertifikanın süresi dolarsa ne olur?#

Süresi dolan bir self-signed sertifika, gerçek sertifikalar gibi tarayıcıda "sertifikanın süresi doldu" hatası verir ve bağlantı reddedilebilir. Test ortamlarında bunu geciktirmek için -days değerini uzun tutabilir (örneğin 825 gün), süre dolduğunda ise aynı komutla yeni bir sertifika üretip sunucuya tanımlayabilirsiniz. Kendi CA'nızı kullanıyorsanız yalnızca servis sertifikasını yenilemeniz yeter, kökü tekrar dağıtmanıza gerek kalmaz.

curl komutum self-signed sertifikaya takılıyor, nasıl çözerim?#

En temiz çözüm, sertifikayı ya da kök CA'yı sistemin güven deposuna eklemektir; ondan sonra curl hiçbir bayrak gerektirmeden çalışır. Tek seferlik bir test için curl --cacert cloutrCA.crt https://dev.test diyerek sertifikayı elle işaret edebilirsiniz. -k (yani --insecure) bayrağı doğrulamayı tamamen kapatır; yalnızca hızlı denemelerde kullanın, betiklerde ve otomasyonda bu bayrağa güvenmeyin çünkü araya girme saldırılarına kapı açar.

Kapanış#

Self-signed sertifikalar, doğru yerde kullanıldığında son derece güçlü bir araçtır: yerel geliştirmede HTTPS davranışlarını test etmek, iç servisleri şifrelemek ve kendi CA'nızla kapalı bir ağda güven kurmak için biçilmiş kaftandır. Kilit nokta, "güvenecek istemcileri siz kontrol ediyorsanız uygun, internetteki ziyaretçiler güvenecekse uygun değil" ayrımını akılda tutmaktır. Tek satırlık bir openssl req komutuyla anahtarınızı ve sertifikanızı üretir, SAN'ı eklemeyi unutmaz ve gerektiğinde yerel güven ekleyerek uyarıları temizlersiniz.

Halka açık bir projede gerçek, uyarısız bir sertifikaya ihtiyacınız olduğunda ise işi otomatiğe bağlamak en akıllıcası. Kendi sunucunuzu yönetiyorsanız bir VDS sunucu üzerinde Certbot ile ilerleyebilir, uğraşmadan tek tıkla SSL isteyen bir kurulum için yönetilen hosting paketlerimizi tercih edebilir, doğru sertifika tipini seçmek veya kurulumu bize bırakmak için de SSL çözümlerimize göz atabilirsiniz. Test tarafında self-signed, üretim tarafında güvenilir bir CA; bu iki dünyayı yerli yerinde kullandığınızda hem hızlı geliştirir hem de yayında sağlam durursunuz.