Apakah mungkin untuk membatasi penggunaan sertifikat root ke domain

Pelanggan saya menggunakan sertifikat yang ditandatangani sendiri agar aplikasi dapat berfungsi. Agar dapat bekerja, saya harus menginstal sertifikat root yang mereka gunakan untuk menandatangani sertifikat.

Apakah mungkin untuk mengonfigurasi sertifikat root sehingga hanya valid ke satu domain?

certificate restrictions

— MichaelD
sumber

Mungkin hanya saya, tapi saya tidak jelas apa yang sebenarnya Anda tanyakan. Apa tujuan akhir yang ingin Anda capai? Jika Anda mengimpor sertifikat root ke kepercayaan pengontrol domain, maka hanya sistem di bawah domain yang akan dapat memvalidasi terhadapnya ...

— Gravy

Sepertinya Anda membingungkan sertifikat yang ditandatangani sendiri dengan menggunakan root CA yang tidak dipercaya secara publik. Aplikasi yang dikonfigurasi untuk menggunakan sertifikat yang ditandatangani sendiri sangat buruk, karena aplikasi harus dikonfigurasikan untuk mengabaikan kesalahan validasi sertifikat. Menggunakan root CA yang tidak dipercaya publik sebenarnya cukup umum.

— Greg Askew

apakah Anda memiliki server CA internal?

— Crypt32

CA dapat membatasi dirinya sendiri untuk domain tertentu dengan batasan nama , tetapi menerapkan batasan secara surut ke CA orang lain adalah masalah yang berbeda.

— Matt Nordhoff

tidak ada perbedaan. Anda dapat menerapkan batasan nama untuk CA pihak ketiga juga. Anda cukup menandatangani sertifikat CA root pihak ketiga dengan menggunakan CA pribadi Anda dan menerbitkan sertifikat silang yang dihasilkan. Dalam hal ini, rantai asing akan berakhir ke rantai pribadi Anda melalui sertifikat silang terbatas.

— Crypt32

Jawaban:

Sebagai aturan praktis:

Tidak , tersirat dalam mempercayai sertifikat CA pelanggan adalah kepercayaan pada setiap sertifikat yang ditandatangani oleh CA.

Saya tidak tahu ada aplikasi / perpustakaan yang memiliki opsi mudah yang memungkinkan Anda sebagai pengguna akhir untuk memilih bahwa Anda akan mempercayai pelanggan Anda atau sertifikat CA lainnya hanya untuk domain (sub-) tertentu yaitu hanya untuk *. example.com dan * .example.org dan tidak ada yang lain.

Mozilla memiliki keprihatinan yang sama tentang CA yang disponsori pemerintah saat ini sebagai titik perhatian terbuka dan misalnya Chrome memiliki pemeriksaan tambahan bawaan untuk mengakses situs Google, yang merupakan cara sertifikat * .google.com nakal dan kompromi dari Diginotar CA menjadi publik. .

Tetapi bahkan jika Anda tidak mempercayai CA, Anda masih dapat mengimpor / mempercayai sertifikat server tertentu yang ditandatangani oleh CA itu, yang akan mencegah peringatan SSL untuk nama host dalam sertifikat itu. Itu seharusnya membuat aplikasi Anda berfungsi tanpa kesalahan atau keluhan.

Pengecualian:

Opsi yang sangat jarang digunakan untuk standar XI PKI X.509v3 adalah ekstensi Name Constraints , yang memungkinkan sertifikat CA memuat daftar putih dan hitam pola nama domain yang diizinkan untuk menerbitkan sertifikat.

Anda mungkin beruntung dan pelanggan Anda menahan diri ketika mereka menyiapkan infrastruktur PKI mereka dan memasukkan kendala Nama itu dalam sertifikat CA mereka. Kemudian Anda dapat mengimpor sertifikat CA mereka secara langsung dan tahu bahwa sertifikat itu hanya dapat memvalidasi rentang nama domain yang terbatas.

— HBruijn
sumber

@CryptoGuy: CA internal juga dapat mengeluarkan sertifikat untuk domain eksternal. Setelah Anda mempercayai CA internal Anda, tidak ada batasan sehingga hanya sertifikat untuk domain (Active Directory atau DNS) Anda sendiri example.comatau *.ad.example.com valid. CA internal Anda juga dapat mengeluarkan sertifikat untuk *.example.bankmemungkinkan serangan orang-di-tengah yang bagus dan mengintai kredensial perbankan online Anda.

— HBruijn

"Segalanya" tidak sepenuhnya akurat. Ada beberapa hal seperti daftar pencabutan sertifikat. Tapi itu tidak mengubah intinya.

— Ben Voigt

maaf, kamu salah lagi. Anda dapat membatasi CA pihak ke-3 untuk mempercayai sertifikat (dari CA itu) yang dikeluarkan untuk daftar nama yang Anda inginkan. Mengenai CA internal Anda sendiri, saya menganggap kepercayaan itu tidak diragukan. Jika Anda tidak percaya CA Anda sendiri, maka ada yang salah dengan IT Anda. Saya ingin mengatakan bahwa dengan memiliki CA pribadi, OP dapat membangun kepercayaan sebagian kepada CA pihak ketiga (dengan membatasi nama yang mereka percayai).

— Crypt32

Ke pos yang diedit: meskipun CA pihak ketiga tidak memiliki ekstensi Name Constraints, dimungkinkan untuk menerapkannya dengan menggunakan server CA internal Anda sendiri melalui sertifikasi silang. Dalam hal ini, rantai sertifikat adalah sebagai berikut: daun sertifikat SSL -> sertifikat silang -> sertifikat CA Anda -> sertifikat root internal Anda. Caranya adalah Anda menandatangani CA pihak ketiga dengan menggunakan CA internal Anda. Dan sertifikat silang akan memiliki semua kendala yang diperlukan.

— Crypt32

CryptoGuy mengatakan ini mungkin, tetapi menemukan detail implementasi itu sulit. Bagaimana dengan jawaban yang menjelaskan bagaimana ini bisa dicapai? Dan mungkin diskusi platform mana yang mendukung nameConstraints.

— jorfus

@CryptoGuy punya jawaban yang cukup bagus di sini, tapi saya ingin mengembangkannya.

Mengutip:

Anda dapat membatasi CA pihak ke-3 untuk mempercayai sertifikat (dari CA itu) yang dikeluarkan untuk daftar nama yang Anda inginkan. Bahkan jika CA pihak ketiga tidak memiliki ekstensi Name Constraints, dimungkinkan untuk menerapkannya dengan menggunakan server CA internal Anda sendiri melalui sertifikasi silang. Caranya adalah Anda menandatangani CA pihak ketiga dengan menggunakan CA internal Anda.

daun sertifikat SSL -> lintas sertifikat -> sertifikat CA Anda -> sertifikat root internal Anda.

Dan inilah cara Anda membuatnya (menggunakan CA command line OpenSSL)

Buat CA sederhana

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

Anda dapat melewati pembuatan CA perantara

Buat permintaan CA perantara, dengan Kendala Nama.

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

Dengan ini dalam ossl_domain_com.cfgfile:

[ 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

Kemudian, tandatangani CA perantara tersebut dengan CA Anda.

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

Jika Anda melewatkan membuat perantara, gunakan CA root Anda untuk masuk

Sekarang, tandatangani kembali CA domain asli di bawah otoritas Anda, menggunakan sertifikat mereka. Anda dapat menambahkan ekstensi CA di sini.

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

Anda mungkin perlu menggunakan -x509-to-reqargumen untuk membuat permintaan, yang Anda tandatangani dengan cara yang persis sama dengan perantara di atas.

Sekarang, tambahkan root CA Anda, intermediate CA, dan domain-cross-ca ke database trust browser Anda.

— davenpcj
sumber

MacOS tidak mendukung nameConstraints. Hanya FIY untuk siapa pun yang bekerja pada nama CA internal yang dibatasi. security.stackexchange.com/questions/95600/… archive.is/6Clgb

— jorfus

T: apa status dari solusi ini? Sistem apa yang berfungsi saat ini (2018)? // Aku menginginkan ini setiap kali aku terpaksa memasang sertifikat perusahaan lain yang ditandatangani sendiri; dan setiap kali saya berpikir tentang Kantor Pos Hong Kong atau Symantec. // Aku pikir aku mungkin tidak peduli tidak pernah menerapkan penyempitan yang dijelaskan, selama mereka tidak secara sengaja menerapkan pelebaran.

— Krazy Glew

@KrazyGlew Saya punya file batch yang saya gunakan untuk ini, dan saya masih menggunakannya secara teratur. Kadang-kadang saya harus menerbitkan kembali sertifikat perantara karena kedaluwarsa atau memutar, jadi ini sedikit lebih manual, tetapi itu tidak menjadi masalah. Kadang-kadang saya menemukan situs yang dikelola otoritas yang gagal dipercaya oleh browser saya karena penggunaan otoritas perantara yang berbeda, atau nama domain tambahan yang mereka tambahkan, yang tidak saya percayai.

— davenpcj

Saya baru saja berhasil menggunakannya, terima kasih. Ini berfungsi dengan baik tanpa sertifikat perantara, apakah ada manfaat menggunakan satu? Selain itu, basicConstraintsbaris dalam file konfigurasi tampaknya menyebabkan ekstensi kendala untuk dimasukkan dalam sertifikat dua kali, yang menyebabkan Firefox menolak sertifikat dengan pesan kesalahan samar. Saya pikir itu bisa dihapus dengan aman.

— wrtlprnft

Saya mendapatkan error pada langkah terakhir: error with certificate to be certified - should be self signed. Apa artinya dan bagaimana menyelesaikannya? pastebin.ubuntu.com/p/QHhpQh2N6J

— mymedia