Certificados SSL II: Operaciones Básicas
Fuente Imagen: https://www.tst.uk.com/ssl-certificates/
Si en el primer tutorial hablamos sobre los conceptos básicos de los certificados, en este vamos a hablar sobre las operaciones básicas para manejarlos: crearlos, firmarlos e instalarlos. Aunque el último paso dependerá de la aplicación y sistema operativo donde queramos instalarlo y puede diferir bastante de unos a otros. Así que, vamos al lío con “Certificados SSL II: Operaciones Básicas”
Creación de Certificados
Aunque he llamado a este primer paso: creación de certificados, no es del todo cierto que creemos el certificado. Lo que vamos a hacer es crear una clave privada y a continuación crearemos un Certificate Request (o CSR para abreviar). Básicamente es un certificado con los datos de nuestro sitio web o aplicación, que no ha sido firmado todavía por una Entidad Certificadora (o CA para abreviar de sus siglas en inglés: Certificate Authority). El certificado se obtendrá una vez la CA haya firmado nuestro CSR.
Para hacer estas operativas, usaremos openssl. Cualquier distribución Linux que uséis, ya tendrá estas librería preinstaladas. En Windows, también es posible instalarlo. En este sitio se encuentran los binarios compilados listos para instalar: https://indy.fulgan.com/SSL/
Paso I: Creación de clave privada
Lo primero es crear una clave privada. En función de la longitud de la clave, obtendremos un certificado más o menos seguro. A día de hoy, una clave por debajo de 2048 bits no se considera segura, pues puede romperse por fuerza bruta con la potencia de computación actual. Así que os recomiendo que como mínimo uséis claves de 2048 bits.
#openssl genrsa -des3 -out elblogtic.key 2048
Generating RSA private key, 2048 bit long modulus
...............+++
................................+++
e is 65537 (0x10001)
Enter pass phrase for elblogtic.key: *************
Verifying - Enter pass phrase for elblogtic.key: *************Con este comando, creamos una clave de 2048 bits cifrada con 3DES, por ello nos pide un password. Cada vez que queramos usar la clave, pedirá que se introduzca ese password. Si no queremos que tenga password, simplemente eliminamos del comando anterior el -des3. Si estamos creando una clave que va a usarse para un certificado para una aplicación (como un servicio web), os recomiendo que la clave NO tenga password, porque si no cada vez que reinicies el servicio Apache, os pedirá el password de la clave privada antes de arrancar.
Paso II: Generación de CSR
Ya tenemos nuestra clave privada, ahora vamos a generar un Certificate Request que enviaremos a una CA para que lo firme y nos devuelva nuestro certificado.
En el CSR se incluye la información del sitio, con lo que a la hora de generarlo, se nos solicitará una serie de preguntas.
En el siguiente ejemplo, vamos a crear un CSR para un certificado para mi sitio web: www.elblogtic.com.
El comando para generarlo es el siguiente:
#openssl req -key elblogtic.key -new -out elblogtic.csr -sha256 You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:ES State or Province Name (full name) [Some-State]:Spain Locality Name (eg, city) []:Palma de Mallorca Organization Name (eg, company) [Internet Widgits Pty Ltd]:El Blog TIC Organizational Unit Name (eg, section) []:Departamento IT Common Name (e.g. server FQDN or YOUR name) []:www.elblogtic.com Email Address []:admin@elblogtic.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:
Como véis, las preguntas son sencillas y son los típicos atributos que podemos encontrar en los detalles de cualquier certificado web que veamos cuando estamos navegando. De todos ellos, los más importantes son:
- Common Name: Se trata del FQDN que el certificado autentica. Es muy importante que pongas exactamente el FQDN de la aplicación en la que se va a instalar el certificado.
- Email Address: Este campo es importante, si la CA que va a firmar el CSR es válida o comercial. Es decir, si vamos a comprar el certificado en Verisign, Thawte, GoDaddy, etc. Porque antes de enviarte el certificado, enviará un email de verificación a ese email, para asegurarse que tú eres el dueño de ese dominio. Si pones un email inválido, no podrás finalizar la compra del certificado. Si no hiciesen esta comprobación básica, podríamos obtener cualquiera un certificado de Microsoft o Google. Imagínaos la de ataques de phishing que se harían !
- Hash SHA256: Si no ponemos la opción -sha256, se firma con sha1, que a día de hoy es débil y no se recomienda ya su uso.
Ya tenemos nuestro CSR, listo para ser firmado por una CA y obtener el certificado.
Paso III: Obtenición del certificado
En este último paso, hay 2 opciones dependiendo del uso al que queramos darle el certificado. El CSR debe ser firmado por una CA, pero la CA puede ser:
- CA oficial y pública: Verisign, Thawte, GoDaddy…etc. Normalmente son de pago, y lo que garantizan es que cualquier usuario de tu aplicación confiará en un certificado emitido por esta CA. Porque estas CAs tienen acuerdos con todos los navegadores, sistemas operativos, aplicaciones, etc. y han instalado sus certificados raíz de confianza para que cuando se muestra un certificado firmado por ellos, se confíe. Normalmente son de pago y es lo que recomiendo si el certificado que queréis generar es para un servicio de acceso público (una web de ventas, por ejemplo).
- CA privada: Se tratan de CA montadas por nosotros mismos, por ejemplo con openssl o con el servicio de CA de Microsoft Windows si tenemos un dominio AD. En este caso, un usuario ajeno a nuestra organización que vea ese certificado, no confiará y saldrá el famoso mensaje del navegador de que el sitio no es seguro. Para evitarlo, tendríamos que enviarle a todos nuestros usuarios el certificado raíz de nuestra CA, para que se lo instalen y así evitar este problema.
En el primer caso (CA públicas), cada sitio tiene un proceso sencillo para comprar el certificado. Se resume básicamente en la selección del tipo de certificado y tiempo de validez, se les pasa el CSR que hemos generado, recibiremos en el email del CSR un email de validación de dominio que tenemos que clicar y validar, y nos enviarán el certificado. Hay que decir que algunas de ellas son gratuitas, como Let’s Encrypt apoyada por la Linux Foundation o StartSSL y la mayoría de sistemas tienen sus certificados raíz.
En el segundo caso, tendremos que haber montado previamente una CA. Esto se escapa del alcance de este Post, y lo podemos explicar en otro si interesa.
De cualquiera de las maneras que usemos, al final tendremos un certificado listo para ser instalado en nuestra aplicación, sistema operativo o host.
Y cómo la instalación varía mucho, lo haremos en un tercer Post.
