Undertegnelse af en offentlig nøgle er faktisk et certifikat. Dette er de skridt, jeg tager for at producere et certifikat for offentlig nøgle, som jeg kan distribuere til andre, så de kan kommunikere sikkert med mig:

Opsætning

1. Generer de private nøgler:
   

   openssl genrsa -out private.pem 2048

2. Generer de offentlige nøgler:
   

   openssl rsa -in private.pem -outform PEM -pubout -out public.pem

3. Opret en CSR (Certificate Signing Request)
   

   openssl req -nye -nøgle private.pem -out certifikat.csr

4. Opret et selvsigneret certifikat (du kan dele dette certifikat)
   

   openssl x509 -req -days 365 -in certifikat.csr -signkey private.pem -out certifikat.crt

Kryptering

openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data> encrypted_data

Dekryptering

1. Uddrag den offentlige nøgle fra certifikaterne
   

   openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem

2. Dekrypter data
   

   openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data> data

Hvis du har til hensigt at få din nøgle underskrevet af en CA, bliver du nødt til at sende din CSR-fil (og nogle kontante penge) til din valgte CA, de giver dig det certifikat, du kan bruge i stedet for det selvsignerede cert nævnt i ovenstående trin.

Kommentarer

• Dette er lidt det modsatte af det, jeg beder om, men det vil gøre med henblik på diskussion. For at den anden side kan dekryptere, har de enten brug for den offentlige nøgle, som er udtrukket af mig, og som er underlagt MITM-angrebet, eller de har brug for hele certifikatet, som inkluderer den (krypterede) private nøgle
• @ user1683793 anden ende har brug for to certifikater. Den første skal de allerede have (det selvsignerede CA-certifikat). Den anden indeholder den offentlige nøgle, som du vil bekræfte, og er underskrevet med CA-certifikatet (ved hjælp af den tilknyttede private CA-nøgle). Gyldigheden af det andet certifikat testes ved hjælp af den offentlige nøgle i CA-certifikatet. Private nøgler holdes altid private.
• Jeg tror, du vil have ” -krypter ” og ” -decrypt ” i stedet for ” -sign ” og ” -bekræft “. (Detaljer her: czeskis.com/random/openssl-encrypt-file.html )
• Virker ikke: 2. Dekryptering af data fungerede ikke for mig. Med: openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data får jeg denne fejl / msg: A private key is needed for this operation
• Afsnit Setup, trin 2 giver public.pem – det er ikke ‘ t brugt i yderligere trin. Hvad er brugen af den offentlige nøgle, når CSR genereres med en privat nøgle?

Der skal være tre enheder involveret i processen:

1. Afsenderen – Du
2. Modtageren – Brugeren
3. Certificate Authority – Trusted Third Party (Eller dig i nogle tilfælde)

Processen der holder tingene trygge er “Afsenderen”, genererer et par nøgler (offentlige og private). Jeg kan godt lide at henvise til disse som nøgle og lås for en bedre visuel. Nøglen (privat) bør aldrig forlade afsenderens besiddelse, det er derfor, den kaldes en privat nøgle.

Afsenderen genererer derefter en Certificate Signing Request (CSR) med den offentlige nøgle (lås ), som videresendes til certifikatmyndigheden (Trusted Third Party), underskriver certifikatmyndigheden den offentlige nøgle (lås) med certifikatmyndighedens private nøgle.

Certifikatmyndigheden sender nu den offentlige nøgle “afsenderne” som er underskrevet af certifikatmyndighedens private nøgle tilbage til “afsenderen”, som nu er certifikatet.

Modtageren får certifikatet (lader sig sige gennem webbrowseren) og kontrollere, at det er gyldigt med certifikatmyndighedernes offentlige nøgle, som både “afsenderen” og “modtageren” har, da de er den betroede tredjepart. Når den er bekræftet, kan den offentlige nøgle i certifikatet stole på * at være “Afsenderens” offentlige nøgle uændret.

Hvis “Modtageren” skal sende data til “Afsenderen”, vil de bruge offentlig nøgle fra det betroede certifikat for at kryptere dataene i cypertekst, som derefter sendes videre til “Afsenderen”. Da kun “Afsenderens” private nøgle kan dekryptere den cyphertext, der blev krypteret med “Afsenderens” offentlige nøgle nogen i midten har i det væsentlige ubrugelig forvansket tekst.

I visse tilfælde kan “afsenderen” generere sin egen certifikatmyndighed ved at underskrive deres egen CSR med et andet sæt nøgler eller selvsignere med det samme sæt nøgler. I dette tilfælde skal “Afsenderens” offentlige nøgle være kendt af begge parter gennem en sikker kanal for at have tillid. I software kan du medtage et certifikat i det leverede, der kan bruges som den betroede tredjepart.

* betroet er kun gyldigt, hvis certifikatmyndigheden opretholder en CRL (Certificate Revocation List) og alle parter overvåger listen for at sikre, at det udstedte certifikat ikke er kompromitteret. Sagen, hvor certifikatmyndigheden er kompromitteret, og den private nøgle er lækket, eksisterer, og når det sker, kan den kompromitterende agent bruge den private nøgle til at generere et betroet certifikat, der efterligner “afsenderen” , i så fald er en MITM mulig, og MITMen kan modtage data fra “afsenderen” dekryptere, gemme, kryptere med et gyldigt certifikat, der ligner “afsenderen” og derefter sende det til “modtageren”.

Tag den krypterede private nøgle ud af kopien af det CA-certifikat, du oprettede (når du giver den til andre). Den private nøgle gør behøver ikke være der, medmindre du skal bruge det til at underskrive et certifikat, der indeholder en anoth er offentlig nøgle.

Når du sender over din offentlige nøgle, skal du i stedet sende et helt certifikat (undtagen den private nøgle), underskrevet ved hjælp af den tilknyttede private CA-nøgle. For at kontrollere gyldigheden af den offentlige nøgle inde i den, skal du kontrollere hash af certifikatet mod det krypterede hash (der blev krypteret ved hjælp af CAs private nøgle). Dette dekrypteres ved hjælp af CAs offentlige nøgle . Hvis dekrypteringen er vellykket, og hashen svarer til certifikatets hash, kan oplysningerne inde i certifikatet stole på.

Der er også mere ved det end bare kryptering, for eksempel et gentagelsesangreb, hvor en hacker sender tidligere gemte krypterede data. TLS dækker meget mere end den gennemsnitlige person ville tro, og det anbefales absolut ikke at implementere et lignende system. Brug TLS når det er muligt til alt, hvad der er beregnet til at være privat.