Certificados Digitales

[Jose_minglein2]

Ah, vale, ok, es que también puedes exportarlo sin clave privada, y me pensaba que te referias a eso.

Lo de la ventanita te lo dice si le dices que te lo diga, exactamente, de todas formas, también es bueno, que lo confirmes cada vez.

[wakewakeup]

Bueno eso ya lo dejaremos que lo decida cada usuario ;)
Hoy he avanzado mucho en esto de los certificados de cliente en parte gracias a ti :) Ahora me he quedado un poco bloqueado, ya que cuando activo en el IIS que pida certificados de cliente, no puedo abrir el proyecto aspnet de pruebas que utilizo. Sin los certificados de cliente se abre sin problemas... por si sabes que puede ser ya que te veo muy puesto te dejo la captura




PD: Por cierto, donde has aprendido tu estas cosas de certificados cliente?

[Jose_minglein2]

Es normal que te salga eso, es por no se que historia, del Visual, no se si se podrá, yo lo que hago para hacer pruebas, es darle a que no sea obligatorio SSL pero que acepte c.cliente (no que los requiera),

entonces, cuando genero la solución y ejecuto, paso de http a https (lo hago por código para no tener que cambiar la dirección siempre en la barra de direcciones), así pues, sale la ventanita, elijo el certificado y puedo ver todas las propiedades desde codigo y trabajar con el (agregarlo a la BD o lo que sea),

Pues la verdad es que a mi me ayudo mucho un compañero (Enriquez) y lo demás toqueteando un poco por aquí otro poco por allá, leyendo documentación en inglés (bueno intentando leer), porque como dices hay muy poca documentación.

[wakewakeup]

Ok, acabo de probar el metodo y tambien me funciona muchas gracias

[Enriquez]

Hola chabales... veo que estais hechos unos expertos ya ;)
Una cosilla, al principio yo ligaba la bbdd con los certificados por medio del campo E de los cert, pero esto me trajo problemas cuando empecé a usar certificados de la FNMT, ya que no tienen ese campo, tambien da problemas cuando un usuario tiene dos cert con el mismo campo E, etc. Yo me he acostumbrado a usar la clave pública que si que es unica y la tienen todos los cert, despues tengo una pequeña tabla con todos los cert que tiene cada usuario (si es que tiene mas de uno). Asi cuando le caducan y se emiten otros es facil ligar las cuentas.

[wakewakeup]

Iniciado por Enriquez

Hola chabales... veo que estais hechos unos expertos ya ;)
Una cosilla, al principio yo ligaba la bbdd con los certificados por medio del campo E de los cert, pero esto me trajo problemas cuando empecé a usar certificados de la FNMT, ya que no tienen ese campo,

Entonces el mail lo tienen en otro campo?

Iniciado por Enriquez

tambien da problemas cuando un usuario tiene dos cert con el mismo campo E, etc.

2 certificados con mismo campo E, y te refieres a mismo email no? no veo el problema...

Iniciado por Enriquez

Yo me he acostumbrado a usar la clave pública que si que es unica y la tienen todos los cert, despues tengo una pequeña tabla con todos los cert que tiene cada usuario (si es que tiene mas de uno). Asi cuando le caducan y se emiten otros es facil ligar las cuentas.

Si caduca el certificado cambia la clave publica?

[Enriquez]

Los certificados que estamos usando para autenticarnos como clientes en un IIS son de navegación, no de correo, por lo que no tienen por que tener un campo E, fíjate en el que tienes de la FNMT y veras que no tiene email (sin embargo tiene dos campos OU). Los certificados pueden tener campos como CN, GN, I, O, OU, L, S, C, E, T, etc.. pero cada CA emite sus certificados como Dios le da a entender y te puedes encontrar con cualquier cosa.. ;)

El problema... imagina que has cifrado datos de un usuario con su clave publica para que él los pueda descifrar con su privada, y puede entrar con dos cert que tienen el mismo email (campo E). Con uno de los dos no podrá descifrar, también tendrás problemas a la hora de comprobar firmas ya que no sabrás que cert tiene en la sesión y con cual firmó, etc ya que todo recae en el email, que es por otra parte una de las cosas mas fáciles de suplantar. Imagina que otro usuario (o tu mismo, que eres el primer sospechoso de suplantación ;) ) se saca un cert con esa cuenta... tendrías que estar comprobando continuamente su validez...


Cuando un certificado caduca, caduca. No cambia nada en él. El usuario se puede sacar otro o renovar ese con las mismas claves. En el segundo caso tendía otro cert con las mismas claves, pero el caducado seguiría caducado.
Este es un tema peligroso, hay que tenerlo previsto ya que toda la información cifrada para un cert, se pierde si este caduca, no podrás decirle al IIS que le deje pasar con un cert caducado. Hay que montar un pollo muy gordo para recuperar la información, manejando la privada a pelo en la máquina del usuario (que es donde esta). Avisa a tus usuarios antes de que pase esto con suficiente antelación, implementa para poder migrar una cuenta a otra con otro cert antes de que caduque, es decir, descifrar con el que esta a punto de caducar y cifrar con el nuevo.

[wakewakeup]

Iniciado por Enriquez

Imagina que otro usuario se saca un cert con esa cuenta... tendrías que estar comprobando continuamente su validez...

Hombre pero para que un CA le de el certificado comprobará su email antes, no?

Iniciado por Enriquez

Cuando un certificado caduca, caduca. No cambia nada en él. El usuario se puede sacar otro o renovar ese con las mismas claves. En el segundo caso tendía otro cert con las mismas claves, pero el caducado seguiría caducado.

Ya entiendo, lo que veo un poco royo es el mantenimiento de esas claves publicas, cada vez que tienes un nuevo usuario o cambia de clave publica. Para saber que la nueva clave publica es del mismo usuario al final tendras que comprobar algún campo del certificado a ver si coincide no?

[Enriquez]

Ya te comento que el campo no tiene por que existir, y mas en los de navegación. Los de la FNMT no lo tienen.
En los certificados de correo si que se comprueba, y precisamente los programas de correo como el Outlook, etc no dejan meter el cert a no ser que coincida la cuenta configurada con el campo E del cert.

Puedes hacer dos cosas, o dejar que la comprobación de la identidad la haga la CA y limitar en el IIS el uso de certificados solo a los emitidos por esa CA (la lista CTL del IIS), o comprobarlo tu que es el caso de usar cert emitidos por ti. Aunque no exista suplantación, que sea el mismo usuario el que tenga dos cert, tienes que tener un vinculo cert-email, es decir pareja_de_claves-email es decir pareja_de_claves-cuenta_en_tu_plataforma. Por eso te comento que es mejor hacerlo con la pública, es igual pero con la ventaja de que es única y solo la puede tener él, ya que para que se cree la sesión en el IIS tiene que firmar un hash con su privada (la famosa ventanita de que tanto se habla).

Yo lo que tengo implementado es una opción de meter mas cert en la misma cuenta, una especie de almacen de los cert de cada usuario (puede entrar con cualquiera de los que tenga), es el usuario el que da de alta y de baja los certificados que tiene o quiere, no hay problemas de suplantación ya que siempre está autenticado y es él el que comprueba su propia identidad. Una vez creada la cuenta con un cert que a mi me parezca de confianza, el resto de los cert no importan, ya le tengo pillado ;), pueden ser incluso gratuitos o emitido por el.

Si ya lo tienes implementado puedes crear una tabla con parejas Kpublica-email para poder hacer la comprobación de que el certificado usado es el correcto y no es otro con el mismo email.

[wakewakeup]

Iniciado por Enriquez

Ya te comento que el campo no tiene por que existir, y mas en los de navegación. Los de la FNMT no lo tienen.

Entonces, me estas diciendo que en un certificado de navegacion, el certificado puede llevar un email no comprobado?

Iniciado por Enriquez

Puedes hacer dos cosas, o dejar que la comprobación de la identidad la haga la CA y limitar en el IIS el uso de certificados solo a los emitidos por esa CA (la lista CTL del IIS), o comprobarlo tu que es el caso de usar cert emitidos por ti. Aunque no exista suplantación, que sea el mismo usuario el que tenga dos cert, tienes que tener un vinculo cert-email, es decir pareja_de_claves-email es decir pareja_de_claves-cuenta_en_tu_plataforma. Por eso te comento que es mejor hacerlo con la pública, es igual pero con la ventaja de que es única y solo la puede tener él, ya que para que se cree la sesión en el IIS tiene que firmar un hash con su privada (la famosa ventanita de que tanto se habla).

Ok, eso entiendo, una CA en la que tengo confianza me permite identificar que un usuario tiene permiso para entrar a mi sistema. Pero si yo quiero llevar un control de cuantas veces accede ese usuario al sistema para cobrarle yo de alguna forma tengo que saber quien es exactamente (no me vale con saber que tiene permiso para entrar). Entonces eso lo tendre que mirar en un campo del certificado, que le identifique en la vida real, un nombre o mail para vincularlo con una cuenta de mi sistema, no me vale una clave publica porque con eso no puedo saber el nombre de la empresa (por decirlo de alguna manera). No se si entiendes mi cacao mental...

[Enriquez]

Iniciado por wakewakeup

Entonces, me estas diciendo que en un certificado de navegacion, el certificado puede llevar un email no comprobado?

Exacto, si te digo que no existe como lo van a comprobar. En España hay dos millones de personas que hacen la declaración de hacienda por internet con certificados de la FNMT que no tienen email (E), y que por supuesto no ha podido comprobar nadie su cuenta de correo del certificado ya que estos no tienen ese campo y no se puede comprobar algo que no existe.


Que utilices la clave pública en tu software para relaccionar certificado y cuenta en tu plataforma, no quiere decir que no puedas leer los campos del cert para ver la identidad del propietario del certificado. No te lies, una cosa son las parejas de claves y otra la identidad física de alguien. Si yo firmo algo (cifro un hash con mi privada) puedo repudiarlo, ya que cualquiera puede generarse una pareja de claves (como en PGP). El no repudio viene cuando hay una tercera persona (la CA) que dice que el poseedor de la pareja de claves soy yo, y que me presenté en sus oficinas con el DNI en la boca cuando me emitieron el certificado. Resumiendo que si tu admites certificados de una CA de confianza, la identidad del usuario la garantiza la CA y tu solo tienes que leer los campos del certificado para estar seguro que es quien dice ser. Si despues quieres demostrar (ante un juez, o ante el que sea) que fulano ha entrado tantas veces, tendrás que hacerle firmas un texto cada vez que entre, o una factura, o la fecha y la hora, o lo que quieras, según el grado de repudio que esperes, suele ser suficiente con los log del IIS, que es lo que tienen los ISP normalmente.

P.D:La CA no le da permiso a nadie para entrar en tu plataforma, eres tu el que tienes que hacer una consulta a bbdd para ver que permisos tiene ese usuario identificado con un cert.

[wakewakeup]

Iniciado por Enriquez

Exacto, si te digo que no existe como lo van a comprobar.

jeje ya pero me referia a que en los casos en los que existe siempre lo comprobaran no? sino vaya autoridad certificadora mas cutre... entiendo yo.

Iniciado por Enriquez

P.D:La CA no le da permiso a nadie para entrar en tu plataforma, eres tu el que tienes que hacer una consulta a bbdd para ver que permisos tiene ese usuario identificado con un cert.

Ok, entonces yo tendria una tabla con las claves publicas de los usuarios, otra tabla con los usuario y el numero de accesos. Entonces llega fin de mes y yo quiero cobrar, donde busco la identidad de la persona para solicitarle el dinero? Yo solo tengo la clave publica pero solo son un monton de bits... Tengo que guardar tambien todo el certificado para ahí ver los demas campos? Cambiaran los demas campos cuando cambie de clave publica un mismo usuario?

[Enriquez]

Las comprobaciones que hacen las CA's son las que ponen en su documento de políticas de certificación, y cada una sigue unos criterios distintos, las habrá que si que comprueben esa dirección y otras que no ya que snifar correo o dar con la clave y el usuario de un POP3 es relativamente sencillo. Lo que si comprueban es la identidad, que es de lo que se trata.

Perdona, pero daba por obvio que tienes que guardar los campos del certificado en los procesos de alta de tus usuarios. Yo lo que hago es guardar en bbdd el cert completo (sin clave privada claro) es decir, guardo el Request.ClientCertificate("Certificate") pero si te es mas cómodo, guarda los campos que necesites, por ejemplo el campo E: Request.ClientCertificate("SubjectEMAIL").

Lo de la clave publica... no se pueden cambiar las claves de los cert, ya que la fima de la CA es el cifrado del hash del cert, si cambia algo se rompe la firma. Si cambia la pública de un usuario es que cambia el certificado, que tendrá los campos iguales, o distintos, salvo en el caso de renovación que será practicamente igual cambiando la fecha de expiración.

[wakewakeup]

Ok. Muchas gracias, creo que ahora si he entendido todo a pesar de lo mal que me explico ;)

[Jose_minglein2]

Joer, me voy 5 minutos y mira si avanzais en la conversación, jeje. Pues eso., añadir que, p.ej. el que comenta Enriquez de la FNMT, tienes que personarte con el DNI para obtenerlo y te dan una clave para descargarlo y tal, por eso no interviene para nada el e-mail.

[wakewakeup]

Jose no nos vuelvas a avandonar que luego te pierdes!! ;)

Oye y ya por curiosidad, ese de la FNMT? como se consigue? es gratis?

[Enriquez]

Si, es gratis, solo tienes que ser Españó

http://www.cert.fnmt.es/clase2/main.htm

Hay una CA que da certificados gratuitos y que tiene una red de "Notarios" (por llamarlo de alguna manera, por que no se si lo son). Pero su raiz no viene en el Explorer, echale un vistazo:

http://www.cacert.org/index.php?id=0&lang=es_ES

P.D: Espero que para el año que viene ya este en circulación el nuevo DNI con certificado y se nos rifen las empresas para currar ;)

[Jose_minglein2]

haber haber

[wakewakeup]

Tanto trabajo dará el nuevo dni? pues habrá que prepararse :)