OpenSSL: Autogestionando nuestros propios certificados

Estimados; ahora vamos a ver como podemos gestionar certificados digitales con la finalidad de proveer de seguridad a nuestros futuros servicios que vayamos habilitando ya sea web, Base de datos, correo, Mensajería Instantánea, controlador de dominio, etc.
Debemos tener en claro conceptos como: entidad certificadora CA; petición de certificado; llave o key y certificado; conceptos que no voy a dar ya que hay definiciones muy buenas, claras y sencillas andando por san google. Ejm: http://es.wikipedia.org/wiki/Autoridad_de_certificación.
En el ámbito de seguridad existe una herramienta que usa algoritmos específicos para crear certificados digitales únicos para cada petición de certificado, esto quiere decir que es imposible que dos certificados generados puedan contener la misma clave con la que fue generada. Esta herramienta se llama OpenSSL que nació de la descontinuación de SSLeay porque sus creadores pasaron a chambear a diferentes empresas de seguridad pero dejaron el código fuente a la comunidad para que lo explote.

Para empezar necesitamos una CA y ya que no tenemos platita para comprar alguna comercial porque todo esto es una enseñanza, nosotros seremos nuestra propia CA. Debemos entonces generarnos nuestros propios certificados de nuestra propia CA no oficial. La desventaja de esto es que ningún navegador nos reconocerá como tal y nos pedirá confirmar cada vez ya que nuestro certificado no es reconocido o no se encuentra en su base de datos.

Instalaremos OpenSSL en nuestro debian (en mi caso es squeeze de 64bits):

root@pruebas:~# aptitude install openssl

Luego creamos una carpeta personalizada donde pondremos nuestros certificados y las llaves. En mi caso:
root@pruebas:~# mkdir EntidadCA

Luego dentro de ella creamos el archivo openssl.conf que es donde se guardarán las configuraciones personalizadas para nuestro caso:
root@pruebas:~# cd EntidadCA/ && touch openssl.conf

Y dentro de openssl.conf copiamos este contenido para que lo personalicen a su conveniencia:
###Esto es una personalización hecha por mì: JPC del archivo original ###ubicado en /etc/openssl/openssl.cnf

dir            = .     # variable que establece el directorio de trabajo
[ ca ]
default_ca     = CA_default
[ CA_default ]
serial         = $dir/serial             # archivo que guarda el siguiente número de serie
database       = $dir/index.txt          # archvio que guarda la bd de certificados
new_certs_dir =  $dir/certificados       # dir que guarda los certificados generados
certificate    = $dir/CACert.pem         # nombre del archivo del certificado raíz
private_key    = $dir/privado/CAkey.pem    # llave privada del certificado raíz
default_md     = md5                     # algoritmo de dispersión usado
preserve  = no  #Indica si se preserva o no el orden de los campos del DN cuando se pasa a los certs.
nameopt        = default_ca    # esta opcion y la siguiente permiten mostrar detalles del certificado
certopt        = default_ca
policy         = policy_match    # indica el nombre de la seccion donde se especifica que campos son obligatorios, opcionales y cuales deben ser iguales al certificado raíz
# seccion de politicas para la emision de certificados
[ policy_match ]
countryName                    = match           # match, obligatorio
stateOrProvinceName            = match
organizationName               = match
organizationalUnitName         = optional        # optional, campo opcional
commonName                     = supplied        # supplied, debe estar en la petición
emailAddress                   = optional
# seccion que indica   como los certificados deben ser creados
[ req ]
default_bits         = 1024            # tamaño de la llave, si no se indica 512
default_keyfile      = key.pem         # nombre de la llave privada
default_md           = md5             # algoritmo de dispersión a utilizar
string_mask          = nombstr         # caracteres permitidos en la mascara de la llave
distinguished_name =   req_distinguished_name # seccion para el nombre distinguido (DN)
req_extensions     = v3_req # seccion con mas extensiones que se añaden a la peticion del certificado
# seccion del nombre distinguido, el valor es el prompt que se vera en pantalla. datos del propietario del certificado. esta seccion define el contenido de datos de id que el certificado llevara.
[ req_distinguished_name ]
0.organizationName             = Nombre de la organizacion Ejemplo: Mi Empresa S.A.A
organizationalUnitName         = Departamento o division
emailAddress                   = Correo electronico
emailAddress_max               = 40
localityName                   = Ciudad o distrito Ejemplo: LIMA
stateOrProvinceName            = Estado o provincia Ejemplo: PERU
countryName                    = Codigo del pais (dos letras) Ejemplo: PE
countryName_min                = 2
countryName_max                = 2
commonName                     = Nombre comun (hostname o IP) Ejemplo: midominio.com
commonName_max                 = 64
# si en la linea de comandos se indica la opcion -x509, las siguientes extensiones tambien aplican
[ v3_ca ]
# indica que se trata de un certificado CA raíz con autoridad para firmar o revocar otros certificados
basicConstraints         = CA:TRUE
# especifica bajo que metodo identificar a la llave publica que sera certificada
subjectKeyIdentifier     = hash
# especifica como identifcar la llave publica
authorityKeyIdentifier = keyid:always,issuer:always
# extensiones de la opcion req
[ v3_req ]
basicConstraints               = CA:FALSE # los certificados firmados no son CA
subjectKeyIdentifier           = hash
# *************************************************************************************

Luego creamos una carpeta donde guardar los certificados creados y otra donde guardar las llaves creadas privadas.
root@pruebas:~# mkdir certificados privado && echo '01' > serial && touch index.txt
El primer archivo 'serial' simplemente contiene el siguiente número de serie de nuestros certificados, ya que apenas vamos a crear el primero su número de serie será 01, después de crearlo se actualizará a 02 y asi sucesivamente.'index.txt' será la base de datos propiamente en base al número de serie.
Quedàndonos así:

root@pruebas:~/EntidadCA# ls -l
total 16
drwxr-xr-x 2     root root   4096 nov 14 02:26 certificados
- rw-r--r--    1    root root       0    nov 14 02:26 index.txt
 -rw-r--r--    1    root root    3841 nov 14 01:58 openssl.conf
drwxr-xr-x 2     root root   4096 nov 14 02:26 privado
- rw-r--r--    1    root root      3    nov 14 02:26 serial


Creando Una CA (recuerden cambiar los datos por los suyos)

root@pruebas:~/EntidadCA# openssl req -new -x509 -extensions v3_ca -keyout privado/CAkey.pem -out CAcert.pem -days 365 -config ./openssl.conf
(Ojo!: al principio nos pedirà una pass phrase: que no es otra cosa que una frase cualquiera que nosotros elijamos; por ejm. 4rr1b4 P3rU)
Generating a 1024 bit RSA private key
...++++++
..........................++++++
writing new private key to 'privado/CAkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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.
-----
Nombre de la organizacion Ejemplo: Mi Empresa S.A.A []:MIPC S.A.C
Departamento o division []:Departamento TI
Correo electronico []:admin@mipc.com
Ciudad o distrito Ejemplo: LIMA []:LIMA
Estado o provincia Ejemplo: PERU []:PERU
Codigo del pais (dos letras) Ejemplo: PE []:PE
Nombre comun (hostname o IP) Ejemplo: midominio.com []:mipc.com

y pasamos a explicar que significa cada paso:
a. req -new -x509   ---> crear un certificado nuevo autofirmado con el standar x509 (http://es.wikipedia.org/wiki/X.509)

b. -extensions v3_ca ---> crear un certificado raíz CA (como lo configuramos en el openssl.conf)

c.  -keyout  ---> nombre y donde guardará la llave privada (en este caso se guarda en privados

d. -out   ---> nombre del certificado raíz CA

e. -days 365 ---> el certificado será válido por 365 días (1 año)

f.  -config ---> archivo de configuración a utilizar (el que describimos openssl.conf

Lo anterior da por resultado dos archivos:
   Un certificado raíz CA (CAcert.pem)
   Una llave privada (privado/CAkey.pem) (La extensión "pem" es de Privacy Enhanced Message)

Solicitando un firmado de certificado

Si llegamos a este punto entonces ya nos hemos convertido en una entidad certificadora, claro sin más autoridad que para nuestro propio dominio, ahora crearemos una peticiòn de que nos firmen nuestro certificado para nuestro servicio.
root@pruebas:~/EntidadCA# openssl req -new -nodes -out solicitud.pem -config ./openssl.conf

Generating a 1024 bit RSA private key
..............................++++++
................................++++++
writing new private key to 'key.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.
-----
Nombre de la organizacion Ejemplo: Mi Empresa S.A.A []:MIPC S.A.C
Departamento o division []:Departamento TI
Correo electronico []:admin@mipc.com
Ciudad o distrito Ejemplo: LIMA []:LIMA
Estado o provincia Ejemplo: PERU []:PERU
Codigo del pais (dos letras) Ejemplo: PE []:PE
Nombre comun (hostname o IP) Ejemplo: midominio.com []:mipc.com

Llegado a este punto abremos creado la peticion "solicitud.pem" de firma de nuestro certificado el cual usaremos con nuestro CA para crear el certificado que estamos pidiendo.

Firmando nuestra petición de Certificado.

Por último firmaremos la solicitud que hicimos en el paso previo, para firmarlo necesitaremos indicar la contraseña que autentifique que
somos la CA y que que por serlo tenemos la autoridad de autorizar (firmar) certificados. (Para nuestro propio uso).

root@pruebas:~/EntidadCA# openssl ca -out cert-firmado.pem -config ./openssl.conf -days 365 -infiles solicitud.pem
(ojo! nos pedirá la misma pass phrase que colocamos antes. ejm: 4rr1b4 P3rU
Using configuration from ./openssl.conf
Enter pass phrase for ./privado/CAkey.pem:
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
organizationName      :PRINTABLE:'MIPC S.A.C'
organizationalUnitName:PRINTABLE:'Departamento TI'
emailAddress          :IA5STRING:'admin@mipc.com'
localityName          :PRINTABLE:'LIMA'
stateOrProvinceName   :PRINTABLE:'PERU'
countryName           :PRINTABLE:'PE'
commonName            :PRINTABLE:'mipc.com'
Certificate is to be certified until Nov 14 05:12:33 2012 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Como ven en el gràfico, se ha creado satisfactoriamente el certificado autofirmado para nuestro dominio.

root@pruebas:~/EntidadCA# cat cert-firmado.pem
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: O=MIPC S.A.C, OU=Departamento TI/emailAddress=admin@mipc.com, L=LIMA, ST=PERU, C=PE, CN=mipc.com
        Validity
            Not Before: Nov 15 05:12:33 2011 GMT
            Not After : Nov 14 05:12:33 2012 GMT
        Subject: C=PE, ST=PERU, O=MIPC S.A.C, OU=Departamento TI, CN=mipc.com/emailAddress=admin@mipc.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:a5:00:94:13:3e:52:64:7b:17:76:0c:11:4b:5b:
                    b9:c8:55:96:34:9f:18:6c:31:69:23:29:e6:b4:15:
                    38:ca:69:de:78:6a:bc:d8:9c:d6:11:28:b0:1e:ae:
                    85:0c:40:59:36:ce:8c:ff:5c:af:00:e1:cd:d6:53:
                    ca:e3:d3:e8:a7:1b:05:bb:a5:db:7a:01:c7:b0:29:
                    2b:ba:29:a2:24:cb:6e:b1:8b:57:e0:0a:d1:b4:53:
                    47:50:60:8b:d9:3e:49:4c:cf:8a:64:fc:ea:d2:6e:
                    e4:3e:1b:55:53:8e:0c:9f:7f:14:d7:d7:61:30:83:
                    53:38:3e:92:e9:ee:e9:75:03
                Exponent: 65537 (0x10001)
    Signature Algorithm: md5WithRSAEncryption
        57:0b:ce:d3:57:73:6e:58:36:a8:ea:be:3a:5b:ad:1a:36:3c:
        23:28:09:e2:f7:cb:4a:f7:42:d0:f3:25:78:76:8e:78:a3:2d:
        87:3b:9e:e8:6e:8c:77:76:61:62:ca:ca:9e:bd:57:e0:ac:71:
        15:ab:37:b1:8b:bf:fa:35:66:f4:d5:76:38:52:48:34:51:14:
        94:e3:a2:c0:e9:f8:3d:68:d6:3a:5d:66:25:93:7c:ee:b2:7f:
        3a:0c:dd:a1:a8:91:50:9b:ee:e2:1e:28:83:65:a1:83:af:df:
        90:89:d1:ef:2e:c9:6c:6a:81:25:a4:3b:58:e4:b7:fe:66:fb:
        94:3c
-----BEGIN CERTIFICATE-----
MIICeTCCAeICAQEwDQYJKoZIhvcNAQEEBQAwgYwxEzARBgNVBAoTCk1JUEMgUy5B
LkMxGDAWBgNVBAsTD0RlcGFydGFtZW50byBUSTEdMBsGCSqGSIb3DQEJARYOYWRt
aW5AbWlwYy5jb20xDTALBgNVBAcTBExJTUExDTALBgNVBAgTBFBFUlUxCzAJBgNV
BAYTAlBFMREwDwYDVQQDEwhtaXBjLmNvbTAeFw0xMTExMTUwNTEyMzNaFw0xMjEx
MTQwNTEyMzNaMH0xCzAJBgNVBAYTAlBFMQ0wCwYDVQQIEwRQRVJVMRMwEQYDVQQK
EwpNSVBDIFMuQS5DMRgwFgYDVQQLEw9EZXBhcnRhbWVudG8gVEkxETAPBgNVBAMT
CG1pcGMuY29tMR0wGwYJKoZIhvcNAQkBFg5hZG1pbkBtaXBjLmNvbTCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApQCUEz5SZHsXdgwRS1u5yFWWNJ8YbDFpIynm
tBU4ymneeGq82JzWESiwHq6FDEBZNs6M/1yvAOHN1lPK49PopxsFu6XbegHHsCkr
uimiJMtusYtX4ArRtFNHUGCL2T5JTM+KZPzq0m7kPhtVU44Mn38U19dhMINTOD6S
6e7pdQMCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBXC87TV3NuWDao6r46W60aNjwj
KAni98tK90LQ8yV4do54oy2HO57obox3dmFiysqevVfgrHEVqzexi7/6NWb01XY4
Ukg0URSU46LA6fg9aNY6XWYlk3zusn86DN2hqJFQm+7iHiiDZaGDr9+QidHvLsls
aoElpDtY5Lf+ZvuUPA==
-----END CERTIFICATE-----
root@pruebas:~/EntidadCA#

Entonces ahora ya disponemos de CACert.pem que lo podemos importar desde los navegadores de las pcs de los usuarios de nuestra red que administramos cosa que asì el navegador no estarà mostrando ese molestoso mensaje que nos indica que no es una conexiòn segura. Y disponemos de cert-firmado.pem que junto a CACert.pem lo podemos configurar en nuestros servidores que administremos y asì les abremos dotado de seguridad aunque sea de manera local.

Reforzando conceptos - Parte II: Modelo TCP/IP

Estimados, siguiendo el "remember" que me propuse en: Reforzando conceptos - Parte I: Modelo OSI / ISO, es que les traigo esta segunda entrega muy resumida y en criollo (como se dice aquí en Perú) para que se entienda y así poder tener los conceptos claros.
Recuerden que la práctica debe ser respalda por una sólida base teórica y no quedar como "empíricos amateurs".

Empecemos

La familia de protocolos TCP / IP está estructurada como una jerarquía de cinco niveles. A veces se refiere colectivamente como una pila de protocolos. Este esquema arquitectónico ofrece las siguientes ventajas:
- Cada capa está diseñada para un propósito específico y existe tanto en el envío y recepción que se dá entre hosts.
- Cada capa está diseñada para que una capa específica en un host envía o recibe exactamente el mismo objeto enviado o recibido por sus respectivo proceso en otro host.
- Cada capa en un host actúa con independencia de otras capas del mismo host, y de acuerdo con la misma capa en otros sistemas.

Para tener una idea comparativa entre TCP/IP y OSI les dejo el siguiente gráfico:

Figura 1: Modelo TCP/IP

CAPAS DEL MODELO TCP/IP	CARACTERÍSTICAS
APPLICATION LAYER (CAPA DE APLICACIÓN)	Involucra las capas Aplicación, Presentación y Sesión del Modelo OSI. Consiste en acceder a los programas y servicios de red por el usuario. Es responsable de definir la forma en que las redes representan los datos. Un gateway funciona en esta capa.
TRANSPORT LAYER (CAPA DE TRANSPORTE)	Gestiona la transferencia de datos utilizando protocolos  de transporte reconocidas y no reconocidas. Esta capa también gestiona las conexiones entre las aplicaciones.
INTERNET LAYER (CAPA DE INTERNET)	Gestiona los datos y direcciones y entrega entre redes. Así como los datos de la fragmentación de la capa de Interfaz de red. Un router funciona en esta capa.
NETWORK INTERFACE LAYER (CAPA DE INTERFAZ DE RED)	Administra la entrega de los datos en la capa de Hardware. Esta capa provee la detección de errores y fragmentación de paquetes. Un “bridge” funciona en esta capa.
HARDWARE LAYER	Describe el equipamiento de la red, incluyendo las señales eléctricas características como el voltaje y la corriente. Un repetidor funciona en esta capa.

Deacuerdo a la descripción, se puede apreciar que el modelo TCP / IP es un formato reducido del Modelo OSI, ya que ha mezclado algunas capas de este último.

Espero les haya quedado claro este ligero resumen. Lo que quisiera lograr es que se sepa qué involucra cada capa y qué función desempeña.

Reforzando conceptos - Parte I: Modelo OSI / ISO

Muchos conceptos se han quedado en el olvido o simplemente se pasan por alto al momento de entrar en el mundo de las redes y servidores en general lo que tenga que ver con la teleinformática. Algunos empiezan a manera de hobbie, por curiosidad, por casualidad, como algunos efectivamente recibieron instrucciones y guías que decidieron enfocarse por este camino. Uno de esos conceptos pasados por alto es: El Modelo OSI, muchos sabemos como levantar un servidor, armar una red con seguridad perimetral, etc, pero si nos preguntan: y en que capa del modelo OSI trabaja el protocolo UDP; o que en capa se encuentra el servicio HTTP, FTP, POP, o por que capa viaja la trama que enviamos de host a host, etc. no sabemos responder, respondemos otra cosa, o simplemente nos quedamos mudos. Es por ello que he decidido hacer una pausa y "refrescar la memoria" porque estoy seguro que más de uno lo ha escuchado, lo ha leído, o por lo menos ha oído hablar del tema.

Empecemos
Network Model: Representa una estructura común o protocolo que involucra la comunicación entre sistemas. Estos modelos son divididos en capas.
El Modelo OSI (Open Systems Interconnection) nació en 1980 de manos de la International Organization for Standarization (ISO) con la finalidad de brindar funcionalidad a las necesidades de comunicación entre los equipos de las diferentes empresas fabricantes que hasta ese entonces era difícil unirlas.
Así fue concebido en 7 capas que muestro en el siguiente gráfico:

Figura 1: Estructura en capas del Modelo OSI

Figura 2: Resumen de capas

Espero les haya quedado claro los conceptos de esto que es muy importante. Posteriormente prepararé la parte 2 que se trata del Modelo TCP/IP, lo compararemos con el Modelo OSI y veremos las principales diferencias.


Lectura Recomendada: The Solaris - TCP/IP Network Administration