Ser una Autoridad de Certificados (Certificate Authority/CA) con OpenSSL


Resumen

Aquí voy a explicar los pasos en forma correcta de cómo ser una autoridad de certificados para una intranet.

Introducción

Resulta que buscando en internet sobre este tema encontraremos muchas formas de hacerlo y muchas de ellas nos complican un poco la vida porque no nos explican bien qué tenemos que tener en cuenta realmente para que los certificados sean válidos o compatibles con lo más habitual. Ni tampoco nos explican qué tenemos que configurar para que las cosas salgan bien.

En este artículo voy a explicar con qué tener cuidado, qué campos rellenar y demás para poder generar certificados válidos para la mayoría de los propósitos. Además, explicaré un poco el concepto de seguridad que conlleva la utilización de un certificado.

Configurando OpenSSL

Crear un certificado no es tan difícil pero para ello necesitamos tener bien configurado OpenSSL. Por lo que sólo tendremos que modificar campos claves en el archivo openssl.cnf. El error que cometía era que modificaba varios, con la intención de personalizarlo lo más posible. Pero eso se alejaba del estándar así que tuve que investigar qué modificación estaba provocando las fallas.

Un error habitual que tuve fue que firefox me decía: “El certificado no es válido o es corrupto. Error código: -8101″. Y no entendía qué estaba pasando. Eso era porque había modificado el campo “nsComment”. ¿Curioso, no? ¿Quién se imaginaría que ese campo generara un certificado inválido? Pues, a mi me costó darme cuenta.

Para empezar a crear cualquier tipo de certificado entonces necesitamos modificar el archivo /etc/ssl/openssl.cnf.

Las líneas que podemos modificar las voy a marcar en color verde. El resto no conviene tocarlas.
Nota: El contenido del archivo que aquí coloco pertenece al de la intranet de Cielo Aragua.

Contenido del ARCHIVO /etc/ssl/openssl.cnf:

#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#

# This definition stops the following lines choking if HOME isn’t
# defined.
HOME = /etc/ssl
RANDFILE = /etc/ssl/private/.rnd

# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
#oid_section = new_oids

# To use this configuration file with the “-extfile” option of the
# “openssl x509″ utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)

[ new_oids ]

# We can add new OIDs in here for use by ‘ca’ and ‘req’.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6

####################################################################
[ ca ]
default_ca = CA_default # The default ca section

####################################################################

[ CA_default ]

dir = /etc/ssl # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to ‘no’ to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.

certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file

x509_extensions = usr_cert # The extentions to add to the cert

# Comment out the following two lines for the “traditional”
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options

# Extension copying option: use with caution.
# copy_extensions = copy

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = sha1 # which md to use.
preserve = no # keep passed DN ordering

# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match

# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

# For the ‘anything’ policy
# At this point in time, you must list all acceptable ‘object’
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 1024
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert

# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret

# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
string_mask = nombstr

# req_extensions = v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = VE
countryName_min = 2
countryName_max = 2

stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Aragua

localityName = Locality Name (eg, city)
localityName_default = Maracay

0.organizationName = Organization Name (eg, company)
0.organizationName_default = Cielo Aragua C.A.

# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd

organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =

commonName = Common Name (eg, YOUR name)
commonName_max = 64

emailAddress = Email Address
emailAddress_max = 64

# SET-ex3 = SET extension number 3

[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20

unstructuredName = An optional company name

[ usr_cert ]

# These extensions are added when ‘ca’ signs a request.

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE

# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType = server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape’s comment listbox.
nsComment = “OpenSSL Generated Certificate”

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren’t
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy

#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

[ v3_req ]

# Extensions to add to a certificate request

basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment

[ v3_ca ]

# Extensions for a typical CA

# PKIX recommendation.

subjectKeyIdentifier=hash

authorityKeyIdentifier=keyid:always,issuer:always

# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign

# Some might want this also
# nsCertType = sslCA, emailCA

# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy

# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where ‘obj’ is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF

[ crl_ext ]

# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.

# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always,issuer:always

[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate

# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.

basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.

# This is OK for an SSL server.
# nsCertType = server

# For an object signing certificate this would be used.
# nsCertType = objsign

# For normal client use this is typical
# nsCertType = client, email

# and for everything including object signing:
# nsCertType = client, email, objsign

# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment

# This will be displayed in Netscape’s comment listbox.
nsComment = “OpenSSL Generated Certificate”

# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren’t
# deprecated according to PKIX.
# subjectAltName=email:move

# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName

# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

FIN del contenido del ARCHIVO /etc/ssl/openssl.cnf:
He marcado en rojo unas líneas que hacían el fallo en firefox para que la identificaras.

Preparar las utilidades

No sólo hay que modificar el archivo de configuración de OpenSSL, sino que también hay que modificar las utilidades para que se ajusten a nuestra configuración. Nosotros solamente utilizaremos una utilidad: CA.pl. Para ello editamos el archivo CA.pl que se encuentra en el directorio “misc” del directorio de configuración de openssl (/etc/ssl).

Solamente hay que cambiar una línea:

$CATOP=”./demoCA”;

En lugar de ./demoCA pondremos /etc/ssl por lo que quedaría:

$CATOP=”/etc/ssl”;

Crear los archivos random

Sin estos archivos no podremos tampoco generar ningún tipo de certificados.

La forma más sencilla para crearlos es usando /dev/random o /dev/urandom del siguiente modo:

Primero nos ponemos en el directorio de OpenSSL: cd /etc/ssl

Luego generamos los archivos random:

head -c 1024 /dev/urandom > private/.rnd
head -c 1024 /dev/urandom > private/.rand

Si no es con /dev/urandom será con /dev/random. Y sino con el comando openssl rand pero dicen que es menos aleatorio que con urandom. Con el comando openssl rand:

openssl rand -out private/.rnd 1024
openssl rand -out private/.rand 1024

Generar el Certificado CA raíz (autofirmado)

Una vez hecho todo lo anterior podremos generar el certificado raíz (CA o Certificate Authority) que es un certificado con el que podremos verificar todos los demás.

Nos ponemos en el directorio de OpenSSL: cd /etc/ssl

Ejecutamos el siguiente comando: ./misc/CA.pl -newca

Ahora se nos preguntará primero la clave maestra (no olvidar nunca esta contraseña) y segundo los datos de la Autoridad de Certificado.

Si tenemos una compañía aconsejo utilizar el nombre de la compañía como Nombre de la Organización, como Nombre de la Unidad Organizacional el nombre de la oficina o el grupo de personas (Como ser Gerencia o Dirección) y finalmente como Nombre Común el nombre de la compañía seguido de “Root CA” para indicar que se trata de un certificado raíz. Así es la manera más habitual de como se arman este tipo de certificados.

Si tenemos una red nada más pues pongámosle el nombre (ej.: Mi Red) de la red y en la parte de Nombre de Unidad Organizacional podremos usar algo así como: Administración. En Nombre Común se puede poner el dominio de la red (ej.: mired.net Root CA).

Hay que tratar de utilizar datos verdaderos porque la forma en que trabajan los certificados sirve para verificar la autenticidad de una entidad entonces es mejor que sepan de quién y dónde.

Luego preguntará de nuevo la clave pero esta vez para firmar el certificado anterior. Un poco de cuidado acá porque si nos equivocamos tendremos que volver a empezar y para que podamos hacerlo tendremos que borrar el archivo private/cakey.pem porque sino el comando CA.pl -newca no nos funcionará más.

Al finalizar se habrán tenido que generar los siguientes archivos:

cacert.pem
private/cakey.pem
careq.pem <- Este último se debe borrar ya que sólo fue necesario para pedir (request) la firma.

Listo, ya tenemos el certificado raíz (cacert.pem) que nos servirá para comprobar el resto de los certificados. Este certificado puede llevarse a otra computadora para ser usado como verificador de los otros certificados.

Es consejable conservar a la llave maestra (cakey.pem) en un lugar seguro y donde nadie pueda acceder. Por ese motivo por defecto se encuentra en el directorio “private” el cual deberíamos asegurarnos que sus permisos sean sólo para root (root:root rwx — —).

Generar un certificado para Apache (u otro servicio similar)

Teniendo el certificado raíz ahora podremos generar certificados para tirar para arriba y bañarnos en certificados si queremos. Bueno, no es consejable hacer eso, pero podremos generar al menos un certificado para Apache de la siguiente forma:

(siempre estando en el directorio de OpenSSL /etc/ssl)

./misc/CA.pl -newreq-nodes

Y nos pedirá los datos del nuevo certificado para el servicio…

Y luego lo firmamos con:

./misc/CA.pl -sign

y nos pedirá la clave para firmar…

Esto generará tres archivos: newreq.pem, newcert.pem, newkey.pem

De los cuales newreq.pem hay que tirarlo a la basura (borrarlo) ya que fue un archivo temporal (un request/petición) que se generó solamente para obtener la firma (sign). Los otros dos los moveremos a donde corresponda (por ejemplo a un directorio donde Apache-SSL pueda leerlos) y también podríamos cambiarles el nombre a algo como: server.crt y server.key respectivamente.

La opción “nodes” sirve para que no encripte con una clave al archivo newkey.pem que por cierto no queremos andar poniendo la clave cada vez que iniciemos el servicio (como apache por ejemplo). Además, normalmente un servidor no tiene teclado ni monitor así que capáz que estamos como 10 minutos esperando a que el servidor arranque y sin saber por qué. Y resulta que era porque pedía clave al querer iniciar un servicio.

Utilizando el Certificado Raíz en Firefox

Para que firefox pueda confiar en los demás certificados que han sido creados a partir del raíz, es aconsejable importar el certificado raíz en Firefox (como Autoridad de Certificados).

En firefox 1.5.1 se encuentra en el siguiente lugar: Editar->Preferencias->Avanzadas->Seguridad->Ver Certificados->Autoridades.

Desde ahí podremos pulsar el botón “Importar” y así seleccionar el archivo cacert.pem e importarlo.

A partir de ese momento cada vez que Firefox visite nuestra web por https automáticamente sabrá que el certificado es válido ya que podrá verificarlo desde el certificado raíz que hemos importado.

En caso de que algún intruso quisiera ponerse en lugar del servidor web (man in the middle attack) firefox sabría que se estaría intentando realizar tal acción al reconocer que el certificado intruso no fue firmado por la autoridad del certificado raíz que hemos creado nosotros.

Luego podremos llevar ese certificado en un pendrive (evitar poner un lugar para copiarlo por la red, como por ejemplo en una página web) personalmente a cada firefox en cada máquina.

Por qué digo que se evite copiarlo por la red desde un servicio como por ejemplo una página o ftp. Bien, de comienzo podemos hacerlo, pero luego si nuestra red se torna grande quizá hayan personas malitencionadas intentando intervenir para robar información privada. Y lo van a poder lograr cuando se introduzca un nuevo miembro a la red (que no tiene el certificado por supuesto). Por ejemplo, si alguien nuevo entra a la red un intruso puede dejar un servicio que reemplace el fidedigno o intervenir al momento que copiemos el certificado (un ataque de persona intermediaria) y enviarnos un certificado de ellos en lugar del nuestro. Para evitar eso, es aconsejable siempre ir personalmente con el certificado en un medio como un pendrive. Por supuesto que es más cómodo copiarlo desde la misma red y no tener que levantarte para nada de la silla y que los nuevos miembros dispongan de esa “facilidad”. Pero estarías corriendo un gran riesgo y no tendrías forma de saberlo sino cuando quizá ya sea tarde. Para ese entonces la información privada del nuevo miembro de la red podría estar comprometida. Por eso es aconsejable ir con el certificado en forma personal en un medio como un pendrive (o un CD-R/RW tal vez).
Lo anterior es válido también si vas a renovar o cambiar el certificado raíz.ç

Más información

Hay varias cosas más que no expliqué, pero las que acabo de explicar son las suficientes para que podamos hacer el trabajo de forma correcta y segura. Hay otros detalles, especialmente unos archivos, que se generan o modifican como forma de control o de guía.

También es un tema más profundo, hay que hacer un estudio más detallado de cómo sucede una firma (cómo se hace, dónde está, dónde se lleva en el certificado). La forma o formato de un certificado también son cosas que no expliqué bien.

Toda esa información es más sencillo encontrarla en Internet. Y ya hay documentación explicando todo eso de una forma bastante entendible y completa. Es por eso que no voy a pasar a explicar eso aquí, pero lo que no encontré en Internet fue una guía paso a paso que explicara como hacer correctamente los certificados. Ni tampoco explicaban cómo solucionar problemas que normalmente uno va a frecuentar (como lo de los archivos random o lo de firefox).

Una buena práctica

Si has mirado el contenido de un archivo de certificado .pem, como ser el mismo cacert.pem, habrás notado que empieza con un montón de texto que trae consigo lo que has escrito para crearlo como el nombre canónico y demás. Ok, es buena práctica borrar todo eso del archivo sólo hasta la parte que dice: —–BEGIN CERTIFICATE—– (ojo de no borrar esa parte). Ya que igualmente esa información está incluida en ese sector y es el que normalmente se utiliza (porque ocupa menos espacio).
Fin del artículo. Saludos y espero que te haya sido de ayuda.

  1. Deja un comentario

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: