Při vytváření certifikátů s vlastním podpisem má být CA.crt nainstalován do klientského počítače?

Samotný řetězec důvěry lze vysvětlit z hlediska struktury certifikátu.

Vycházíme-li z certifikátu vašeho serveru (tj. cert, který byste obvykle používali pro apache):

• váš serverový certifikát je generován certifikační autoritou na základě vámi poskytnuté CSR. Že CSR obsahuje váš veřejný klíč a některé další informace, které CA může nebo nemusí mít zájem používat.
• CA obdrží váš CSR a (obecně) vytvoří podepsaný certifikát pomocí zprostředkujícího CA. Váš certifikát bude mít dva veřejné klíče: jeden pro předmět (což je veřejný klíč extrahovaný z vaší CSR) a jeden pro vydávající stranu, což je zprostředkující certifikát CA.
• CA “ Intermediální certifikát je sám podepsaný certifikát (s některými speciálními možnostmi), kde klíčem subjektu bude veřejný klíč zprostředkující CA (což je stejný veřejný klíč, jaký je uveden ve veřejném klíči vydavatele vašeho certifikátu serveru). podpisový (nebo vydávající) klíč bude kořenovým certifikátem CA (alternativně bude dalším zprostředkujícím).
• kořenový certifikát CA je (obecně) certifikát podepsaný svým držitelem. V praxi to znamená, že klíče vydavatele a subjektu jsou stejný veřejný klíč.

Můžete to vidět kontrolou certifikátů ve volné přírodě, např .:

$ openssl s_client -connect google.com:443 < /dev/null CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority 

Řetěz důvěry, který tato sestavení lze shrnout jako (vycházím z “ bottom „- certifikát Equifax):

• kořenový CA (Equifax) deleguje každodenní činnosti na zprostředkujícího CA (GeoTrust) a podepisuje certifikát představující tuto skutečnost (tj. nastavení CA: TRUE, KeyUsage: keyCertSign). Jinými slovy, kořenová certifikační autorita „důvěřuje“ zprostředkovateli ve vydávání certifikátů jeho jménem (snad po dokončení řady povinných kroků ověření).
• v tomto řetězci zprostředkující (Geotrust) dále delegoval na Google CA (CN = Google Internet Authority G2).
• delegát (aka Google zprostředkující CA) poté podepíše CSR, což je ve skutečnosti dokument uvádějící, že pro daný množina jmen (t CN a případně Alternativní jména subjektu), pár soukromých / veřejných klíčů je platný / důvěryhodný (důvěra zde vychází ze skutečnosti, že ověřili nárok mluvit za křestní jméno – v tomto případě vydal Google CA certifikát pro * .google.com).

Všimněte si, že (root) CA jsou obecně podepsané sami sebou – CA je obecně důvěryhodná, protože se řídí sadou procesů a postupů, které mají zajistit, aby lidem nevydávala certifikáty kdo by je neměl mít. Proto nemůžu jít ven a získat certifikát, že jsem google.Jedná se tedy o konvenci svého druhu (i když podporovanou formálními mechanismy), a pokud si založíte vlastní CA, distribucí jejích kořenových (a mezilehlých) certifikátů dosáhnete přesně stejné věci jako distribuce certifikátů jiných CA: udělá vydané certifikáty tímto CA bude systémem přijato jako platné (tj. důvěryhodné).

Z praktičtějšího hlediska je úložiště důvěryhodnosti (pro openSSL) spousta souborů se specifickou konvencí pojmenování. Viz https://www.openssl.org/docs/faq.html#USER5 :

Když certifikát je ověřen, jeho kořenová CA musí být OpenSSL „důvěryhodná“, což obvykle znamená, že certifikát CA musí být umístěn v adresáři nebo souboru a příslušný program musí být nakonfigurován tak, aby jej mohl číst

Tímto adresářem je / etc / ssl / certs (existují i jiné, například / etc / pki na RH-like).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 poskytuje další přehled o tom, jak lze do obchodu přidat certifikát, protože dělá https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,

Krátká verze je update-ca-certificates automatizuje proces a je běžně používaným nástrojem.

Trochu delší verze spočívá v tom, že certifikáty je třeba ukládat pomocí hash (např. do souborů s názvem based na výstupu openssl x509 -hash -in cert.pem), aby mohl openSSL efektivně ověřovat řetězce.

Viz https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html pro další pozadí.

aktualizováno tak, aby odpovídalo na otázky v komentářích:

Certifikát serveru , v této diskusi, je definován jako důvěryhodný nebo ne na základě jeho řetězce důvěry. Pokud přemýšlíte o tom, jak (např.) curl https://google.com funguje, je to o něco snazší pochopit:

• curl otevře spojení TLS s google, které vrací certifikát.
• curl se dívá na ten certifikát „koncového uživatele“ – tj. certifikát serveru a hledá konkrétně vydavatele.
• pokud je emitent „známý“ v úložiště důvěryhodnosti, zbytek řetězce důvěryhodnosti je ověřen (tj. je zkontrolován certifikát vydavatele certifikátu serveru, a pokud má jiného vydavatele než sebe, je tento emitent zkontrolován atd.). Certifikát se považuje za platný pouze v případě, že lze ověřit celý řetězec důvěryhodnosti.

Distribuce řetězců důvěry by však bylo naprosto nepraktické, pokud by bylo nutné zahrnout certifikáty koncových uživatelů. Nemám žádná čísla o tom, kolik webů je venku, ale na základě skutečnosti, že Alexa poskytuje špičkový 1 milion, byste předpokládali, že je to více než 1 milion.

Což je něco jako řetěz důvěry: obecně musíte mít certifikáty vydavatele, ale nepotřebujete distribuci koncových certifikátů, protože vám řeknou, kdo je emitent.

A můžete ověřit, že nejsou “ lhát, protože můžete zkontrolovat veřejný klíč emitenta (a řetězec důvěry, který jej stanoví, je správný klíč) a ověřit, zda byl certifikát koncového uživatele (tj. serveru) skutečně podepsán soukromým protějškem emitenta veřejný klíč.

Takže ne, neměli byste distribuovat certifikáty koncových uživatelů, ale pouze řetězec důvěry – nebo, jednodušeji, distribuovat všechny certifikáty, které vygenerujete, kde BasicConstraints (oprávněně) říkají alespoň CA: TRUE. Nedistribuujte nic, co tuto podmínku nesplňuje, protože je to ztráta času a místa na disku – vše, co ne říká CA: TRUE, lze ověřit proti něčemu, co ano.

Komentáře

• To tedy v každém případě znamená, že klient potřebuje přístup ke kořenovému certifikačnímu úřadu CA, nebo pouze k certifikačnímu úřadu CA, jehož je server certifikát byl podepsán? Nebo mi stále úplně chybí nějaký bod?
• Aby bylo možné ověřit certifikát serveru, klient (i) bude potřebovat přístup k úplnému řetězci důvěryhodnosti tohoto certifikátu. V opačném případě bude klient buď považovat certifikát za neplatný, nebo požádá uživatele, aby jej přijal. Ve vašem případě se zdá poněkud pravděpodobné, že byste nenastavovali distribuční bod pro vaše CA / CRL, takže nejjednodušším způsobem je zajistit, aby vaše certifikáty byly v klientských počítačích v / etc / ssl / certs. tl; dr: certifikát je při vytváření důvěry omezený, pokud ' nelze navázat jeho řetězec důvěry. Abyste to dokázali, musíte ověřit celý řetězec. Takže zpřístupněte celý řetězec důvěryhodnosti
• Znamená to, že pokud je na serveru kořenový CA, zprostředkující CA a podepsaný certifikát, Všechny tři z těchto certifikátů musí být klientovi k dispozici v rámci /etc/ssl/certs adresář? Protože všechny obsahují veřejné klíče?