Wanneer ik iets over SSL probeer te begrijpen, heb ik het altijd moeilijk om te onthouden waar “sleutel” en “certificaat” naar verwijzen. Ik vrees dat veel mensen ze verkeerd of door elkaar gebruiken. Is er een standaard verschil tussen een sleutel en een certificaat?
Een certificaat bevat een openbare sleutel.
Het certificaat bevat niet alleen de openbare sleutel, maar ook aanvullende informatie, zoals de uitgever, waarvoor het certificaat gebruikt moet worden, en andere soorten metagegevens.
Gewoonlijk wordt een certificaat zelf ondertekend door een certificeringsinstantie (CA) met behulp van de privésleutel van de CA. Hiermee wordt de echtheid van het certificaat geverifieerd.
Deze twee foto’s samen verklaarden alles voor mij:
Bron: linuxvoice ](https://www.linuxvoice.com/masterclass-secure-your-website-with-ssl-encryption/)
Bron: infosecinstitute
Laten we zeggen dat bedrijf A een sleutelpaar ](https://en.wikipedia.org/wiki/Public-key_cryptography) heeft en zijn publieke sleutel voor publiek gebruik moet publiceren (aka ssl op zijn website).
Dus de openbare sleutel van bedrijf A, ondertekend met een geldige privésleutel van de CA, wordt het certificaat van bedrijf A genoemd.
Ik zal het met een voorbeeld uitleggen.
In een normale PKI, gebaseerd op sleutelparen, zijn er een private sleutel en een publieke sleutel.
In een op certificaten gebaseerd systeem zijn er een privésleutel en een certificaat. Het certificaat bevat meer informatie dan de openbare sleutel.
Demo (U kunt een certificaat en privésleutel genereren): http://www.selfsignedcertificate.com/
U kunt het privésleutelbestand en het certificaatbestand downloaden, u ziet dat het certificaatbestand veel informatie bevat, zoals hieronder weergegeven.
U kunt uw gegenereerd certificaat (openen met een teksteditor), en privésleutel (openen met een teksteditor) van deze site vergelijken: https://www.sslshopper.com/certificate-key-matcher.html ](https://www.sslshopper.com/certificate-key-matcher.html)
Als het certificaat overeenkomt met de private sleutel van de client, is de client er zeker van, dat het certificaat is gegeven door de client of gegeven door de vertrouwde agent van de client (CA).
Echter, er zijn problemen bij communicatie op basis van alleen de particuliere sleutel en het certificaat.
Omdat iedereen zijn eigen certificaat en privésleutel kan genereren, bewijst een eenvoudige handshake niets over de server, behalve dat de server de privésleutel kent die overeenkomt met de publieke sleutel van het certificaat. Een manier om dit probleem op te lossen is om de client een set van een of meer certificaten te laten hebben die hij vertrouwt. Als het certificaat niet in de set zit, is de server niet te vertrouwen.
Er zijn verschillende nadelen aan deze eenvoudige aanpak. Servers zouden na verloop van tijd moeten kunnen upgraden naar sterkere sleutels (“sleutelrotatie”), waardoor de publieke sleutel in het certificaat wordt vervangen door een nieuwe. Helaas moet nu de client-app worden bijgewerkt vanwege wat in wezen een wijziging van de serverconfiguratie is. Dit is vooral problematisch als de server niet onder controle staat van de ontwikkelaar van de app, bijvoorbeeld als het een webdienst van een derde partij is. Deze aanpak heeft ook problemen als de app moet praten met willekeurige servers, zoals een webbrowser of e-mail app.
Om deze nadelen te ondervangen, worden servers doorgaans geconfigureerd met certificaten van bekende uitgevers, Certificate Authorities (CA’s) genaamd. et host-platform (client) bevat doorgaans een lijst van bekende CA’s die het vertrouwt. Net als een server heeft een CA een certificaat en een private sleutel. Wanneer de CA een certificaat voor een server afgeeft, ondertekent hij het servercertificaat met zijn private sleutel. De client kan dan verifiëren dat de server een certificaat heeft dat is uitgegeven door een CA die bekend is bij het platform.
Hoewel het gebruik van CA’s enkele problemen oplost, introduceert het een ander. Omdat de CA certificaten uitgeeft voor veel servers, is er nog steeds een manier nodig om er zeker van te zijn dat je praat met de server die je wilt. Om dit op te lossen identificeert het certificaat dat door de CA is uitgegeven de server met een specifieke naam zoals gmail.com of een wildcarded set van hosts zoals *.google.com.
Het volgende voorbeeld zal deze concepten wat concreter maken. In het onderstaande fragment van een commandoregel, kijkt het commando openssl tool’s s_client naar Wikipedia’s server certificaat informatie. Het specificeert poort 443 omdat dat de standaard is voor HTTPS. Het commando stuurt de uitvoer van openssl s_client naar openssl x509, dat informatie over certificaten opmaakt volgens de X.509 standaard. Meer bepaald vraagt het commando naar het onderwerp, dat de servernaaminformatie bevat, en de emittent, die de CA identificeert.
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
U kunt zien dat het certificaat is uitgegeven voor servers die overeenkomen met *.wikipedia.org door de RapidSSL CA.
Zoals u kunt zien, kan de client door deze extra informatie die door de CA naar de servers wordt gestuurd, gemakkelijk weten of hij met zijn server communiceert of niet.
Een SSL certificaat wordt verkregen van een vertrouwde certificeringsautoriteit, die instaat voor de veilige verbinding van de website. SSL-certificaten bevatten gewoonlijk het logo van de authenticatie en ook de openbare sleutels die nodig zijn voor het coderen en decoderen van gegevens die naar de computer moeten worden verzonden. SSL-sleutels Functies
Tijdens een sessie kunnen verschillende SSL-sleutels** worden gegenereerd. De sleutels worden gebruikt om te verifiëren dat de informatie niet gewijzigd is of dat er niet mee geknoeid is.
Verschil in levenscyclus
Certificaten gaan langer mee dan SSL-sleutels. SSL-certificaten worden verkregen van een certificeringsautoriteit, die regelmatig door banken en bedrijven kan worden vernieuwd. SSL-sleutels of sessiesleutels daarentegen worden tijdens de sessie op unieke wijze gegenereerd en worden weggegooid wanneer de sessie eindigt. Lees hier meer
OK, laten we dit afbreken zodat niet technische mensen het kunnen begrijpen.
Zie het als volgt. Een certificaat is als een kluisje bij je bank. Het bevat een heleboel belangrijke dingen; meestal dingen die je identiteit bevatten. Het certificaat heeft een publieke sleutel en heeft een private sleutel nodig om het te openen.
Je kluisje heeft ook twee sleutels nodig om het te openen, net als een certificaat.
Bij een kluisje is de sleutel van de bankier de publieke sleutel, want die blijft bij de bank en de publieke sleutel blijft bij het certificaat. Jij hebt de privésleutel, die nodig is om je certificaat te halen, en in het voorbeeld van het kluisje is naast de publieke sleutel ook de privésleutel nodig.
Voordat u uw kluisje kunt openen, moet u eerst uw identiteit verifiëren (een soort certificaataanvraag); als u eenmaal geïdentificeerd bent, gebruikt u uw privésleutel samen met de publieke sleutel om uw kluisje te openen. Dit is een beetje zoals een certificaat aanvragen, en dan uw certificaat krijgen van de certificatie autoriteit (zolang u geïdentificeerd kan worden (vertrouwd) en u de juiste sleutel heeft).