Certificat de servidor

4 Maig 2014
Josep Ma Solanes 0

Quina creu això dels certificats! Però no m’he pogut estar d’intentar explicar de manera planera per a què necessitem els certificats.

Aquesta entrada fa referència a l’ús de certificats en la banda servidor, és a dir, per protegir un servei que volem oferir. Digueu-li Web, correu electrònic, VPN, connexió Wi-Fi, etc…

El certificat al costat servidora serveix per protegir la COMUNICACIÓ, el transport de les dades, no l’AUTENTICACIÓ de l’equip o usuari que es fa d’una altre forma.

Per a què em serveix posar un certificat?

El certificat serveix per protegir la comunicació entre un client i el servidor, establint un canal de comunicació segur. A l’estil de les pel·lícules d’espies, com si fos el telèfon vermell. D’aquesta manera s’intenta evitar que algú pugui estar mirant què s’està enviant o parlant entre ells. L’ús de certificats en els servidors ha de ser l’habitual i exigible en tots els serveis segurs que hi ha a Internet o dins l’empresa i, dels que com usuari, heu d’assegurar que així sigui quan s’introdueixen dades sensibles: comptes d’usuari i contrasenyes, accés al banc, targetes de crèdit, contractes, correu electrònic, etc… En aquest aspecte, hem d’estar atents que no s’intenti substituir el certificat del servidor per un altre. Seguint el símil dels espies, equivaldria a l’agent secret que segresta l’espia i es fa passar per ell per obtenir la informació desitjada. L’error que sempre he trobat en aquests casos,  és que el comprador no tingui almenys una foto de l’espia per poder verificar la seva identitat a simple vista. Les pel·lícules són pel·lícules. En l’entorn de certificats, el servidor (seria com el comprador o venedor de la peli), gairebé mai coneix al client (l’espia o comprador del material). Per tant, s’ha d’idear una manera en que el client, automàticament i de forma transparent, pugui passar informació secreta al servidor sense que ningú més es pugui posar pel mig. Aquesta manera és amb la utilització dels certificats en els servidors.

Quins elements hi intervenen?

Entitat Certificadora

En tota infraestructura de certificats, el primer què necessito és algú que generi i validi que els certificats que s’utilitzen són els correctes, que els ha generat qui diu que és i no qualsevol altre. Això s’aconsegueix amb l’ENTITAT CERTIFICADORA. Aquesta pot ser comercial (“pública”) o pròpia. Poso pública entre cometes perquè la confiança amb l’entitat certificadora és sempre això, una relació de confiança. Depèn de cadascú que confiï en una entitat certificadora. Si no hi ha manera de què el client i el servidor parlin prèviament per posar-se d’acord en l’entitat certificadora a utilitzar, el seu serà que tots dos confiïn en un tercer que proporcioni aquesta seguretat, equivaldria a un mediador que coneix totes les parts.

No existeix una entitat certificadora “bona”, totes són bones i dolentes a la vegada, és una qüestió de confiança.

En el cas d’Espanya, hi ha certes entitats certificadores validades per l’estat (Fábrica de Moneda y Timbre, ID Cat, Camerfirma, etc…) per tramitacions legals dins el territori (declaració de la renta, firma de documents, facturació electrònica, etc…), però que siguin “legals” a Espanya no vol dir que ho siguin a França. Cadascú escombra cap a casa seva i de moment no hi ha una entitat d’administració pública que les pugui agrupar a totes. Si utilitzeu els certificats de ID Cat o Camerfirma el més normal és que aparegui el missatge de no confiança amb l’entitat certificadora. Això és així perquè aquests organismes no han afegit el certificat de la seva entitat als navegadors per defecte. Pel que s’ha de fer manualment com en qualsevol altre entitat. És una operació habitual. Claus públiques de IDCat Per tant, el primer què s’ha de fer com a client és confiar amb l’entitat certificadora que ha emès els certificats que utilitzen els servidors. Cal afegir el certificat de l’entitat emissora a l’aplicació que s’hagi d’utilitzar (ja sigui el navegador, el lector PDF, el correu electrònic, etc…); com a Entitat de certificació arrel de confiança. D’aquesta manera, quan un servei presenti un certificat emès per l’entitat certificadora corresponent, l’aplicació podrà comprovar que el certificat ha estat generat per aquesta entitat i no per una altre. En cas que no confiem amb l’entitat certificadora que genera els certificats, no es podrà fer aquesta comprovació i en el navegador apareixerà el molest missatge, que la majoria accepta sense llegir, informant que no es pot comprovar l’identitat del lloc. En altres tipus d’aplicacions (VPNs, Wi-Fi, etc…) el més normal és que, al no poder comprovar l’identitat del certificat, no es generi la comunicació. Error de confiança en el certificat del servidor

Certificat de servidor

L’altre element necessari és el certificat que s’assigna al servei del servidor. El que s’instal·la al servidor Web, VPN, Wi-Fi, etc… Aquest certificat conté una clau pública (contrasenya pública) i una clau privada (contrasenya privada) i NO s’ha de distribuir MAI als clients, només s’ha d’instal·lar als servidors que proporcionin el servei. Ho remarco perquè és l’error més comú amb el que em trobo, que s’instal·li o distribueixi aquest certificats als clients. Un cop instal·lat el certificat al servei que es vol protegir, a grans trets, aquest és el funcionament que segueix:

  • L’usuari accedeix al servei mitjançant l’aplicació corresponent, per exemple, amb un navegador a una web segura.
  • El servidor detecta la connexió a la web i presenta el certificat associat, proporcionant la clau pública del certificat del servidor al client.
  • El navegador del client comprova que el certificat que ha presentat el servidor és de confiança (pertany a una entitat certificadora donada d’alta en el navegador).
  • En cas afirmatiu, tanca la connexió amb el cadenat. En cas contrari, el navegador emet el missatge d’advertència de que el lloc no és segur.
  • El client es guarda la clau pública que utilitza per xifrar (protegir) totes les comunicacions amb el servidor.
  • A la vegada, el servidor rep les comunicacions xifrades del client que desxifra amb la seva clau privada. Al no tenir ningú més aquesta clau privada s’assegura la confidencialitat.

S’acaba d’establir un canal de comunicació segur amb dues parts (emissor i receptor) quan aquestes no es coneixen. Però en aquest punt no es comprova la identificació de la persona que vol accedir, el pas que correspon a introduir l’usuari, contrasenya, token, targeta de crèdit, etc… la responsabilitat del qual recau al propi servei. L’únic que s’ha fet ha estat protegir la comunicació perquè quan s’introdueixin aquestes o altres dades quedin al marge de mirades o orelles externes.

Conclusió

Per protegir una comunicació entre un servei i múltiples clients que no conec, la manera que tinc per fer-ho és utilitzar un certificat que controlo a la part servidora. Que a la vegada, els clients que accedeixin al servei han de confiar amb l’entitat certificadora que ha emès aquest certificat. El certificat de la part servidor NO el distribuiré mai als clients. En canvi, el certificat públic de l’entitat emissora m’interessa que es distribueixi com a més màquines i aplicacions millor perquè puguin utilitzar els meus serveis protegits.   T’ha agradat l’article? El pots compartir a les xarxes socials. També pots deixar la teva opinió, comentari o suggeriment. Gràcies!

Similar Posts by The Author:

 

Deixar un comentari

Recorda que no es contestaran preguntes personals, només d´interés comú que ens enriqueixin a tots.
La teva adreça de correu electrònic no serà publicada. Els camps obligatoris estan indicats.

Aquest lloc utilitza Akismet per reduir el correu brossa. Aprendre com la informació del vostre comentari és processada