Komut şudur: curl -k. Eğer gerçekten tek ihtiyacınız olan buysa, burada durabilirsiniz.
Bu makalenin geri kalan kısmının yazılmasının nedeni şudur: -k komutu, sertifika sorununu çözmez — sadece sorunu tespit eden kontrolü devre dışı bırakır. curl'un kendi belgeleri bu konuda alışılmadık derecede açık ve net; "kesinlikle bundan kaçınılmasını tavsiye ediyor" ve "üretim ortamında asla doğrulamayı atlamamanız gerektiğini" belirtiyor. Bu vurgu onlara ait, bize değil.
Biz Geonode adresindeyiz ve proxy satıyoruz; dürüstçe belirtmek gerekirse, bu sorunun ürünümüzle neredeyse hiçbir ilgisi yoktur. Sertifika hataları, makineniz, makinenizin güven deposu ve sunucu arasında ortaya çıkar. Tek bir istisna vardır — kurumsal bir ağdaki bir ara proxy, bu hatanın en yaygın nedenlerinden biridir ve aşağıda buna ayrılmış bir bölüm bulunmaktadır — ancak ne bizden ne de başkalarından bir şey satın alarak sertifika hatasını çözemezsiniz.
Zaman ayırmaya değer olan şey, tanıdır. Sertifika hatalarının az sayıda belirli nedeni vardır ve bunların çoğu için -k yazmak kadar kısa süren ve doğrulamayı açık bırakan bir çözüm vardır. Eksik bir ara sertifika, güncel olmayan bir CA paketi, curl'ün tanımadığı bir kurumsal kök sertifika, süresi dolmuş bir sertifika, bir ana bilgisayar adı uyuşmazlığı. Her birinin kendine özgü bir belirtisi ve kendine özgü bir çözümü vardır.
Düşünmeden -k komutuna başvurmanın pratik riski soyut değildir. Bu risk, bayrağın bir komut dosyasına kopyalanması, komut dosyasının üretim ortamına geçmesi ve gerçek bir ele geçirme sorununu yakalayabilecek bir kontrolün artık çalışmamasıdır — üstelik bunun devre dışı bırakıldığını kimsenin hatırlamadığı bir ortamda.
Aşağıda curl'ün davranışıyla ilgili her şey, curl'ün kendi SSL sertifika belgelerinden ve curl kitabından alınmıştır.
Herkesin Aradığı Komut
İşte burada, çeşitli seçenekleriyle birlikte.
# Skip verification of the server's certificate
curl -k https://example.com
# Same thing, long form
curl --insecure https://example.com
# Skip verification for the proxy's certificate as well
curl -k --proxy-insecure -x https://proxy.example.com:8080 https://example.com
,
-k
ve --insecure
aynı seçeneği ifade eder. --proxy-insecure
ise ayrı bir seçenektir ve hedef sunucunun değil, HTTPS proxy’sinin kendi sertifikasını doğrular — bunlar birbirinden bağımsız iki doğrulama işlemidir ve birinin devre dışı bırakılması diğerini devre dışı bırakmaz.
Hatayı Sessize Almadan Önce İnceleyin
Bayrağı kullanmadan önce, on saniyenizi ayırarak asıl sorunun ne olduğunu belirleyin:
curl -v https://example.com
Ayrıntılı çıktı, TLS el sıkışmasını ve doğrulamanın başarısız olmasının spesifik nedenini gösterir. "Yerel sertifika veren sertifikası alınamıyor" hatası, "sertifikanın süresi doldu" hatasından çok farklıdır; bu da ana bilgisayar adı uyuşmazlığından farklıdır — ve her biri farklı bir çözüm gerektirir.
Sunucunun gerçekte sunduğu sertifikaya daha ayrıntılı bir bakış:
curl -vI https://example.com 2>&1 | grep -A 20 "Server certificate"
Bu komut, konu, düzenleyici ve geçerlilik tarihlerini gösterir. Çoğu zaman cevap hemen ortadadır: sertifikanın süresi geçen Salı günü dolmuştur, farklı bir ana bilgisayar adı için düzenlenmiştir ya da düzenleyici, daha önce hiç duymadığınız bir kuruluştur — bu da genellikle trafiğinizin bir şekilde ele geçirildiğini gösterir.
Kazanılması Gereken Bir Alışkanlık
Önce teşhis koyun, sonra karar verin. -k
, kontrolünüz altındaki bir sunucuya karşı tek seferlik bir test yapmak için meşru bir araçtır. Ancak bu, bir sonuçtan ziyade refleks haline geldiğinde sorun yaratır; çünkü komut, neyi engellediği konusunda hiçbir bilgi vermez.
-k Seçeneği Aslında Neleri Devre Dışı Bırakır?
Çoğu kişinin sandığından daha fazlasını devre dışı bırakır ve işte bu kısmı iyice kavramaya değer.
Varsayılan olarak, curl belgelerine göre, curl sertifika doğrulamasını “imzayı doğrulayarak ve sertifikanın URL’de belirtilen sunucu adı için oluşturulduğundan emin olarak” gerçekleştirir.
Bu cümle iki ayrı kontrolü tanımlar ve -k her ikisini de devre dışı bırakır.
Birinci Kontrol: İmza Zinciri
Bu sertifika, sisteminizin güvendiği bir sertifika yetkilisine kadar uzanan bir zincir oluşturuyor mu? Bu, sertifikanın, OpenSSL kurulu olan herhangi bir kişi tarafından beş dakikada oluşturulmuş değil, tanınmış bir sertifika yetkilisi tarafından verildiği kanıtıdır.
Bu kontrol yapılmazsa, herhangi bir sertifika kabul edilir. Sizinle sunucu arasında bulunan herhangi bir kişi tarafından oluşturulan kendi kendine imzalanmış bir sertifika, gerçek bir sertifika yetkilisinden alınan bir sertifika kadar kolayca kabul edilir.
İkinci Kontrol: Ana Bilgisayar Adı
Bu sertifika, gerçekten de talep ettiğiniz ana bilgisayara ait mi? attacker.example için geçerli ve usulüne uygun olarak düzenlenmiş bir sertifika, yine de bank.example için bir sertifika değildir ve ana bilgisayar adı kontrolü bunu sağlar.
Bu kontrol yapılmazsa, herhangi bir etki alanı için gerçek bir sertifika, herhangi bir bağlantı için kabul edilir.
Geriye Kalanlar
Bağlantı hâlâ şifrelenmiştir. TLS hâlâ bir şifreleme algoritması üzerinde anlaşmaya varır ve trafik, ağ üzerinde düz metin olarak iletilmez.
Ancak kimlik doğrulaması yapılmayan şifreleme, sizi pasif bir gözlemciden korur, aktif bir gözlemciden değil. Curl kitabı, bunun sonucunu açıkça ortaya koyar: doğrulama seviyesi düşürüldüğünde, “iletişiminiz Ortadaki Adam (Man-In-The-Middle) saldırılarına maruz kalabilir”. Bağlantıyı ele geçirebilecek konumda olan herhangi biri kendi sertifikasını sunabilir, TLS bağlantınızı sonlandırabilir, her şeyi okuyup değiştirebilir ve bundan sonra ayrı bir bağlantı açabilir. Kilit simgesinin gösterdiği şifrelemeyi görürsünüz, ancak bunun hiçbir anlamı kalmaz.
Bu Durum Neden Komut Dosyalarında Daha Önemlidir?
Etkileşimli olarak, -k yazdığınızı ve bunun nedenini bilirsiniz. Bir komut dosyasında ise, bu bayrak, nedeni unutulduktan çok sonra bile kalıcı olur. Kimlik bilgileri bu bayrak aracılığıyla gönderilir. Veriler bu bayrak üzerinden geri gelir ve güvenilir kabul edilir.
Otomasyonda bunu kullanmanız gerekiyorsa, nedenini ve kaldırmak için nelerin değiştirilmesi gerektiğini belirten bir yorum bırakın. Bu tek satır, düşünülmüş bir karar ile görünmez bir karar arasındaki farkı oluşturur.
Bu Hatayı Neden Görüyorsunuz?
Beş neden, bu durumun neredeyse tamamını kapsar; her birinin ayrıntılı çıktıda kendine özgü bir izi vardır.
1. Eksik Ara Sertifika
En yaygın neden budur ve bu, sizin tarafınızdaki bir sorun değil, sunucudaki bir yapılandırma hatasıdır.
Sertifika zinciri: Sunucunun sertifikası, sisteminizin güvendiği bir kök sertifika tarafından imzalanmış bir ara sertifika otoritesi tarafından imzalanır. Sunucunun kendi sertifikasının yanı sıra ara sertifikaları da göndermesi gerekir. Yalnızca kendi sertifikasını gönderirse, istemciniz zinciri tamamlayamaz.
Tarayıcılar genellikle eksik ara sertifikaları otomatik olarak getirerek veya önceki ziyaretlerden önbelleğe alarak bu sorunu örtbas eder. curl ise bunu yapmaz. Dolayısıyla, karakteristik belirti, bir sitenin tarayıcıda mükemmel çalışıp curl'da çalışmamasıdır — ve sunucu gerçekten yanlış yapılandırılmıştır; tarayıcı ise hoşgörülü davranmaktadır.
Çözüm: Sunucuyu yöneten kişiden tam zinciri yapılandırmasını isteyin. Sunucu size aitse, bu değişiklik beş dakika sürer ve tarayıcı dışındaki tüm istemcilerin sorununu tek seferde çözer.
2. Güncel Olmayan CA Paketi
Sisteminizin güvenilir sertifika yetkilileri listesi güncel değildir, bu nedenle meşru bir şekilde verilmiş bir sertifika tanınmamaktadır. Eski sistemlerde, minimal konteyner görüntülerinde ve uzun ömürlü sanal makinelerde sık görülür.
Çözüm: Sistemin CA sertifikaları paketini güncelleyin.
3. Kurumsal TLS Denetimi
Kuruluşunuzun ağı, trafiği şifresini çözer ve yeniden şifreler; bu sırada kendi sertifikasını sunar. Aşağıda buna ilişkin ayrı bir bölüm bulunmaktadır.
4. Kendi Kendini İmzalayan Sertifika
Geliştirme sunucuları, dahili araçlar, cihazlar. Sertifika kendi kendini imzaladığı için zincirlenecek bir sertifika yetkilisi yoktur.
Çözüm: Doğrulamayı genel olarak devre dışı bırakmak yerine, curl komutunu --cacert ile açıkça bu sertifikaya yönlendirin.
5. Gerçekten Süresi Dolmuş veya Yanlış Sertifika
Bazen kontrol doğru sonuç verir. Sertifikanın süresi dolmuştur, farklı bir ana bilgisayar adı için verilmiştir veya site gerçekten yanlış yapılandırılmıştır.
Çözüm: Siteyi yöneten kişiye durumu bildirin. Burada -k komutunu kullanmak, doğru bilgileri kasten görmezden gelmek anlamına gelir.
Ayrıntılı Çıktıyı Okuma
"Yerel sertifika verenin sertifikası alınamıyor" mesajı, neden 1, 2 veya 3'e işaret eder. "Sertifikanın süresi dolmuş" mesajı neden 5'e karşılık gelir ve yorumlanmasına gerek yoktur. Ana bilgisayar adı uyuşmazlığı da neden 5'e aittir. Tanıdık olmayan bir sertifika veren adı ise neden 3'e aittir ve geçici çözüm aramak yerine araştırmaya değer bir durumdur.
Tercih Sırasına Göre Çözümler
En iyiden en kötüye doğru. Aşağı doğru ilerleyin ve bir tanesi işe yaradığında durun.
1. Sunucuyu Düzeltin
Eğer sorun eksik bir ara sertifika ise ve sunucuyu siz kontrol ediyorsanız, tam zinciri yapılandırın. Bu, her istemci için sorunu kalıcı olarak çözer ve başkalarının deneyimini de iyileştiren tek çözümdür.
2. CA Paketinizi Güncelleyin
# Debian / Ubuntu
sudo apt-get update && sudo apt-get install --reinstall ca-certificates
# RHEL / Fedora
sudo update-ca-trust
# Alpine
apk add --no-cache ca-certificates && update-ca-certificates
Bu son adım, konteynerler içindeki sertifika hatalarının çok büyük bir kısmını çözer; çünkü minimal görüntüler genellikle CA paketi olmadan dağıtılır.
3. curl'u Doğru Sertifikaya Yönlendirin
Kendi kendine imzalanmış veya dahili bir sertifika için, bunu açıkça belirtin. Doğrulama devam eder — sadece curl'a bu bağlantı için neye güveneceğini söylemiş olursunuz.
# A specific CA certificate file
curl --cacert /path/to/ca.crt https://internal.example.com
# A directory of certificates
curl --capath /etc/ssl/certs https://internal.example.com
Bu, dahili hizmetler ve geliştirme ortamları için doğru cevaptır ve -k
komutundan neredeyse hiç daha fazla çaba gerektirmez. Aradaki fark, beklenmedik bir durum bağlantıyı kesintiye uğratırsa işlemin yine de başarısız olmasıdır; ki bu da doğrulamanın asıl amacıdır.
4. Ortam Değişkeninde Ayarlama
Tüm bir oturum veya konteyner için, curl belgelerinde “CURL_CA_BUNDLE
ortam değişkenini istediğiniz yola ayarlayarak kendi CA sertifika dosyanızı belirtebilirsiniz” ve “SSL_CERT_FILE
ile SSL_CERT_DIR
de desteklenmektedir” şeklinde belirtilmiştir.
export CURL_CA_BUNDLE=/path/to/corporate-ca-bundle.crt
curl https://example.com # verification on, using your bundle
Son iki değişken, çok sayıda başka araç tarafından da desteklenmektedir; bu da, araçları tek tek ayarlamak yerine tüm ortamı tek seferde düzeltmek için iyi bir yöntemdir.
5. Sertifikayı Sistem Deposuna Ekleyin
Sürekli karşılaşacağınız bir kurumsal kök sertifika varsa, bunu sistem düzeyinde bir kez yükleyin. Böylece makinedeki tüm araçlar normal şekilde çalışır.
# Debian / Ubuntu
sudo cp corporate-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
6. Ancak O Zaman, -k
Ve bunu yaparsanız, kapsamı olabildiğince dar tutun: tek bir komut, tek bir ana bilgisayar ve nedenini açıklayan bir açıklama.
Kurumsal TLS İncelemesi
İnsanların en çok kafa karıştırıcı bulduğu durum budur, çünkü görünürde bir sorun yok gibi görünür.
Neler Oluyor?
Birçok kuruluş, güvenlik ve uyumluluk amacıyla şifrelenmiş trafiği denetleyen ekipmanlar kullanır. TLS trafiğini okumak için şifresini çözmesi gerekir; bu da bağlantınızı sonlandırması, içeriği incelemesi ve kendi bağlantısını açması anlamına gelir.
Bunun, hiçbir tarayıcının şikayet etmeden çalışması için kuruluş, yönetilen makinelere kendi kök sertifikasını yükler. Tarayıcılar ve sistem uygulamaları bu sertifikaya güvenir, bu nedenle her şey normal görünür. Denetim cihazı, sertifika doğrulamanın tespit etmek için var olduğu tam da o müdahaleyi gerçekleştiriyor ve bunu yapmaya yetkilendirilmiştir.
Peki Neden curl Hata Veriyor?
curl, nasıl derlendiğine ve hangi TLS kütüphanesini kullandığına bağlı olarak sistem güven deposunu kullanmayabilir. Dolayısıyla, tarayıcınızın hiçbir uyarı vermeden kabul ettiği kurumsal kök sertifika, curl tarafından tanınmaz ve curl, zinciri doğrulayamadığını doğru bir şekilde bildirir.
Bunun ipucu, ayrıntılı çıktıda gizlidir: Sertifikanın düzenleyicisi, genel bir sertifika yetkilisi değil, kendi kuruluşunuz veya bir güvenlik sağlayıcısının adıdır.
Doğru Çözüm
Kurumsal kök sertifikasını dışa aktarın — bunu BT ekibiniz sağlayabilir veya bir tarayıcıdan çıkarabilirsiniz — ve yukarıdaki yöntemlerden birini kullanarak ekleyin. CURL_CA_BUNDLE bir kabuk oturumu için, günlük olarak kullandığınız bir makine için sistem deposu.
Bu, doğrulamanın çalışmaya devam etmesini sağlar. Her şeye güvenmek yerine, kuruluşunuzun kasıtlı olarak yüklediği ek bir yetkiliye güvenmiş olursunuz.
Yanlış Çözüm
Her yerde ve kalıcı olarak -k kullanın. Bu yöntem işe yarar, ancak bu durumda size bunu bildirecek tek mekanizmayı devre dışı bıraktığınız için gerçek anlamda kötü niyetli bir müdahaleyi fark edemezsiniz. Zaten meşru müdahalelerin yapıldığı bir ağda, bunları meşru olmayan müdahalelerden ayırt edebilmek, tam da korunması gereken yetenektir.
Konteynerler Hakkında Bir Not
Konteynerler, ana bilgisayarın güven deposunu devralmaz. Dizüstü bilgisayarınızda çalışan ancak kurumsal ortamda başarısız olan bir konteyner için genellikle kurumsal kökün görüntüye eklenmesi veya monte edilmesi gerekir — bu, derleme aşamasında uygulanacak bir çözümdür; Dockerfile’da doğrulamayı devre dışı bırakmak için bir neden değildir.
Proxy'ler ve TLS
Bu bizim uzmanlık alanımızdır ve esas olarak hangi sertifika hakkında şikayet edildiğini bilmekle ilgilidir.
İki Ayrı Doğrulama
curl komutunu bir HTTPS proxy üzerinden yönlendirdiğinizde, iki TLS bağlantısı ve iki bağımsız kontrol gerçekleşir.
Proxy ile olan bağlantınız. --proxy-insecure, --proxy-cacert ve ilgili seçeneklerle kontrol edilir.
Hedef ile olan bağlantı. -k, --cacert ve genel seçeneklerle kontrol edilir.
Bunları karıştırmak, zaman kaybına yol açan yaygın bir nedendir. Bir proxy yapılandırılmışken curl bir sertifika hatası veriyorsa, herhangi bir değişiklik yapmadan önce iki bağlantıdan hangisinin başarısız olduğunu belirleyin — ayrıntılı çıktı, bunları birbirinden ayırır.
Sıradan Bir HTTP Proxy'si Bu Soruna Neden Olmaz
Standart bir HTTP proxy'si ve bir HTTPS hedefi olduğunda, curl bir CONNECT isteği gönderir ve proxy bir tünel açar. Ardından, TLS el sıkışması sizinle hedef arasında uçtan uca gerçekleşir ve proxy sertifikayı göremez veya değiştiremez. Böyle bir proxy üzerinden sertifika hataları alıyorsanız, bunun nedeni proxy değil, daha önce bahsedilen sıradan nedenlerden biridir.
Sıradan bir proxy'nin HTTPS trafiğinizi okuyamamasının nedeni de budur. Şifrelenmiş baytları, bunları yorumlayamadan aktarır.
Engelleyici Proxy'lerde Durum Farklıdır
Bir proxy, HTTPS'yi denetleyecek şekilde yapılandırılmışsa, TLS'yi sonlandırır ve kendi sertifikasını sunar — bu, yukarıdaki kurumsal denetim örneğinin farklı bir kılıfı altındaki halidir. İmza aynıdır: ayrıntılı çıktıda tanınmayan bir sertifika veren.
Kural
Doğrulamayı devre dışı bırakmak yerine, proxy'nin sertifika yetkilisini ekleyin. Sebep öncekiyle aynıdır ve gereken çaba da aynıdır.
Sertifikalardan daha çok müşterilerimiz için önemli olan bir başka nokta: ana bilgisayar adı aramalarınızın proxy üzerinden mi yapıldığını yoksa yerel olarak mı çözümlendiğini kontrol edin. curl ile, socks5h:// komutu ana bilgisayar adını proxy’ye gönderirken, socks5:// komutu ise bunu makinenizde çözümler. Bu bir sertifika sorunu değildir, ancak proxy kurulumunun genellikle sahibinin amaçladığından farklı bir şekilde davranmasının bir başka örneğidir.
curl yerine kodda
Aynı karar her programlama dilinde karşımıza çıkar; genellikle varsayılan ergonomi açısından daha kötü bir durum söz konusudur.
Python'da
import requests
# Verification on, using a specific CA bundle — preferred
r = requests.get("https://internal.example.com", verify="/path/to/ca.crt")
# Verification off — equivalent to curl -k
r = requests.get("https://internal.example.com", verify=False)
requests
, doğrulama devre dışı bırakıldığında bir uyarı verir ve internetteki pek çok kod, bu uyarıyı ele almak yerine bastırır. Uyarıyı bastırmak, asıl sorundan çok daha kötüdür; çünkü bu, bir şeylerin olağandışı olduğuna dair kalan son işareti ortadan kaldırır.
requests
ayrıca REQUESTS_CA_BUNDLE
'yi de dikkate alır ve SSL_CERT_FILE
, Python ekosisteminde yaygın olarak desteklenir — bu nedenle, daha önce bahsedilen ortam değişkeni yaklaşımı genellikle tüm araç zincirini tek seferde düzeltir.
Node.js
// Preferred: supply the CA for this request
const https = require('https');
const fs = require('fs');
const agent = new https.Agent({ ca: fs.readFileSync('/path/to/ca.crt') });
// Avoid: disables verification for the entire process
// NODE_TLS_REJECT_UNAUTHORIZED=0
Bu ortam değişkeni özel bir uyarıyı hak ediyor. Bu değişken işlem genelinde geçerlidir; dolayısıyla, sizin yazmadığınız bağlantılar da dahil olmak üzere (bağımlılıklar, telemetri, paket indirmeleri) işlemin kurduğu her bağlantı için doğrulamayı devre dışı bırakır. Node, bu değişken ayarlandığında bir uyarı görüntüler. Bunun yerine NODE_EXTRA_CA_CERTS
komutunu kullanarak bir sertifika ekleyin; bu, yan etkiler yaratmadan asıl sorunu çözer.
Model
Her ekosistem hem hedefli bir seçenek hem de genel bir anahtar sunar. Hedefli seçenek birkaç karakter daha fazla yer kaplar ve açıkça muaf tutmadığınız her şey için doğrulama işleminin devam etmesini sağlar.
Genel anahtar ise, bir depoya eklenir, diğer üç hizmete kopyalanır ve iki yıl sonra bir kesintinin neden tespit edilemediğini araştırmaya çalışan biri tarafından keşfedilir.
Ne Zaman Görmezden Gelmek Aslında Sorun Değildir
Bu, yasaklardan oluşan bir bölüm değildir — gerçek durumlar vardır ve aksini iddia etmek, bu tavsiyenin kolayca göz ardı edilmesine yol açar.
Kendi başınıza başlattığınız yerel bir geliştirme sunucusu. Kendi makinenizde olduğu için diğer uçta ne olduğunu tam olarak biliyorsunuz. -k ile localhost arasındaki fark anlamlı bir risk oluşturmaz. Sertifikayı --cacert ile sağlamak yine de daha düzenli bir yöntemdir ve sadece birkaç saniye sürer.
Sertifikanın kendisini hata ayıklamaya çalıştığınız tek seferlik etkileşimli bir test. Başka bir yerde sertifika sorunu giderilirken isteğin geri kalan kısmının çalışıp çalışmadığını belirlemek, son derece makul bir kullanımdır.
Uçtan uca sizin kontrolünüz altında olan izole bir ağ; burada bir dinleyicinin yer alabileceği hiçbir yol yoktur. Pratikte nadir görülen bir durumdur ve bunun gerçekten doğru olup olmadığı konusunda kendinize dürüst olmanızda fayda vardır.
Sürekli yeniden oluşturulan, kendi imzalı sertifikalara sahip geçici test altyapısı üzerinde yapılan otomatik testler. Burada bile, genellikle sertifikayı işaret etmek mümkündür ve daha iyidir.
Ne Zaman Uygun Değildir
Üretim ortamındaki her şey. curl'un kendi belgeleri "asla" diyor ve haklıdır.
Kimlik bilgilerini gönderen her şey. Doğrulama olmadan, bunları kimin aldığını bilemezsiniz.
Yanıtına göre hareket edeceğiniz her şey. Doğrulama olmadan, yanıt yol üzerindeki herhangi biri tarafından yazılmış olabilir.
Kontrolünüz altında olmayan bir ağdaki her şey — halka açık Wi-Fi, bir müşterinin ofisi, paylaşımlı bir ortam.
Tekrarlayan bir hataya kalıcı çözüm olarak. Tekrarlayan bir hatanın bir nedeni vardır. Bu nedenin bir çözümü vardır. -k, bunu bulmamanın bir yoludur.
Tek Satırlık Test
Şunu sorun: Eğer şu anda biri bu bağlantıyı dinliyor olsaydı, bunu bilmek ister miydim?
Cevabınız evet ise, doğrulamayı açık tutun ve altta yatan nedeni giderin. Cevabınız gerçekten hayır ise — örneğin masanızdaki bir makineye gönderilen önemsiz bir istek — o zaman -k kullanabilirsiniz ve bu makale ihtiyacınız olandan daha uzun sürmüş demektir.
Sık Sorulan Sorular
curl'da SSL sertifika hatalarını nasıl görmezden gelebilirim?
curl -k https://example.com, veya uzun biçimi --insecure. Bir HTTPS proxy'sinin kendi sertifikası için ise --proxy-insecure komutu ayrıdır. curl belgeleri, bunu kullanmaktan kaçınmanızı ve üretim ortamında asla uygulamamanızı şiddetle tavsiye eder.
curl -k komutu aslında ne yapar?
Bu komut iki kontrolü devre dışı bırakır: sertifikanın güvenilir bir sertifika yetkilisine bağlı olup olmadığı ve bağlandığınız ana bilgisayar adı için düzenlenip düzenlenmediği. Bağlantı şifreli kalır ancak artık kimlik doğrulaması yapılmaz; bu da, tespit edemeyeceğiniz bir şekilde ele geçirilme riskine maruz kalabileceği anlamına gelir.
Tarayıcım sertifika hatası vermezken curl neden veriyor?
Genellikle sunucu ara sertifikalarını göndermediği içindir. Tarayıcılar eksik ara sertifikaları genellikle otomatik olarak alır veya önbelleğe alır; curl ise bunu yapmaz. Sunucu yanlış yapılandırılmıştır ve tarayıcı bu durumu görmezden gelmektedir. Ayrıca, tarayıcınızın curl'ün tanımadığı bir kurumsal kök sertifikasına güveniyor olması da mümkündür.
"Yerel sertifika veren sertifikası alınamıyor" hatasını nasıl düzeltebilirim?
Sırasıyla: sunucunun tam sertifika zincirini göndermesini sağlayın, sisteminizin CA sertifikaları paketini güncelleyin veya --cacert komutuyla curl'u doğru sertifikaya yönlendirin. Konteynerlerde bu sorun, çoğu zaman sadece ca-certificates paketinin eksik olmasından kaynaklanır.
curl'un kendi imzalı bir sertifikaya güvenmesini nasıl sağlarım?
curl --cacert /path/to/cert.crt https://internal.example.com. Doğrulama etkin kalır ve curl o bağlantı için söz konusu sertifikaya güvenir; bu, -k komutuna göre daha güvenlidir ve çok az ek çalışma gerektirir.
Tüm curl komutları için bir CA paketi ayarlayabilir miyim?
Evet. CURL_CA_BUNDLE seçeneğini paketinizin yoluna ayarlayın. curl ayrıca SSL_CERT_FILE ve SSL_CERT_DIR seçeneklerini de destekler; bu seçenekler diğer birçok araç tarafından da kabul edildiğinden, tüm ortamı tek seferde düzeltmek için iyi bir yoldur.
curl -k komutu trafiğimi hala şifreliyor mu?
Evet, bağlantı hala şifrelenmiştir. Ancak kimlik doğrulaması yapılmayan şifreleme, yalnızca pasif gözlemlere karşı koruma sağlar. Aktif bir dinleyici, herhangi bir sertifika sunabilir, her şeyi şifresini çözebilir ve iletebilir — ki doğrulama tam da bunu önlemek için vardır.
Docker konteynerinde curl -k komutunu kullanmak güvenli midir?
Genellikle buna gerek yoktur. Minimal temel görüntüler sıklıkla CA paketi olmadan dağıtılır; bu nedenle ca-certificates komutunu çalıştırarak sorunu düzgün bir şekilde çözebilirsiniz. Sorunun nedeni kurumsal bir kök sertifika ise, doğrulamayı devre dışı bırakmak yerine bu sertifikayı görüntüye ekleyin veya görüntünün içine monte edin.
Sonuç: `
`curl -k`` komutu tek bir tuş vuruşuyla çalışır. Bu komut, size bir sorunun olduğunu bildiren mekanizmayı devre dışı bırakır; ancak sorun hâlâ devam eder.
Öncelikle curl -v adresinde on saniye zaman ayırın. Sertifika hatalarının birkaç nedeni vardır ve her biri kendini açıkça belli eder. Eksik bir ara sertifika, açık ara en yaygın nedenidir ve bu, bir sitenin tarayıcıda çalışıp curl'da çalışmamasının neden olduğu kafa karıştırıcı durumu açıklar — tarayıcılar eksik parçaları getirir, curl ise getirmez ve sunucu gerçekten yanlış yapılandırılmıştır. Konteynerlerde ise çözüm, çoğu zaman sadece eksik bir ca-certificates paketidir.
Olağandışı bir şeye güvenmeniz gerektiğinde, buna özel olarak güvenin. Tek bir bağlantı için --cacert, bir ortam için CURL_CA_BUNDLE veya SSL_CERT_FILE, her gün kullandığınız bir makine için sistem deposu. Bunların her biri, doğrulamanın çalışmasını sürdürürken, curl’a kabul etmeye karar verdiğiniz ek bir yetki kurumu hakkında bilgi verir. Bunlar, -k adresinden birkaç saniye daha uzun sürer ve yolda beklenmedik bir şey ortaya çıkarsa yine başarısız olur; bu kontrolün var olmasının tek nedeni de budur.
Kurumsal ağlarda bunun nedeni genellikle TLS denetimidir — ve çözüm, denetimi durdurmak yerine kuruluşun kök sertifikasını eklemektir. Zaten yetkili dinleme gerçekleştirilen bir ağda, bunu yetkisiz dinlemeden ayırt edebilmek her zamankinden daha önemlidir, daha az değil.
Proxy'ler bu konuda büyük ölçüde yanıltıcıdır. Sıradan bir HTTP proxy'si, HTTPS trafiğini tüneller ve sertifikaya müdahale edemez; bir proxy üzerinden hata alıyorsanız, neden başka bir yerdedir. Biz proxy satıyoruz ve bu sorun için size satabileceğimiz hiçbir şey yok.
Ve “şu anda birinin bunu dinlediğini bilmek ister miydim” sorusunun cevabı hayırsa — kendi masanızdaki bir sunucuya gönderilen önemsiz bir istek — o zaman -k yeterli. Zarara neden olan, bayrak değil, reflekstir.
