När CA.crt ska skapas med självsignerade certifikat ska det installeras i klientmaskinen?

Kedjan av förtroende i sig kan förklaras i termer av certifikatstrukturen.

Om vi börjar från din servers certifikat (dvs. certifikatet du vanligtvis använder för apache):

• ditt servercert genereras av en certifikatutfärdare, baserat på en CSR du tillhandahåller. CSR innehåller din offentliga nyckel och annan information som CA kan eller inte är intresserad av att använda.
• CA mottar din CSR, och (generellt) skapar ett signerat certifikat med hjälp av en mellanliggande CA. Ditt certifikat kommer att ha två offentliga nycklar: en för ämnet (som är den offentliga nyckel som extraheras från din CSR) och en för den utfärdande parten, som är CA: s mellanliggande certifikat.
• CA s mellanliggande certifikat är i sig ett undertecknat certifikat (med vissa speciella alternativ), där ämnesnyckeln kommer att vara den mellanliggande CA: s offentliga nyckel (som är samma offentliga nyckel som finns i utgivarens offentliga nyckel i ditt servercertifikat). signerings (eller utfärdande) nyckel kommer att vara CA: s rotcertifikat (alternativt kommer det att vara en annan mellanliggande).
• CA: s rootcertifikat är (vanligtvis) ett självsignerat certifikat. I praktiken betyder detta att utfärdar- och ämnesnycklarna är samma offentliga nyckel.

Du kan se detta genom att kontrollera certifikat i naturen, t.ex.:

$ 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 

Den kedja av förtroende som detta bygger kan sammanfattas som (jag börjar från ” bottom ”- Equifax cert):

• root CA (Equifax) delegerar dagliga aktiviteter till en mellanliggande CA (GeoTrust) och undertecknar ett certifikat som representerar detta faktum (dvs. inställning CA: TRUE, KeyUsage: keyCertSign). Med andra ord, ”CA” litar ”intermediären för att utfärda certifikat för dess räkning (förhoppningsvis efter att ha slutfört en serie obligatoriska valideringssteg).
• i denna kedja, den mellanliggande (Geotrust) har vidare delegerat till en Google CA (CN = Google Internet Authority G2).
• delegaten (även kallad Googles mellanliggande CA) undertecknar sedan en CSR, vilket i själva verket är ett dokument som anger att för en given uppsättning namn (t han CN, och möjligen ämnesalternativ), är ett privat / offentligt nyckelpar giltigt / pålitligt (förtroendet här kommer från det faktum att de har validerat påståendet att tala för ett givet namn – i det här fallet har Google CA utfärdat en certifikat för * .google.com).

Observera att (root) CA: er i allmänhet är självsignerade – en CA är allmänt betrodda eftersom den följer en uppsättning processer och procedurer som känns för att säkerställa att den inte utfärdar certifikat till människor som inte borde ha dem. Därför kan jag inte gå ut och skaffa mig ett certifikat som säger att jag är google.Detta är därför en sorts konvention (om än en som stöds av formella mekanismer), och om du startar din egen CA, uppnår du att distribuera dess rot (och mellanliggande) certifikat exakt samma sak som att distribuera certifikat från andra CA: er gör att certifikat utfärdas av att CA godkänns som giltiga (dvs. pålitliga) av systemet.

I mer praktiska termer är trust store (för openSSL) ganska mycket en massa filer med en specifik namngivningskonvention. Se https://www.openssl.org/docs/faq.html#USER5 :

När ett certifikat är verifierat att dess rot-CA måste ”lita på” av OpenSSL, det betyder vanligtvis att CA-certifikatet måste placeras i en katalog eller fil och det relevanta programmet är konfigurerat för att läsa det

Den katalogen är / etc / ssl / certs (det finns andra, till exempel / etc / pki på RH-gillar).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 ger ytterligare en översikt över hur man lägger till ett certifikat i butiken, som gör https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,

Den korta versionen är att update-ca-certifikat automatiserar processen och är det vanliga verktyget.

Den något längre versionen är att certifikat måste lagras med hash (t.ex. i filer som heter baserade på utdata från openssl x509 -hash -in cert.pem), så att openSSL effektivt kan validera kedjor.

Se https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html för ytterligare bakgrund.

uppdaterade för att svara på frågorna i kommentarer:

Servercertifikatet , i denna diskussion, definieras som pålitlig eller inte baserat på dess kedja av förtroende. Om du tänker på hur (t.ex.) curl https://google.com fungerar är det lite lättare att förstå:

• curl öppnar en TLS-anslutning till google, som returnerar ett certifikat.
• curl tittar på certifikatet ”slutanvändare” – dvs. serverns certifikat och letar specifikt efter emittenten.
• om emittenten är ”känd” i tillitsbutiken valideras resten av förtroendekedjan (dvs. servercertifikatutfärdarens certifikat är markerat, och om det har en annan utfärdare än sig själv kontrolleras den emittenten osv.). Endast om hela förtroendekedjan kan valideras anses certifikatet vara giltigt.

Det skulle dock vara absolut opraktiskt att distribuera förtroendekedjor om slutanvändarcertifikat måste inkluderas. Jag har inte några siffror om hur många webbplatser som finns där, men baserat på det faktum att Alexa ger en topp 1M, skulle du anta att den är mer än 1 miljon.

Vilket är en punkt för en kedja av förtroende: du behöver i allmänhet ha emittentcertifikaten, men du behöver inte slutcertifikaten distribueras, eftersom de säger dig vem emittenten är.

Och du kan verifiera att de inte är ” ljuger inte, eftersom du kan kontrollera utgivarnas offentliga nyckel (och kedjan av förtroende som fastställer att den är rätt nyckel) och verifiera om slutanvändarens (dvs. server) certifikat verkligen undertecknades av den privata motsvarigheten till emittentens offentlig nyckel.

Så nej, du ska inte distribuera slutanvändarens certifikat, utan bara kedjan av förtroende – eller i enklare termer: distribuera alla certifikaten du genererar där BasicConstraints (legitimt) säger något åtminstone CA: TRUE. Distribuera inte något som inte uppfyller det villkoret, eftersom det är slöseri med din tid och diskutrymme – allt som inte säger CA: TRUE kan valideras mot något som gör det.

Kommentarer

• Så betyder det under alla omständigheter att klienten behöver tillgång till root CA-certifikatet, eller bara det CA-certifikat som servern har certifikatet undertecknades av? Eller saknar jag fortfarande någon punkt?
• För att verifiera servercertifikatet behöver klienten / klienterna få tillgång till hela förtroendekedjan för certifikatet. I annat fall anser klienten att certifikatet är ogiltigt eller ber användaren att acceptera det. I ditt fall verkar det vara troligt att du inte skulle ställa in en distributionsplats för dina CA / CRL: er, så det enklaste sättet är att se till att dina certifikat finns i / etc / ssl / certs på klientmaskiner. tl; dr: ett certifikat är en begränsad användning för att skapa förtroende om du kan ' t upprätta sin förtroendekedja. Och du måste validera hela kedjan för att fastställa det. Så gör hela förtroendekedjan tillgänglig
• Betyder det att om det finns en rot-CA, en mellanliggande CA och det signerade certifikatet på servern, måste alla dessa tre certifikat vara tillgängliga för klienten inom /etc/ssl/certs katalog? Eftersom dessa alla innehåller de offentliga nycklarna?