En mi anterior post os hablaba sobre la forma de poder utilizar varios certificados SSL en un mismo servidor y las posibilidades y limitaciones técnicas que existían.

Un certificado de servidor para SSL suele ser un producto caro. El precio en una entidad certificadora decente van desde unos pocos cientos a más de 1.000 euros, dependiente del tipo de certificado. Además es un proceso tedioso ya que hay que demostrar fehacientemente que somos quiénes decimos ser (que es de lo que va todo esto realmente, claro), lo que implica envío de papeles para su verficación, llamadas, faxes, etc... Conviene seleccionar una entidad certificadora conocida ya que de este modo su certificado raíz, que la verifica a ella primeramente, estará ya instalada en nuestro equipo, cosa que no ocurre con otras menos comunes (y supone una barrera comercial importante para éstas últimas). Todo el sistema de infraestructura de clave pública (PKI) se sustenta en esas relaciones de confianza jerarquizadas.

El objetivo de un certificado digital de servidor (para SSL) es triple ya que pretende lo siguiente:

1.- Autenticación del servidor: sirve para constatar ante los usuarios, de forma fiable, que el servidor al que se están conectando es quién dice ser y que por lo tanto nos estamos conectando de verdad a nuestro banco o servicio on-line.

2.- Cifrado de comunicaciones: la clave pública del servidor se utiliza para cifrar las comunicaciones iniciales, en las que se acuerdan el método de cifrado simétrico y la clave de cifrado que se utilizarán para cifrar todas las comunicaciones posteriores. Eso asegura la confidencialidad de las comunicaciones entre cliente y servidor, y es uno de los motivos por los que no se pueden simultanear certificados como hemos visto en el post anterior, ya que hasta la URL que se solicita viaja cifrada.

3.- No repudio de las comunicaciones realizadas por parte del servidor.

Cuando estamos desarrollando una aplicación y la queremos probar con SSL, o bien cuando sólo queremos el certificado SSL para un uso restringido (por ejemplo para nuestros dos o tres usuarios móviles que se quieren conectar cuando están fuera de la oficina), quizá el coste de un certificado real no está justificado. Para generar un certificado propio podemos poner en marcha nuestra propia infraestructura PKI, para lo cual Windows Server viene preparad. Aunque nos resultará fácil montar una PKI propia puede que no esté justificado todo el trabajo que conlleva para genrar uno o dos certificados.

Para permitir a los desarrolladores el uso de certificados SSL sin tener que comprarlos o generarlos con una PKI propia, en el interesante Kit de Recursos de Windows Server 2003 que ya hemos mencionado en el anterior post, se incluye una pequeña utilidad de línea de comandos que te va a encantar. Se trata de SelfSSL.exe.

Este ejecutable nos permite generar para cualquier servidor virtual de IIS un certificado digital SSL que está firmado por nosotros mismos. Lo genera y además lo instala y deja listo para su uso. La utilización de SelfSSL es muy sencilla:

Así, para generar un certificado SSL para un servidor virtual que tenga una validez de un año y que valide al dominio zonasegura.midominio.com tendría que escribir algo como esto:

selfssl /T /N:CN=zonasegura.midominio.com /V:365 /S:1669802537

El valor para el parámetro /S es el identificador d enuestro servidor virtual y, como hemos visto, lo sacamos con la utilidad IIS Metabase Explorer. Además he añadido el parámetro /T para que el certificado generado se instale en la lista de certificados de confianza del navegador local. De este modo en el servidor de pruebas no recibiremos advertencias sobre que el origen del certificado no se puede validar.

Y es que este es el mayor inconveniente de estos certificados: al acceder mediante SSL a los sitios protegidos con ellos recibiremos una advertencia de seguridad delnavegador, ya que el certificado no está emitido por una entidad de confianza reconocida. Esto es lógico sino el uso de certificados "de verdad" carecería de sentido, pues se perdería su objetivo principal que es la confianza, y pervertiríamos el concepto subyacente a las PKI.

No obstante, incluso en estas condiciones y aparte de su uso para pruebas y desarrollo, este tipo de certificados auto-firmados pueden ser muy útiles, ya que nos permiten conseguir el objetivo 2, es decir, el cifrado de las comunicaciones. Si por ejemplo tenemos algún trabajador que esporádicamente está de viaje y se quiere conectar al webmail o a una aplicación desde una red pública (un WiFi en una cafetería o centro comercial, por ejemplo) podemos utilizar uno de estos certificados para cifrar las comunicaciones y que las claves no viajen en claro y puedan ser interceptadas. No nos valida el servidor pero tampoco tenemos esto si nos conetcamos de forma "normal", por HTTP, y sería muy raro que alguien intentara suplantar justo a nuestro webmail usando envenanimiento de DNS en un centro comercial para engañar a un comercial nuestro y robarle las credenciales ¿no? ;-)

Es decir, ni se te ocurra usar esto para una aplicación de verdad ni para algo a lo que deban acceder muchos usuarios, pero para pruebas y para conexiones esporádicas a sistemas no críticos nos permitirá ahorrarnos un dinero y conseguir al menos el cifrado de datos en las conexiones, lo que no es poco.

Espero que te sirva :-)

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA