Subido por Javier Vargas

Desarrollo de una Autoridad de Certificación

Anuncio
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.
Descargar