Kök sertifika kullanımını bir etki alanı ile sınırlandırmak mümkün mü


28

Müşterim, bir uygulamanın çalışması için kendinden imzalı bir sertifika kullanıyor. Çalışabilmek için, sertifikayı imzalamak için kullandıkları kök sertifikayı yüklemem gerekiyor.

Bir kök sertifikasını yalnızca bir etki alanına doğrulayacak şekilde yapılandırmak mümkün mü?


Sadece ben olabilirim, ama gerçekte ne sorduğun belli değil. Hangi son durumu başarmaya çalışıyorsunuz? Kök sertifikalarını etki alanı denetleyicilerinin güvenine içe aktarırsanız, yalnızca bu etki alanı altındaki sistemler buna karşı doğrulayabilir ...
Gravy

Genel olarak güvenilir olmayan bir kök CA kullanarak kendinden imzalı sertifikaları karıştırıyor gibisiniz. Kendinden imzalı bir sertifika kullanacak şekilde yapılandırılmış bir uygulama, sertifika doğrulama hatalarını yoksaymak üzere yapılandırılması gerekeceğinden, çok kötüdür. Genel olarak güvenilmeyen bir kök CA kullanmak aslında oldukça yaygındır.
Greg Askew

dahili bir CA sunucunuz var mı?
Crypt32

1
Bir CA, kendisini ad kısıtlamaları olan belirli etki alanları ile sınırlayabilir , ancak başkalarının CA'sına geriye dönük olarak kısıtlamalar uygulamak farklı bir konudur.
Matt Nordhoff

3
fark yok. Üçüncü taraf bir CA'ya da ad kısıtlamaları uygulayabilirsiniz. Özel CA'nızı kullanarak 3. taraf kök CA sertifikasını imzalamanız ve oluşturulan çapraz sertifikayı yayınlamanız yeterlidir. Bu durumda, yabancı zincir kısıtlı çapraz sertifika ile özel zincirinize ulaşacaktır.
Crypt32

Yanıtlar:


24

Kural olarak:

Hayır , müşterinin CA sertifikasına güvenmek, söz konusu CA tarafından imzalanan her sertifikanın güvenidir.

Son kullanıcı olarak müşterilerinize veya herhangi bir diğer CA sertifikasına yalnızca belirli (alt) alanlar için, yani yalnızca * için güveneceğinizi seçmenizi sağlayan kolay bir seçeneğe sahip uygulamaları / kütüphaneleri bilmiyorum. example.com ve * .example.org ve başka hiçbir şey.

Mozilla, şu anda güvenilir olan devlet destekli CA'lar hakkında açık bir ilgi noktası olarak benzer bir endişeye sahiptir ve örneğin, Chrome , Google sitelerine erişmek için yerleşik olarak yapılan ek denetimlere sahiptir; bu, * .google.com sertifikasının ve Diginotar CA'nın uzlaşmasının nasıl halka açık hale getirileceğini .

Ancak, CA'ya güvenmese bile, söz konusu CA tarafından imzalanan belirli bir sunucu sertifikasını içe aktarabilir / güvenebilirsiniz; bu, söz konusu sertifikadaki ana bilgisayar adları için SSL uyarılarını önler. Bu, uygulamanızın hatasız veya şikayetsiz çalışmasını sağlamalıdır.

İstisnalar:

X.509v3 PKI standardının çok az kullanılmış bir seçeneği, bir CA sertifikasının, sertifika verilmesine izin verilen alan adı desenlerinin beyaz ve kara listelerini içermesine izin veren Ad Kısıtlamaları uzantısıdır.

Şanslı olabilirsiniz ve müşteriniz PKI altyapısını oluşturduklarında ve bu Ad kısıtlamasını CA sertifikalarına eklediklerinde kendilerini sınırlamış olabilirler. Ardından, CA sertifikalarını doğrudan içe aktarabilir ve yalnızca sınırlı sayıda etki alanı adını doğrulayabildiğini bilirsiniz.


2
@CryptoGuy: Bir dahili CA, dış alanlar için sertifika da verebilir. Dahili CA'nıza güvendikten sonra, yalnızca kendi (Active Directory veya DNS) etki alanınız için sertifikaların geçerli olduğu example.comveya *.ad.example.comgeçerli olmadığı konusunda hiçbir kısıtlama yoktur . Dahili CA'nız aynı zamanda *.example.bankortada güzel bir saldırıya izin vermek ve çevrimiçi bankacılık bilgilerinizi susturmak için sertifikalar verebilir .
HBruijn

1
"Her şey" tam olarak doğru değil. Sertifika iptal listeleri gibi şeyler var. Ancak bu, alt çizgiyi değiştirmiyor.
Ben Voigt

1
üzgünüm yine yanlışsın. 3. taraf CA'yı, istediğiniz ad listesine verilen sertifikalara (o CA'dan) güvenmesi için kısıtlayabilirsiniz. Kendi iç CA'nızla ilgili olarak, güvenimi hiç şüphesiz kabul ediyorum. Kendi CA'nıza güvenmiyorsanız, BT'nizde bir sorun var demektir. Özel bir CA'ya sahip olmakla, OP'nin 3. taraf bir CA'ya (güvendikleri isimleri sınırlayarak) kısmi bir güven sağlayabildiğini söylemek istiyorum.
Crypt32

3
Düzenlenen yayınınıza: 3. taraf CA'nın Ad Sınırlamaları uzantısı olmasa bile, bunları kendi sertifika sertifikaları aracılığıyla kendi CA CA sunucunuzu kullanarak uygulamak mümkündür. Bu durumda, sertifika zinciri aşağıdaki gibi olacaktır: leaf SSL cert -> çapraz sertifika -> CA sertifikanız -> dahili kök sertifikanız. İşin püf noktası, dahili CA'nızı kullanarak 3. taraf CA'yı imzalamanızdır. Ve çapraz sertifika gerekli tüm kısıtlamalara sahip olacaktır.
Crypt32

1
CryptoGuy bunun mümkün olduğunu söylüyor, ancak uygulama detaylarını bulmak zor. Bunun nasıl gerçekleştirilebileceğini açıklayan bir cevaba ne dersiniz? Ve belki de hangi platformların nameConstraints'i desteklediğinin bir tartışması.
jorfus

17

@CryptoGuy'un burada oldukça iyi bir cevabı vardı, fakat üzerinde genişlemek istedim.

Kelimeleri ifade etmek:

3. taraf CA'yı, istediğiniz ad listesine verilen sertifikalara (o CA'dan) güvenmesi için kısıtlayabilirsiniz. 3. parti CA'nın Adı Sınırlamaları uzantısı olmasa bile, kendi dahili CA sunucunuzu çapraz sertifikalandırma yoluyla kullanarak uygulamak mümkündür. İşin püf noktası, dahili CA'nızı kullanarak 3. taraf CA'yı imzalamanızdır.

yaprak SSL sertifikası -> çapraz sertifika -> CA sertifikanız -> dahili kök sertifikanız.

Ve işte bu işlemi nasıl yapıyorsunuz (OpenSSL komut satırını CA kullanarak)

Basit bir CA oluşturun

openssl req -new -x509 -days 3650 -newkey rsa:2048 -sha256 -out root-ca.crt -keyout root-ca.key -subj "/CN=My Root CA"

Bir ara CA oluşturmayı atlayabilirsiniz

Ad Kısıtlamaları ile bir ara CA isteği oluşturun.

openssl req -new -days 3650 -newkey rsa:2048 -out domain-ca.req -sha256 -keyout domain-ca.key -config ossl_domain_com.cfg

Bununla birlikte ossl_domain_com.cfgdosyada:

[ req ]
prompt=no
distinguished_name=req_distinguished_name
req_extensions=domain_ca

[ req_distinguished_name ]
CN=somedomain.com trust CA

[ domain_ca ]
basicConstraints=critical,CA:true,pathlen:1
nameConstraints=critical,permitted;DNS:.somedomain.com

Ardından, Intermediate domain CA'yı CA'nızla işaretleyin.

openssl x509 -req -in domain-ca.req -CA root-ca.crt -CAkey root-ca.key -sha256 -set_serial 1 -out domain-ca.crt -extensions domain_ca -extfile ossl_domain_com.cfg

Bir ara oluşturmayı atladıysanız, imzalamak için kök CA'nızı kullanın.

Şimdi, orijinal alan adının CA'sını, sertifikasını kullanarak kendi yetkiniz altında tekrar imzalayın. CA uzantılarını buraya ekleyebilirsiniz.

openssl x509 -in third_party_ca.crt -CA domain-ca.crt -CAkey domain-ca.key -set_serial 47 -sha256 -extensions domain_ca -extfile ossl_domain_com.cfg -out domain-cross-ca.crt

-x509-to-reqYukarıdaki aracı ile aynı şekilde imzalayacağınız bir istek oluşturmak için argümanı kullanmanız gerekebilir .

Şimdi, kök CA'nızı, orta CA'yı ve domain-ca'yı tarayıcınızın güven veritabanına ekleyin.


2
MacOS nameConstraints'i desteklemiyor. Sadece bir ad üzerinde çalışan herkes için dahili CA'yla kısıtlı. security.stackexchange.com/questions/95600/… archive.is/6Clgb
jorfus

S: Bu çözümün durumu nedir? Günümüzde hangi sistemler çalışıyor (2018)? // Bunu, her zaman başka bir şirketin kendinden imzalı bir sertifikayı kurmak zorunda kaldığımda istedim; ve her zaman Hong Kong Postanesi veya Symantec'i düşünüyorum. // Kötülüğün olmamasına dikkat etmeyebileceğimi düşünüyorum, yanlışlıkla genişletmeyi uygulamadıkları sürece, tarif edilen daralmayı uygular.
Krazy Glew

@KrazyGlew Bunun için kullandığım bir toplu iş dosyasına sahibim ve hala düzenli olarak kullanıyorum. Zaman zaman ara sertifikalarını süresi dolaştıkça ya da döndürdükçe yeniden düzenlemeliyim, bu yüzden biraz daha el ile, ancak bir sorun olmadı. Ara sıra, tarayıcımın farklı bir ara Otorite veya ekledikleri ek bir alan adı nedeniyle benimkine güvenmediği için güvenmediği otorite tarafından yönetilen sitelerde rastlarım.
davenpcj

2
Sadece başarıyla kullandım, teşekkürler. Orta sertifika olmadan harika çalışıyor, birini kullanmanın bir avantajı var mı? Ayrıca, basicConstraintsyapılandırma dosyasındaki satır kısıtlama uzantısının sertifikaya iki kez dahil edilmesine neden olur ve bu da Firefox’un sertifikayı şifreli bir hata mesajı ile reddetmesine neden olur. Bence güvenle kaldırılabilir.
wrtlprnft

Ben son adımda bir hata alıyorum: error with certificate to be certified - should be self signed. Ne anlama geliyor ve bunu nasıl çözersiniz? pastebin.ubuntu.com/p/QHhpQh2N6J
mymedia
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.