Esta guía permite configurar un servidor IIS7 para que solicite certificados de autenticación del DNIe (DNI electrónico). Buena parte de lo que aquí cuento forma parte de un piloto desarrollado por Paco del Campo.
Algunas cosas que rodean al DNIe parecen seguir el principio de security through obscurity. Lástima que el portal del DNI Electrónico no tenga información sobre los dos perfiles fundamentales en la difusión de los servicios con autenticación digital, los programadores y los técnicos de sistemas.
Posibles usos de los certificados
Un sitio web puede utilizar certificados del DNIe para identificar de forma completamente segura a un usuario de un servicio electrónico.
Si los usuarios que acceden son totalmente desconocidos para nuestra organización (no tenemos cuenta de usuario o forma de identificación equivalente), el certificado nos permite conocer la identidad del solicitante, su nombre y su NIF. Con estos datos, podemos asociarlos a un posible registro existente en nuestra base de datos o crear un nuevo registro.
Si por contra, el usuario del DNIe tiene una cuenta de usuario en nuestro directorio, podemos decidir asociar la clave pública de este certificado con esa cuenta de usuario. De esta forma, tendremos un método de autenticación de alta seguridad, que podría reemplazar al tradicional usuario/contraseña.
Pasos a seguir
El proceso consta de las siguientes fases:
- Registrar en el servidor los certificados de la CA raíz y de la CA subordinada del DNIe
- Instruir a IIS7 para que solicite certificados de cliente,
- Definir el tipo de equivalencia entre certificados y cuentas de usuario
- Decidir qué política se va a seguir con la validación de certificados revocados
Antes de empezar, es fundamental asegurarse de que el cliente en el que está el lector de DNIe funciona correctamente, validándolo con alguno de los servicios de dnielectronico.es.
Registro de CAs
El servidor IIS debe tener registradas las CA raíz y subordinadas que permitan validar los certificados que queremos emplear, en nuestro, la CA Raíz y la CA subordinada 001.
Se descargan en el servidor y se da doble clic para instalarlas. Dentro del asistente para importarlas, es importante elegir la opción de selección manual del almacén de certificados, y la opción 'mostrar almacenes físicos'. De esta forma, siendo administradores de la máquina, podemos registrar los certificados en el almacén de sistema, de forma que otros servicios puedan verlos. Si no somos administradores, o UAC está activo, los certificados se registrarán para este usuario.
En de la CA raíz se meterá en el de "Entidades de certificación raíz de confianza" y el de la subordinada en "Entidades de certificación intermedias".
Configuración de IIS7
Tenemos que activar SSL en el servidor web deseado, para lo que se seguirán los pasos de generar o solicitar un certificado y activar el binding del servidor al puerto 443. Es importante comprobar en este punto que somos capaces de establecer una conexión segura al servidor.
El siguiente paso es indicar a IIS7 que queremos utilizar certificados de cliente en el proceso de establecimiento de la conexión SSL. Esto se realiza desde la configuración de SSL de IIS.
También debemos revisar la configuración de autenticación, para asegurarnos, con independencia del tratamiento de los certificados, que nuestro sitio tiene permisos correctos de acceso, que se controlarán limitando los permisos de las carpetas IIS correspondientes.
Ahora tenemos que decidir cómo hacer la equivalencia entre certificados y cuentas de usuario de la máquina. Hay dos posibilidades:
- Uno a uno (oneToOneMappings): el usuario del certificado tiene ya una cuenta en nuestro dominio, por lo hacemos que cada certificado equivalga a una cuenta del dominio o de la máquina. La asociación se hace con la clave pública del certificado.
- Muchos a uno (manyToOneMappings): hacemos que todos los certificados que cumplan un determinado criterio se asocien a una cuenta del dominio o de la máquina, que es la que finalmente accederá a los contenidos. Este escenario es el más habitual cuando no conocemos a priori los certificados que vamos a manejar, en el que cualquier certificado válido puede ser usado para acceder a nuestro servicio.
La configuración de estas opciones no se puede realizar directamente desde la administración de IIS, sino editando los ficheros XML del directorio \Windows\System32\inetsrv\config, en concreto el fichero applicationHost.config.
Sin embargo, hay una herramienta tremendamente útil que nos ayudará, el Administration Pack para IIS (versión beta, para entornos x32, hay otra descarga para x64), que ofrece "Configuration Editor", una herramienta que se integra con la consola de administración y que permite editar cualquier parámetros de los ficheros .config generales o específicos de una web, explorar las posibles configuraciones (analiza el esquema de los ficheros), buscar... Una vez instalado, aparece en la parte de abajo de las herramientas de administración.
Vamos a realizar una configuración manyToOne, por lo que abriremos en Configuration Editor en el servidor deseado, y exploramos la clave system.webServer/security/authentication/iisClientCertificateMappingAuthentication.
En esta página se explica cómo hacer el mapeo oneToOne, similar a lo aquí expuesto, salvo por la necesidad de incorporar la clave pública del certificado que se desea asociar.
Activamos la opción manyToOneCertificateMappingsEnabled y entramos en la opción ManyToOneMappings, en la que definiremos cada una de las asociaciones.
Creamos una asociación, dándole un nombre descriptivo, e introduciendo los datos de una cuenta de usuario que será la que acceda a los contenidos para los usuarios que se validen con el certificado correspondiente. Es conveniente crear una cuenta sin ningún tipo de privilegio, y añadirla a la seguridad de acceso de la carpeta IIS que tenga los contenidos.
Ahora tenemos que crear una o varias reglas, que serán los patrones de certificados que aceptamos para esta asociación. Podemos hacer reglas muy generales (todos los certificados de una autoridad) u otras más específicas. Para ello, elegimos qué campo/subcampo del certificado queremos usar y cuál debe ser su valor. Se pueden usar wildcards como *.
En nuestro caso, el certificateField es el Issuer, y dentro del mismo, elegimos el certificateSubField OU, que en el caso del DNIe es DNIE.
Aceptamos todos los cambios realizados.
Validación de certificados revocados
Por defecto IIS tratará de validar el estado de revocación de los certificados empleados, pero por defecto, no existe un servicio OCSP en el que validarlos.
El Ministerio de Industria tiene un servicio OCSP operativo en http://ocsp.ctpa.mityc.es. Para poder usarlo, debemos modificar las propiedades de la CA intermedia AC DNIE 001. Para modificarlo, abrimos una mmc de certificados sobre la cuenta de máquina y editamos las propiedades (con botón derecho sobre la CA) de AC DNIE 001, añadiendo un servicio OCSP adicional a la dirección anterior.
La otra posibilidad es desactivar la validación de las listas de revocación, en caso de que no tengamos acceso a la red o queramos que sea así. Tenemos que usar la herramienta netsh para modificar sus propiedades.
Arrancamos netsh y usamos el comando http para entrar en este contexto. Con el comando show sslcert veremos la relación completa de endpoints http definidos, alguno de los cuales tiene ssl activo. Podemos ver uno concreto con la opción ipport.
Es importante copiar toda la configuración que se muestre del que queremos cambiar, porque tendremos que borrarlo y crearlo de nuevo (se puede hacer show, delete y add, pero no set ¿?).
Vemos la configuración completa:
Lo borramos con:
delete sslcert ipport=192.168.0.103:443
Y lo creamos de nuevo, cambiando la opción verifyclientcertrevocation.
add sslcert ipport=192.168.0.103:443 certhash=16d044b6c802473cc3c59c204e8f92928b3dd011
appid={4dc3e181-e14b-4a21-b022-59fc669b0914} certstorename=MY
verifyclientcertrevocation=disable
Y comprobamos todo...
Creamos una página default.aspx en el servidor, con un código que nos permita recoger y mostrar los datos del certificado, para así asegurarnos que todo funciona.
<%@ Page Language="C#"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Untitled Page</title>
</head>
<body>
<h2>Información en el certificado</h2>
<p>
<%
HttpClientCertificate cs = Request.ClientCertificate;
Response.Write("ClientCertificate Settings:<br>");
Response.Write("Certificate = " + cs.Certificate + "<br>");
Response.Write("Cookie = " + cs.Cookie + "<br>");
Response.Write("Flags = " + cs.Flags + "<br>");
Response.Write("IsPresent = " + cs.IsPresent + "<br>");
Response.Write("Issuer = " + cs.Issuer + "<br>");
Response.Write("IsValid = " + cs.IsValid + "<br>");
Response.Write("KeySize = " + cs.KeySize + "<br>");
Response.Write("SecretKeySize = " + cs.SecretKeySize + "<br>");
Response.Write("SerialNumber = " + cs.SerialNumber + "<br>");
Response.Write("ServerIssuer = " + cs.ServerIssuer + "<br>");
Response.Write("ServerSubject = " + cs.ServerSubject + "<br>");
Response.Write("Subject = " + cs.Subject + "<br>");
Response.Write("ValidFrom = " + cs.ValidFrom + "<br>");
Response.Write("ValidUntil = " + cs.ValidUntil + "<br>");
Response.Write("What's this = " + cs.ToString() + "<br>");%>
</p>
</body>
</html>
Si algo falla, recibiremos mensajes de error en el cliente. Lo mejor es comprobar en los ficheros de log del servidor (\inetpub\logs\) para ver el código y subcódigo de error (ej. 403.16) y así analizar qué es lo que está fallando.
Y si todo va bien:
