Desarrollo de una Autoridad de Certificación Introducción OpenSSL es una librería criptográfica libre y gratuita que provee muchas herramientas en línea de comandos para manejar certificados digitales. Algunas de éstas pueden ser usadas para actuar como una Autoridad de Certificación (CA). Una CA es una entidad que firma certificados digitales. Muchos sitios web necesitan hacer conocer a sus usuarios que la conexión es segura, es por ello que pagan a una CA internacional confiable y conocida (p.ej. VeriSign, DigiCert) para que firmen un certificado para sus dominios En algunos casos tiene más sentido actuar como tu propia CA antes que pagar a una conocida. Casos comunes serían asegurar una intranet o emitir certificados a clientes para permitirles autenticarse en un servidor (p.ej. Apache, OpenVPN). Creación del par clave / certificado de la CA raíz Para actuar como una CA hay que tratar con pares criptográficos de claves privadas / certificados públicos. El primer par que debemos crear es el raíz, que consiste en una clave privada raíz (ca.key.pem) y un certificado raíz (ca.cert.pem). Este par forma la identidad de su CA. Usualmente la CA raíz no firma certificados directamente a un servidor o cliente. La CA raíz es usada solamente para crear una o más CAs intermedias, que son validadas por la CA raíz para firmar certificados en su nombre. Esta es una mejor práctica ya que permite que la clave privada de la raíz sea utilizada lo menos posible y permanezca offline ya que compromete una CA raíz sería muy perjudicial. Es una buena práctica crear el par clave/certificado raíz en un ambiente seguro. Lo ideal sería que estuviera encriptado por completo y en una computadora que esté permanentemente aislada de internet. Crear y configurar claves SSH en Linux Existen diferentes opciones para conectarse de forma remota y segura a un servidor según el sistema operativo que utilicemos. En el caso de Linux, el protocolo SSH es el más utilizado. El protocolo SSH proporciona un método seguro para acceder a un recurso privado, mediante el uso de un usuario y una contraseña, de forma remota. Sin embargo, este sistema tiene un problema: la contraseña podría ser capturada por cualquier atacante, lo que pondría en riesgo la información que tengamos guardada en su interior. De ahí la importancia de usar un sistema de autenticación adicional: las claves SSH. Éstas, al contrario que las contraseñas, son casi imposibles de descifrar. ¿Qué es la autenticación con clave pública? La autenticación con clave pública es un método de seguridad alternativo a las contraseñas, mucho más difícil de hackear y, por lo tanto, más seguro. ¿Qué son las claves SSH? La clave SSH consiste en la generación de un par de claves que proporcionan dos largas cadenas de caracteres —una pública y una privada—. La clave pública se instala en cualquier servidor y luego se desbloquea mediante la conexión con un cliente SSH que hace uso de la clave privada. Si las dos claves coinciden, el servidor SSH permite el acceso sin necesidad de utilizar una contraseña. No obstante, para añadir una capa de seguridad adicional, siempre podemos aumentar la protección de la clave privada usando una contraseña. Configurar la autenticación con claves RSA paso a paso 1º.- Crear el par de claves RSA El primer paso consiste en crear el par de claves RSA en la máquina cliente, que por lo general es el equipo que solemos utilizar. Para ello ejecutamos la siguiente instrucción en la línea de comandos: # ssh-keygen -t rsa 2º.- Almacenar las claves y la contraseña Una vez hayamos ejecutado la instrucción para generar las claves, se nos pedirá que indiquemos en qué ruta queremos almacenar la clave: Enter file in which to save the key (/root/.ssh/id_rsa): 3º.- Generar una contraseña para la clave privada Una vez indicada la ruta en la que se almacenará la clave, podemos incluir una contraseña: Enter passphrase (empty for no passphrase): Si no queremos usar una contraseña, podemos dejarlo en blanco como se indica entre paréntesis y pulsar «Enter». Sin embargo, es recomendable incluirla para añadir una capa de seguridad adicional. De este modo, aunque algún ciberdelincuente consiguiera la clave, no podrían hacer uso de ella mientras no diera con la contraseña. El único inconveniente de crear una contraseña es que habría que escribirla cada vez que se utilizara. Por supuesto, lo más recomendable es crear siempre contraseñas seguras. • La clave pública se guardará en: /root/.ssh/id_rsa.pub. • La clave privada se guardará en: /root/.ssh/id_rsa. 4º.- Copiar la clave pública Una vez hayamos generado las claves, hay que colocar la clave pública en el servidor virtual donde la queremos utilizar. Podemos copiar la clave pública dentro del archivo autorized_keys en el servidor con la instrucción ssh-copy-id. Para que se copie correctamente hay que indicar la dirección IP de la máquina, como se indica a continuación: ssh-copy-id –i ~/.ssh/id_rsa.pub usuario@maquina ssh-copy-id es un script que se conecta a la máquina y copia el archivo (indicado por la opción -i) en ~/.ssh/authorized_keys, y ajusta los permisos de forma adecuada. Si no se dispone del programa ssh-copy-id se puede realizar una copia manual a la máquina remota del archivo conteniendo la clave pública (por ejemplo, usando scp o sftp) y añadir su contenido al archivo ~/.ssh/authorized_keys. Preparando el directorio Creamos el directorio /root/ca para guardar todas las claves y certificados: # mkdir /root/ca Creamos la estructura de directories. Los archivos index.txt y serial actúan como una base de datos de archivos planos para realizar el seguimiento de los certificados firmados: # # # # cd /root/ca mkdir certs crl newcerts private chmod 700 private touch index.txt # echo 1000 > serial Preparar el archivo de configuración (openssl.cnf) para la raíz Debemos crear un archivo de configuración para poder usar OpenSSL. Este archivo de configuración debe ser copiado en /root/ca/openssl.cnf La sección [ ca ] es mandatoria. Alli se le indica a OpenSSL que use las opciones que están en la sección [ CA_default ] y en ésta debemos incluir el directorio donde se encuentra la CA raíz (/root/ca) # OpenSSL root CA configuration file. # Copy to `/root/ca/openssl.cnf`. [ ca ] # `man ca` default_ca = CA_default [ CA_default ] # Directory and file locations. dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/newcerts database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/ca.key.pem certificate = $dir/certs/ca.cert.pem # For certificate crlnumber crl crl_extensions default_crl_days revocation lists. = $dir/crlnumber = $dir/crl/ca.crl.pem = crl_ext = 30 # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 name_opt cert_opt default_days preserve policy = = = = = ca_default ca_default 375 no policy_strict [ policy_strict ] # The root CA should only sign intermediate certificates that match. # See the POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ policy_loose ] # Allow the intermediate CA to sign a more diverse range of certificates. # See the POLICY FORMAT section of the `ca` man page. countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] # Options for the `req` tool (`man req`). default_bits = 2048 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, so use SHA-2 instead. default_md = sha256 # Extension to add when the -x509 option is used. x509_extensions = v3_ca [ req_distinguished_name ] # See <https://en.wikipedia.org/wiki/Certificate_signing_request>. countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address # Optionally, specify some defaults. countryName_default = AR stateOrProvinceName_default = Argentina localityName_default = 0.organizationName_default = DSSI SA organizationalUnitName_default = emailAddress_default = [ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ v3_intermediate_ca ] # Extensions for a typical intermediate CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign [ usr_cert ] # Extensions for client certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = client, email nsComment = "OpenSSL Generated Client Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment extendedKeyUsage = clientAuth, emailProtection [ server_cert ] # Extensions for server certificates (`man x509v3_config`). basicConstraints = CA:FALSE nsCertType = server nsComment = "OpenSSL Generated Server Certificate" subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer:always keyUsage = critical, digitalSignature, keyEncipherment extendedKeyUsage = serverAuth [ crl_ext ] # Extension for CRLs (`man x509v3_config`). authorityKeyIdentifier=keyid:always [ ocsp ] # Extension for OCSP signing certificates (`man ocsp`). basicConstraints = CA:FALSE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer keyUsage = critical, digitalSignature extendedKeyUsage = critical, OCSPSigning Se utilizan policy_strict para todas las firmas de la CA raíz, ya que ésta es solamente utilizada para crear CA intermedias. También se utilizan policy_loose para todas la CAs intermedias debido a que éstas firman certificados de clientes y servidores que pueden venir de una gran variedad de terceros. Las opciones de la sección [ req ] son utilizadas cuando se crean certificados o cuando se firman requerimientos de certificados. Las opciones de la sección [ req_distinguished_name ] contiene la información que normalmente se requiere en un requerimiento de firma de un certificado. La extensión crl_ext se aplica cuando se crean listas de revocación de certificados y se utiliza la extensión ocsp cuando se firma el certificado OCSP (Online Certificate Status Protocol). Creación de la clave raíz Se crea la clave raíz (ca.key.pem) y se conserva en un lugar seguro. Cualquiera que se obtenga la clave raíz puede emitir certificados de confianza. Hay que encripta la clave con encripción AES 256 y con una clave robusta. Generalmente se utiliza 4096 bits para las claves de la CA raiz e intermedias. # cd /root/ca # openssl genrsa -aes256 -out private/ca.key.pem 4096 Enter pass phrase for ca.key.pem: clavesecreta Verifying - Enter pass phrase for ca.key.pem: clavesecreta # chmod 400 private/ca.key.pem Creación del certificado raíz Se usará la clave raíz (ca.key.pem) para crear el certificado raíz (ca.cert.pem). Se le dará al certificado raíz una fecha de expiración en días. Cuando el certificado raíz expire, todos los certificados firmados por la CA se invalidan. Es por ello que siempre se da un fecha de expiración grande, p.ej. 7300 días (20 años). # cd /root/ca # openssl req -config openssl.cnf \ -key private/ca.key.pem \ -new -x509 -days 7300 -sha256 -extensions v3_ca \ -out certs/ca.cert.pem Enter pass phrase for ca.key.pem: secretpassword You are about to be asked to enter information that will be incorporated into your certificate request. ----- Country Name (2 letter code) [XX]:AR State or Province Name []:Argentina Locality Name []: Organization Name []:DSSI SA Organizational Unit Name []:DSSI SA Certificate Authority Common Name []:DSSI SA Root CA Email Address []: # chmod 444 certs/ca.cert.pem Verificar el certificado raiz # openssl x509 -noout -text -in certs/ca.cert.pem Se obtiene la siguiente salida • • • • • El algoritmo de firma usado Los días de validez del certificado El largo en bits de la clave pública El Issuer, que es la entidad que firma el certificado El Subject, que refiere al certificado en sí. El Issuer y el Subject son idénticos ya que el certificado es auto firmado. Hay que tener en cuenta que los certificados raíz son auto firmados. Crear el par clave / certificado de la CA Intermediaria Una CA intermediaria es una entidad que puede firmar certificados en nombre de una CA raíz. La CA raíz firma el certificado de la CA intermedia generando así una “cadena de confianza”. El fin de usar una CA intermedia es principalmente la seguridad. Como ya se dijo anteriormente la clave de la raíz debe permanecer al mayor resguardo posible.- Si una clave intermedia es comprometida, la CA raíz puede revocar el certificado de la CA intermedia y crear un nuevo par criptográfico para esa CA intermedia. Preparando el directorio Los archivos de la CA raíz están en /root/ca por lo que se debe elegir, por conveniencia, un directorio diferente (/root/ca/ntermediate) para almacenar los archivos de la CA intermedia. # mkdir /root/ca/intermediate Se debe crear la misma estructura de directorios que la creada para la CA raíz. Es conveniente crear también el directorio csr para almacenar los requerimientos de firmas de certificados. # # # # # cd /root/ca/intermediate mkdir certs crl csr newcerts private chmod 700 private touch index.txt echo 1000 > serial Se agrega el archive crlnumber a la estructura de directories de la CA intermedia y éste es usado por mantener un seguimiento de la lista de revocación de certificados # echo 1000 > /root/ca/intermediate/crlnumber cd Se debe copiar el archivo de configuración de OpenSSL a /root/ca/intermediate/openssl.cnf. Sólo cinco opciones son modificadas respecto del archivo de configuración de la CA raíz. [ CA_default ] dir private_key certificate crl policy = = = = = /root/ca/intermediate $dir/private/intermediate.key.pem $dir/certs/intermediate.cert.pem $dir/crl/intermediate.crl.pem policy_loose Creación de la clave intermedia Se debe crear la clave intermedia (intermediate.key.pem). Se va a encriptar con AES 256 y un clave robusta. # cd /root/ca # openssl genrsa -aes256 \ -out intermediate/private/intermediate.key.pem 4096 Enter pass phrase for intermediate.key.pem: secretpassword Verifying - Enter pass phrase for intermediate.key.pem: secretpassword # chmod 400 intermediate/private/intermediate.key.pem Creación del certificado intermedio Se debe usar la clave intermedia para crear el CSR (certificate signing request). Los detalles generalmente coinciden con la CA raíz. El Common Name, sin embargo, debe ser diferente. # cd /root/ca # openssl req -config intermediate/openssl.cnf -new -sha256 \ -key intermediate/private/intermediate.key.pem \ -out intermediate/csr/intermediate.csr.pem Enter pass phrase for intermediate.key.pem: clavesecreta You are about to be asked to enter information that will be incorporated into your certificate request. ----Country Name (2 letter code) [XX]:AR State or Province Name []:Argentina Locality Name []: Organization Name []:DSSI SA Organizational Unit Name []:DSSI SA Certificate Authority Common Name []:DSSI SA Intermediate CA Email Address []: Para crear un certificado intermedio se usan la CA raíz con la extensión v3_intermediate_ca para firmar el CSR. Este debería ser válido por un período de tiempo más corto que el certificado raíz. Diez años (3650 días) sería un tiempo razonable. # cd /root/ca # openssl ca -config openssl.cnf -extensions v3_intermediate_ca \ -days 3650 -notext -md sha256 \ -in intermediate/csr/intermediate.csr.pem \ -out intermediate/certs/intermediate.cert.pem Enter pass phrase for ca.key.pem: secretpassword Sign the certificate? [y/n]: y # chmod 444 intermediate/certs/intermediate.cert.pem En el archivo index.txt es en donde la herramienta ca de OpenSSL guarda el certificado. Este archivo no puede ser borrado ni editado a mano. Contiene una línea en la que hace referencia al certificado intermedio. Verificar el certificado intermedio Como se hizo con el certificado raíz, se puede chequear que los detalles del certificado intermedio son correctos. # openssl x509 -noout -text \ -in intermediate/certs/intermediate.cert.pem Al verificar un certificado intermedio frente al certificado raíz, si la “cadena de confianza” está intacta nos indica OK. # openssl verify -CAfile certs/ca.cert.pem \ intermediate/certs/intermediate.cert.pem intermediate.cert.pem: OK Creación del archivo de cadena de certificado Cuando una aplicación (p.ej. un navegador) intente verificar un certificado firmado por una CA intermedia, debe verificar asimismo éste frente al certificado raíz. Para completar la “cadena de confianza”, se debe crear un “CA certificado chain” para ser presentado a la aplicación. Para crearlo, hay que concatenar los certificados raíz e intermedio. Este archivo se usará luego para verificar los certificados firmados por la CA intermedia. # cat intermediate/certs/intermediate.cert.pem \ certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem # chmod 444 intermediate/certs/ca-chain.cert.pem Nuestro archivo generado debe incluir el certificado raíz porque las aplicaciones no conocen de su existencia todavía. Una mejor opción, particularmente si se está administrando una intranet, es instalar el certificado raíz en cada cliente que necesite conectarse. En este caso, el archivo cadena necesita solo el certificado intermedio. Firmar certificados de servidores y clientes Se firmarán certificados usando la CA intermedia. Estos certificados pueden ser usados en distintas situaciones, como por ejemplo para asegurar conexiones a un navegador o para autenticar clientes que se conecten a un servicio. Los pasos que a continuación se indican son realizados desde la perspectiva de la autoridad de certificación. Un tercero, sin embargo, puede crear su propio par clave/certificado sin revelar su clave privada. Solo da el CSR y la autoridad devuelve el certificado firmado. En este escenario se saltea los comandos genrsa y req. Crear una clave Los pares de claves raíz/certificado de la CA intermediaria son de 4096 bits. Los certificados de los clientes y servidores normalmente expiran luego de un año, es por ello, que se puede usar encriptación de 2048 bits. Si se está creando un par criptográfico para ser usado en un servidor web (p.ej. apache), se necesitará entrar el password cada vez que se reinicia el servidor. Se podría omitir la opción –aes256 para crear la clave sin password. # cd /root/ca # openssl genrsa -aes256 \ -out intermediate/private/www.example.com.key.pem 2048 # chmod 400 intermediate/private/www.example.com.key.pem Crear un certificado Hay que usar la clave privada para crear un CSR. Los detalles del CSR no necesariamente tienen que coincidir con los de la CA intermedia. Para certificar servidores, el Common Name tiene que ser un dominio altamente calificado (p. ej. www.example.com), mientras que para el certificado del cliente puede ser cualquier identificador único (p. ej. una dirección de correo). Nótese que el Common Name no puede ser el mismo en el certificado root e intermediario. # cd /root/ca # openssl req -config intermediate/openssl.cnf \ -key intermediate/private/www.example.com.key.pem \ -new -sha256 -out intermediate/csr/www.example.com.csr.pem Enter pass phrase for www.example.com.key.pem: clavesecreta You are about to be asked to enter information that will be incorporated into your certificate request. ----Country Name (2 letter code) [XX]:US State or Province Name []:California Locality Name []:Mountain View Organization Name []:DSSI SA Organizational Unit Name []:DSSI SA Web Services Common Name []:www.example.com Email Address []: Para crear un certificado se usa la CA intermediaria para firmar el CSR. Si el certificado va a ser usado en un servidor, se usa la extensión server_cert. En cambio si el certificado se va a usar para autenticación de usuario se usa la extensión usr_cert. Los certificados generalmente se dan con una validez de un año, aunque una CA dará generalmente unos días más extras para sortear algún inconveniente. # cd /root/ca # openssl ca -config intermediate/openssl.cnf \ -extensions server_cert -days 375 -notext -md sha256 \ -in intermediate/csr/www.example.com.csr.pem \ -out intermediate/certs/www.example.com.cert.pem # chmod 444 intermediate/certs/www.example.com.cert.pem El archivo intermediate/index.txt contendrá una línea que hará referencia a este nuevo certificado Verificar el certificado # openssl x509 -noout -text \ -in intermediate/certs/www.example.com.cert.pem El Issuer es la CA intermedia y el Subject refiere al certificado en sí Usamos el CA certificate chain creado anteriormente (ca-chain.cert.pem) para verificar que el nuevo certificado valida la “cadena de confianza”. # openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \ intermediate/certs/www.example.com.cert.pem Desplegar el certificado Ahora hay que desplegar el nuevo certificado en el servidor o distribuir el certificado al cliente. Cuando se despliega en un servidor (p.ej. Apache) se necesita hacer disponibles los siguientes archivos: • • • ca-chain.cert.pem www.example.com.key.pem www.example.com.cert.pem Si se está firmando un certificado de un tercero, no se necesita su clave privada, sólo se necesitan los siguientes archivos: • • ca-chain.cert.pem www.example.com.cert.pem Listas de revocación de certificados Una CRL (certificate revocation list) muestra una lista de certificados que han sido revocados. Una aplicación cliente, como un navegador, puede usar la CRL para chequear la autenticidad de un servidor. Una aplicación servidor, como puede ser Apache o OpenVPN, puede usar la CRL para denegar acceso a clientes que ya no son confiables. Se debe publicar la CRL en una ubicación pública accesible (p.ej. http://example.com/intermediate.crl.pem). Los terceros pueden buscar la CRL en esa ubicación para chequear cuales certificados permanecen y cuales están revocados. Algunas aplicaciones han dejado de usar CRL y usan el OCSP (Online Certificate Status Protocol). Preparar el archivo de configuración Cuando una CA firma un certificado, normalmente codifica la ubicación de CRL en el certificado. Agregue crlDistributionPoints en la sección apropiada. En nuestro caso se debe agregar en la sección [ server_cert ] [ server_cert ] # ... crlDistributionPoints = URI:http://example.com/intermediate.crl.pem Crear la CRL Chequear el contenido de la CRL con la herramienta crl Como no hay certificados revocados todavía, la salida muestra: No Revoked Certificates Se debería recrear la CRL a intervalos regulares. Por defecto, la CRL expira luego de 30 días. Esto se controla en la opción default_crl_days en la sección [ CA_default ] Revocar un certificado Vamos a usar un ejemplo. Alice está corriendo un servidor Apache y tiene una carpeta privada con fotos. Alice quiere que su amigo Juan pueda acceder a esa carpeta. Juan crea su clave privada Juan crea su CSR y se lo envía a Alice: Alice lo firma: Alice verifica que el certificado es válido: El archivo index.txt debería contener la nueva entrada Alice envía a Juan el certificado firmado. Juan lo instala en su navegador y a partir de ese momento, tiene permitido el acceso a la carpeta privada de Alice. Con el tiempo ocurre que Juan a utilizado incorrectamente el contenido de esa carpeta por lo que Alice necesita revocarle inmediatamente el acceso La línea que en el archivo index.txt corresponde al certificado de Bob ahora comienza con una R. Esto significa que el certificado está revocado Luego de revocar el certificado de Juan, Alice debe recrear la CRL. Y chequear su contenido. Observemos que, a diferencia de la vez anterior, en la que no había certificados revocados, ahora nos muestra el certificado revocado. Uso de la CRL del lado del servidor Para certificados de clientes, es la aplicación del lado del servidor (p. ej. Apache) la que realiza esta verificación. Esta aplicación necesita tener el acceso local de la CRL. En el caso de Alice se podría haber agregado la directiva SSLCARevocationPath a la configuración de su Apache y copiar la CRL en su servidor web. La próxima vez que Bob conecte al servidor web, Apache chequeará el certificado de Bob frente a la CRL y denegará el acceso. De igual modo OpenVPN tiene la directiva crl_verify para bloquear clientes que tienen sus certificados revocados. Uso de la CRL del lado del cliente Para certificados de servidor, es la aplicación del lado del cliente (p.ej. navegador) que realiza la verificación. Esta aplicación tiene que tener acceso remoto a la CRL. Si un certificado es firmado con una extensión que incluya crlDistributionPoints, la aplicación del lado del cliente puede leer esta información y buscar la CRL en la ubicación específica. OCSP (Online Certificate Status Protocol) El OCSP fue creado como una alternativa a las CRL. Del mismo modo que la CRL habilita a un tercero (p.ej. un navegador) a determinar si un certificado está revocado o no. Cuando una CA firma un certificado, incluye el OSCP server address (p.ej. http://oscp.example.com) en el certificado. Preparar el archivo de configuración Para usar OCSP la CA debe colocar la ubicación del servidor en el certificado que firme. Eso se realiza la opción authorityInfoAccess en la sección [ server_cert ] [ server_cert ] # ... authorityInfoAccess = OCSP;URI:http://ocsp.example.com Crear el par OCSP # cd /root/ca # openssl genrsa -aes256 \ -out intermediate/private/ocsp.example.com.key.pem 4096 Ahora debemos crear el CSR. Los detalles generalmente coinciden con la CA firmante pero el Common Name debe ser un nombre de dominio altamente calificado. # cd /root/ca # openssl req -config intermediate/openssl.cnf -new -sha256 \ -key intermediate/private/ocsp.example.com.key.pem \ -out intermediate/csr/ocsp.example.com.csr.pem Enter pass phrase for intermediate.key.pem: clavesecreta You are about to be asked to enter information that will be incorporated into your certificate request. ----Country Name (2 letter code) [XX]:AR State or Province Name []:Argentina Locality Name []: Organization Name []:DSSI SA Organizational Unit Name []:DSSI SA Certificate Authority Common Name []:ocsp.example.com Email Address []: Ahora debemos firmar el CSR con la CA intermediaria # openssl ca -config intermediate/openssl.cnf \ -extensions ocsp -days 375 -notext -md sha256 \ -in intermediate/csr/ocsp.example.com.csr.pem \ -out intermediate/certs/ocsp.example.com.cert.pem Revocar un certificado La herramienta de OpenSSL ocsp puede actuar como un respondedor OCSP pero sólo para testeo. Creamos un certificado de servidor para testear # cd /root/ca # openssl genrsa -out intermediate/private/test.example.com.key.pem 2048 # openssl req -config intermediate/openssl.cnf \ -key intermediate/private/test.example.com.key.pem \ -new -sha256 -out intermediate/csr/test.example.com.csr.pem # openssl ca -config intermediate/openssl.cnf \ -extensions server_cert -days 375 -notext -md sha256 \ -in intermediate/csr/test.example.com.csr.pem \ -out intermediate/certs/test.example.com.cert.pem Debemos correr el OCSP respondedor en el localhost. Éste lee el archivo index.txt directamente. El respondedor está firmado con el par criptográfico OCSP (usando las opciones -rkey y -rsinger). # openssl ocsp -port 127.0.0.1:2560 -text -sha256 \ -index intermediate/index.txt \ -CA intermediate/certs/ca-chain.cert.pem \ -rkey intermediate/private/ocsp.example.com.key.pem \ -rsigner intermediate/certs/ocsp.example.com.cert.pem \ -nrequest 1 Enter pass phrase for ocsp.example.com.key.pem: clavesecreta En otra terminal debemos enviar una consulta al respondedor OCSP. La opción -cert indica donde certificar la consulta. # openssl ocsp -CAfile intermediate/certs/ca-chain.cert.pem \ -url http://127.0.0.1:2560 -resp_text \ -issuer intermediate/certs/intermediate.cert.pem \ -cert intermediate/certs/test.example.com.cert.pem En el comienzo la salida muestra: • Si se recibió una respuesta exitosa (OCSP Response Status) • La identidad del repondedor (Responder ID) • El estado de revocación del certificado (Cert Status) OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: ... CN = ocsp.example.com Produced At: Apr 11 12:59:51 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9 Serial Number: 1003 Cert Status: good This Update: Apr 11 12:59:51 2015 GMT Revocar el certificado # openssl ca -config intermediate/openssl.cnf \ -revoke intermediate/certs/test.example.com.cert.pem Enter pass phrase for intermediate.key.pem: clavesecreta Revoking Certificate 1003. Data Base Updated Como antes ejecutamos el respondedor OCSP y en otra terminal enviamos la consulta. Esta vez nos mostrará Cert Status: revoked y en Revocation Time. OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: ... CN = ocsp.example.com Produced At: Apr 11 13:03:00 2015 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: E35979B6D0A973EBE8AEDED75D8C27D67D2A0334 Issuer Key Hash: 69E8EC547F252360E5B6E77261F1D4B921D445E9 Serial Number: 1003 Cert Status: revoked Revocation Time: Apr 11 13:01:09 2015 GMT This Update: Apr 11 13:03:00 2015 GMT Añadir un certificado de la CA en el navegador Chrome o Firefox o Edge Los navegadores incluyen los certificados de algunas autoridades de certificados en las que se confía. En el caso de crear una CA propia como lo realizado y un certificado para un servidor firmado por esta CA, el navegador mostrará una advertencia indicando que el certificado presentado no es de confianza antes de permitir entrar al sitio web, con este mensaje el usuario es consciente de que el certificado del servidor no es de confianza y si el usuario lo desea se le permite el acceso al sitio web. Aun así, el navegador muestra una advertencia en el icono de seguridad del sitio web de que hay un problema con el certificado. Para eliminar el mensaje de advertencia al acceder al sitio web y la advertencia del icono de seguridad del sitio web hay que instalar en el navegador el certificado de la CA raíz e intermedia. En el navegador web Chrome desde Configuración > Privacidad y seguridad > Seguridad > Gestionar los certificados del dispositivo. En el navegador web Edge desde Configuración > Privacidad, búsqueda y servicios > Seguridad > Administrar certificados. En el navegador web Firefox desde Ajustes > Privacidad & Seguridad > Seguridad > Certificados. Por defecto los navegadores web ya incorporan los certificados de varias CA importantes de internet.
