Experiència en l'ús de la tecnologia Rutoken per registrar i autoritzar usuaris al sistema (part 3)

Bon dia!

A la part anterior Hem creat amb èxit el nostre propi centre de certificació. Com pot ser útil per als nostres propòsits?

Mitjançant una autoritat de certificació local, podem emetre certificats i també verificar signatures en aquests certificats.

Quan emet un certificat a un usuari, l'autoritat de certificació utilitza una sol·licitud de certificat especial Pkcs#10, que té el format de fitxer ".csr". Aquesta sol·licitud conté una seqüència codificada que l'autoritat de certificació sap analitzar correctament. La sol·licitud conté tant la clau pública de l'usuari com les dades per crear un certificat (una matriu associativa amb dades sobre l'usuari).

Veurem com rebre una sol·licitud de certificat al següent article, i en aquest article vull donar les ordres principals de l'autoritat de certificació que ens ajudaran a completar la nostra tasca al costat del backend.

Per tant, primer hem de crear un certificat. Per fer-ho fem servir l'ordre:

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

ca és l'ordre openSSL que es relaciona amb l'autoritat de certificació,
-batch: cancel·la les sol·licituds de confirmació quan es genera un certificat.
user.csr — sol·licitud per crear un certificat (fitxer en format .csr).
user.crt - certificat (resultat de l'ordre).

Perquè aquesta ordre funcioni, l'autoritat de certificació s'ha de configurar exactament com es descriu a la part anterior de l'article. En cas contrari, haureu d'especificar addicionalment la ubicació del certificat arrel de l'autoritat de certificació.

Ordre de verificació del certificat:

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

cms és una ordre openSSL que s'utilitza per signar, verificar, xifrar dades i altres operacions criptogràfiques mitjançant openSSL.

-verify - en aquest cas, verifiquem el certificat.

authenticate.cms: un fitxer que conté dades signades amb el certificat emès per l'ordre anterior.

-inform PEM - S'utilitza el format PEM.

-CAfile /Users/……/demoCA/ca.crt - camí al certificat arrel. (Sense això, l'ordre no va funcionar per a mi, tot i que els camins a ca.crt es van escriure al fitxer openssl.cfg)

-out data.file — Envio les dades desxifrades al fitxer data.file.

L'algorisme per utilitzar una autoritat de certificació a la part posterior és el següent:

• Registre d'usuari:
  1. Rebem una sol·licitud per crear un certificat i desar-lo al fitxer user.csr.
  2. Desem la primera ordre d'aquest article en un fitxer amb l'extensió .bat o .cmd. Executem aquest fitxer des del codi, havent desat prèviament la sol·licitud per crear un certificat al fitxer user.csr. Rebem un fitxer amb el certificat user.crt.
  3. Llegim el fitxer user.crt i l'enviem al client.

• Autorització d'usuari:
  1. Rebem dades signades del client i les desem al fitxer authenticate.cms.
  2. Deseu la segona ordre d'aquest article en un fitxer amb l'extensió .bat o .cmd. Executem aquest fitxer des del codi, havent desat prèviament les dades signades del servidor a authenticate.cms. Rebem un fitxer amb dades desxifrades data.file.
  3. Llegim data.file i comprovem la validesa d'aquestes dades. S'ha descrit el que cal comprovar exactament al primer article. Si les dades són vàlides, l'autorització de l'usuari es considera correcta.

Per implementar aquests algorismes, podeu utilitzar qualsevol llenguatge de programació que s'utilitzi per escriure el backend.

En el següent article veurem com treballar amb el connector Retoken.

Gràcies!

Font: www.habr.com