Creación de una Autoridad Certificadora (CA) con OpenSSL. == Introducción == En la actualidad cada vez más gente utiliza servicios basado en Internet, como correo electrónico, servicios web, transacciones en linea y muchos más. Quienes ofrecen estos servicios deben de proporcionar una manera de garantizar la privacidad y seguridad de estas comunicaciones. Muchos servicios de red son configurados de tal manera de que la comunicación cliente/servidor sea segura, esto se logra cifrando la comunicación, es decir, estableciendo un canal seguro para enviar información sensible para el usuario, como pueden ser: nombres de usuarios, contraseñas, números de tarjetas de crédito y otro información que es confidencial. Estos canales seguros también llamados tuneles son creados usando criptografía simétrica y asimétrica, muchos servicios tales como servidores Web, SMTP, IMAP, POP y muchos otros más usan criptografía de llave publica usando certificados SSL x509, todo con el fin de asegurar la identidad y confidencialidad de los usuarios. Empresas como Thawte y VeriSign proveen servicios comerciales para la expedición de certificados SSL, estas son las conocias Autoridades Certificadoras de confianza. Un ejemplo, los navegadores web más comunes reconocen a estas dos empresas como Autoridades Certificadoras de confianza, para obtener un certificado SSL por una de las conocidas CA, es necesario que les demuestres que tu eres quien dices ser y que tienes los derechos para usar el certificado, por ejemplo no expiden un certificado a algún individuo o empresa sin identificación oficial que lo apruebe. Los certificados SSL expedidos por estas CA cuestan dinero, algunas veces vale la pena comprar uno por ejemplo para un servidor web que ofrecerá servicios de comercio electrónico y que debe garantizar la confidencialidad de sus usuarios. Pero muchas otras veces se requiere usar conexiones seguras para otros servicios como correo electrónico (SMTP, IMAP, POP3) por Internet y no se tiene el presupuesto para pagar por un certificado SSL. En este documento se explica como crea tu propia Autoridad Certificadora y usarla para fines personales o de uso interno en tu empresa, explicaremos como crear Peticiones para firma de certificados (CSR por sus siglas en Inglés), firmarlas y generar certificados usando herramientas libres y de código abierto como OpenSSL. === Sobre los Certificados x.509 == Estos certificados usan el protocolo SSL/TLS para asegurar la privacidad y autenticidad de las comunicaciones digitales. Por ejemplo en un sitio web un certificado SSl provee: * Ofrecer transacciones economicas seguras. proteccion de datos sensibles: datos bancarios, tarjetas de credito. * Garantizar la privacidad de la informacion suministrada por el eusuario de la página web, protegiendo el proceso de transmisión de datos entre el usuario y el servidor. BIen, un sistema que permita una comuniacioin segura debe de proveer las siguientes caraterisicas o funcionalidades: * Confidencialidad: el contenido de la comunicacion ha de ser inutil para una tercera parte que lo pudiera interceptar. * Autenticacióñ: el sistema ha de asegurarnos que una tercera parte no puede usurpar la identidad de alguna de las dos partes que intervienen en la comunicacion. * Integridad: nos debe de garantizar que la informacion transimitda, ademas de no ser interceptada, no pueda ser modificada por una tercera parte. * No repudio: debe garantizar que ninguno de los participantes en una comunicacion pueda negar parte de la misma. Es un concepto ligado al de autenticación, y así será considerado. - Criptografia Simetrica: Algoritmos de cifrado simétrico son IDEA, RC5, etc. - Criptografía asimétrica o de clave pública: PGP, SSL, - Certificados x.509 SSL utiliza certificados x.509 para el intercampio de claves públicas. Estos certificados x.509 contienen además de la clave pública del interlocutor, información acerca de su identidad, así como información complementaria sobre algoritmos utilizados para la generaión de claves, plazos de validez del propio certificado, etc. Por otra parte, estos certificados contienen una firma digital que garantiza la integridad de sus contenidos, ya sea por la clave privada del mismo interlocutor (certificados autofirmados), o por la clave privada de una tercera parte (certificado firmado por una cA). SOn los de ese último tipo, los firmados por una cA, los ncesarios para garantizar los cuatro requerimientos iniciales. Los datos de un sujeto que se incluyen en un certificado x.509 son: * CN: nombre común o nombre largo * E-Mail: Dirección de correo electrónico * O: NOmbre de su organización * OU: Departamento * L: Localidad * SP: Provincia o estado. * C: País x.509 es un estandar para una Infraestructura de Llave Publica (PKI), el cual especifica el formato para certificados de claves publicas, y un algoritmo de validacion de la ruta del certificado. La version actual de x509 es la version 3 y es la que se usa ampliamente. En el sistema x.509, una CA emite un certificado asociado a una clave púlica a un Nombre Distinguido particular en la tradición de c.500 o a un Nombre Alternativo tal como en una direccion de correo eletrónico o una entrada de DNS. Los certificados raíz de confianza de una organización puden distribuirse a todos los empleados de manera que ellos pueden usar el sistema de infraestructura de clave pública de la compañía. Navegadores web como IE, NEtscape/Mozilla y OPera vienen pre-instalados con certificados raíz, de manera que certificados SSL de grandes vendedores que hayan pagado por el privilegio de ser pre-instalados funcionen al instante. x.509 incluye tambien estándares para implementación de CRLs, y con frecuencia aspectos de sistemas PKI. La forma aprovada por la IETF de chequear la validez de un certificado es el Online Certificate Status Protocol (OCSP). Extensiones de archivo de certificados [editar] Las extensiones de archivo de certificados X.509 son: * .CER - Certificado codificado en CER, algunas veces es una secuencia de certificados * .DER - Certificado codificado en DER * .PEM - Certificado codificado en Base64, encerrado entre "-----BEGIN CERTIFICATE-----" y "-----END CERTIFICATE-----" * .P7B - Ver .p7c * .P7C - Estructura PKCS#7 SignedData sin datos, solo certificado(s) o CRL(s) * .PFX - Ver .p12 * .P12 - PKCS#12, puede contener certificado(s) (público) y claves privadas (protegido con clave) PKCS #7 es un estándar para firmar o cifrar datos (ellos lo llaman "sobreado"). Dado que el certificado es necesario para verificar datos firmados, es posible incluírlos en la estructura SignedData. Un archivo .P7C es simplemente una estructura SignedData, sin datos para firmar. PKCS #12 evolucionó del estándar PFX (Personal inFormation eXchange) y se usa para intercambiar objetos públicos y privados dentro de un archivo. Un archivo .PEM puede contener certificados o claves privadas, encerrados entre las líneas BEGIN/END apropiadas. Estructura de un certificado [editar] La estructura de un certificado digital X.509 v3 es la siguiente: * Certificado o Versión o Número de serie o ID del algoritmo o Emisor o Validez + No antes de + No después de o Tema o Tema información de clave pública + Algoritmo de clave pública + Tema clave pública o Identificador único de emisor (opcional) o Identificador único de tema (opcional) o Extensiones (optional) + ... * Algoritmo de certificado de firma * Certificado de firma Los identificadores únicos de emisor y tema fueron introducidos en la versión 2, y las extensiones en la versión 3. == Términos == CA: Autoridad Certificadora. Llave Privada: Esta es una llave privada RSA generada para crear un CSR, también es usada para firmar los certificados. Certificado Raíz: Este certificado es comúnmente utilizado por los programas clientes para validar la autenticidad de el certificado de un servidor, algunos de los atributos que contienen los certificados de un servidor es el nombre de la Autoridad Certificadora que firmo el certificado. CSR: Petición para firma de certificado, estos son enviados a la CA para firmarse. Certificado. == Inicializando la CA.== Lo primero que haremos es crear la llave privada RSA y el certificado raíz para nuestra CA, la llave privada solo sera usada cuando tengamos que firmar un CSR por lo que debe de mantenerse en un lugar seguro y de preferencia que no este conectado a alguna red, ya que si llegara a caer en manos equivocadas podría comprometer la seguridad de nuestros sistemas. NOTA: La llave privada raíz RSA sera protegida con un "frase de paso" (Passphrase), sin esta no podrá ser utilizada. El certificado raíz deberá de ser instalado en cada sistema cliente que use los servicios. NOTA: Certificates must be checked for expiration, to avoid at best browser warnings, and at worst service outages due to expired certificates. La creación de la CA requiere de la herramienta openssl, comprobaremos que la tengamos instalada: $ which openssl /usr/bin/openssl Si no se tiene instalada utilizar la herramienta de gestión de paquetes de tu distribución. 1. Creación de un directorio donde mantendremos los archivos de la CA. Si usamos una área personalizada para nuestra CA previene que las actualizaciones por parte de nuestro distribuidor modifique nuestra configuración o sobrescriba nuestros archivos y/o scripts. por lo que usaremos un directorio aparte de /etc/ssl donde normalmente esta la configuración de openssl. En nuestros ejemplos crearemos una CA para tuxjm.net por ejemplo usaremos el directorio llamado TuxjmCA, digamos que lo tenemos en /opt/TuxjmCA. # mkdir -p /opt/TuxjmCA # cd /opt/TuxjmCA La configuración global normalmente se almacena en un archivo de configuración llamado openssl.cnf que regularmente se encuentra en /etc/ssl/ En nuestro caso usaremos un archivo de configuración en que estará almacenado en /opt/TuxjmCA Copiar el archivo de configuración de openssl: # cp /etc/ssl/openssl.cnf /opt/TuxjmCA/openssl.cnf Editaremos este archivo para definir información básica para la generación de certificados. Editar algunos parametros básicos: Ya que todos los comandos y certificados los manejaremos bajo el directorio /opt/TuxjmCA entonces editaremos estos parametros: dir = ./demoCA # Where everything is kept Cambiarlo por: dir = /opt/TuxjmCA # Where everything is kept Si se quieren poner algunos valores a la hora de crear los certificados hacerlos en la sección de: [ req_distinguished_name ], para mas opciones, ver: man 5 config, guardar el archivo y entonces empezaremos a crear los certificados. Algunos de estos parametros se pueden predeterminar, así están por default: # egrep '_default.*=' openssl.cnf countryName_default = AU stateOrProvinceName_default = Some-State 0.organizationName_default = Internet Widgits Pty Ltd #1.organizationName_default = World Wide Web Pty Ltd #organizationalUnitName_default = Normalmente prefiero fijar countryName_default, stateOfPrivenceName_default y 0.organizationName_default. los tengo así: # egrep '_default.*=' openssl.cnf countryName_default = MX stateOrProvinceName_default = Baja California 0.organizationName_default = Tuxjm Inc. #1.organizationName_default = World Wide Web Pty Ltd #organizationalUnitName_default = Aunque si firmas certificados para servidores que tienes en otros estados seria recomendable dejar el campo de stateOrPrivincename_default como viene originalmente. El archivo openssl.cnf hace referencia a algunos archivos y directorios que normalmente existen en /etc/ssl, pero nosotros estaremos en otro por lo que los crearemos en nuestro directorio /opt/TuxjmCA # cd /opt/TuxjmCA Crearemos algunos directorios que serán utilizados para tener organizados nuestros certificados y llaves privadas RSA. # mkdir certs crl csr newcerts private Cambiaremos los permisos para el directorio private para que solo el usuario root pueda accederlo: # chmod go-rwx private Crear e inicializar el archivo serial que mantiene los números de serie de nuestros certificados SSL. # echo "01" > serial Crear el archivo que mantiene el índice de la base de datos de certificados: index.txt # touch index.txt - Crear la el certificado raíz y la llave privada de nuestra CA: # cd /opt/TuxjmCA ==== # openssl req -config openssl.cnf -new -x509 -days 3650 -keyout private/cakey.pem -out cacert.pem Generating a 1024 bit RSA private key ...............++++++ ...............++++++ writing new private key to 'private/cakey.pem' Enter PEM pass phrase: SÚPER_MEGA_CONTRASEÑA_o_Passphrase Verifying - Enter PEM pass phrase: SÚPER_MEGA_CONTRASEÑA ----- 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]:MX State or Province Name (full name) [Some-State]:Baja California Locality Name (eg, city) []:Tijuana Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tuxjm Organizational Unit Name (eg, section) []:Tuxjm Certificate Authority Common Name (eg, YOUR name) []:ca.tuxjm.net Email Address []:jmedina@tuxjm.net ==== Esto creara dos archivos, uno de el certificado raíz, el cual puede ser publicado a los que vayan a usar nuestra infraestructura de llave publica, y el archivo de la llave privada, el cual se usara para firmar las Certificados de Requerimiento de Certificados (CSR), este archivo se debe de tener en un lugar seguro. # ls -l cacert.pem private/cakey.pem -rw-r--r-- 1 root root 1330 2006-12-16 17:26 cacert.pem -rw-r--r-- 1 root root 963 2006-12-16 17:26 private/cakey.pem Bien, aunque el certificado raíz no sera usado para algún servicio, podemos comprobar su funcionamiento, así: # openssl s_server -cert cacert.pem -key private/cakey.pem -www Enter pass phrase for private/cakey.pem: SÚPER_MEGA_CONTRASEÑA Using default temp DH parameters Using default temp ECDH parameters ACCEPT Si el comando se ejecuta sin problemas, significa que los certificados están bien hechos, este comando anterior levanto un servidor web en modo seguro es decir con soporte HTTPS, puedes apuntar tu navegador a la dirección: https://localhost:4433 y veras que te pide verificar el certificado, ahí mismo puedes ver su información. == Exportando el certificado raíz de nuestra CA. == El certificado raíz de nuestra CA debe de ser instalado en todos los sistemas que estarán interactuando con los certificados firmados por nuestra CA. Nuestro certificado es el archivo cacert.pem el cual esta en formato PEM por default. Ver el capitulo: Notas en la exportación de certificados a los clientes. Una CA firma los CSR enviados por los clientes para producir un certificado. El certificado es enviado es regresado a el cliente para usarse con alguna aplicación. En nuestros ejemplos los CSR serán guardados con terminación .csr, usaremos el formato hostname.csr, donde hostname es el FQDN usado en el atributo x509 common name. == Creación de un CSR usando openssl == Para crear un CSR en sistemas *nix usamos la herramienta openssl en la linea de comando. Ejemplo para crear un CSR para un servidor web: # openssl req -nodes -new -keyout private/www.tuxjm.net.key -out csr/www.tuxjm.net.csr Generating a 1024 bit RSA private key ..............................++++++ ..............++++++ writing new private key to 'private/www.tuxjm.net.key' ----- 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]:MX State or Province Name (full name) [Some-State]:Baja California Locality Name (eg, city) []:Tijuana Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tuxjm Organizational Unit Name (eg, section) []:Hosting Common Name (eg, YOUR name) []:www.tuxjm.net Email Address []:jmedina@tuxjm.net Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: (SOLO_DAR_ENTER) An optional company name []: (SOLO_DAR_ENTER) En la parte de los atributos EXTRA ahí solo daremos enter para el challenge password y el nombre de la compañía opcional. En el comando usamos el parametro "-nodes" indica que la llave privada RSA no estará protegida por una contraseña, esto puede ser un problema de seguridad pero hay ocasiones donde no podemos tener una contraseña en el llave privada, por ejemplo tenemos un servidor web que reinicio en la madrugada y dicho servidor se encuentra a varios kilometros de distancia, el servidor web no iniciara si no se le teclea la contraseña de la llave privada. Entonces, el comando anterior nos genero dos archivos. La llave privada para nuestro CSR y e CSR. # ls -l csr/www.tuxjm.net.csr private/www.tuxjm.net.key -rw-r--r-- 1 root root 729 2006-12-16 17:46 csr/www.tuxjm.net.csr -rw-r--r-- 1 root root 891 2006-12-16 17:46 private/www.tuxjm.net.key Para poder tener nuestro certificado SSL para uso en nuestro servidor web. deberemos de enviar el CSR a la CA para que sea firmado y se genere un certificado. EL archivo de la llave privada RSA no es necesario que se envié y se deberá de mantener en un lugar seguro. === Creación de Certificados === La CA firma CSR enviados por los clientes para producir un certificado. El certificado es regresado a el cliente para en alguna aplicación. Como recordamos en la parte anterior acordamos que íbamos a guardar los CSR con finalización .csr. Supongamos que el cliente ya nos envío su CSR, y lo guardamos en /opt/TuxjmCA/csr, entonces procederemos a firmarlo con nuestra CA. # openssl ca -config openssl.cnf -out certs/www.tuxjm.net.crt -in csr/www.tuxjm.net.csr -policy policy_anything Using configuration from openssl.cnf Enter pass phrase for /opt/TuxjmCA/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Jun 24 08:48:38 2007 GMT Not After : Jun 23 08:48:38 2008 GMT Subject: countryName = MX stateOrProvinceName = Baja California localityName = Tijuana organizationName = Tuxjm organizationalUnitName = Hosting commonName = www.tuxjm.net emailAddress = webmaster@tuxjm.net X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: E5:F9:54:1F:C4:81:5F:DF:15:03:D2:28:65:1B:42:B7:08:DB:DC:BC X509v3 Authority Key Identifier: keyid:8E:33:DF:93:09:03:DD:ED:81:FE:BE:B4:98:5B:DD:56:A9:7F:0C:4B DirName:/C=MX/ST=Baja California/L=Tijuana/O=Tuxjm Inc./OU=Tuxjm Certificate Authority/CN=ca.tuxjm.net/emailAddress=jmedina@tuxjm.net serial:D5:28:CC:8C:17:C5:5E:7C Certificate is to be certified until Jun 23 08:48:38 2008 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 En este paso es donde se debe de verificar la información del solicitante si se aprueba entonces simplemente se firma el certificado. Esto nos generara el certificado SSL que sera retornado a el solicitante. El archivo que retornaremos es certs/www.tuxjm.net.crt. Por default openssl guarda una copia de el certificado para un uso a futuro, como la revocación el certificado. Los certificados son almacenados bajo el directorio newcerts, pero con el nombre de archivo basados en el numero de serie, y no el nombre del host de la petición. === Revocación de Certificados === Si un certificado en particular ya no se considera como confiable, este puede ser revocado por la CA. La revocación en si es fácil; la parte difícil es distribuir una lista de revocación a todos los clientes y aplicaciones que usan los certificados de nuestra CA. La CA debe de guardar los certificados que firma bajo un directorio de la CA para una fácil revocación. Guardando los certificados como hostname.crt es una manera de hacer esto; una copia de el certificado también es guardado bajo el directorio newcerts, aunque es nombrado con el numero de serie. Esto lo podemos comprobar comparando el fingerprint de el certificado recién generado con el nombre del host y el basado en el numero de serie: # openssl x509 -noout -fingerprint < certs/www.tuxjm.net.crt SHA1 Fingerprint=39:2D:87:9F:07:6F:27:01:15:67:FD:18:5F:DB:F5:14:F9:C4:5E:AA # openssl x509 -noout -fingerprint < newcerts/01.pem SHA1 Fingerprint=39:2D:87:9F:07:6F:27:01:15:67:FD:18:5F:DB:F5:14:F9:C4:5E:AA == Revocando un certificado == Supongamos que queremos revocar el certificado jamedina.tuxjm.net por lo que su archivo sera jamedina.tuxjm.net.crt y se encuentra en certs/jamedina.tuxjm.net # openssl ca -revoke certs/jamedina.tuxjm.net.crt Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./private/cakey.pem: Revoking Certificate 01. Data Base Updated == Generando la Lista de Certificados Revocados (CRL) == # openssl ca -gencrl -out /opt/TuxjmCA/crl/crl.pem Using configuration from /usr/lib/ssl/openssl.cnf Enter pass phrase for ./private/cakey.pem: El comando anterior nos creo el archivo crl/crl.pem # ls -l crl/crl.pem -rw-r--r-- 1 root root 556 2006-12-19 00:09 crl/crl.pem Ver la lista de certificados revocados en formato texto: http://www.openssl.org/docs/apps/crl.html # openssl crl -in crl/crl.pem -text -noout -CAfile cacert.pem Publicar la lista de de certificados revocados (CRL) El cual debe de ser distribuido a nuestros clientes que usen nuestra CA. == Referencias == OpenSSL: http://www.openssl.org/ OpenSSL Command-Line HOWTO: http://www.madboa.com/geek/openssl/ Servicios de Certificación: http://www.david-guerrero.com/papers/certificacion/certificacion.html X.509: http://es.wikipedia.org/wiki/X.509 OpenSSL Documentation: http://sial.org/howto/openssl/ OpenSSL Self-signed Test Certificates: http://sial.org/howto/openssl/self-signed/ OpenSSL Certificate Authority Setup: http://sial.org/howto/openssl/ca/ Generating Certificate Signing Requests (CSR): http://sial.org/howto/openssl/csr/ Example TLS Certificate Configuration: http://sial.org/howto/openssl/examples/ Exporting OpenSSL Certificates: http://sial.org/howto/openssl/exporting/ OpenSSL S/MIME: http://sial.org/howto/openssl/smime/ Monitoring for certificate expiration: http://sial.org/howto/openssl/check-expire/