Rehberler

Yazan Matt Connor 2026-07-16 · Güncellendi 2026-07-24

Ubuntu 24.04 self-signed sertifika oluşturma

Q: Kendi kendine imzalanmış bir sertifika oluşturduktan sonra Chrome neden hâlâ "Not secure" diyor?

Hata NET::ERR_CERT_AUTHORITY_INVALID ise sertifika geçerlidir; Chrome henüz sertifikaya güvenmek için bir nedene sahip değildir. 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ı kullandığını unutmayın. Hata NET::ERR_CERT_COMMON_NAME_INVALID ise sertifika, URL ile eşleşen bir Subject Alternative Name içermiyor demektir; sertifika -addext "subjectAltName=..." ile yeniden oluşturulmalıdır.

Q: -k parametresi kullanmadan curl'ün kendi kendine imzalanmış bir sertifikaya güvenmesi nasıl sağlanır?

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 olmalıdır. Bu işlemden sonra curl, sertifikayı herhangi bir genel sertifika gibi doğrular. Sistemi değiştirmeden tek seferlik bir istek yapmak için curl --cacert /path/to/cert.crt yalnızca ilgili dosyaya göre doğrulama yapar; -k ise doğrulamayı tamamen devre dışı bırakır ve hiçbir kullanıcının scriptlerinde yer almamalıdır.

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

Üç durumu kontrol edin. Dosya .crt ile bitmelidir; .pem uzantısı sessizce atlanır ve update-ca-certificates 0 added hatası verir. İçerik, DER ikili formatı değil, -----BEGIN CERTIFICATE----- ile başlayan PEM metni olmalıdır. Ayrıca uygulama sistem deposunu kullanmalıdır; Linux üzerindeki Chrome, Firefox, Python requests, Node.js ve Java her biri kendi özel güven deposuna sahiptir ve sertifikanın her birine ayrı ayrı eklenmesi gerekir.

Ubuntu 24.04 üzerinde Chrome uyumlu self-signed TLS sertifikası üretme yöntemi. OpenSSL ile SAN ekleme, Nginx kurulumu ve sertifikaya tam güven sağlama.

Ne inşa ediyorsunuz

Modern tarayıcılar ve istemciler tarafından kabul edilen bir self-signed TLS sertifikası — doğru subjectAltName, mantıklı anahtar izinleri, nginx veya Apache entegrasyonu — ve hemen hemen her kılavuzun atladığı bir kısım: istemcilerin uyarıları geçmek yerine sertifikaya tam olarak güvenmesini sağlamak, böylece curl -k değerini scriptlere kalıcı olarak kodlamak zorunda kalmazsınız. Sonuçta, bir iç servis sayısının altı olması durumunda kullanılacak beş komutluk bir özel CA yapısı.

Öncelikle karar aşaması; çünkü self-signed sertifikalar, sanıldığından çok daha az durumda doğru araçtır. Eğer servis, gerçek bir DNS adı altında halka açık internetten erişilebilir durumdaysa, okumayı bırakın ve bunun yerine nginx üzerinde certbot ile ücretsiz bir Let's Encrypt sertifikası veya Apache eşdeğerini edinin. Bu işlem ücretsizdir, kendini yeniler ve dünyadaki tüm tarayıcılar buna halihazırda güvenir. Halka açık bir sitede self-signed sertifika kullanmak, kullanıcıları güvenlik uyarılarını geçmeye alıştırır; bu, düz HTTP kullanımından daha kötü bir alışkanlıktır.

Aşağıdaki senaryolarda self-signed doğru araçtır: internet erişimi olmayan durumlar; VPS üzerindeki bir WireGuard tünel adresine bağlı bir yönetim paneli, özel bir ağdaki staging sunucusu, backendler arası servis trafiği, bir ev laboratuvarı cihazı veya Webmin'in 10000 portu için oluşturduğu geçici sertifikanın değiştirilmesi. Let's Encrypt zaten 10.8.0.1 veya git.internal.lan için sertifika düzenleyemez; hiçbir halka açık CA, bir sertifikaya özel IP veya uydurma bir TLD eklemez. Bu isimler için CA sizsiniz.

Aşağıdaki tüm işlemler, OpenSSL 3.0.x (doğrulamak için openssl version) ile gelen yeni bir Ubuntu 24.04 üzerinde çalışmaktadır. Buradaki hiçbir işlem internet erişimi gerektirmez; her şey çevrimdışı (air-gapped) çalışabilir.

Eski tek satırlık komutun Chrome tarafından reddedilen sertifikalar üretme nedeni

2017 öncesi tüm eğitimlerde verilen komut şöyledir:

# 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, hostname bilgisini Common Name alanına yazar ve subjectAltName uzantısı olmayan bir sertifika üretir. Bu sertifika geçersizdir. Chrome, Nisan 2017'de (versiyon 58 ile) Common Name alanını okumayı bırakmıştır; RFC 2818 zaten 2000 yılında CN eşleştirmesini devre dışı bırakmıştı. Firefox, Safari, curl ve Python da aynı şekilde çalışır. Bir sertifika, sunucuyu ya SAN uzantısı aracılığıyla tanımlar ya da hiç tanımlamaz. Tarayıcı bu durumu şu şekilde belirtir:

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 işlem bu hatayı düzeltmez, çünkü sertifika gerçekte hiçbir şeyi tanımlamamaktadır. Eğer şu an NET::ERR_CERT_COMMON_NAME_INVALID hatası alıyorsanız, sertifikanız SAN içermiyor (veya yanlış SAN içeriyor) demektir ve yeni bir sertifika oluşturmanız gerekir. Neyse ki çözüm tek bir komuttur.

Tarayıcılar tarafından kabul edilen bir sertifika oluşturun: tek komut

OpenSSL 1.1.1 sürümüyle birlikte -addext bayrağı eklenmiştir. Bu sayede, eski kılavuzlarda SAN eklemek için kullanılan yapılandırma dosyası karmaşasına artık gerek yoktur. 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"

Bayrakların işlevleri:

-x509, imza isteği yerine doğrudan kendi imzalı bir sertifika üretir.
-newkey rsa:4096, aynı adımda yeni bir anahtar oluşturur; RSA 4096 eski istemcilerle sorun yaşamaz; tüm bağlantılar modern ise -newkey ec -pkeyopt ec_paramgen_curve:P-256 daha küçük ve daha hızlıdır.
-noenc, eski -nodes kullanımının OpenSSL 3.x yazımıdır: anahtar üzerinde parola bulunmaz. Her iki yazım da çalışır. Parolalı bir anahtar, nginx'in her açılışta girdi beklerken takılmasına neden olur; bu nedenle sunucu anahtarları için bu yöntem tercih edilir.
-days 730 — iki yıl; bu sayı hakkında daha fazla bilgi geçerlilik süresi bölümünde verilmiştir.
-subj, etkileşimli soruları satır içi olarak yanıtlar. CN artık sadece görseldir, ancak yine de birincil isim olarak ayarlanmalıdır; bazı araçlar bunu görüntüler.
-addext "subjectAltName=...", temel bayraktır. İstemcilerin yazacağı tüm isimleri ve tüm IP adreslerini listeleyin: ana bilgisayarlar için DNS: girişleri (DNS:*.internal.lan gibi joker karakterler uygundur), adresler için IP: girişleri. Eğer bir kullanıcı https://10.8.0.1 adresine erişecekse, IP:10.8.0.1 girişi mutlaka bulunmalıdır; sadece DNS içeren bir SAN, NET::ERR_CERT_COMMON_NAME_INVALID hatalarına tekrar yol açar.

Herhangi bir yapılandırma yapmadan önce SAN'ın başarıyla eklendiğ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 çıktı yerine No extensions in certificate yazıyorsa, sertifikanın SAN bilgisi yoktur ve tarayıcılar bunu reddedecektir; işleme devam etmek yerine sertifikayı yeniden oluşturun.

Anahtarı koruma altına alın

Sistemdeki her kullanıcı tarafından okunabilen bir özel anahtar, teknik olarak özel bir anahtar değildir. Ubuntu üzerinde /etc/ssl/private zaten 710 root:ssl-cert olarak ayarlanmıştır ve bu durum yetkisiz erişimi engeller; ancak dosya izinlarını açıkça şu şekilde belirleyin:

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

nginx ve Apache, yetkilerini düşürmeden önce sertifikaları root kullanıcısı ile okur, bu nedenle root:root mod 600 bu servisler için uygundur. Eğer anahtar; Node uygulaması, Gitea veya bir Python daemon'ı gibi kendi kullanıcısıyla çalışan ve anahtarı kendisi yükleyen bir servise aitse, anahtarı yine mod 600 olacak şekilde ilgili servis kullanıcısına chown verin. Asla yapılmaması gerekenler: mod 644 kullanmak, anahtarı bir git deposuna kopyalamak veya /tmp içine kopyalamaktır.

nginx içine entegre edin

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, reload işlemi gerçekleşmeden önce syntax is ok ve test is successful çıktılarını vermelidir. Eğer SSL_CTX_use_PrivateKey_file() failed ... key values mismatch çıktısı alınırsa, sertifika ve anahtar farklı oluşturma süreçlerinden gelmektedir; failure-modes bölümüne bakınız.

Apache içine entegre edin

sudo a2enmod ssl proxy proxy_http

Burada sadece ssl yeterli değildir: aşağıdaki vhost ProxyPass kullanmaktadır. mod_proxy ve mod_proxy_http ayarları eksik olduğunda, konfigürasyon testi Invalid command 'ProxyPass', perhaps misspelled or defined by a module not included in the server configuration hatası verir. 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 isteğine yanıt vermelidir. Şimdi bir istemci makineden test edin:

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

ve şu hatayı alacaksınız:

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

Bu bir hata değildir. Bu, TLS'in çalıştığını gösterir: curl, sertifikanızı tanımıyor ve kimlik doğrulayamadığı bir sunucuyla iletişime geçmeyi reddediyor. Bir sonraki bölüm asıl çözümdür; internetteki birçok kişinin yaptığı yöntem ise bu değildir.

İstemcilerin güvenmesini sağlayın — ve reddedilmesi gereken hatalı uygulamalar

Yanlış çözüm yöntemleri aşağıda belirtilmiştir. curl -k (veya --insecure) bir script içine gömülmüş, verify=False Python requests içinde, NODE_TLS_REJECT_UNAUTHORIZED=0 Node içinde kullanıldığında sertifikanız güvenilir hale gelmez. Bu yöntemler sertifika doğrulamasını kapatır. Bu durum, istemcinin saldırganlar tarafından sunulan sertifikalar dahil olmak üzere herhangi bir sertifikayı kabul edeceği anlamına gelir. TLS yükü devam ederken, TLS'in temel amacı olan kimlik doğrulama özelliği kaybedilir. Daha da kötüsü, bu bayraklar yayılır: bir cron job içine, ardından bir deploy scriptine ve en sonunda üretim koduna yapıştırılır; sonunda hangi bağlantıların geçici olması gerektiği unutulur. Eğer bir verify=False hata ayıklama oturumundan sonra hala sistemde duruyorsa, tasarım hatalıdır.

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

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

Çıktıdaki önemli 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 kritik nokta bulunmaktadır. Dosya mutlaka .crt ile bitmelidir; .pem uzantısı sessizce görmezden gelinir ve hata mesajı almadan 0 added hatası alınır. İçerik PEM formatında olmalıdır; dosya -----BEGIN CERTIFICATE----- ile başlamalıdır; DER formatındaki bir ikili dosyayı önce openssl x509 -inform der -in file.der -out file.crt ile dönüştürün. Self-signed sertifikanın kendisini kök olarak eklemek işe yarar çünkü self-signed sertifika kendi köküdür.

Bundan sonra curl, wget, git, apt ve sistem paketine karşı OpenSSL kullanan diğer tüm araçlar, hiçbir bayrak gerektirmeden sunucuya güvenir. Kendi güven deposuna sahip olan ve ayrı işlem gerektiren bazı istemciler şunlardır:

Linux üzerindeki 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/.pki/nssdb -A -t "C,," -n "git.internal" -i git.internal.crt.
Firefox kendi deposuna sahiptir: Ayarlar → Gizlilik ve Güvenlik → Sertifikalar → İçe Aktar, veya sistem deposunu okuması için about:config içindeki security.enterprise_roots.enabled ayarını true olarak değiştirin.
Python requests, kendi CA paketini (certifi) kullanır ve sistem deposunu görmezden gelir: 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: NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt değişkenini dışa aktarın.

Windows istemcilerde .crt dosyasına çift tıklayın ve Trusted Root Certification Authorities altına yükleyin; macOS'ta ise Keychain Access içindeki System keychain'e ekleyin ve Always Trust olarak işaretleyin.

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

Sertifika başına güven yönetimi ölçeklenemez: altı servis ve dört istemci makinesi toplamda yirmi dört güven kurulumu demektir ve her yeni servis bu sayıyı artırır. Çözüm özel bir CA kullanmaktı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 olan mkcert, Ubuntu 24.04 depolarında mevcuttur ve update-ca-certificates'in atladığı NSS depolarını (Chrome, Firefox) yönetir:

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 makinedeki tüm güven depolarına kaydeder; üçüncü komut, yukarıdaki nginx veya Apache kod bloklarına eklenmeye hazır git.internal.lan+2.pem ve git.internal.lan+2-key.pem çıktılarını üretir. Bu aracın tasarım varsayımı bir geliştirme makinesidir; kök anahtar -install komutunun çalıştırıldığı makinede saklanır. Bu nedenle geliştirme dizüstü bilgisayarları için idealdir, ancak sunucu kümeleri için uygun değildir.

Sunucular için standart OpenSSL, tüm CA işlemlerini beş komutla gerçekleştirir:

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

Hata son komuttadır: openssl x509 -req varsayılan olarak CSR içerisindeki tüm uzantıları kaldırır, buna dikkatle eklediğiniz SAN da dahildir. -copy_extensions copy (OpenSSL 3.x seçeneğidir, dolayısıyla 24.04 üzerinde çalışır) bu uzantıları korur; bu seçenek kullanılmazsa imzalanmış sertifika SAN içermez ve Chrome tekrar NET::ERR_CERT_COMMON_NAME_INVALID hatası verir. Daha önceki gibi openssl x509 -noout -ext subjectAltName kontrolü ile doğrulama yapın.

lab-ca.crt dosyasını yukarıdaki güven deposu adımlarıyla istemcilere dağıtın; bu işlem her makine için bir kez yapılır. lab-ca.key dosyasını çok değerli bir varlık gibi koruyın: izinler 600 olmalıdır ve ideal olarak imzaladığı sunuculardan farklı bir makinede saklanmalıdır; çünkü bu anahtara sahip olan kişi, istemcilerinizin güveneceği herhangi bir isim için sertifika üretebilir.

Expiry and rotation

Kamuya açık CA sertifika ömürleri kısalmaktadır. CA/Browser Forum, Mart 2026 itibarıyla yeni ihraç edilen kamuya güvenilir sertifikaları 200 gün ile sınırlandırmıştır (398 günden düşürülmüştür). Bu süre 2027'de 100 güne, Mart 2029'da ise 47 güne düşecektir. Ancak bu kurallar yalnızca kamuya güvenilen CA'lar için geçerlidir. Özel CA yapınız bu kurallara tabi değildir ve tarayıcılar manuel olarak yüklenen kök sertifikalar için bu kuralları zorunlu kılmaz. Uygulanan gerçek bir kısıtlama mevcuttur: Apple platformları, kim tarafından ihraç edilirse edilsin, 825 günden uzun geçerliliğe sahip TLS sunucu sertifikalarını reddeder. iPhone veya Mac cihazlarının bağlanması gerekiyorsa, uç (leaf) sertifikaları iki yıl veya daha kısa tutulmalıdır. -days 730 bu eşiği her yerde karşılar; on yıllık bir kök sertifika ve iki yıllık uç sertifikalar uygun bir iç yapı oluşturur.

Uzun ömürlü sertifikalar tek bir şekilde hata verir: Kimsenin seçtiği tarihi hatırlamadığı bir tarihte, sessizce ve aynı anda tüm sertifikalar geçersiz olur. Mevcut durumunuzu kontrol edin:

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

Yenileme işlemini gerçek bir takvime kaydedin veya 30 gün kala sizi uyarması için cron kullanın; openssl x509 -checkend 2592000 -in cert.crt son geçerlilik süresi bu kadar saniye kaldığında sıfır dışında bir değerle çıkar. Eğer halihazırda durum izleme için Uptime Kuma kullanıyorsanız, HTTPS izleyicileri yaklaşan sertifika süresi dolumu için ücretsiz uyarı verir.

Özel bir CA ile rotasyon işlemi oldukça basittir: CSR 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 istemciler herhangi bir değişiklik fark etmez.

Hata modları ve karşılaşılacak dizinler

NET::ERR_CERT_AUTHORITY_INVALID — Sertifika kusuru değil, güven işlemi öncesindeki beklenen durumdur. Kök sertifika yüklendikten sonra bu durum devam ediyorsa: Linux üzerinde Chrome, sistem deposu yerine NSS kullanmaktadır (bakınız certutil adımı); veya kopyalanan dosya .crt ile bitmemiştir ve update-ca-certificates 0 added hatası vermiştir; veya sunucu, güvenilen sertifikadan farklı bir sertifika sunmaktadır — 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 bulunmamaktadır veya SAN, adres çubuğundaki ismi kapsamamaktadır. Klasik durum: SAN DNS:git.internal.lan listeler ancak kullanıcı https://10.8.0.1 adresine gitmiştir. Güven deposu değişiklikleri bu sorunu çözemez; eksik giriş ile 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 tarafından imzalanmış sertifikalar için aynı anlama gelir. Tek seferlik çözüm: curl --cacert lab-ca.crt https://...; kalıcı çözüm: güven deposu. -k değildir.

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (veya Expecting: CERTIFICATE REQUEST, veya no start line) — PEM karmaşası. OpenSSL'e yanlış dosya türü verdiniz: sertifika beklenen yere anahtar veya CSR, veya PEM beklenen yere DER binary dosyası. head -1 filename elinizdeki dosyanın türünü belirtir — bir sertifika -----BEGIN CERTIFICATE----- ile başlar. DER dosyaları için openssl x509 -inform der -in file.der -out file.crt ile dönüştürün.

nginx: [emerg] SSL_CTX_use_PrivateKey_file(...) failed (SSL: error ... key values mismatch) — Sertifika ve anahtar birbirine ait değildir; genellikle oluşturma komutunun iki kez çalıştırılması ve dosyaların karışması nedeniyle oluşur. openssl x509 -in git.internal.crt -noout -pubkey | sha256sum ile openssl pkey -in git.internal.key -pubout | sha256sum değerlerini karşılaştırarak doğrulayın; eşleşen hash değerleri, eşleşen bir çift anlamına gelir. Farklılık varsa, her ikisini birlikte yeniden oluşturun.

FAQ

Kendi kendine imzalanmış bir sertifika oluşturduktan sonra Chrome neden hâlâ "Not secure" diyor?

Hata NET::ERR_CERT_AUTHORITY_INVALID ise sertifika geçerlidir; Chrome henüz sertifikaya güvenmek için bir nedene sahip değildir. 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ı kullandığını unutmayın. Hata NET::ERR_CERT_COMMON_NAME_INVALID ise sertifika, URL ile eşleşen bir Subject Alternative Name içermiyor demektir; sertifika -addext "subjectAltName=..." ile yeniden oluşturulmalıdır.

-k parametresi kullanmadan curl'ün kendi kendine imzalanmış bir sertifikaya güvenmesi nasıl sağlanır?

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 olmalıdır. Bu işlemden sonra curl, sertifikayı herhangi bir genel sertifika gibi doğrular. Sistemi değiştirmeden tek seferlik bir istek yapmak için curl --cacert /path/to/cert.crt yalnızca ilgili dosyaya göre doğrulama yapar; -k ise doğrulamayı tamamen devre dışı bırakır ve hiçbir kullanıcının scriptlerinde yer almamalıdır.

Kendi kendine imzalanmış bir sertifikanın geçerlilik süresi ne kadar olabilir?

Teknik olarak istediğiniz kadar uzun olabilir; CA/Browser Forum limitleri (şu an 200 gün, 2029'a kadar 47 gün) kamuya açık güvenilen CA'ları bağlar, özel güveni değil. Uygulamada, Apple cihazları yayıncıdan bağımsız olarak daha uzun süreli sertifikaları reddettiği için sunucu sertifikalarını 825 gün ile sınırlandırın. İki yıllık (-days 730) uç sertifikalara sahip on yıllık bir özel kök sertifika makul bir varsayılandır; yenileme işlemini takviminize kaydedin, çünkü süresi dolmuş bir dahili sertifika, kimsenin hatırlamadığı bir tarihte tüm sistemleri sessizce devre dışı bırakır.

Kendi kendine imzalanmış bir sertifika mı yoksa Let's Encrypt mi kullanmalıyım?

Servisin genel bir DNS adına sahipse ve internetten erişilebiliyorsa, her zaman Let's Encrypt kullanın; ücretsizdir, otomatiktir ve tüm istemciler tarafından halihazırda güvenilmektedir. Kendi kendine imzalanmış (veya özel bir CA) sertifikalar, Let's Encrypt'in oluşturamadığı durumlar içindir: özel IP'ler, .lan gibi yalnızca dahili olan ana bilgisayar adları, hava boşluklu (air-gapped) ağlar ve kasıtlı olarak bir VPN arkasına gizlenmiş servisler. Karar verme süreci erişilebilirlik ve isimlendirme ile ilgilidir, güvenlik gücüyle ilgili değildir; kriptografi aynıdır.

Üç durumu kontrol edin. Dosya .crt ile bitmelidir; .pem uzantısı sessizce atlanır ve update-ca-certificates 0 added hatası verir. İçerik, DER ikili formatı değil, -----BEGIN CERTIFICATE----- ile başlayan PEM metni olmalıdır. Ayrıca uygulama sistem deposunu kullanmalıdır; Linux üzerindeki Chrome, Firefox, Python requests, Node.js ve Java her biri kendi özel güven deposuna sahiptir ve sertifikanın her birine ayrı ayrı eklenmesi gerekir.

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