Rehberler

Yazan Matt Connor 2026-10-16

Ubuntu 24.04 Self-Signed TLS Sertifikası Oluşturma

Q: Chrome, kendi imzaladığım sertifikayı oluşturmama rağmen neden hala "Güvenli değil" diyor?

Hata NET::ERR_CERT_AUTHORITY_INVALID ise sertifika doğrudur, Chrome'un ona güvenmesi için henüz bir nedeni yoktur. Sertifikayı (veya özel CA kök sertifikanızı) istemcinin güven deposuna yükleyin. Linux üzerinde Chrome'un sistem deposunu değil, certutil aracılığıyla NSS veritabanını (Chrome 146 sürümünden beri ~/.local/share/pki/nssdb konumunda veya varsa eski ~/.pki/nssdb konumunda) kullandığını unutmayın. Hata NET::ERR_CERT_COMMON_NAME_INVALID ise sertifika, URL ile eşleşen bir Subject Alternative Name içermiyordur ve -addext "subjectAltName=..." ile yeniden düzenlenmelidir.

Q: curl'ün -k kullanmadan kendi imzaladığım bir sertifikaya güvenmesini nasıl sağlarım?

Sertifikayı (PEM formatında, .crt uzantılı) /usr/local/share/ca-certificates/ dizinine kopyalayın ve sudo update-ca-certificates komutunu çalıştırın; çıktı 1 added ifadesini içermelidir. Bundan sonra curl, sertifikayı herhangi bir genel sertifika gibi doğrular. Sistemi etkilemeden tek seferlik bir istek için curl --cacert /path/to/cert.crt bayrağı yalnızca o dosya üzerinden doğrulama yapar; -k ise doğrulamayı tamamen devre dışı bırakır ve hiçbir betikte kullanılmamalıdır.

Q: Sertifikayı /usr/local/share/ca-certificates dizinine eklememe rağmen neden reddediliyor?

Üç şeyi kontrol edin. Dosya .crt ile bitmelidir; .pem uzantısı sessizce atlanır ve update-ca-certificates bu durumda 0 added raporlar. İçerik, DER ikili verisi değil, -----BEGIN CERTIFICATE----- ile başlayan PEM metni olmalıdır. Ayrıca uygulamanın sistem deposunu gerçekten kullanıyor olması gerekir; Chrome (Linux üzerinde), Firefox, Python requests, Node.js (--use-system-ca ile başlatılmadığı sürece) ve Java'nın her biri kendi özel güven deposunu tutar ve sertifikanın ayrı ayrı eklenmesini gerektirir.

Ubuntu 24.04 üzerinde Chrome tarafından kabul edilen self-signed TLS sertifikası oluşturun. SAN desteği, nginx yapılandırması ve curl -k kullanmadan sertifikaya güvenme adımları.

Ne inşa ediyorsunuz

Modern tarayıcıların ve istemcilerin gerçekten kabul ettiği, doğru subjectAltName yapılandırılmış, mantıklı anahtar izinlerine sahip ve nginx veya Apache ile entegre edilmiş bir self-signed TLS sertifikası. Ayrıca çoğu rehberin atladığı o kritik nokta: istemcilerin sertifikaya düzgün bir şekilde güvenmesini sağlamak; böylece uyarıları geçmek veya curl -k değerini betiklerin içine kalıcı olarak gömmek zorunda kalmazsınız. Son aşamada, bir iç servis altıya çıktığında kullanabileceğiniz beş komutluk özel bir CA kurulumu yer alıyor.

Öncelikle karar aşaması; çünkü self-signed sertifikalar, kullanıldıkları sıklığa kıyasla çok daha nadir durumlarda doğru araçtır. Eğer servis, gerçek bir DNS adı üzerinden genel internete açıksa, okumayı bırakın ve bunun yerine nginx üzerinde certbot ile ücretsiz Let's Encrypt sertifikası veya Apache için eşdeğerini alın. Bu yöntem ücretsizdir, kendini yeniler ve ana akım tarayıcılar ile işletim sistemleri tarafından halihazırda güvenilirdir. Genel bir sitede self-signed sertifika kullanmak, kullanıcılarınızı güvenlik uyarılarını görmezden gelmeye alıştırır; bu, düz HTTP kullanmaktan daha kötü bir alışkanlıktır.

Self-signed sertifikalar, genel internetin dahil olmadığı durumlar için doğru araçtır: VPS üzerindeki bir WireGuard tünel adresine bağlı bir yönetim paneli, özel bir ağdaki hazırlık (staging) sunucusu, backend'ler arası servis trafiği, bir ev laboratuvarı cihazı veya Webmin'in 10000 numaralı portta kendi kendine oluşturduğu yer tutucu sertifikanın değiştirilmesi gibi. Let's Encrypt zaten 10.8.0.1 veya git.internal.lan için sertifika düzenleyemez; hiçbir genel CA, özel bir IP adresini veya uydurma bir TLD'yi sertifikaya dahil etmez. Bu tür isimler için CA sizsiniz.

Aşağıdaki her şey, OpenSSL 3.0.x sürümüyle gelen (doğrulamak için openssl version) temiz bir Ubuntu 24.04 sunucusu üzerinde çalışır. Burada hiçbir işlem internet erişimi gerektirmez; tamamen çevrimdışı (air-gapped) ortamda çalışır.

Eski tek satırlık komut neden Chrome tarafından reddedilen sertifikalar üretir

2017 öncesi tüm rehberlerin sunduğu komut şu şekildedir:

# Do not run this: shown so you recognise it in old guides
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout selfsigned.key -out selfsigned.crt

Bu komut bir dizi etkileşimli soru sorar, ana makine adınızı Common Name alanına yerleştirir ve subjectAltName uzantısı içermeyen bir sertifika üretir. Bu sertifika kullanıldığı anda geçersizdir. Chrome, 2017 yılının Nisan ayında yayınlanan 58 numaralı sürümünde Common Name okumayı durdurmuştur; RFC 2818 zaten 2000 yılında CN eşleşmesini kullanımdan kaldırmıştı. Firefox ve Safari de aynı şekilde davranır. curl ve Python'ın ssl modülü, sertifikada hiçbir SAN bulunmadığında Common Name alanına geri döner; bu nedenle SAN içermeyen bir sertifika hızlı bir curl testinden geçebilir ancak her tarayıcıda hata verir. Bir tarayıcı için sertifika, sunucusunu SAN uzantısı aracılığıyla tanımlar veya hiç tanımlamaz; tarayıcı size bu durumu tam olarak şu ifadelerle bildirir:

NET::ERR_CERT_COMMON_NAME_INVALID

This server could not prove that it is git.internal.lan; its security
certificate does not specify Subject Alternative Names.

Güven deposu (trust-store) üzerinde yapılan hiçbir değişiklik bu hatayı düzeltmez, çünkü sertifika aslında hiçbir şeyi tanımlamamaktadır. Şu anda NET::ERR_CERT_COMMON_NAME_INVALID hatası ile karşı karşıyaysanız, sertifikanızda SAN yoktur (veya hatalıdır) ve yeni bir tane oluşturmanız gerekir. Neyse ki çözüm tek bir komuttan ibarettir.

Tarayıcıların kabul edeceği bir sertifika oluşturma: tek komut

OpenSSL, 1.1.1 sürümüyle birlikte -addext bayrağını kullanıma sundu; bu sayede eski kılavuzlarda SAN eklemek için kullanılan karmaşık yapılandırma dosyalarına artık gerek kalmadı. Ubuntu 24.04 üzerinde:

sudo openssl req -x509 -newkey rsa:4096 -sha256 -days 730 -noenc \
  -keyout /etc/ssl/private/git.internal.key \
  -out /etc/ssl/certs/git.internal.crt \
  -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"

Her bir bayrağın işlevi:

-x509, bir imzalama isteği yerine doğrudan kendinden imzalı bir sertifika üretir.
-newkey rsa:4096, aynı adımda yeni bir anahtar oluşturur. RSA 4096 hiçbir eski istemciyle uyum sorunu yaşatmaz; bağlantı kuran tüm istemciler modern ise -newkey ec -pkeyopt ec_paramgen_curve:P-256 daha küçük ve hızlıdır.
-noenc, eski -nodes bayrağının OpenSSL 3.x sürümündeki karşılığıdır: anahtarda parola koruması olmaz. Her iki yazım şekli de çalışır. Parola korumalı bir anahtar, nginx'in her açılışta girdi beklemesine ve askıda kalmasına neden olur; bu nedenle sunucu anahtarı için bu bayrağı kullanmanız önerilir.
-days 730, iki yıl; bu sayı hakkında daha fazla bilgi için geçerlilik süresi bölümüne bakınız.
-subj, etkileşimli soruları satır içi olarak yanıtlar. CN artık sadece görsel amaçlıdır ancak yine de birincil isme ayarlayın; bazı araçlar bunu görüntüler.
-addext "subjectAltName=...", en kritik bayraktır. İstemcilerin yazacağı her ismi ve her IP adresini listeleyin: ana bilgisayar adları için DNS: girdileri (DNS:*.internal.lan gibi joker karakterler kullanılabilir), adresler için IP: girdileri. Eğer herhangi bir kullanıcı https://10.8.0.1 adresine giderse, IP:10.8.0.1 girdisinin orada olması gerekir; sadece DNS içeren bir SAN, onlara tekrar NET::ERR_CERT_COMMON_NAME_INVALID hatası verecektir.

Herhangi bir bağlantı kurmadan önce SAN'ın gerçekten eklenip eklenmediğini doğrulayın:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -ext subjectAltName

Doğru çıktı:

X509v3 Subject Alternative Name:
    DNS:git.internal.lan, IP Address:10.8.0.1

Eğer bunun yerine No extensions in certificate çıktısı alırsanız, sertifikada SAN yoktur ve tarayıcılar bunu reddedecektir; devam etmeden önce sertifikayı yeniden oluşturun.

Anahtarın güvenliğini sağlama

Sunucudaki her kullanıcının okuyabildiği bir özel anahtar, artık özel bir anahtar değildir. Standart bir Ubuntu 24.04 sisteminde /etc/ssl/private zaten 700 root:root durumundadır; bu nedenle yalnızca root kullanıcısı içeriğini listeleyebilir. Dosya, yalnızca ssl-cert paketi (apache2 bunu önerir) yüklendiğinde 710 root:ssl-cert haline gelir. Durum ne olursa olsun, dosya izinlerini açıkça şu şekilde ayarlayın:

sudo chown root:root /etc/ssl/private/git.internal.key
sudo chmod 600 /etc/ssl/private/git.internal.key

nginx ve Apache, ayrıcalıklarını düşürmeden önce sertifikaları root yetkisiyle okur; bu nedenle root:root 600 modu bu servisler için uygundur. Eğer anahtar, kendi kullanıcı hesabıyla çalışan ve anahtarı doğrudan yükleyen bir servis (Node uygulaması, Gitea, Python daemon vb.) içinse, chown komutuyla anahtarı ilgili servis kullanıcısına atayın ve yine 600 modunu kullanın. Asla yapmamanız gerekenler: 644 modu, anahtarın bir git deposunda kopyasını tutmak veya /tmp dizininde bir kopyasını bulundurmaktır.

Nginx ile yapılandırma

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name git.internal.lan;

    ssl_certificate     /etc/ssl/certs/git.internal.crt;
    ssl_certificate_key /etc/ssl/private/git.internal.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

sudo nginx -t && sudo systemctl reload nginx

nginx -t komutu, yeniden yükleme işlemi gerçekleşmeden önce syntax is ok ve test is successful çıktılarını vermelidir. Eğer bunun yerine SSL_CTX_use_PrivateKey_file() failed ... key values mismatch çıktısı alınıyorsa, sertifika ve anahtar farklı üretim süreçlerine aittir; bu durumda hata modları bölümüne bakılmalıdır.

Apache ile entegrasyon

sudo a2enmod ssl proxy proxy_http

ssl burada tek başına yeterli değildir: aşağıdaki vhost yapılandırması ProxyPass kullanır ve mod_proxy ile mod_proxy_http olmadan yapılandırma testi Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration hatasıyla başarısız olur. Vhost dosyasını /etc/apache2/sites-available/git-internal.conf olarak kaydedin:

<VirtualHost *:443>
    ServerName git.internal.lan
    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/git.internal.crt
    SSLCertificateKeyFile   /etc/ssl/private/git.internal.key

    ProxyPass        / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

sudo a2ensite git-internal
sudo apache2ctl configtest && sudo systemctl reload apache2

configtest, Syntax OK yanıtını vermelidir. Şimdi bir istemci makineden test edin:

curl -v https://git.internal.lan/

ve bir hata alacaksınız:

curl: (60) SSL certificate problem: self-signed certificate

Bu bir hata değildir. Bu, TLS'in çalışma şeklidir: curl sertifikanızı tanımaz ve kimliğini doğrulayamadığı bir sunucuyla iletişim kurmayı reddeder. Bir sonraki bölüm gerçek çözümü içermektedir ve bu, internetin yarısının şu anda yaptığı yöntemden farklıdır.

İstemcilerin güvenmesini sağlamak ve kaçınılması gereken hatalı yöntemler

Önce yanlış düzeltmeler, yani gerçekte ne oldukları. Bir betik içine gömülen curl -k (veya --insecure), Python requests içindeki verify=False veya Node içindeki NODE_TLS_REJECT_UNAUTHORIZED=0; bunların hiçbiri sertifikanızı güvenilir kılmaz. Bu yöntemler sertifika doğrulamasını devre dışı bırakır; bu da istemcinin, saldırganın araya yerleştirdiği bir sertifika dahil olmak üzere, herhangi bir sertifika sunan herhangi bir sunucuyla sorunsuz iletişim kuracağı anlamına gelir. TLS'in getirdiği yükü taşımaya devam ederken, TLS'in asıl amacı olan kimlik doğrulama özelliğini kaybedersiniz. Daha kötüsü, bu bayraklar yayılır: bir cron işine, ardından bir dağıtım betiğine ve nihayet üretim koduna yapıştırılır; sonunda kimse hangi bağlantıların geçici olması gerektiğini hatırlayamaz. Eğer bir verify=False, onu ortaya çıkaran hata ayıklama oturumundan sonra varlığını sürdürüyorsa, tasarım hatalıdır.

Doğru çözüm, her istemci işletim sistemine bu sertifikanın güvenilir bir kök sertifika olduğunu öğretmektir. Ubuntu ve Debian istemcilerinde:

sudo cp git.internal.crt /usr/local/share/ca-certificates/git.internal.crt
sudo update-ca-certificates

Çıktıda önemli olan satır (ardından bir Running hooks in /etc/ca-certificates/update.d... bloğu gelir):

Updating certificates in /etc/ssl/certs...
1 added, 0 removed; done.

Bu satırlarda iki gizli tuzak bulunur. Dosya mutlaka .crt ile bitmelidir; .pem uzantısı sessizce göz ardı edilir ve hiçbir hata mesajı almadan 0 added hatasıyla karşılaşırsınız. Ayrıca içerik PEM formatında olmalıdır, dosya -----BEGIN CERTIFICATE----- ile başlar; DER ikili dosyasını önce openssl x509 -inform der -in file.der -out file.crt ile dönüştürün. Kendinden imzalı sertifikayı kök olarak eklemek işe yarar çünkü kendinden imzalı bir sertifika kendi köküdür.

Bundan sonra curl, wget, git, apt ve sistem paketine karşı OpenSSL kullanan diğer her şey, hiçbir bayrağa gerek kalmadan sunucuya güvenir. Kendi güven depolarını taşıyan ve özel işlem gerektiren birkaç istemci şunlardır:

Linux üzerinde Chrome/Chromium, sistem deposunu değil bir NSS veritabanını okur: sudo apt install libnss3-tools, ardından kullanıcı başına certutil -d sql:$HOME/.local/share/pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt. Bu yol, 146 sürümünden beri Chrome'un varsayılanıdır; eğer kullanıcı eski bir kurulumdan kalan bir ~/.pki/nssdb dosyasına sahipse, Chrome bunu okumaya devam eder, bu nedenle bu makinelerde -d yolunu sql:$HOME/.pki/nssdb olarak ayarlayın.
Firefox'un kendi deposu vardır: Ayarlar → Gizlilik ve Güvenlik → Sertifikalar → İçe Aktar. Windows ve macOS üzerinde, işletim sistemi deposunu okuması için about:config içindeki security.enterprise_roots.enabled değerini true olarak değiştirebilirsiniz; Mozilla bu tercihi Windows ve macOS için belgeler, Linux için değil, bu yüzden Ubuntu üzerinde içe aktarma yöntemini kullanın.
Python requests, kendi CA paketini (certifi) kullanır ve sistem deposunu yok sayar: verify="/usr/local/share/ca-certificates/git.internal.crt" parametresini geçin veya REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt değişkenini dışa aktarın.
Node.js, varsayılan olarak kendi paketlenmiş köklerini kullanır: NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt değişkenini dışa aktarın veya az önce güncellediğiniz sistem deposunu --use-system-ca bayrağı (Linux üzerinde Node 23.9 ve sonrası) ya da NODE_USE_SYSTEM_CA=1 (Node 24.6 ve 22.19 ve sonrası) ile okumasını sağlayın.

Windows istemcilerinde .crt dosyasına çift tıklayın ve Güvenilen Kök Sertifika Yetkilileri (Trusted Root Certification Authorities) altına yükleyin; macOS üzerinde ise Keychain Access içindeki System anahtarlığına ekleyin ve Her Zaman Güven (Always Trust) olarak işaretleyin.

Birçok servis için tek kök: küçük bir özel CA

Sertifika bazlı güven yönetimi, servis sayısı arttıkça sürdürülemez hale gelir: altı servis ve dört istemci makine, yirmi dört adet güven kurulumu demektir; her yeni servis bu yükü artırır. Çözüm, özel bir CA kurmaktır; istemciler tek bir kök sertifikaya güvenir ve siz her servisin sertifikasını bu kök ile imzalarsınız.

Kullanıcı dostu seçenek, Ubuntu 24.04 depolarında bulunan ve update-ca-certificates aracının atladığı NSS depolarını (Firefox ve aşağıda belirtilen bir istisna ile Chrome) yönetebilen mkcert aracıdır:

sudo apt install -y mkcert libnss3-tools
mkcert -install
mkcert git.internal.lan "*.internal.lan" 10.8.0.1

mkcert -install bir kök sertifika oluşturur ve bunu sistem deposuna, bulabildiği tarayıcı NSS depolarına ve JAVA_HOME ayarlandığında Java deposuna kaydeder. Node, aksi belirtilmedikçe sistem deposunu okumaz; bu nedenle Node uygulamalarını yukarıda belirtildiği gibi --use-system-ca (veya NODE_USE_SYSTEM_CA=1) ile başlatın ya da NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem" değişkenini dışa aktarın. Üçüncü komut, yukarıdaki nginx veya Apache yapılandırmalarına doğrudan eklenebilecek git.internal.lan+2.pem ve git.internal.lan+2-key.pem dosyalarını üretir. Aracın tasarım varsayımı bir geliştirme makinesidir; kök anahtar -install komutunu çalıştıran makinede kalır. Bu nedenle geliştirme dizüstü bilgisayarları için mükemmeldir ancak sunucu filoları için uygun değildir.

Ekim 2026 itibarıyla karşılaşılan durum şudur: mkcert, Chrome'un NSS veritabanını yalnızca eski ~/.pki/nssdb yolunda arar; Chrome'un 146. sürümden beri varsayılan olarak kullandığı ~/.local/share/pki/nssdb yoluna bakmaz. Eski veritabanının bulunmadığı bir makinede, kök sertifikayı Chrome için -i "$(mkcert -CAROOT)/rootCA.pem" kullanarak bir önceki bölümdeki certutil komutuyla kendiniz ekleyin.

Sunucular için standart OpenSSL ile tüm CA süreci beş komutta tamamlanır:

openssl genrsa -out lab-ca.key 4096
openssl req -x509 -new -key lab-ca.key -sha256 -days 3650 \
  -out lab-ca.crt -subj "/CN=Lab Internal CA" \
  -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl genrsa -out git.key 2048
openssl req -new -key git.key -out git.csr -subj "/CN=git.internal.lan" \
  -addext "subjectAltName=DNS:git.internal.lan,IP:10.8.0.1"
openssl x509 -req -in git.csr -CA lab-ca.crt -CAkey lab-ca.key \
  -CAcreateserial -days 730 -sha256 -copy_extensions copy -out git.crt

Buradaki tuzak son komuttadır: openssl x509 -req, varsayılan olarak CSR içindeki tüm uzantıları siler; buna özenle eklediğiniz SAN bilgisi de dahildir. -copy_extensions copy (OpenSSL 3.x seçeneği olduğu için 24.04 üzerinde çalışır) bu uzantıları korur; bu seçenek atlanırsa imzalanan sertifika SAN içermez ve Chrome sizi tekrar NET::ERR_CERT_COMMON_NAME_INVALID hatasıyla karşılar. Doğrulamayı daha önce olduğu gibi aynı openssl x509 -noout -ext subjectAltName kontrolü ile yapın.

lab-ca.crt dosyasını, makine başına bir kez olmak üzere yukarıdaki güven deposu adımlarıyla istemcilere dağıtın. lab-ca.key dosyasını ise mücevherleriniz gibi koruyun: dosya izinlerini 600 yapın ve ideal olarak imzaladığı sunuculardan farklı bir makinede tutun. Çünkü bu anahtara sahip olan kişi, istemcilerinizin güveneceği herhangi bir alan adı için sertifika üretebilir.

Süre sonu ve yenileme

Halka açık CA sertifikalarının ömürleri kısalmaktadır; CA/Browser Forum, Mart 2026 itibarıyla halka açık güvenilir sertifikaların süresini 200 güne (398 günden düşürülerek) sınırlamış, bu sürenin 2027'de 100 güne, Mart 2029'da ise 47 güne inmesini kararlaştırmıştır. Ancak bu kurallar yalnızca halka açık güvenilir CA'leri bağlar. Özel CA'niz bu kurallara tabi değildir ve tarayıcılar manuel olarak yüklenen kök sertifikalar için bu kısıtlamaları uygulamaz. Gerçek dünyada geçerli olan tek bir kısıtlama vardır: Apple platformları, kim tarafından düzenlenmiş olursa olsun 825 günden uzun geçerliliği olan hiçbir TLS sunucu sertifikasını kabul etmez. Bu nedenle iPhone veya Mac cihazların bağlantı kurması gerekiyorsa, yaprak sertifikaların süresini iki yıl veya daha kısa tutun. -days 730 bu sınırı her yerde karşılar; on yıllık bir kök sertifika ve iki yıllık yaprak sertifikalar, dahili kullanım için uygun bir yapıdır.

Uzun ömürlü sertifikalar tek bir şekilde başarısız olur: kimsenin seçtiğini hatırlamadığı bir tarihte, sessizce ve tamamen. Mevcut durumunuzu kontrol edin:

openssl x509 -in /etc/ssl/certs/git.internal.crt -noout -enddate

Yenileme işlemini gerçek bir takvime işleyin veya openssl x509 -checkend 2592000 -in cert.crt kullanarak 30 gün önceden cron ile bildirim alın; bu komut, sertifika süresinin dolmasına belirtilen saniye kadar kaldığında sıfır olmayan bir çıkış kodu döndürür. Eğer halihazırda durum izleme için Uptime Kuma kullanıyorsanız, HTTPS monitörleri yaklaşan sertifika süresi sonlarını ücretsiz olarak işaretler.

Özel bir CA ile sertifika yenileme işlemi oldukça basittir: CSR oluşturma ve imzalama komutlarını tekrar çalıştırın, dosyaları değiştirin ve web sunucusunu yeniden yükleyin. Kök sertifika değişmediği için hiçbir istemci herhangi bir değişiklik fark etmeyecektir.

Hata modları ve karşılaşacağınız dizeler

NET::ERR_CERT_AUTHORITY_INVALID, güveni tesis etmeden önceki beklenen durumdur, sertifikada bir kusur değildir. Kök sertifikayı yükledikten sonra bu durum devam ediyorsa: Linux üzerinde Chrome, sistem deposu yerine NSS veritabanını okur (bkz. certutil adımı) ve Chrome 146 sürümünden itibaren, eski bir ~/.pki/nssdb mevcut değilse bu veritabanı ~/.local/share/pki/nssdb konumunda bulunur; dolayısıyla diğer yola eklenen bir kök sertifika asla görülmez. Ya da kopyalanan dosya .crt ile bitmiyordur ve update-ca-certificates, 0 added hatasını vermiştir. Alternatif olarak sunucu, güvendiğinizden farklı bir sertifika sunuyor olabilir; parmak izlerini openssl s_client -connect git.internal.lan:443 </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 ile karşılaştırın.

NET::ERR_CERT_COMMON_NAME_INVALID, sertifikada SAN alanı yoktur veya SAN, adres çubuğundaki ismi kapsamamaktadır. Klasik durum: SAN listesinde DNS:git.internal.lan vardır ancak kullanıcı https://10.8.0.1 adresine gitmiştir. Güven deposu değişiklikleri bunu düzeltemez; eksik girişi ekleyerek sertifikayı yeniden oluşturun.

curl: (60) SSL certificate problem: self-signed certificate, curl sertifikaya güvenmemektedir. self-signed certificate in certificate chain varyantı, özel CA'niz tarafından imzalanmış bir sertifika için aynı anlama gelir. Tek seferlik çözüm: curl --cacert lab-ca.crt https://...; kalıcı çözüm: güven deposudur. -k değildir.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (veya Expecting: CERTIFICATE REQUEST ya da no start line), PEM karmaşasıdır. OpenSSL'e yanlış türde bir dosya verdiniz: sertifika beklenen yerde bir anahtar veya CSR, ya da PEM beklenen yerde bir DER ikili dosyası. head -1 filename elinizde gerçekte ne olduğunu söyler; bir sertifika -----BEGIN CERTIFICATE----- ile başlar. DER formatı için openssl x509 -inform der -in file.der -out file.crt ile dönüştürme yapın.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch), sertifika ve anahtar birbirine ait değildir; genellikle oluşturma komutu iki kez çalıştırıldığında ve dosyalar karıştığında meydana gelir. openssl x509 -in git.internal.crt -noout -pubkey | sha256sum ile openssl pkey -in git.internal.key -pubout | sha256sum karşılaştırmasını yaparak doğrulayın; eşleşen hash değerleri, eşleşen bir çift anlamına gelir. Eğer farklılarsa, her ikisini de birlikte yeniden oluşturun.

FAQ

Chrome, kendi imzaladığım sertifikayı oluşturmama rağmen neden hala "Güvenli değil" diyor?

Hata NET::ERR_CERT_AUTHORITY_INVALID ise sertifika doğrudur, Chrome'un ona güvenmesi için henüz bir nedeni yoktur. Sertifikayı (veya özel CA kök sertifikanızı) istemcinin güven deposuna yükleyin. Linux üzerinde Chrome'un sistem deposunu değil, certutil aracılığıyla NSS veritabanını (Chrome 146 sürümünden beri ~/.local/share/pki/nssdb konumunda veya varsa eski ~/.pki/nssdb konumunda) kullandığını unutmayın. Hata NET::ERR_CERT_COMMON_NAME_INVALID ise sertifika, URL ile eşleşen bir Subject Alternative Name içermiyordur ve -addext "subjectAltName=..." ile yeniden düzenlenmelidir.

curl'ün -k kullanmadan kendi imzaladığım bir sertifikaya güvenmesini nasıl sağlarım?

Sertifikayı (PEM formatında, .crt uzantılı) /usr/local/share/ca-certificates/ dizinine kopyalayın ve sudo update-ca-certificates komutunu çalıştırın; çıktı 1 added ifadesini içermelidir. Bundan sonra curl, sertifikayı herhangi bir genel sertifika gibi doğrular. Sistemi etkilemeden tek seferlik bir istek için curl --cacert /path/to/cert.crt bayrağı yalnızca o dosya üzerinden doğrulama yapar; -k ise doğrulamayı tamamen devre dışı bırakır ve hiçbir betikte kullanılmamalıdır.

Kendi imzaladığım bir sertifika ne kadar süre geçerli olabilir?

Teknik olarak istediğiniz kadar uzun olabilir; CA/Browser Forum sınırları (şu an 200 gün, 2029 itibarıyla 47 gün) genel güvenilen CA'ları bağlar, özel güveni değil. Uygulamada, sunucu sertifikalarını 825 gün ile sınırlayın, çünkü Apple cihazları düzenleyicisi kim olursa olsun daha uzun süreli sertifikaları reddeder. On yıllık bir özel kök sertifika ve iki yıllık (-days 730) yaprak sertifikalar makul bir varsayılandır; yenileme tarihini takviminize işleyin, çünkü süresi dolan bir dahili sertifika, kimsenin hatırlamadığı bir tarihte her şeyi sessizce devre dışı bırakır.

Kendi imzaladığım sertifikayı mı yoksa Let's Encrypt'i mi kullanmalıyım?

Servisin genel bir DNS adı varsa ve internetten erişilebiliyorsa her zaman Let's Encrypt kullanın; ücretsizdir, otomatiktir ve çoğu tarayıcı ile işletim sistemi tarafından zaten güvenilirdir (çok eski cihazların bağlanması gerekiyorsa Let's Encrypt uyumluluk listesini kontrol edin). Kendi imzaladığınız (veya özel bir CA) sertifikalar, Let's Encrypt'in düzenleyemediği durumlar içindir: özel IP adresleri, .lan gibi yalnızca dahili ana bilgisayar adları, internete kapalı ağlar ve kasıtlı olarak VPN arkasına gizlenmiş servisler. Bu karar erişilebilirlik ve isimlendirme ile ilgilidir, güvenlik gücüyle değil; kriptografi aynıdır.

Üç şeyi kontrol edin. Dosya .crt ile bitmelidir; .pem uzantısı sessizce atlanır ve update-ca-certificates bu durumda 0 added raporlar. İçerik, DER ikili verisi değil, -----BEGIN CERTIFICATE----- ile başlayan PEM metni olmalıdır. Ayrıca uygulamanın sistem deposunu gerçekten kullanıyor olması gerekir; Chrome (Linux üzerinde), Firefox, Python requests, Node.js (--use-system-ca ile başlatılmadığı sürece) ve Java'nın her biri kendi özel güven deposunu tutar ve sertifikanın ayrı ayrı eklenmesini gerektirir.

#openssl #tls#self-signed#ubuntu #security