El servicio de autenticación tiene que ver con garantizar que una comunicación sea autentica. En el caso de un solo mensaje, tales como una señal de alarma o peligro, la función del servicio de autenticación es garantizar al receptor que el mensaje viene desde la fuente que el mensaje dice que vino. En el caso de una interacción de mensajes, tal como una conexión TLS, el servicio abarca dos aspectos:
![]() |
En el momento de la iniciación de la conexión, el servicio garantiza que las dos entidades son autenticas, esto es, que cada una es la entidad que esta dice que es. |
![]() |
El servicio debe garantizar que la conexión no vaya a ser interferida de manera tal que una tercer parte pueda camuflarse como una de las dos partes legitimas con el proposito de transmitir o recibir mensajes de forma no autorizada. |
Con referencia al primer punto, otra cosa a tener en cuenta es que cuando hablamos de Internet o el protocolo TCP/IP, estamos hablando de una metodologia de desarrollo de sistemas del tipo Cliente/Servidor. Cuando queremos establecer una conexión TLS, una de las partes actua como servidor, brindando algún tipo de servicio. La otra parte actua como un cliente, haciendo pedidos al servidor, para que luego este último retorne un resultado.
La forma de autenticar las partes en una conexión cliente/servidor no es simétrica, sino que depende de si es el cliente quien quiere autenticar al servidor, o es el servidor quien quiere autenticar al cliente.Además, cuando se autentica un server, lo que se esta autenticando es la organización que es responsable por el servidor en el que corre el servicio, un una cierta dirección IP. Cuando se autentica un cliente, lo que se esta autenticando es el usuario que esta corriendo el programa cliente.
Comunmente se usan cinco tipos de certificados:
![]() |
Certificados de clientes TLS/SSL (*): Se usan para identificar clientes a los servers via TLS/SSL (autenticación de clientes). Tipicamente, se asume que la identidad del cliente es la misma que la identidad de un ser humano, tal como un empleado de una empresa. |
![]() |
Certificados de server TLS/SSL (*): Se usan para identificar servers a los clientes via TLS/SSL (autenticación de server). La autenticación del server podria ser usada con o sin la autenticación del cliente. |
![]() |
Certificados S/MIME: Son usados para e-mail firmado y encriptado. Como con los certificados de clientes TLS/SSL, la identidad del cliente se asume que tipicamente sea la misma que la identidad de un ser humano, tal como el empleado de una empresa. Un simple certificado podria ser usado como un certificado S/MIME y un certificado TLS/SSL. |
![]() |
Certificados para firmar objetos: Se usan para identificar firmantes de código en Java, scripts en JavaScript, u otros archivos firmados. Por ej. las clases de un applet Java estan firmados y comprimidos en un archivo JAR. |
![]() |
Certificados de CA: Se usan para identificar CAs. Los software cliente y server usan certificados de CA para determinar que otros certificados son confiables. |
(*) La notación "TLS/SSL" no significa que el nombre del certificado sea ese, sino que existen certificados de esos tipos tanto para SSL como para TLS.
El software cliente que requiera un servicio de un servidor
(por ej. una página de un servidor de Web), el cual se va a
transferir a traves de una conexión TLS, puede querer tener
cierta validación criptografica de la identidad del servidor, es
decir que quiere autenticar que el server que envía la
información es realmente quien dice que és.
A modo de ejemplo, el browser Netscape Navigator siempre requiere
la autenticación del server de Web antes de establecer una
conexión TLS.
Como se explicó en el Paso 2 del
Handshake Protocol, el server envía un certificado X.509 para
autenticarse a si mismo. El cliente usa ese certificado en el Paso 3 para autenticar la
identidad del server que el certificado dice que representa.
Para autenticar el enlace entre una clave pública y el server identificado por el certificado que contiene la clave pública, un cliente con capacidad para usar TLS (o SSL) debe recibir un "SI" por respuesta a las cuatro preguntas mostradas en la Tabla 1 a fin de poder autenticar la identidad del server. Aunque la cuarta pregunta técnicamente no es parte del protocolo TLS, es responsabilidad del cliente soportar este requerimiento, el cual ofrece alguna garantia de la identidad del server y además ayuda a protegerse contra un tipo de ataque a la seguridad conocido como "man in the middle" (hombre en el medio).
1. La fecha de hoy esta dentro del período de validez del certificado? | El cliente chequea el período de validez del certificado del server. Si la fecha y hora corriente estan fuera del rango, el proceso de autenticación se detiene y la respuesta es "NO". Si la fecha y hora corriente estan dentro del período de validez del certificado, el cliente pasa a la pregunta 2. |
2. El CA emisor es un CA confiable? | Cada cliente con capacidades TLS (o SSL) mantiene una lista de certificados de CA confiables (ver Figura 2). Esta lista determina cuales certificados de server aceptará el cliente. Si el distinguished name (DN) del CA emisor es igual al DN de un CA en la lista del cliente de CAs confiables, la respuesta a esta pregunta es SI, y el cliente va a la pregunta 3. Si el CA emisor no esta en la lista, el server no será autenticado a menos que el cliente pueda verificar que haya una cadena de certificados que termine en un CA que esté en la lista (ver Jerarquias de CAs para detalles). |
3. La clave pública del CA emisor valida la firma digital del server? | El cliente usa la clave pública del certificado del CA (el cual encontró en su lista de CAs confiables en la pregunta 2) para validar la firma digital del CA que esta en el certificado del server siendo presentado. Si la información en el certificado del server ha cambiado desde que fue firmado por el CA o si la clave pública del certificado del CA no corresponde a la clave privada usada por el CA para firmar el certificado del server, el cliente no autentica la identidad del server, y la respuesta es "NO". Si la firma digital del CA puede ser validada, el cliente trata el certificado del usuario como una "carta de presentación" valida de ese CA y procede. En este punto, el cliente ya tiene determinado que el certificado del server es valido. Es responsabilidad del cliente ahora hacer la pregunta 4 antes del paso final. |
4. El nombre de dominio especificado en el DN del server es igual a nombre de dominio real? | Este paso confirma que el server realmente esta localizado en la misma dirección de red (dirección IP) especificada por el nombre de dominio en el certificado del server. Aunque este paso no sea tecnicamente parte del protocol TLS, provee la única protección contra una forma de ataque a la seguridad conocida como Man-in-the-Middle Attack (ver en [4] o [6]). El cliente toma la dirección IP especificada en el DN del certificado del server y hace un pointer query al servidor de DNS. Los clientes deben ejecutar este paso y deben rechazar la autenticación del server o establecer una conexión si los nombres de dominio no son iguales. Si el nombre de dominio real del server es igual al nombre de dominio en el certificado del server, el cliente va al paso final. |
Figura 2: Lista de CAs
confiables en Internet Explorer
5. Paso final: El server es autenticado. El cliente procede con el handshake de TLS. Si el cliente no llega a este paso por alguna razón, significa que el server identificado por el certificado no puede ser autenticado, y el usuario será avisado del problema y se le informará que no se puede establecer una conexión encriptada y autenticada. Si el server requiere la autenticación del cliente, el server lleva a cabo los pasos descriptos en Autenticación del Cliente.
Después de los pasos descriptos aquí, el server debe usar exitosamente su clave privada para desencriptar el premaster secret que el cliente envia en el Paso 4 del Handshake TLS. De otra forma, la sesión TLS será terminada. Esto provee una garantia adicional de que la identidad asociada con la clave pública en el certificado del server es de hecho la del server con el cual esta conectado el cliente.
Los servers preparados para usar TLS pueden ser configurados para requerir que el cliente sea autenticado, para tener cierta garantia de la identidad del cliente. Cuando un server configurado de esta manera requiere autenticación del cliente (ver Paso 6 del Handshake Protocol), el cliente envia al server un certificado X.509 y separadamente envia también ciertos datos firmados digitalmente para autenticarse a sí mismo. El server usa los datos firmados digitalmente para validar la clave pública en el certificado y para autenticar la identidad que el certificado dice que representa.
El protocolo TLS requiere que el cliente cree una firma digital a partir de datos generados aleatoriamente (conocidos solo por el cliente y el server), los cuales se les aplica una función de hashing (tal como por ej. MD5 o SHA-1) durante el handshake. El hash de los datos luego se encripta con la clave privada que corresponde a la clave pública en el certificado presentado al server.
Para autenticar el enlace entre la clave pública y la persona u otra entidad identificada por el certificado que contiene la clave pública, un server que usa TLS debe recibir una respuesta "SI" a las primeras cuatro preguntas mostradas en la Tabla 2. Aunque la quinta pregunta no es parte del protocolo TLS, los servers pueden ser configurados para soportar este requerimiento para tomar ventaja de la entrada de un usuario en un directorio LDAP como parte del proceso de autenticación (por ej., los servidores Web de Netscape tienen este requerimiento).
Un server que usa TLS hace las siguientes preguntas para autenticar la identidad de un usuario:
1. La clave publica del usuario valida a su firma digital? | El server chequea que la firma digital
del usuario pueda ser validada con la clave pública del
certificado. Si es así, el server ha establecido que la
clave pública que se afirmaba pertenecia al usuario
cliente (digamos Juan Perez) se corresponde con la clave
privada usada para crear la firma y que los datos no han
sido adulterados desde que fueron firmados. No obstante, en este punto, el enlace entre la clave pública y el DN especificado en el certificado no ha sido establecido aún. El certificado podria haber sido creado por alguien intentando personificar al usuario. Para validar el enlace entre la clave pública y el DN, el server debe completar también la pregunta 3 y la pregunta 4. |
2. La fecha de hoy esta dentro del período de validez? | El server chequea el período de validez del certificado. Si la fecha y hora corriente estan afuera de ese rango, el proceso de autenticación se detiene aqui. Si la fecha y hora corriente estan dentro del período de validez del certificado, el server va a la pregunta 3. |
3. El CA emisor es un CA confiable? | Cada server que use TLS mantiene una lista de certificados de CA confiables, de forma similar a la Figura 2. Esta lista determina cuales certificados aceptará el server. Si el DN del CA emisor es igual al DN de un CA en la lista de CAs confiables del server, la respuesta a esta pregunta es "SI", y el server va a la pregunta 4. Si el CA emisor no esta en la lista, el cliente no será autenticado a menos que el server pueda verificar una cadena de certificados terminando en un CA que este en la lista (ver Jerarquias de CAs para detalles). Los administradores pueden controlar cuales certificados son confiables o cuales no son confiables dentro de sus organizaciones controlando las listas de certificados de CA mantenidas por clientes y servers. |
4. La clave pública del CA emisor valida la firma digital del cliente? | El server usa la clave pública del certificado del CA (el cual se encuentra en la lista de CAs confiables en la pregunta 3) para validar la firma digital del CA sobre el certificado siendo presentado. Si la información en el certificado ha cambiado desde que fue firmado por el CA o si la clave pública en el certificado del CA no corresponde a la clave privada usada por el CA para firmar el certificado, el server no autenticará la identidad del usuario. Si la firma digital del CA puede ser validada, el server trata al certificado del usuario como una "carta de presentación" válida que viene de ese CA y procede. En este punto, el protocolo TLS permite al server considerar que el cliente esta autenticado y procede con la conexión como se describe en la pregunta 6. También, algunos servers pueden ser configurados opcionalmente para hacer la pregunta 5 antes que la pregunta 6. |
5. El certificado del usuario esta listado en la entrada LDAP de ese usuario? | Este paso opcional provee una manera para que un administrador del sistema revoque un certificado de un usuario aún si este pasa todas las preguntas anteriores. Algunos servers de CAs (por ej. el Netscape Certificate Server) puede automaticamente borrar un certificado revocado de la entrada del usuario en el directorio LDAP. Entonces, todos los servers que estan configurados para ejecutar este paso se negarán a autenticar ese certificado o establecer una conexión. Si el certificado del usuario en el directorio es identico al certificado del usuario presentado en el handshake TLS, el server pasa a la pregunta 6. |
6. El cliente autenticado esta autorizado para tener acceso a los recursos que requirió? | El server chequea qué recursos se le permite acceder al cliente de acuerdo a las listas de control de acceso (ACLs) del server y establece una conexión con el acceso apropiado. Si el server no llega a la pregunta 6 por algún motivo, el usuario identificado por el certificado no puede ser autenticado, y al usuario no se le permite acceder a ninguno de los recursos del server que requieren autenticación. |
En las grandes organizaciones, podria ser apropiado delegar la responsabilidad de emitir certificados a muchas diferentes Certificate Authorities (CAs). Por ejemplo, el número de certificados podria ser demasiado grande como para que mantenga una sola CA; diferentes unidades organizacionales podrian tener diferentes politicas de requerimientos; o podria ser importante que un CA este físicamente localizado en algún área geografica cerca de la gente a quienes se emiten los certificados.
Es posible delegar las responsabilidades de emisión de certificados a CAs subordinados. El standard X.509 incluye un modelo para establecer una jerarquia de CAs como el mostrado en la Figura 3.
En este modelo, el CA raiz (root CA) esta en la cima de la jerarquia. El certificado del CA raiz es un certificado autofirmado: esto es, el certificado es firmado digitalmente por la misma entidad --el CA raiz-- que el certificado identifica. Los CAs que son subordinados directos del CA raiz tienen sus certificados de CA firmados por el CA raiz. En general:
![]() |
El certificado del CA raiz lo firma él mismo. |
![]() |
Los CAs a un nivel N+1 en la jerarquia tienen sus certificados firmados por el CA a nivel N. |
Las organizaciones tienen un amplio grado de flexibilidad en terminos de la forma en que establecen sus jerarquias de CA. La Figura 3 es simplemente un ejmplo; muchos otros arreglos son posibles.
Las jerarquias de CAs se reflejan en las cadenas de
certificados (certificate chain). Una cadena de
certificados es una serie de certificados emitidos por
CAs sucesivos.
Una cadena de certificados traza un camino de certificados desde
una rama en la jerarquia hasta la raiz de la jerarquia. En una
cadena de certificados ocurre lo siguiente:
![]() |
Cada certificado es seguido por el certificado de su CA emisor. |
![]() |
Cada certificado contiene el DN de ese emisor del certificado, el cual es el mismo que el subject name del próximo certificado en la cadena. |
![]() |
Cada certificado se firma con la clave privada de su emisor. La firma puede ser verificada con la clave pública en el certificado del emisor, el cual es el próximo certificado en la cadena. |
La verificación de una cadena de certificados es el proceso
de estar seguro que una cadena de certificados dada esta bien
formada, es válida, apropiadamente firmada, y fidedigna
(confiable).
Por ejemplo, el software de Netscape usa el siguiente
procedimiento para formar y verificar una cadena de certificados,
empezando con el certificado siendo presentado para autenticar:
![]() |
Se chequea el período de validez del certificado contra la fecha y hora corriente provista por el reloj del sistema en que se esta verificando. |
![]() |
Se localiza el certificado del emisor. La fuente puede ser ya sea la lista de certificados de CA confiables del verificador (sobre el cliente o el server) o la cadena de certificados provista por el subject (por ejemplo, sobre una conexión TLS). |
![]() |
Se verifica la firma del certificado usando la clave pública en el certificado del emisor. |
![]() |
Si el certificado del emisor es confiable por el verificador en la lista de certificados de CA del verificador, la verificación se detiene exitosamente aqui. De otra forma, el certificado del emisor se chequea para estar seguro que contiene la indicación de CA subordinado apropiada en la extensión de tipo de certificado Netscape, y la verificación de la cadena retorna al paso 1 para empezar de vuelta, pero con este nuevo certificado. |
Fechas de validez expiradas, una firma invalida, o la ausencia de un certificado para el CA emisor en cualquier punto en la cadena de certificados causa que la autenticación falle.