Ervaring in die gebruik van Rutoken-tegnologie vir die registrasie en magtiging van gebruikers in die stelsel (deel 3)

Goeie dag!

In die vorige deel Ons het suksesvol ons eie sertifiseringsentrum geskep. Hoe kan dit nuttig wees vir ons doeleindes?

Deur 'n plaaslike sertifiseringsowerheid te gebruik, kan ons sertifikate uitreik en ook handtekeninge op hierdie sertifikate verifieer.

Wanneer 'n sertifikaat aan 'n gebruiker uitgereik word, gebruik die sertifiseringsowerheid 'n spesiale sertifikaatversoek Pkcs#10, wat die '.csr'-lêerformaat het. Hierdie versoek bevat 'n geënkodeerde volgorde wat die sertifiseringsowerheid weet hoe om korrek te ontleed. Die versoek bevat beide die gebruiker se publieke sleutel en data vir die skep van 'n sertifikaat ('n assosiatiewe skikking met data oor die gebruiker).

Ons sal kyk hoe om 'n versoek vir 'n sertifikaat in die volgende artikel te ontvang, en in hierdie artikel wil ek die hoofopdragte van die sertifiseringsowerheid gee wat ons sal help om ons taak aan die agterkant te voltooi.

So eers moet ons 'n sertifikaat skep. Om dit te doen gebruik ons ​​die opdrag:

openssl ca -batch -in user.csr -out user.crt

ca is die openSSL-opdrag wat verband hou met die sertifiseringsowerheid,
-batch - kanselleer bevestigingsversoeke wanneer 'n sertifikaat gegenereer word.
user.csr — versoek om 'n sertifikaat te skep (lêer in .csr-formaat).
user.crt - sertifikaat (resultaat van die opdrag).

Om hierdie opdrag te laat werk, moet die sertifiseringsowerheid presies gekonfigureer word soos beskryf in die vorige deel van die artikel. Andersins sal u die ligging van die wortelsertifikaat van die sertifiseringsowerheid ook moet spesifiseer.

Sertifikaatverifikasie opdrag:

openssl cms -verify -in authenticate.cms -inform PEM -CAfile /Users/……/demoCA/ca.crt -out data.file

cms is 'n openSSL-opdrag wat gebruik word vir die ondertekening, verifikasie, enkripteer van data en ander kriptografiese bewerkings met behulp van openSSL.

-verifieer - in hierdie geval verifieer ons die sertifikaat.

authenticate.cms - 'n lêer wat data bevat wat onderteken is met die sertifikaat wat deur die vorige opdrag uitgereik is.

-inform PEM - PEM-formaat word gebruik.

-CAfile /Users/……/demoCA/ca.crt - pad na die wortelsertifikaat. (sonder dit het die opdrag nie vir my gewerk nie, alhoewel die paaie na ca.crt in die openssl.cfg-lêer geskryf is)

-out data.file — Ek stuur die gedekripteerde data na die lêer data.file.

Die algoritme vir die gebruik van 'n sertifiseringsowerheid aan die agterkant is soos volg:

  • Gebruikersregistrasie:
    1. Ons ontvang 'n versoek om 'n sertifikaat te skep en dit in die user.csr-lêer te stoor.
    2. Ons stoor die eerste opdrag van hierdie artikel in 'n lêer met die uitbreiding .bat of .cmd. Ons hardloop hierdie lêer vanaf kode, nadat ons voorheen die versoek gestoor het om 'n sertifikaat te skep in die user.csr-lêer. Ons ontvang 'n lêer met die user.crt-sertifikaat.
    3. Ons lees die user.crt-lêer en stuur dit aan die kliënt.

  • Gebruiker magtiging:
    1. Ons ontvang ondertekende data van die kliënt af en stoor dit in die authenticate.cms-lêer.
    2. Stoor die tweede opdrag van hierdie artikel in 'n lêer met die uitbreiding .bat of .cmd. Ons hardloop hierdie lêer vanaf die kode, nadat ons voorheen die ondertekende data vanaf die bediener in authenticate.cms gestoor het. Ons ontvang 'n lêer met gedekripteerde data data.file.
    3. Ons lees data.file en kontroleer hierdie data vir geldigheid. Wat presies nagegaan moet word, word beskryf in die eerste artikel. As die data geldig is, word gebruikermagtiging as suksesvol beskou.

Om hierdie algoritmes te implementeer, kan jy enige programmeertaal gebruik wat gebruik word om die agterkant te skryf.

In die volgende artikel sal ons kyk hoe om met die Retoken-inprop te werk.

Skep 'n nuwe weergawe!

Bron: will.com

Voeg 'n opmerking