El uso de certificados es un método extendido dentro del mundo de la web y las aplicaciones cliente/servidor para crear conexiones seguras vía SSL y para autenticar/autentificar quién está detras de cada extremo de la conexión.
Un aplicación de los certificados es su uso para realizar una autenticación mútua entre un cliente y un servidor. Esto permite:
- Establecer una conexión segura ya que al contar el lado servidor con un par de claves, que será el origen de su certificado, puede también establecer una conexión segura vía SSL.
- Autenticar, no solo el lado servidor de la conexión, es decir, a que se está conectando el cliente, si no también autenticar al cliente, desde el punto de vista del servidor. Esto aumentará la seguridad del lado servidor, permitiendo el acceso solo a aquellos cliente que cuenten con el certificado deseado.
Los pasos para implementar una autenticación mútua con certificados usando el servidor de aplicaciones Tomcat y la herramienta de generación de claves y certificados de Java keytool, presente en cualquier JDK, son los siguientes:
1. Si aún no se tiene, se crea el almacén de claves del servidor con su par de claves correspondiente:
|
1 |
keytool -genkey -keystore D:\appservers\tomcat.keystore -alias tomcat -keyalg RSA –keypass bobdog |
2. Se exporta el certificado del servidor a partir del par de claves anteriormente creado:
|
1 |
keytool -export -alias tomcat -keypass bobdog -file server.cer -keystore tomcat.keystore |
3. Se añade el certificado del servidor al almacén de claves que usa el cliente desde la aplicación que emplea para conectar al servidor:
|
1 |
keytool –import –alias server –keystore “C:\Archivos de programa\Java\jdk1.6.0_33\jre\lib\security\cacerts” –file server.cer |
4. Creamos un nuevo par de claves para el cliente:
|
1 |
keytool -genkey -alias cliente -keyalg RSA -storetype PKCS12 -keystore cliente.p12 |
Almacenamos el par de claves como de tipo PKCS12 para poder importar posteriormente otros certificados de cliente generados a partir de los navegadores web.
5. Generamos el certificado del cliente:
|
1 |
keytool -export -alias cliente -keystore cliente.p12 -storetype PKCS12 -file cliente.cer |
6. Añadimos al almacén de claves del servidor el certificado del cliente que queremos autenticar:
|
1 |
keytool -import -v -file cliente.cer -keystore tomcat.keystore |
7. Si aún no se ha relizado, se configura Tomcat para que use la conexión segura vía SSL:
En el fichero de configuración de Tomcat <TOMCAT_HOME>\conf\server.xml se descomenta el conector definido para SSL. Además se añaden la ruta al almacén de claves del servidor y el password para acceder al mismo.
|
1 2 3 4 5 |
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" keystoreFile="D:\appservers\tomcat.keystore" keystorePass="bobdog" truststoreFile="D:\appservers\tomcat.keystore" truststorePass="bobdog" clientAuth="false" sslProtocol="TLS" /> |
Se reinicia Tomcat.
8. Se ha de crear el usuario y rol asociados al cliente a autenticar. Esto se puede realizar de diferentes maneras y usando distintos mecanismos de autenticación y autorización de usuarios con los que cuenta Tomcat. El más sencillo de todos es el uso del fichero de usuarios de Tomcat. Si se opta por este mecanismo, los pasos a seguir son los siguientes:
Editar en el fichero de usuarios de Tomcat (<TOMCAT_HOME\conf\>tomcat-users.xml) y añadir al mismo el rol y el usuario autenticado con el certificado anteriormente importado. Por ejemplo:
|
1 2 |
<role rolename="cliente"/> <user username="CN=cliente, OU=TTD, O=Indra, L=Madrid, ST=Madrid, C=ES" password="null" roles="cliente" /> |
La cadena incluida como username ha de ser exactamente el conjunto de valores que se usaron para crear el par de claves del cliente. Reiniciar Tomcat para que los cambios tengan efecto.
9. Por último, en el descriptor de la aplicación web del lado servidor se ha de configurar la restricción de seguridad que dara pie a la autenticación mediante certificados. Para ello, se edita el fichero WEB-INF/web.xml y se incluye, dentro de la etiqueta principal de web-app lo siguiente:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<!-- SECURITY CONSTRAINT 4 MUTUAL AUTHENTICATION (BASED ON CERTIFICATES) --> <security-constraint> <web-resource-collection> <web-resource-name>MainServlet</web-resource-name> <url-pattern>/MainServlet</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>cliente</role-name> </auth-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> <security-role> <role-name>cliente</role-name> </security-role> |
Mediante la configuración anterior se indica lo siguiente:
<url-pattern>/MainServlet</url-pattern> – indica el contexto dentro de la aplicación web que se verá afectada por la restricción.
<http-method/> – se especifica que métodos HTTP se autenticarán.
<role-name>cliente</role-name> – es el nombre del rol al que se le permite el acceso.
<transport-guarantee>CONFIDENTIAL</transport-guarantee> – indica que el acceso ha de ser vía HTTPS de forma obligatoria.
<auth-method>CLIENT-CERT</auth-method> – activa el método de autenticación por certificado.
10. Las pruebas:
Las pruebas de autenticación pueden ser realizadas bien desde un navegador web que intente acceder a la URL servidora protegida o bien con una aplicación de cliente, como un cliente HTTP(S).
- Navegador Web
Sería necesario importar el certificado del cliente al mismo. Una vez hecho esto, basta con intentar acceder a la URL que se quiere testear. Si la autenticación es validad, se accederá sin problemas, si no el navegador indicará el error.
- Cliente HTTP(S)
Ha de importar ámbos certificados, el de cliente y el de servidor, en el almacén de claves que use la aplicación. Si la aplicación está implementada en Java, se puede usar el almacén de claves por defecto de la JVM, que se encuentra en <JAVA_HOME>\ jre\lib\security\cacerts.