PRÁCTICA DE

INFRAESTRUCTURA DE
CLAVES PÚBLICAS
Memoria del laboratorio

Por Pablo Benítez Sánchez, Mario Lobato Grima y Luis Muñiz García
Contenido
1. Generación de certificado de CA 2
Confección y firma del certificado para la CA 3
Establecimiento del entorno de la CA 4
2. Envío del certificado de la CA 4
3. Envío de solicitudes 5
4. Firma y devolución de los certificados 6
5. Importación de certificados a los correos 7
6. Envío de mensaje firmado de A a B 8
7. Respuesta con mensaje firmado de B a A 8
8. Revocación de los certificados 9

Ilustración 1: Escenario de la práctica 2

Ilustración 2: ubicación [Link] 3
Ilustración 3: Certificado autofirmado de la CA. 3
Ilustración 4: Envío del certificado de la CA. 5
Ilustración 5: Solicitud de certificados 6
Ilustración 6: Firma y devolución de certificados 7
Ilustración 7: Importación de certificados a Thunderbird. 8
Ilustración 8: Envío de mensaje firmado 8
Ilustración 9: Respuesta con mensaje firmado y cifrado. 9
Ilustración 10: Diagrama de paso de mensajes con OCSP 10
Ilustración 11: Revocación de certificados. 11

1
 1. Generación de certificado de CA
Tras configurar las cuentas de correo, determinamos que Pablo sería la Autoridad Certificadora
(CA). En la siguiente ilustración, queda reflejado el escenario, con los equipos y la topología de
red que se usará para los siguientes apartados para la realización de la práctica.

Red del
laboratorio INTERNET

eth0 eth0

eth0

[Link]/32 [Link]/32 [Link]/32

Luis (A) Pablo (CA) Mario (B)

Ilustración 1: Escenario de la práctica

Además, cada uno de los usuarios generó sendas claves, públicas y privadas, para poder firmar
y certificar los mensajes. Para ello, en cada equipo se usó el siguiente comando.
$ openssl genrsa -aes256 -out mykey_crypt.pem 2048

Antes de comenzar, se procedió a la descarga del fichero raíz de la FMNT, disponible en su página
web. Visualizamos el contenido, el cual estaba codificado en binario con representación ASN1,
traduciéndolo como texto en claro mediante el siguiente comando.
$ openssl x509 -inform DER -in AC_Raiz_FNMT-RCM_SHA256.cer -text
-noout

Cuyo contenido empezaba por la siguiente línea.

Certificate: …

El objeto de esto era familiarizarse con los campos más relevantes de un certificado de AC, como
la fecha de validez del certificado, sus usos permitidos, el tipo y longitud de clave, así como el
sujeto y emisor de dicho certificado.

A continuación, se procedió a la búsqueda del fichero de configuración de openssl. Dicho fichero

en la distribución de centOS queda ubicado en el siguiente árbol de directorios.

2
 /etc

/pki

/tls

/[Link]

Ilustración 2: ubicación [Link]

Para hallarlo, se hizo uso del siguiente comando.

$ openssl versión -d

Dicho fichero fue copiado en el directorio de trabajo ( /home/dit/certs ) para su

manipulación y distribución por parte de la Autoridad Certificadora.

Confección y firma del certificado para la CA

Seguidamente, Pablo autofirmó su certificado, utilizando para ello su par de claves protegidas
mediante AES 256 con clave de 2048 bits, y el fichero de configuración de openssl. Todo ello se
refleja en la siguiente ilustración.

[Link]

$ openssl req...

[Link]/32

Pablo (CA)
Priv key Public key
Pablo Pablo

Ilustración 3: Certificado autofirmado de la CA.

Para ello, empleó el siguiente comando.

$ openssl req -new -x509 -key mykey_crypt.pem -out [Link] -
config [Link]

A continuación, inspeccionamos el contenido de la primera línea del fichero generado mediante

el siguiente comando.

3
$ openssl x509 -noout -text -in [Link]

El contenido de dicho fichero comenzaba de la misma forma que el certificado raíz de la FMNT.
Certificate: …

Diferenciándose en éste por los campos de:

• la localidad (Sevilla)
• provincia (Sevilla)
• organización (US)
• la unidad de la organización (dit)
• y el nombre común (CN=CA_Pablo/emailAddress=benitez@[Link]) entre otros.

Establecimiento del entorno de la CA

La forma escogida de preparar una infraestructura para almacenar y operar con los certificados
fue crear varios subdirectorios y ficheros. Para ello, la CA ejecutó los siguientes comandos.
$ mkdir CA CA/certs CA/crl CA/private CA/newcerts
$ touch CA/[Link]

A continuación, se procedió a mover los certificados autofirmados y las claves de la CA a los

subdirectorios correspondientes con los siguientes comandos.
$ mv CAkey_crypt.pem CA/private/[Link]
$ mv [Link] CA/[Link]

Por último, insertamos el contador del número de serie (“01”) como contenido en los ficheros
serial y crlnumber.
$ echo 01 > CA/serial
$ echo 01 > CA/crlnumber

Con todo esto ya tenía la Autoridad Certificadora todo lo necesario para empezar a desempeñar
sus funciones.

2. Envío del certificado de la CA

Previo a la distribución del certificado autofirmado de la CA, Pablo insertó en el archivo
[Link] la siguiente línea en la sección de [ usr_cert ].
authorityInfoAccess = OCSP;URI:[Link]

De esta forma, cuando le lleguen las solicitudes de certificado a la CA, podrá almacenarlas en el
servidor OCSP, en la dirección [Link]/32.

Por último, la CA adjuntó su certificado autofirmado ([Link]) utilizando el cliente de correo

electrónico de Thunderbird, tal y como se muestra en la siguiente ilustración.

4
 [Link]/32 [Link]/32 [Link]/32

Luis (A) Pablo (CA) Mario (B)

CA envía su certificado

Ilustración 4: Envío del certificado de la CA.

Por último, antes de efectuar la emisión de la solicitud de firmado por parte de ambos sujetos,
se importó el certificado de la CA en las cuentas de correo electrónico. Para ello, se efectuaron
los siguientes pasos.

1. En la pestaña de configuración, pulsamos en “cifrado extremo a extremo”.

2. Pulsamos en “Administrar certificados S/MIME”.
3. En la pestaña de “Autoridades” seleccionamos el certificado que nos ha enviado la CA
([Link]).
4. Finalmente, pulsamos en “confiar en esta CA para identificar usuarios de correo”.

Con todo esto, sólo nos restaba firmar las solicitudes de certificados.

3. Envío de solicitudes
Ambos usuarios efectuaron la solicitud de certificados, empleando para ello estos comandos.
[Mario@lt19]$ openssl req -new -key Mario_key_crypt.pem -out
cert_mario.csr -config [Link]

[Luis@lt17]$ openssl req -new -key Luis_key_crypt.pem -out

cert_luis.csr -config [Link]

Cabe recordar que para generar la solicitud se utiliza la clave pública, que va comprimida dentro
del archivo de extensión .pem pasado por línea de comandos.

Si se inspecciona cualquiera de los dos archivos .csr generados, veremos que su contenido
comienza con la siguiente línea.
-----BEGIN CERTIFICATE REQUEST-----
…

5
A continuación, se envían ambas solicitudes a la CA, tal y como se muestra en la siguiente
ilustración.

[Link]/32 [Link]/32 [Link]/32

Pub key
Priv key Luis Priv key Pablo Pablo Priv key Mario
Luis (A) Pablo (CA) Mario (B)

Pub key Luis Pub key Mario

Ilustración 5: Solicitud de certificados

Para ello, se hizo uso del cliente de correo Thunderbird, adjuntando en ambos correos sendos
archivos generados. En la siguiente sección se verá cómo firmó la CA ambas solicitudes.

4. Firma y devolución de los certificados

La autoridad certificadora hizo uso de los siguientes comandos para firmar las solicitudes de
certificado.
$ openssl ca -config [Link] -in cert_luis.csr -out
luis_certified.crt
$ openssl ca -config [Link] -in cert_mario.csr -out
mario_certified.crt

Cuando inspeccionamos cualquiera de los ficheros generados, podemos observar que su

contenido comienza por la siguiente línea.
Certificate:
…

Seguidamente, se adjuntó ambos certificados en un correo electrónico para enviárselos a sus

respectivos propietarios. Dicho evento queda reflejado en la siguiente ilustración.

6
 [Link]/32 [Link]/32 [Link]/32

Luis (A) Pablo (CA) Mario (B)

CA firma las solicitudes

Ilustración 6: Firma y devolución de certificados

Con esto, ambos usuarios tuvieron todo lo necesario para proceder a importar estos certificados
para mandar correos firmados.

5. Importación de certificados a los correos

Ambos usuarios, Luis y Mario, se intercambiaron los certificados firmados por la CA para
posteriormente importarlos a su cuenta de correo mediante Thunderbird.

Para importar los certificados de usuarios firmados por la Autoridad Certificadora en

Thunderbird, estos son los pasos a seguir.

1) Cada usuario deberá exportar su clave privada y su certificado firmado por la CA a un

fichero PKCS#12, mediante el comando:
$ openssl pkcs12 -export -in usuario_certified.crt -inkey
[Link] -out usuario_cert.p12

2) Seguidamente, ejecutar el comando:

$ thunderbird.

3) Una vez abierta la interfaz gráfica de usuario, pulsamos en la pestaña “Configuración de

la cuenta”.
4) Pulsamos en “Cifrado extremo a extremo”.
5) Pulsamos sobre “Administrar certificados S/MIME”.
6) Pulsamos sobre “Sus certificados” dentro del menú contextual, y finalmente pulsamos
sobre “importar” para buscar nuestro fichero de extensión .p12 generado en el paso 1.
7) Ahora pulsamos sobre “Personas” e importamos el certificado del compañero (Luis
importará el de Mario y Mario importará el de Luis, todo ello se verá más adelante en el
apartado 7).

7
 8) Por último, pulsamos sobre “Autoridades” e importamos el certificado de la CA.

Con estos certificados ya podemos enviar correos firmados digitalmente. En la siguiente

ilustración se refleja la interacción entre los comandos y los archivos necesarios para generar el
fichero .p12 para mandar correos firmados.

Usuario_certified.crt

$ openssl
pkcs12...

Correo
firmado

Priv key
Usuario usuario

Ilustración 7: Importación de certificados a Thunderbird.

6. Envío de mensaje firmado de A a B

En la interfaz gráfica de usuario de Thunderbird, en la pestaña de configuración de la cuenta,
pulsamos en “Añadir mi firma digital de forma predeterminada” y buscamos en nuestro almacén
de certificados el fichero .p12. Confirmamos, procedemos a redactar un mensaje de prueba y
enviamos al usuario B (Mario) tal y como se muestra en la siguiente ilustración.

[Link]/32 [Link]/32

Luis (A) Mario (B)

Ilustración 8: Envío de mensaje firmado

7. Respuesta con mensaje firmado de B a A

De forma análoga, el usuario B (Mario) ha efectuado las mismas interacciones con la interfaz
gráfica de usuario, cargando su certificado para la firma digital de los correos de forma
predeterminada y elige cifrar el correo utilizando para ello el certificado de Luis (pulsando en
“seguridad” en la ventana de redacción, y seleccionando “Requerir cifrado”. Todo ello queda
conceptualmente recogido en la siguiente ilustración.

8
 Pub key de
Luis ([Link])

[Link]/32 [Link]/32

Luis (A) Mario (B)

Ilustración 9: Respuesta con mensaje firmado y cifrado.

Dado que Mario ha cifrado el mensaje utilizando la clave pública de Luis, la cual está presente
en su certificado, Luis puede descifrarlo utilizando para ello su clave privada.

8. Revocación de los certificados

Para este apartado, la CA hace uso del servidor OCSP para mantener actualizada la vigencia de
los certificados, de forma que los usuarios puedan comprobarlo mandándole peticiones al
servidor. Para ello, lo primero que hizo fue generar una petición de certificado para dicho
servidor utilizando el siguiente comando.
$ openssl req -config [Link] -new -newkey rsa:2048 -nodes -
out [Link] -keyout [Link] -extensions v3_OCSP

Seguidamente, se firmó dicha petición con el siguiente comando.

$ openssl ca -config [Link] -extensions v3_OCSP -in [Link]
-out [Link]

Con esto, obtenemos el fichero [Link], que es el certificado obtenido para el servidor.

Por último, la CA arrancó el servidor OCSP utilizando el siguiente comando.

$ openssl ocsp -index CA/[Link] -port 8123 -rsigner [Link] -
rkey [Link] -CA CA/[Link] -text -out [Link] &

Si inspeccionamos la primera línea de los ficheros legibles generados, veremos que se

corresponden con lo descrito a continuación:

● Para el fichero [Link]:

Certificate:

● Para el fichero [Link]

V 231104174441Z 01 unknown
/C=ES/ST=Sevilla/O=US/OU=ETSI/CN=luis/emailAddress=muniz@t
[Link]

Y para el fichero [Link]:

9
OCSP Request Data:
…

Previo a que la Autoridad Certificadora revocase los certificados anteriormente concedidos,

cada usuario comprobó la vigencia de su certificado expeditado. Para ello, se hizo uso de los
siguientes comandos.
$ openssl ocsp -url [Link] -resp_text -issuer
[Link] -cert [Link]
$ openssl ocsp -url [Link] -resp_text -issuer
[Link] -cert [Link]

Generando por pantalla el estado del certificado, reseñando el campo “Cert Status: good” de
ambos certificados. En el siguiente diagrama de paso de mensajes se ilustra la secuencia de
mensajes entre los clientes y el servidor OCSP.

Ilustración 10: Diagrama de paso de mensajes con OCSP

A continuación, la Autoridad Certificadora revocó ambos certificados, empleando para ello los
siguientes comandos.
$ openssl ca -config [Link] -revoke CA/newcerts/[Link] -
crl_reason keyCompromise
$ openssl ca -config [Link] -revoke CA/newcerts/[Link] -
crl_reason keyCompromise

Correspondiéndose “01” y “02” con los números de serie asignados a Luis y Mario
respectivamente.

Por último, se recargó la configuración del servidor arrancándolo de nuevo (debido a la

implementación).

Conceptualmente, la situación queda reflejada en la siguiente ilustración.

10
 OCSP DDBB

Luis Update Mario

Servidor OCSP
[Link]/32

Pablo (CA)

Ilustración 11: Revocación de certificados.

Por último, ambos usuarios intentaron comprobar el estado de sus certificados repitiendo el
siguiente comando.

$ openssl ocsp -url [Link] -resp_text -issuer

[Link] -cert [Link]

Y obteniendo por pantalla la respuesta pertinente del servidor OCSP, mostrando

concretamente el estado:
Cert Status: revoked

Si inspeccionamos de nuevo el fichero [Link], podemos observar que en ambos certificados

con sus respectivos números de serie encontraremos una entrada similar a la que se muestra.

R 231104165056Z 221104172038Z,keyCompromise 01 unknown

/C=ES/ST=Sevilla/O=ETSI/OU=US/CN=luis/emailAddress=muniz@[Link]

Por último, si se intenta enviar de nuevo un correo con un certificado revocado, desde el propio
cliente de correo de Thunderbird nos dará un aviso (si no tenemos marcado la casilla de adjuntar
siempre la firma digital) informando que no se puede asegurar que el remitente es quien dice
ser.

Si por el contrario dicha casilla estuviera marcada, no nos dejaría enviar dicho mensaje.

11