Es un gran mojón tener que generar un certificado para cada servicio. Y aquí, en el 5to infierno de infomed usar cualquier proveedor de CA gratis (como let’s encrypt) es por gusto.

En estos caso, no queda otro remiendo que usar un CA firmado localmente. La idea es.

Generamos un par de claves que harán la función de “autoridad certificadora”

• crear un Clave Privada (.key) y mantenerla bien escondida
• crear la Clave Pública del anterior (.pem) y la distribuimos

Una vez que tengamos nuestra autoridad certificadora. Empezamos a generar certificados y lo firmamos con esta.

• generamos una clave privada (el .key para este certificado)
• hacer una solicitud de certificado (.csr) al .key anterior
• generamos el dichoso certificado
• firmamos el certificado usando el .key de la CA

Usaremos al tan legalmente controversial OpenSSL para esta tarea.

La clave (.key) del CA, debe crearse en una máquina desconectada de la red y preferiblemente sepultada a 3 metros bajo tierra. Si esto le parece demasiado paranoico, entonces mantenga el “.key” en el servidor más aislado de la red. Preferiblemente, aquel que parezca menos importante y lejos de internet. En mi caso, yo uso mi laptop personal para tareas administrativas y es ahí donde tengo todas las claves privadas.

Supón que lo hagas en un servidor determinado. Creamos entonces en el home del root, un espacio adecuado para esto.

1
2
3

 mkdir -m700 CA
 cd CA
 unmask 077

Creamos la super-secretísima clave privada, que hará la función de CA:

openssl genrsa -out rootCA.key 2048

1
2
3
4
5

 [lazaro@artema CA]$ openssl genrsa -out rootCA.key 2048
 Generating RSA private key, 2048 bit long modulus
 ..............................+++
 .......................................................+++
 e is 65537 (0x010001)

Ya tenemos la piedra angular de nuestro CA; pero así no sirve. Esa es la clave primaria, o sea, la que tiene la facultad de descifrar y derivar nuevos certificados. No nos conviene que nuestros “usuarios finales”, o lo servidores, usen esta clave. Necesitamos crear una “clave pública”, esta clave pública se deriva de la privada, pero solo tiene la facultad de cifrar, así la puede tener cualquiera y mandarnos datos cifrados. Sin embargo, NO se puede usar la clave pública para DEScifrar. Al menos no; usando tecnología civil.

Nota para los imbéciles: El rootCA.key no se le puede dar a nadie.

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

 [lazaro@artema CA]$  openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 3650 -out rootCA.pem
 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]:CU
 State or Province Name (full name) [Some-State]:Havana
 Locality Name (eg, city) []:Plaza
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Calixto Garcia
 Organizational Unit Name (eg, section) []:Calixto Garcia
 Common Name (e.g. server FQDN or YOUR name) []:Hospital Calixto Garcia
 Email Address []:ssl@hcg.sld.cu

Ya tenemos la clave pública (el “.pem”). Este fichero será distribuido a nuestros clientes para que puedan hacer dos cosas: Cosa 1, cifrar los datos, sin poder descifrarlos. Cosa 2, identificar a la autoridad certificadora.

1
2

 [lazaro@artema CA]$ ls
 rootCA.key  rootCA.pem

Nota para los imbéciles: El rootCA.pem se instalará en los clientes, navegadores, teléfonos, etc…

Note además, que hemos dado a nuestra clave pública, 10 años antes de su caducidad (-days 3650). Quizás quieras darle un solo.

Ya puedes hacer público el “.pem” para que todo el que sepa que hacer con este, se lo instale. Por ejemplo, si tienes una intranet local, podrías dejarla con http plano y brindar información (así como la descarga) sobre el dicha clave. Puedes crear una página de HTML plano explicando porque SSL y como instalarlo en los navegadores. Ahí dices además, que se debe iniciar la conexión usando el prefijo “https”. Podrías poner esa página como el destino de redirección para todos los virtualhsot que usen “http” y así hacer conciencia a los usuarios. Por ejemplo, en servidores con información sensible (como los webmails), solo debe ser alcanzado usando ssl.

Pero sin extremismos. Una intranet que brinda información pública, no tiene que ser obligado por SSL (a menos que sea un wordpress con login).

Por cierto, Firefox tiene su propio almacén de certificados. Dirígete a Configuraciones, Avanzada, Certificados.

Una vez ahí, ve a donde dice Autoridades (no a tus certificados) y procede a importar el certificado.

En android también es tremenda balasera instalar el “.pem” y no dejará de meterme miedo diciendo que “un tercero podría estar manipulando tu información”. Lo cual no deja de ser cierto, poner un SSLbumper a squid bataría para hacer horrores.

Llégate a la configuración de seguridad y verás una opción que dice “instalar certificados desde la tarjetaSD” o “desde el almacenamiento”.

En algunos android 4, si te pide una clave y no sabes cual es, debes configurar el acceso al teléfono mediante clave. O sea, quita el patrón, pon una clave y prueba importar el “.pem”. Al pedir la clave pones la que estableciste para entrar. Una vez importado el certificado, vuelves a poner el mecanismo de seguridad que deses (patrón, ninguno, etc…)

de vuelta al servidor secreto

Pasemos ahora a crear uno (o varios) certificados para nuestros servidores. Para empezar, crearemos el certificado del servidor de correo, pero no del smtp, si no del webmail.

MUY IMPORTANTE en los certificados, el CN (Common Name) no puede ser el que te de la gana a tí. Si por ejemplo tu servidor de correo está en webmail.dominio.cu, ese ha de ser su CN

Nota para los imbéciles: Creas un certificado para cada servicio y su CN será el mismo nombre del virtualhost.

Creamos una clave privada para este servidor (para que pueda cifrar, te requiero que es bilateral y simétrico).

openssl genrsa -out webmail.key 2048

1
2
3
4
5

 [lazaro@artema CA]$ openssl genrsa -out webmail.key 2048
 Generating RSA private key, 2048 bit long modulus
 .+++
 ......................................................................................+++
 e is 65537 (0x010001)

Le pedimos a esta clave que genera un certificado (certificate request).

openssl req -new -key webmail.key -out webmail.csr

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

 [lazaro@artema CA]$ openssl req -new -key webmail.key -out webmail.csr
 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]:CU
 State or Province Name (full name) [Some-State]:Havana
 Locality Name (eg, city) []:Plaza
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Calixto Garcia
 Organizational Unit Name (eg, section) []:Calixto Garcia
 Common Name (e.g. server FQDN or YOUR name) []:webmail.hcg.sld.cu
 Email Address []:ssl@hcg.sld.cu
 
 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:

Ya tenemos las dos máquinas enigmas listas, pero no están sincronizadas y por ende, los cifrados producidos producidos por estos dos ficheros, serán simétricos pero no bilaterales. Alguien debe decirle que son padre e hijo.

Eso lo haremos, firmando con nuestro CA, el certificado generado.

openssl x509 -req -in webmail.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out webmail.crt -days 3650 -sha256

1
2
3
4

[lazaro@artema CA]$ openssl x509 -req -in webmail.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out webmail.crt -days 3650 -sha256
Signature ok
subject=C = CU, ST = Havana, L = Plaza, O = Calixto Garcia, OU = Calixto Garcia, CN = webmail.hcg.sld.cu, emailAddress = ssl@hcg.sld.cu
Getting CA Private Key

Note como hacemos uso de las claves pública y privada del CA. Por tanto, si un atacante adquiere los certificados del webmail y los colocase en otro sitio, este no machea el CN webmail.hcg.sld.cu y desata una advertencia en el navegador de nuestros usuarios. Además, no podrá firmar el certificado para modificarlo e incluir su CN.

1
2

[lazaro@artema CA]$ ls
rootCA.key  rootCA.pem  rootCA.srl  webmail.crt  webmail.csr  webmail.key

Bueno, todo listo, hagamos un paquete con todo lo necesario para que nuestro servidor de correo se lo configure en el webmail. Para postfix y para dovecot, debemos hacer otro que machee smtp.hcg.sld.cu y pop3.hcg.sld.cu sucesivamete.

REPITO! el rootCA.key NO puede hacerse público. Así que le daremos una copia del rootCA.pem

1
2
3
4
5
6
7
8
9
10

 [lazaro@artema CA]$ mkdir webmail
 [lazaro@artema CA]$ mv webmail.* webmail/
 [lazaro@artema CA]$ cp rootCA.pem webmail/
 [lazaro@artema CA]$ tar cvfz webmail.tar.gz webmail/
 webmail/
 webmail/webmail.crt
 webmail/webmail.csr
 webmail/webmail.key
 webmail/rootCA.pem
 [lazaro@artema CA]$ scp webmail.tar.gz root@webmail.hcg.sld.cu:/root/

Instálale esos certificado a tu apache/nginx y todo el que tenga el rootCA.pem instalado en su dispositivo; verá a “Calixto Garcia” como una legítima autoridad certificadora al abrir el webmail.

Lo que si no me queda claro es como se le instala el “.pem” a Windows. ¿Sugerencias?

Aquí les dejo el script que uso para hacer esto de forma automatizada. Para correrlo cree un directorio. Por ejemplo:

1
2
3

 mkdir miCA
 cd miCA
 mkcert.sh

Al correrlo la primera vez te creara el rootCA.pem, luego al correrlo con argumentos, se generan certificados para dichos dominios.

1
2
3

 mkcert.sh fulanito.dominio.cu
 ...
 echo fulanito.dominio.cu.tar.gz está listo para despachar

Te devolverá un .tar.gz con todo dentro.