Ubuntu 24.04 Self-Signed TLS Sertifikası Oluşturma

Ne inşa ediyorsunuz

Modern tarayıcıların ve istemcilerin gerçekten kabul ettiği, doğru subjectAltName yapılandırılmış, makul anahtar izinlerine sahip, nginx veya Apache ile entegre edilmiş bir self-signed TLS sertifikası. Ayrıca çoğu kılavuzun atladığı o kritik nokta: uyarıları geçmek veya curl -k değerini betiklere kalıcı olarak gömmek yerine, istemcilerinizin bu sertifikaya düzgün bir şekilde güvenmesini sağlamak. Son aşamada, tek bir iç servis altıya çıktığında kullanabileceğiniz beş komutluk bir özel CA kurulumu.

Öncelikle karar aşaması; çünkü self-signed sertifikalar, kullanıldıkları sıklıktan çok daha az durumda 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 karşılığı kurulumuna geçin. Bu yöntem ücretsizdir, kendini yeniler ve dünyadaki tüm tarayıcılar 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 gelip tıklamaya alıştırır ki 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'nizdeki bir WireGuard tünel adresine bağlı bir yönetim paneli, özel bir ağdaki hazırlık (staging) sunucusu, arka uçlar arasındaki servisler arası trafik, bir ev laboratuvarı cihazı veya Webmin'in 10000 numaralı portta kendisi için 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 (doğrulamak için openssl version) ile gelen yeni 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 rehberlerde verilen 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ı olmayan bir sertifika üretir. Bu sertifika oluşturulduğu anda geçersizdir. Chrome, 58 numaralı sürümünde (Nisan 2017'de) Common Name alanını okumayı bırakmıştır; RFC 2818 ise CN eşleştirmesini zaten 2000 yılında kullanımdan kaldırmıştır. Firefox, Safari, curl ve Python da aynı şekilde davranır. Bir sertifika, sunucusunu SAN uzantısı aracılığıyla tanımlar; aksi takdirde tanımlayamaz. 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ıyla karşılaşıyorsanı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, imzalama isteği yerine doğrudan kendinden imzalı bir sertifika üretir.
• -newkey rsa:4096, aynı adımda yeni bir anahtar oluşturur. RSA 4096 eski istemcilerle uyumluluk sorunu yaratmaz; eğer 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: anahtar üzerinde parola koruması olmaz. Her iki yazım da çalışır. Parola korumalı bir anahtar, nginx'in her açılışta girdi beklemesine ve askıda kalmasına neden olur; sunucu anahtarı için bu bayrak gereklidir.
• -days 730, iki yıl; bu süreyle ilgili 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 alan adını girin; 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: girişleri (DNS:*.internal.lan gibi joker karakterler kullanılabilir), adresler için IP: girişleri. Eğer herhangi biri 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, kullanıcıya tekrar NET::ERR_CERT_COMMON_NAME_INVALID hatası verecektir.

Herhangi bir bağlantı kurmadan önce SAN'ın sertifikaya işlendiğ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ıyorsanız, sertifikada SAN yoktur ve tarayıcılar bunu reddedecektir; devam etmeden önce sertifikayı yeniden oluşturun.

Anahtarı kilitleyin

Sunucudaki her kullanıcının okuyabildiği bir özel anahtar, artık özel bir anahtar değildir. Ubuntu üzerinde /etc/ssl/private zaten 710 root:ssl-cert olarak yapılandırılmıştır; bu durum sıradan gözleri uzak tutsa da dosya izinlerini açıkça 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 kullanıcısı olarak okur; bu nedenle root:root 600 modu onlar için uygundur. Eğer anahtar, kendi kullanıcısı ile çalışan ve anahtarı doğrudan yükleyen bir servis (Node uygulaması, Gitea, Python daemon gibi) içinse, chown komutuyla sahipliği ilgili servis kullanıcısına verin ve yine 600 modunu kullanın. Asla yapmamanız gerekenler: 644 modu, git deposunda bir kopya bulundurmak veya /tmp dizininde bir kopya tutmaktı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ış çözümlerden ve bunların neden hatalı olduğundan bahsedelim. Bir betiğin içine gömülen curl -k (veya --insecure), Python requests içindeki verify=False veya Node içindeki NODE_TLS_REJECT_UNAUTHORIZED=0, sertifikanızın güvenilir olmasını sağlamaz. Bu komutlar 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 sorunsuzca 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ılmacıdır: önce bir cron işine, sonra bir dağıtım betiğine, en sonunda da üretim koduna yapıştırılır ve bir süre sonra hangi bağlantıların geçici olması gerektiği unutulur. 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ıdaki önemli satır (bunu bir Running hooks in /etc/ca-certificates/update.d... bloğu takip eder):

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

Bu satırlarda iki kritik nokta gizlidir. 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ı ve dosya -----BEGIN CERTIFICATE----- ile başlamalıdır; 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 sertifika olarak eklemek işe yarar çünkü kendinden imzalı bir sertifika kendi köküdür.

Bundan sonra curl, wget, git, apt ve sistem paketini kullanan diğer tüm OpenSSL tabanlı araçlar, hiçbir bayrağa gerek duymadan sunucuya güvenir. Kendi güven depolarını taşıyan bazı istemciler ise özel işlem gerektirir:

• Linux üzerinde Chrome/Chromium, sistem deposunu değil 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 yolunu izleyin 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 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: NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/git.internal.crt değişkenini dışa aktarı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 (Anahtar Zinciri Erişimi) içindeki System anahtar zincirine ekleyin ve Her Zaman Güven (Always Trust) olarak işaretleyin.

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

Sertifika bazlı güven yönetimi ölçeklenemez: altı servis ve dört istemci makine, yirmi dört adet güven kurulumu demektir; her yeni servis bu sayıyı daha da 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, Ubuntu 24.04 depolarında bulunan ve update-ca-certificates aracının atladığı NSS depolarını (Chrome, Firefox) 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 makinedeki tüm güven depolarına kaydeder; üçüncü komut ise 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. Tasarım amacı bir geliştirme makinesidir; kök anahtar -install komutunu çalıştıran makinede tutulur. Bu nedenle geliştirme dizüstü bilgisayarları için idealdir ancak sunucu filoları için uygun değildir.

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, dikkatle eklediğiniz SAN dahil olmak üzere CSR içindeki tüm uzantıları siler. -copy_extensions copy (OpenSSL 3.x seçeneği olduğundan 24.04 üzerinde çalışır) bu uzantıları korur; bu seçeneği atlarsanız 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 openssl x509 -noout -ext subjectAltName ile yapın.

lab-ca.crt dosyasını istemcilere yukarıdaki güven deposu adımlarıyla, her makine için yalnızca bir kez dağıtın. lab-ca.key dosyasını ise artık bir mücevher gibi koruyun: 600 modunda tutun ve ideal olarak imzaladığı sunuculardan farklı bir makinede saklayın; çünkü bu dosyaya sahip olan kişi, istemcilerinizin güveneceği herhangi bir isim 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 dizgeler

NET::ERR_CERT_AUTHORITY_INVALID, güveni tesis etmeden önceki beklenen durumdur, sertifikada bir kusur değildir. Kök sertifikayı yükledikten sonra devam ediyorsa: Linux üzerinde Chrome, sistem deposu yerine NSS'i okuyordur (bkz. certutil adımı); veya kopyalanan dosya .crt ile bitmiyordur ve update-ca-certificates, 0 added hatası vermiştir; ya da sunucu güvendiğinizden farklı bir sertifika sunuyordur, 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 bulunmuyor veya SAN, adres çubuğundaki ismi kapsamıyor. Klasik durum: SAN içerisinde DNS:git.internal.lan listeleniyor ancak kullanıcı https://10.8.0.1 adresine gidiyor. Güven deposu değişiklikleri bunu düzeltemez; eksik girişle yeniden düzenleyin.

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

unable to load certificate ... Expecting: TRUSTED CERTIFICATE (veya Expecting: CERTIFICATE REQUEST, ya da no start line), PEM karmaşası. OpenSSL'e sertifika beklediği yerde yanlış türde bir dosya verdiniz: anahtar veya CSR dosyası ya da PEM beklediği yerde DER ikili dosyası. head -1 filename elinizde ne olduğunu söyler, bir sertifika -----BEGIN CERTIFICATE----- ile başlar. DER 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ğil; genellikle oluşturma komutu iki kez çalıştırıldığında ve dosyalar karıştığında oluşur. openssl x509 -in git.internal.crt -noout -pubkey | sha256sum ile openssl pkey -in git.internal.key -pubout | sha256sum karşılaştırması yaparak doğrulayın; eşleşen hash değerleri, eşleşen bir çift anlamına gelir. Farklılarsa, her ikisini birlikte yeniden oluşturun.

FAQ

Kendi imzaladığım sertifikayı oluşturmama rağmen Chrome neden hala "Güvenli değil" uyarısı veriyor?

Hata NET::ERR_CERT_AUTHORITY_INVALID ise sertifika düzgündür, ancak Chrome'un ona güvenmesi için henüz bir neden 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ı kullandığını unutmayın. Hata NET::ERR_CERT_COMMON_NAME_INVALID ise sertifika, URL ile eşleşen bir Subject Alternative Name (SAN) içermiyordur ve -addext "subjectAltName=..." ile yeniden düzenlenmesi gerekir.

-k bayrağını kullanmadan curl ile kendi imzaladığım bir sertifikaya nasıl güvenebilirim?

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. Bu işlemden sonra curl, sertifikayı genel bir sertifika gibi doğrular. Sistemi etkilemeyen 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 script içerisinde 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) yalnızca genel güvenilir CA'ları bağlar, özel güven yapılarını değil. Uygulamada, sunucu sertifikalarını 825 gün ile sınırlayın; çünkü Apple cihazları, düzenleyen 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 not edin; süresi dolmuş bir dahili sertifika, kimsenin hatırlamadığı bir tarihte tüm sistemi sessizce devre dışı bırakır.

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

Eğer servisin genel bir DNS adı varsa ve internetten erişilebiliyorsa, her zaman ücretsiz, otomatik ve tüm istemciler tarafından güvenilen Let's Encrypt kullanılmalıdır. Kendi imzaladığınız sertifikalar (veya özel bir CA), Let's Encrypt'in düzenleyemediği durumlar içindir: özel IP adresleri, .lan gibi yalnızca dahili kullanılan ana bilgisayar adları, internete kapalı ağlar ve bilinçli olarak VPN arkasına gizlenmiş servisler. Bu karar erişilebilirlik ve isimlendirme ile ilgilidir, güvenlik gücü ile değil; kriptografi her iki durumda da aynıdır.

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

Üç noktayı kontrol edin. Dosya .crt ile bitmelidir; .pem uzantısı sessizce atlanır ve update-ca-certificates komutu 0 added çıktısını verir. İçerik, DER ikili formatı değil, -----BEGIN CERTIFICATE----- ile başlayan PEM metni olmalıdır. Ayrıca uygulamanın sistem deposunu gerçekten kullanıyor olması gerekir; Linux üzerinde Chrome, Firefox, Python requests, Node.js ve Java'nın her biri kendi özel güven deposunu tutar ve sertifikanın her birine ayrı ayrı eklenmesi gerekir.