november 25, 2020
Articles
Ingen kommentarer

Når CA.crt oprettes med selvsignerede certifikater, skal det installeres i klientmaskinen?

Jeg prøver at arbejde med OpenSSL C API, jeg er relativt ny til alt dette stadig, og jeg finder en masse blandet information derude, så jeg synes det er klogt at bede om idéer / meninger / afklaring.

Under alle omstændigheder kræver klientprogrammet, at der indlæses et certifikat eller et bibliotek, der indeholder en “TrustStore”. Er dette bare en anden betydning for serverens CA-certifikat selv, hvis jeg opretter mine egne SSL-certifikater til den nævnte server?

Og i bekræftende fald, fungerer den mellemliggende CA til dette formål til erstatning af root CA?

Jeg tror, jeg er på rette vej. Imidlertid ville jeg bare have en afklaring for at forhindre, at jeg laver en reel dyb fejl, da jeg “har hørt nogle modstridende oplysninger med hensyn til dette. Nogle siger, at klienten har brug for selve rodcertifikatet; andre kilder siger, at de kun installerer mellemliggende CA til af sikkerhedsmæssige årsager, hvilket synes logisk.

Jeg er generelt lidt forvirret over, hvordan tillidskæden fungerer i forhold til en klientforbindelse. Jeg har faktisk kun nogensinde haft brug for at generere en CSR og installere et certifikat på webserveren, så klientsidens ting er lidt nye for mig.

Dette spørgsmål blev oprindeligt stillet her på Stack Overflow blev det foreslået, at jeg spurgte info-sec-samfundet.

Kommentarer

  • Jeg tror, du bruger den forkerte sætning: et selvsigneret certifikat er et certifikat, hvor udstedercertifikatet er selve certifikatet. Du sandsynligvis betyde et certifikat, der er underskrevet af din egen CA i stedet. I dette tilfælde: rod-CAen sættes normalt i tillidsbutikken, og det mellemliggende certifikat underskrevet af rod-CAen og bladcertifikatet underskrevet af det mellemliggende certifikat sendes under TLS-håndtrykket .
  • Mulig duplikat af Hvordan fungerer SSL / TLS PKI?

Svar

tl; dr Hvis certifikatet indeholder en vis variation af CA:TRUE, er det fornuftigt at distribuere det, hvis det ikke gør det, er der ingen fordel ved at distribuere det.

Selve tillidskæden kan forklares i form af certifikatstrukturen.

Hvis vi starter fra din servers cert (dvs. det certifikat, du typisk bruger til apache):

  • dit servercert genereres af en certifikatmyndighed baseret på en CSR, du giver. Denne CSR indeholder din offentlige nøgle og nogle andre oplysninger, som CA måske eller måske ikke er interesseret i at bruge.
  • CA modtager din CSR og opretter (generelt) et underskrevet certifikat ved hjælp af en mellemliggende CA. Dit certifikat vil have to offentlige nøgler: en til emnet (som er den offentlige nøgle hentet fra din CSR) og en til den udstedende part, som er CAs mellemliggende certifikat.
  • CA ” s mellemliggende certifikat er i sig selv et underskrevet certifikat (med nogle specielle indstillinger), hvor emnenøglen vil være den mellemliggende CAs offentlige nøgle (som er den samme offentlige nøgle som findes i udstederens offentlige nøgle på dit servercertifikat). signatur (eller udstedelse) nøgle vil være CAs rodcertifikat (alternativt vil det være et andet mellemprodukt).
  • CAs rodcertifikat er (generelt) et selvsigneret certifikat. I praksis betyder dette, at udsteder- og emne-nøglerne er den samme offentlige nøgle.

Du kan se dette ved at kontrollere certifikater i naturen, fx: 

$ 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 tillidskæde, som dette bygger, kan sammenfattes som (jeg starter fra ” bund “- Equifax-certifikatet):

  • rod-CA (Equifax) delegerer dag-til-dag-aktiviteter til en mellemliggende CA (GeoTrust) og underskriver et certifikat, der repræsenterer dette faktum (dvs. indstilling af CA: TRUE, KeyUsage: keyCertSign). Med andre ord “stoler” root-CA mellemproduktet for at udstede certifikater på dets vegne (forhåbentlig efter at have gennemført en række obligatoriske valideringstrin).
  • i denne kæde, det mellemliggende (Geotrust) har yderligere delegeret til en Google CA (CN = Google Internet Authority G2).
  • delegaten (også kaldet Googles mellemliggende CA) underskriver derefter en CSR, hvilket faktisk er et dokument, der angiver det for en given sæt navne (t CN, og muligvis Subject Alternative Names), er et privat / offentligt nøglepar gyldigt / betroet (tilliden her kommer fra det faktum, at de har valideret kravet om at tale med et givet navn – i dette tilfælde har Google CA udstedt en certifikat for * .google.com).

Bemærk, at (root) CAer generelt er selvsignerede – en CA er generelt tillidsfuld, fordi den overholder et sæt processer og procedurer, der føles for at sikre, at den ikke udsteder certifikater til folk hvem skulle ikke have dem. Derfor kan jeg ikke gå ud og skaffe mig et certifikat, der siger, at jeg er google.Dette er derfor en slags konvention (omend en understøttet af formelle mekanismer), og hvis du starter din egen CA, opnår distribution af dens rod (og mellemliggende) certifikater nøjagtigt det samme som at distribuere certifikater fra andre CAer: det gør certifikater udstedt af denne CA accepteres som gyldige (dvs. pålidelige) af systemet.

I mere praktiske vendinger er tillidsbutikken (for openSSL) stort set en masse filer med en specifik navngivningskonvention. Se https://www.openssl.org/docs/faq.html#USER5 :

Hvornår et certifikat er bekræftet, at dets root-CA skal være “betroet” af OpenSSL, det betyder typisk, at CA-certifikatet skal placeres i en mappe eller fil, og det relevante program er konfigureret til at læse det

Denne mappe er / etc / ssl / certs (der er andre, såsom / etc / pki på RH-lignende).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 giver yderligere overblik over, hvordan man tilføjer et certifikat til butikken, som gør https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,

Den korte version er, at update-ca-certifikater automatiserer processen og er det almindeligt anvendte værktøj.

Den lidt længere version er, at certifikater skal lagres med hash (f.eks. i filer navngivet baseret på output fra openssl x509 -hash -in cert.pem), så openSSL effektivt kan validere kæder.

Se https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html for yderligere baggrund.

opdateret for at svare på spørgsmålene i kommentarer:

Servercertifikatet defineres i denne diskussion som betroet eller ikke baseret på dens kæde af tillid. Hvis du tænker på, hvordan (f.eks.) curl https://google.com fungerer, er det lidt lettere at forstå:

  • curl åbner en TLS-forbindelse til google, som returnerer et certifikat.
  • curl ser på det “slutbruger” certifikat – dvs. serverens certifikat og ser specifikt efter udstederen.
  • hvis udstederen er “kendt” i tillidsbutikken valideres resten af tillidskæden (dvs. servercertifikatudsteders certifikat er kontrolleret, og hvis det har en anden udsteder end sig selv, kontrolleres denne udsteder osv.). Kun hvis hele tillidskæden kan valideres, betragtes certifikatet som gyldigt.

Det ville dog absolut upraktisk at distribuere tillidskæder, hvis slutbrugercertifikater skulle medtages. Jeg har ikke nogen numre på, hvor mange websteder der er, men baseret på det faktum, at Alexa giver en top 1M, antager du, at det er mere end 1 million.

Hvilket er en slags pointen med en kæde af tillid: du skal generelt have udstedercertifikaterne rundt, men du behøver ikke at slutcertifikaterne skal distribueres, fordi de fortæller dig, hvem udstederen er.

Og du kan kontrollere, at de ikke er ” t lyve, fordi du kan kontrollere udstedernes offentlige nøgle (og den tillidskæde, der fastslår, at den er den rigtige nøgle), og validere, om slutbrugercertifikatet (dvs. serveren) virkelig blev underskrevet af den private modstykke til udstederens offentlig nøgle.

Så nej, du bør ikke distribuere slutbrugercertifikaterne, men kun kæden af tillid – eller i enklere vendinger: distribuere alle de certs du genererer hvor BasicConstraints (legitimt) siger i det mindste noget CA: SAND. Distribuer ikke noget, der ikke opfylder denne betingelse, fordi det er spild af din tid og diskplads – alt, hvad der ikke siger CA: TRUE kan valideres mod noget der gør.

Kommentarer

  • Så betyder det under alle omstændigheder, at klienten har brug for adgang til rod-CA-certifikatet eller bare det CA-certifikat, som serveren har certifikat blev underskrevet af? Eller mangler jeg stadig et eller andet punkt?
  • For at verificere servercertifikatet har klienten (e) brug for adgang til den fulde tillidskæde for det cert. Ellers vil klienten enten betragte certifikatet som ugyldigt eller bede brugeren om at acceptere det. I dit tilfælde virker det noget sandsynligt, at du ikke opretter et distributionspunkt for dine CA / CRLer, så den enkleste måde er at sikre, at dine certifikater er i / etc / ssl / certs på klientmaskiner. tl; dr: et certifikat er en begrænset anvendelse til oprettelse af tillid, hvis du ' t kan etablere sin kæde af tillid. Og du skal validere hele kæden for at fastslå det. Så gør hele tillidskæden tilgængelig
  • Betyder det, at hvis der er en rod-CA, en mellemliggende CA og det underskrevne certifikat på serveren, skal alle tre af disse certifikater være tilgængelige for klienten inden for /etc/ssl/certs -mappe? Da disse alle indeholder de offentlige nøgler?

Svar

Et selvsigneret certifikat er netop det: det er underskrev mig selv (det er dets eget tillidsanker).

Derfor skal det placeres manuelt og eksplicit på applikationens liste over pålidelige ankre. For at have tillid til det, afhænger det af operativsystemet og applikationen. For eksempel, hvis du bruger Windows interne certifikatlager, skal du placere det selvsignerede certifikat i “betroet rodcertifikatmyndighed” -lager, ellers accepteres certifikatet ikke. OpenSSL bruger et andet applikationsspecifikt lagersystem: du bliver også nødt til at installere certifikatet som en betroet CA, men hvordan det afhænger meget af nøjagtigt hvilket program og operativsystem du bruger (se denne artikel for nogle generiske instruktioner).

Kommentarer

  • Så betyder det " Trust Store " certifikat er lige det samme som det, der er installeret i apache, for eksempel? At ' s den del, der er mest forvirrende, i ' ma GNU/Linux bruger, hvis mappe jeg havde brug for at linke til i klientapplikationen, var /etc/ssl/certs. Men jeg kunne ikke finde en klar forklaring på, hvad processen er på den side af tingene. I det mindste forstår du mit spørgsmål her, det vigtigste punkt bag det er at skrive klienten og få den til at stole på den server, den opretter forbindelse til.
  • Hvad jeg ' m at prøve at gøre præcist er at oprette en CA, og jeg antager, at certifikatet er underskrevet af CA (mellemliggende), så i så fald betyder det, at CA er tillidsanker, derfor den mellemliggende Ca skal installeres i den betroede certifikatmappe? Tak, fordi du svarede.
  • Dit spørgsmål er derfor mere generelt. Jeg ' har foreslået at lukke det med et link til det svar, du søger.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *