Moet bij het maken van zelfondertekende certificaten de CA.crt op de clientcomputer worden geïnstalleerd?

De vertrouwensketen zelf kan worden verklaard in termen van de certificaatstructuur.

Als we beginnen met het certificaat van uw server (dwz het certificaat dat u normaal gesproken zou gebruiken voor apache):

• uw servercertificaat wordt gegenereerd door een certificeringsinstantie, op basis van een CSR die u verstrekt. Die CSR bevat uw openbare sleutel en enige andere informatie die de CA al dan niet wil gebruiken.
• de CA ontvangt uw CSR en maakt (doorgaans) een ondertekend certificaat met behulp van een tussenliggende CA. Uw certificaat heeft twee openbare sleutels: een voor het onderwerp (dit is de openbare sleutel die uit uw CSR is gehaald) en een voor de uitgevende partij, het tussenliggende certificaat van de CA.
• de CA ” s tussencertificaat is zelf een ondertekend certificaat (met enkele speciale opties), waarbij de onderwerpsleutel de openbare sleutel van de tussenliggende CA is (dit is dezelfde openbare sleutel als in de openbare sleutel van de uitgever van uw servercertificaat). de ondertekende (of uitgevende) sleutel zal het rootcertificaat van de CA zijn (of het zal een ander tussenproduct zijn).
• Het rootcertificaat van de CA is (over het algemeen) een zelfondertekend certificaat. In de praktijk betekent dit dat de uitgever en de onderwerpssleutel dezelfde openbare sleutel zijn.

U kunt dit zien door certificaten in het wild te controleren, bijv .:

$ 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 

De vertrouwensketen die dit opbouwt kan worden samengevat als (ik begin met de ” bottom “- het Equifax-certificaat):

• de root-CA (Equifax) delegeert dagelijkse activiteiten aan een tussenliggende CA (GeoTrust) en ondertekent een certificaat dat dit feit vertegenwoordigt (dwz het instellen van CA: TRUE, KeyUsage: keyCertSign). Met andere woorden, de root-CA “vertrouwt” de tussenpersoon om namens hem certificaten uit te geven (hopelijk na het voltooien van een reeks verplichte validatiestappen).
• in deze keten, de tussenpersoon (Geotrust) heeft verder gedelegeerd aan een Google CA (CN = Google Internet Authority G2).
• De gedelegeerde (ook bekend als de tussenliggende Google-CA) ondertekent vervolgens een CSR, wat in feite een document is waarin staat dat voor een bepaalde set namen (t e CN, en mogelijk Subject Alternative Names), is een privé / openbaar sleutelpaar geldig / vertrouwd (het vertrouwen komt hier voort uit het feit dat ze de claim hebben gevalideerd om voor een bepaalde naam te spreken – in dit geval heeft de Google CA een certificaat voor * .google.com).

Merk op dat (root) CAs over het algemeen zelfondertekend zijn – een CA wordt over het algemeen vertrouwd omdat deze zich houdt aan een reeks processen en procedures die worden gevoeld om ervoor te zorgen dat ze geen certificaten aan mensen afgeeft wie zou ze niet moeten hebben. Daarom kan ik niet uitgaan om een certificaat te halen waarin staat dat ik Google ben.Dit is daarom een soort conventie (zij het ondersteund door formele mechanismen), en als u uw eigen CA start, bereikt het distribueren van de root- (en tussenliggende) certificaten precies hetzelfde als het distribueren van de certificaten van andere CAs: het zorgt ervoor dat certificaten worden uitgegeven door die CA worden aanvaard als geldig (dwz betrouwbaar) door het systeem.

In meer praktische termen, de trust store (voor openSSL) bestaat eigenlijk uit een hoop bestanden met een specifieke naamgevingsconventie. Zie https://www.openssl.org/docs/faq.html#USER5 :

Wanneer een certificaat is geverifieerd, de root-CA moet “vertrouwd” zijn door OpenSSL. Dit betekent doorgaans dat het CA-certificaat in een map of bestand moet worden geplaatst en dat het relevante programma moet worden geconfigureerd om het te lezen

Die map is / etc / ssl / certs (er zijn andere, zoals / etc / pki op RH-likes).

https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu#719047 geeft wat verder overzicht van hoe men een certificaat aan de winkel toevoegt, zoals doet https://askubuntu.com/questions/73287/how-do-i-install-a-root-certificate ,

De korte versie is dat update-ca-certificaten automatiseert het proces, en is de meest gebruikte tool.

De iets langere versie is dat certificaten moeten worden opgeslagen met een hash (bijvoorbeeld in bestanden met namen op de uitvoer van openssl x509 -hash -in cert.pem), zodat openSSL efficiënt ketens kan valideren.

Zie https://www.openssl.org/docs/man1.0.2/apps/c_rehash.html voor wat extra achtergrondinformatie.

heeft bijgewerkt om te reageren op de vragen in opmerkingen:

Het servercertificaat wordt in deze discussie gedefinieerd als vertrouwd of niet op basis van de vertrouwensketen. Als je nadenkt over hoe (bijv.) curl https://google.com werkt, is het een beetje gemakkelijker te begrijpen:

• curl opent een TLS-verbinding met Google, die terugkeert een certificaat.
• curl kijkt naar dat “eindgebruiker” -certificaat, dwz het servercertificaat, en zoekt specifiek naar de uitgever.
• of de uitgever “bekend” is in de trust store, wordt de rest van de trust chain gevalideerd (dwz het certificaat van de uitgever van het servercertificaat wordt gecontroleerd, en als het een andere uitgever heeft dan zichzelf, wordt die uitgever gecontroleerd, enz.). Alleen als de volledige vertrouwensketen kan worden gevalideerd, wordt het certificaat als geldig beschouwd.

Het zou echter absoluut onpraktisch zijn om vertrouwensketens te distribueren als er certificaten van eindgebruikers zouden moeten worden opgenomen. Ik heb geen cijfers over het aantal websites dat er zijn, maar uitgaande van het feit dat Alexa een top 1 miljoen levert, zou je aannemen dat het meer dan 1 miljoen is.

Dat is een beetje het punt van een vertrouwensketen: je hebt over het algemeen de uitgevercertificaten nodig, maar je hoeft de eindcertificaten niet te verspreiden, omdat ze je vertellen wie de uitgever is.

En je kunt verifiëren dat ze niet zijn ” t liegen, omdat je de openbare sleutel van de uitgever kunt controleren (en de vertrouwensketen waarmee wordt vastgesteld dat het de juiste sleutel is), en valideren of het eindgebruikercertificaat (dat wil zeggen de server) echt is ondertekend door de privé-tegenhanger van de uitgever openbare sleutel.

Dus nee, u moet niet de eindgebruikercertificaten distribueren, maar alleen de vertrouwensketen – of, eenvoudiger gezegd: distribueer alle de certificaten die u genereert waar de BasicConstraints (legitiem) iets zeggen tenminste CA: TRUE. Verspreid niets dat niet aan die voorwaarde voldoet, want het is een verspilling van je tijd en schijfruimte – alles wat niet zegt CA: TRUE kan worden gevalideerd tegen iets dat dat wel doet.

Opmerkingen

• Dat betekent dus in ieder geval dat de client toegang nodig heeft tot het root-CA-certificaat, of alleen het CA-certificaat waarvan de server certificaat is ondertekend door? Of mis ik nog steeds een punt volledig?
• Om het servercertificaat te verifiëren, hebben de client (s) toegang nodig tot de volledige trust chain voor dat cert. Anders zal de client het certificaat als ongeldig beschouwen of de gebruiker vragen het te accepteren. In uw geval lijkt het enigszins waarschijnlijk dat u geen distributiepunt voor uw CA / CRLs zou opzetten, dus de eenvoudigste manier is om ervoor te zorgen dat uw certificaten zich in / etc / ssl / certs op clientmachines bevinden. tl; dr: een certificaat is een beperkt gebruik bij het vestigen van vertrouwen als je ' de vertrouwensketen niet kunt vestigen. En je moet de volledige keten valideren om dat vast te stellen. Maak dus de hele vertrouwensketen beschikbaar.
• Betekent dit dat als er een root-CA, een tussenliggende CA en het ondertekende certificaat op de server is, alle drie deze certificaten beschikbaar moeten zijn voor de client binnen de /etc/ssl/certs directory? Omdat deze allemaal de openbare sleutels bevatten?