
29/06/2005, 04:13
|
| | Fecha de Ingreso: marzo-2004
Mensajes: 142
Antigüedad: 21 años Puntos: 0 | |
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.
Última edición por Enriquez; 29/06/2005 a las 04:26 |