Hablemos de Certificados TLS/SSL - Crear un nuevo certificado a través de un CSR


Este artículo va a ser el primero de una serie de artículos, en los que voy a hablar de certificados.

Creo que por norma, la gente en los que yo me incluyó, se suele liar bastante con el tema de los certificados. Espero que estos artículos puedan ayudaros en algo :)

Dicho esto, en este primer artículo vamos a ver como generar un certificado SSL/TLS a través de un CSR. CSR son las siglas de Certificate Signing Request .

Pero antes que nada hablemos brevemente de los certificados TLS. Lo primero que vamos a ver es una definición sobre que son los certificados TLS. Por ejemplo, a mí me gusta mucho la definición de Digicert (https://www.digicert.com/es/tls-ssl/tls-ssl-certificates)

Los certificados TLS (Transport Layer Security o «seguridad de la capa de transporte»), generalmente llamados certificados digitales o SSL, son la base de la seguridad en Internet. Los certificados TLS/SSL protegen las conexiones a Internet mediante el cifrado de los datos que intercambian el navegador, el sitio web y el servidor de este. Garantizan que los datos se transmitan de forma privada y sin que se produzcan alteraciones, pérdidas ni robos.

Teniendo una definición de que son los certificados, la siguiente pregunta es:

¿Cómo funcionan los certificados?

Lo primero que hay que decir es que necesitamos un certificado emitido por una entidad certificadora válida (https://en.wikipedia.org/wiki/Certificate_authority).

Una entidad certificadora (CA) es aquella entidad o corporación encargada de emitir los certificados (https://community.rsa.com/s/article/List-of-Trusted-Certificate-Authorities-for-HFED-and-Trusted-Headers-Applications-0453c48e).

Los navegadores/servicios confiaran en estas entidades certificadoras cuando se visiten sitios con certificados emitidos por estas.

Es decir si tu llegas y en tu equipo te creas un certificado autofirmado, es decir que no has usado una entidad certificadora, y lo instalas en tu dominio, pues el navegador web fallará diciendo que ese certificado no es válido.

Ni falta me hace deciros que si entráis en un sitio y veis la imagen de arriba, salgáis de allí de forma inmediata jeje.

Vale pues ya tenemos nuestro certificado emitido por una entidad certificadora, y lo hemos instalado.

Ahora voy a intentar explicarme de la forma más claro que pueda, de como funciona un certificado en un navegador web:

  1. Un usuario accede a un sitio web usando https://nombredeldominio.com.

    El navegador le envía al servidor que versiones de TLS soporta, la suite de cifrado (https://www.flu-project.com/2020/09/suites-de-cifrado-tlsssl-parte-i.html) soportado por el navegador y un numero aleatorio generado llamado Client Random.

  2. El servidor escoge que versión de TLS y suite de cifrado van a usar en base a la información que le manda el navegador, y la suite de cifrado y versión de TLS que el servidor soporta.

    El servidor le envía de vuelta al navegador:

    • La versión de TLS a usar.

    • La suite de cifrado a usar.

    • El certificado con la firma digital de la entidad certificadora y la clave pública (OJO QUE NUNCA SE ENVÍA LA CLAVE PRIVADA¡¡¡)

    • Un número aleatorio generado llamado Server Random.

  3. El navegador web, una vez recibido el certificado y la demás información, verifica que el certificado es válido (no ha caducado, no ha sido recocado …).

    Además comprueba que esta firmado por una entidad certificadora de confianza.

  4. Vale ahora el navegador, sabe que el certificado es válido.

    El tema ahora es validar que la clave privada del certificado que tiene el servidor es buena buena (jejeje). Para ello el navegador, crea un número aleatorio random llamado pre-master secret .

    Este pre-master secret es encriptado usando la clave pública del certificado y envíado al servidor, por lo que si el servidor tiene la clave privada buena debe ser capaz de desencriptarlo.

  5. Vale, ahora tanto el navegador como el servidor poseen los siguientes datos:

    • La pre-master secret.

    • El Server Random.

    • El Client Random.

    Con estos datos, navegador y servidor pueden calcular y crear lo que se conoce como la clave de sesión compartida.

  6. Después el navegador, enviara un mensaje al servidor, encriptandolo con esta clave de sesión compartida.

  7. El servidor, recibirá este mensaje desencriptándolo también con la clave de sesión compartida, y comprobando si es correcto.

    Sí es así, el navegador sabe que la clave de sesión compartida del servidor es buena.

  8. El servidor , después envía un mensaje encriptándolo también con la clave de sesión compartida.

  9. El navegador, usando la clave de sesión compartida, lo desencripta y comprueba si es correcto. Si es así, el servidor sabe que la clave de sesión compartida del navegador es buena, y por tanto en resumen la clave de sesión compartida se ha calculado correctamente tanto en el navegador como en el servidor .

  10. A partir de ahora, ya rock and roll¡¡¡ , el navegador y el servidor usando esta clave de sesión compartida se enviarán la información encriptada, durante lo que dure lo que se conoce como sesión TLS.

A estos pasos descritos arriba se le conoce como SSL Handshake (SSL apretón de manos).

Se que a priori, pueda parecer complicado este proceso de SSL Handshake. Por eso quizás este gráfico de la página https://ssl.com pueda seros de ayuda:

Una vez que sabemos que es un certificado y para que sirve, vamos a abrir el primer melón de este artículo:

¿ Qúe son, certificados SSL o TLS?

SSL es un protocolo de comunicación creado en 1994, que ha tenido tres versiones:

  • SSL 1.0 en el año 1994 creado por Nestscape, que nunca fue usado en producción.
  • SSL 2.0 que en el año 1995 , ahora sí usado en Netscape Navigator.
  • SSL 3.0 apareció en el año 1996 y fue deprecado en 2015.
  • TLS 1.0 apareció en 1999 como una evolución de SSL, quedando deprecado en 2021.
  • TLS 1.2 apareció en 2008.
  • TLS 1.3 es la última versión del protocolo aparecida en 2018.

Resumiendo sobre el tema de de SSL o TLS, TLS es una evolución de SSL y cuando la gente suele hablar de certificados SSL en realidad habla de certificados TLS, es decir SSL y TLS suelen ser términos intercambiables. Sobre el tema de que versiones usar del protocolo, usar únicamente TLS 1.2 o 1.3 que son los que actualmente no estan deprecados, aunque lo mejor es USAR SOLO TLS 1.3.

Ahora hablemos sobre los tipos de certificados existentes, dependiendo de como deben ser validados por la entidad certificadora, para que estas nos emitan un certificado.

Estos tipos de certificado son:

  • Certificados de dominio (DV) : Para que te emitan estos certificados, solo con acreditar que eres el dueño del dominio te lo dan.

    Para demostrar que el dominio es tuyo suelen pedir que metas unas entradas DNS o bien recibir un correo en la cuenta de email asociado al dominio en el registro WHOIS (https://en.wikipedia.org/wiki/WHOIS) .

    Este el tipo de certificado más barato, y suele usarse en blogs , sitios personales, etc.

    En el navegador estos certificados suelen verse sin una organización definida en el campo Subject:

  • Certificados con validación de organización (OV): Son certificados que se suelen emitir a empresas, y al contrario que con los certificados de dominio, las entidades certificadoras hacen más comprobaciones.

    Se comprueban cosas tales como:

    • Que la empresa exista de verdad.

    • Que exista el domicilio especificado.

    • Comprobaciones en bases de datos oficiales.

    • Llamadas directamente a la empresa para corroborar los datos.

    Estos tipos de certificados suelen ser usados por comercios medianos, empresas que no trabajan con dinero etc…

    En el navegador podemos ver, que en estos tipos de certificados la propiedad subject contiene la información de la empresa:



  • Certificados con validación extendida (EV): Son los certificados con el nivel de seguridad mayor, ya que para que te den este tipo de certificado, la entidad certificadora realiza muchas comprobaciones para emitirte este certificado.

    Entre alguna de las comprobaciones que hacen están:

    • Comprobar que existe la empresa y que los datos que se han proporcionado por parte de la empresa son correctos.
    • Llamada de verificación a la empresa, contactando con un responsable para confirmar los datos.
    • En esta llamada se comprobará también, que si la persona que solicitó el certificado tiene permitido gestionar los certificados, etc…
    • Exigir documentación adicional a la empresa.

Sin lugar a dudas este certificado es el que cuesta más dinero, de los 3 tipos de certificados comentados.

Estos tipos de certificados son usados por bancos, los gigantes del comercio online como Ebay. En general con empresas que trabajan con dinero vamos.

En el navegador este tipo de certificados pueden verse fácilmente viendo la propiedad Issued to

Por último, y antes meternos en faena, vamos a ver los tipos de certificados, según si serán emitidos para un dominio, un dominio y sus subdominios , o por el contrario para más de un dominio.

Estos tipos de certificados son:

Ahora ya, después de toda la parrafada que os he metido (que creo era necesaria jajaja), vamos a ver como generar una petición de certificado, más conocido como CSR (Certificate Signing Request).

En este artículo voy a crear una petición de certificado para mi dominio https://hablemosdecertificados.recetadevops.dev

Este CSR lo voy a generar desde mi máquina de Windows 11. Solo comentaros, una afirmación que me han dicho en más de una ocasión.

Esa afirmación es:

El CSR , siempre lo debo de generar en el servidor donde vaya a instalar el certificado.

Esto es totalmente FALSO y aparte imposible para muchos casos. Otra cosa, es que por ejemplo, tu tienes un único servidor con un IIS y quieres hacerlo directamente en el servidor donde se va instalar el certificado.

Pero es que muchas veces es imposible, sino:

  • ¿Como genero mi certificado en un App Service?
  • ¿Como genero mi certificado en un Application gateway?
  • ….

Teniendo las herramientas necesarias, incluso online, tal y como ofrecen muchas entidades certificadoras, tu creas la petición CSR DONDE TE DE LA GANA.

Aclarado esto (sino no me quedaba a gusto), vamos a ver los pasos a seguir:

  1. Descargamos Open SSL para Windows en el siguiente enlace:

    https://slproweb.com/products/Win32OpenSSL.html

  2. Descargamos la versión full:

  3. Lo instalamos, usando las configuraciones por defecto como la ruta de instalación por defecto (C:\Program Files\OpenSSL-Win64)










4. Ahora, vamos a agregar a la variable de entorno Path, la ruta donde esta el ejecutable del OpenSSL. De esa formas, vamos a poder ejecutar desde cualquier directorio de en la Terminal de Windows 11.

La ruta a poner es C:\Program Files\OpenSSL-Win64\bin



  1. Ahora abrimos el Terminal de Windows, y testeamos que funciona OpenSSL:



  1. Como hemos dicho, vamos a generar un CSR para nuestro certificado del dominio https://hablemosdecertificados.recetasdevops.dev

    Vamos a generar un CSR y una clave privada que sera cifrada con RSA de 2048 bit. Desde hace mucho se suele usar RSA de 2048 bit, pero esta pisando con mucha fuerza usar ECDSA, por una serie de ventajas. En el siguiente enlace podeís ver una comparativa sobre RSA y ECDSA:

    https://nordvpn.com/es/blog/ecdsa-vs-rsa/#:~:text=The%20RSA%20algorithm%20uses%20significantly,security%20to%20reach%20this%20standard.

    Lanzamos el siguiente comando:

    openssl req -new -newkey rsa:2048 -nodes -out hablemosdecertificados.csr -keyout hablemosdecertificados.key

Comentemos los parametros más importantes :

  • out: Aqui indicamos el nombre del fichero CSR que se va a crear.
  • keyout: Aquí definimos el nombre del fichero con la clave privada del certificado que se va a crear.

  1. Se nos pide una serie de datos:

Estos datos son:

  • Country name: País de la empresa/persona en formato ISO.
  • State or province name: Provincia de la empresa/persona.
  • Locality name: Ciudad o pueblo de la empresa persona.
  • Organization name: Nombre de la empresa.
  • Organization Unit Name: Departamento dentro de la empresa.
  • Common Name: Esto es lo más IMPORTANTE, el dominio para el que pedimos el certificado.
  • Email address: El mail que quedará asociado al certificado.

Como vamos a pedir un certificado de validación de dominio (DV) (acordaros al príncipio del artículo), pues la información que pongamos no será en realidad validada. Esto no ocurrirá, si pedimos que un certificado para la empresa sea de validación de organización (OV) o validación extendida (EV).

  1. El resultado de ejecutar el comando anterior, será que se generaran los siguientes ficheros:

  1. Si vemos el fichero CSR, por dentro vemos lo siguiente:

  1. Vale, ya tenemos nuestro certificado CSR. Ahora debemos enviarselo a la entidad certificadora. El proceso de cómo enviar el CSR a la entidad certificadora será diferente en cada una de estas.

    En nuestro ejemplo usamos https://ssl.com, y se lo envíamos a través de un formulario:

  2. Luego pues se nos va a pedir demostrar que somos los propietarios o tenemos acceso a ese dominio que vamos a validar.

    Nosotros vamos a hacerlo a través de una entrada de DNS.

    Esto ya dependiendo de vuestro proveedor de DNS deberéis de hacerlo de una forma u otra.

  3. Vale ya hemos validado a través de DNS que somos los propietarios del dominio, y nuestra entidad certificadora nos ha generado nuestro certificado con la clave pública.

    Ahora bajamos el fichero:

  4. Ponemos el fichero en el mismo directorio donde tenemos la clave privada y la el fichero CSR. El fichero CSR lo podemos borrar ya:

  5. En el caso de querer instalar este certificado en Apache o Nginx, no tenemos que hacer nada más. Únicamente poner la clave privada y pública en los servidores.

    Pero en el caso de usar el certificado en IIS o en servicios de Azure como App Service o Application Gateway, debemos generar un fichero pfx, donde dentro de un único fichero tengamos la clave pública y privada del certificado.

    Para generar un fichero pfx, en nuestro ejemplo lanzamos lo siguiente:

    openssl pkcs12 -export -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -nomac -inkey hablemosdecertificados.key -in hablemosdecertificados_recetasdevops_dev.chained.crt -out hablemosdecertificados.key.pfx

    Comentamos los parámetros más importantes:

    • inkey: Nombre del fichero que tiene la clave privada.
    • in: Nombre del fichero que tiene la clave pública.
    • out: Nombre del fichero pfx que se va a generar.

Nos pide una password. Esta password será usada cuando instalemos este certificado con el fichero pfx generado:

​


  1. Y con esto tendríamos ya nuestro pfx listo para ser instalado:

Y con esto acabamos este artículo extenso, pero que espero os pueda ayudar.

En nuestro próximo artículo veremos como instalar este certificado en un App Service :)