Teoría

Certificado Digital: Es un documento electrónico que identifica a una persona o institución

con una clave pública que le permite hacer trámites por internet. Este es emitido y firmado
por una autoridad de certificación.
X.509: Es un formato de certificado para certificados de llave pública. Documento que ha
sido codificado o firmado de manera digital en base al estándar recogido en la Internet
Engineering Task Force y según la RFC 5280 especifica un número de 64 bits para estos.
ASN.1: Conjunto de reglas de sintaxis y conjunto de reglas de codificación. Es una forma de
describir datos comenzando con tipos primitivos y construyendo tipos más complejos.
PEM: Archivo de texto que contiene uno o más elementos en codificación en Base64 ASCII,
cada uno con encabezados y pies de página de texto sin formato. Un único archivo puede
contener un certificado de entidad final, una clave privada o varios certificados que formen
una cadena completa de confianza.
DER: Codificación binaria para certificados X.509 y claves privadas. No contienen
declaraciones de texto sin formato. No debe tener declaraciones BEGIN/END y se mostrará
contenido binario ilegible
PKCS#7: Es una sintaxis estándar para almacenar datos firmados y/o cifrados. Sintaxis
general para datos a los que se les puede aplicar criptografía. Admite la recursividad, permite
autenticar atributos arbitrarios.
PKCS#12: Es un formato binario para almacenar una cadena de certificados y una clave
privada en un único archivo cifrado.
Llave pública: La llave que se puede enviar a través de un canal inseguro. Una llave
compartida. Se puede buscar y compartir.
Llave privada: Representación de dos números primos secretos muy grandes. Debe
mantenerse a salvo y cerca. Sin esta no se pueden leer los mensajes cifrados que se le
envían y tampoco enviar mensajes cifrados.

Criptografía
● Criptografía simétrica
También conocida como criptografía de clave secreta o criptografía de una clave. Su nombre
se debe a que este método emplea la misma clave tanto para el cifrado como el descifrado
de un mensaje. Por lo que el emisor y el receptor deben estar previamente de acuerdo y en
conocimiento de la clave a utilizar. Toda la seguridad está centrada en la clave. Por lo que
debe ser secreta y que no sea fácil de adivinar por una tercera persona.
 ● Criptografía asimétrica
uso de una fórmula matemática muy compleja para crear un par de claves: la clave privada y
la clave pública. A través de estas claves se establece un canal de comunicación seguro
entre las partes, en el que tanto el emisor como el receptor deben usar criptografía asimétrica
con un mismo algoritmo definido, que les permitirá crear un juego de claves único e
irrepetible para cada uno. En ese proceso de comunicación, el emisor y el receptor
comparten entre ellos sus claves públicas; estas claves cifrarán posteriormente los mensajes
que intercambien entre ellos. Y las claves privadas descifrarán esos mensajes para poder ver
su contenido.

Algoritmo RSA
El RSA es un sistema criptográfico que permite enviar mensajes cifrados sin tener que
intercambiar una clave privada y es el más utilizado para este fin. También permite realizar
firmas digitales y es un sistema que se basa en un problema matemático llamado
«factorización de números enteros».
RSA, al ser un cifrador asimétrico, trabaja con dos claves, una pública y una privada. Todo el
contenido de texto plano, o contenido sin cifrar, que se haya encriptado con la clave pública,
podrá ser descifrado mediante la clave privada, y viceversa, todo contenido cifrado con la
clave privada podrá ser descifrado mediante la clave pública.
La criptografía RSA puede aplicarse para convertir datos, un texto o incluso un archivo de
imagen a través de un algoritmo y hacerlo así irreconocible. Sin la clave RSA privada, el
archivo correspondiente queda ilegible y no puede ser descifrado ni por un programa. Los
datos subyacentes se convierten primero en números naturales y posteriormente se
encriptan con la ayuda de la clave RSA pública. Tanto la clave RSA pública como la privada
consisten en un par de números, de los cuales uno es idéntico. Este número se llama módulo
RSA.

Los dos números restantes se llaman exponente de cifrado y exponente de descifrado. Estos
dos exponentes se forman a partir de números primos seleccionados al azar que tienen
aproximadamente la misma magnitud, pero no deben estar demasiado cerca unos de otros. A
continuación, los números se calculan mediante varias fórmulas matemáticas. El método de
encriptado informático es de acceso público y, por lo tanto, puede ser fácilmente
comprendido. Sin embargo, para volver a hacer legible el texto cifrado, se necesita la clave
RSA privada además de la pública. Hasta ahora, no ha habido ningún algoritmo que
descomponga de forma fiable un número en sus factores primos.

Confidencialidad, integridad y no repudio

Muchos servicios en Internet son sensibles. Es común que se necesite:
● Confidencialidad
● Integridad
● Autenticación
● Autenticidad
● No repudio

Confidencialidad
El principal conjunto de funciones de este tipo de cifrado está relacionado con proteger el
contenido y la integridad del mismo. Se busca, principalmente, que sea ininteligible para un
tercero y, asimismo, que el algoritmo de encriptación sea imposible de romper en la práctica.
El cifrado de infraestructura de clave pública o cifrado asimétrico no es una medida suficiente
por sí sola para garantizar la seguridad del contenido. Por eso, se debe combinar con más
herramientas y estrategias de cifrado. Además, se debe tener presente que de nada sirve
tener el sistema de encriptación más seguro si se descuidan otros aspectos de la
ciberseguridad, como la posibilidad de un ataque de ingeniería social.

No repudio
Con la expresión "no repudio" se hace referencia a la capacidad de afirmar la autoría de un
mensaje o información.
El no repudio o irrenunciabilidad provee garantía al receptor de una comunicación en cuanto
que el mensaje fue originado por el emisor y no por alguien que se hizo pasar por este.
Además, previene que el remitente o emisor del mensaje afirme que él no envió el mensaje.

Integridad
Los mensajes o datos que envían y reciben los dispositivos y los servidores no sufren
modificaciones.
La necesidad de la firma digital
1. Para resolver el problema de que cifrar datos con RSA únicamente, es muy lento
2. Para tener un mecanismo que permita corroborar la integridad del mensaje recibido
Ojo que la firma digital solita todavía no es suficiente para dar confianza

Firma digital
La firma digital es una herramienta tecnológica que permite verificar su integridad, así como
identificar jurídicamente la vinculación de forma clara al autor con el documento electrónico.
Es la prueba fidedigna de que el suscriptor de un documento es la persona que dice ser.
La firma digital consiste en una secuencia de caracteres (datos electrónicos) que se obtienen
mediante un algoritmo de una forma matemática (llamado cifrado asimétrico).
La firma digital es un recurso que permite a las personas suscribir una amplia variedad de
documentos (electrónicos), entre los que se encuentran los contratos comerciales, facturas,
invitaciones, transacciones monetarias, notificaciones judiciales, gestiones de crédito y, en
algunos casos, hasta votar por internet.
¿Por qué PKI?
Para administrar las llaves privadas de forma segura
● Generación segura de llaves privadas (autoridades certificadoras, usuarios finales, …)
● Publicación confiable de llaves públicas
● Verificación de llaves
● Lidiar con llaves que se vuelven inseguras
● Regulación de uso de las llaves (autenticación, cifrado, firma digital, etc.)
CONFIANZA
 Certificados digitales
1.

2.

3.

4.
5.

6.

7.
8.

9.

10.
11.

12.

13.
14.

15.

16.
17.

18.

19.
20.

21.

22.
23.

24.

25.
26.

27.

28.
 29.

30.

31.

32.
Verificación vs validación

Se verifica un único objeto criptográfico

Se valida una cadena, con fechas de vencimiento y estado de los certificados

¿Qué son los certificados?

● Estructura de datos que vincula una ENTIDAD A con una LLAVE PÚBLICA.
● Es FIRMADO DIGITALMENTE por un tercero: Autoridad X.
● Si yo:
○ Tengo un texto T firmado digitalmente por A
Y
○ Si yo confío en X
Entonces
○ Puedo comprobar al verificar la firma digital, la autenticidad de A.
● Reducimos la CONFIANZA en las llaves públicas a confiar en una AUTORIDAD.
● ¿Qué tienen?
○ AL MENOS:
■ El nombre del SUJETO a quien se vincula la llave pública.
■ La LLAVE PÚBLICA vinculada al sujeto.
■ El ALGORITMO CRIPTOGRÁFICO para utilizar la llave pública.
■ El NÚMERO DE SERIE del certificado.
■ El PERIODO DE VALIDEZ del certificado.
■ El EMISOR del certificado (y quien lo firma digitalmente).
■ Las RESTRICCIONES que aplican al certificado (por ejemplo, de uso).
Repositorio Github: https://github.com/reichelmorav/entity_digital_signature_pki

SIN HSM

https://jamielinux.com/docs/openssl-certificate-authority/introduction.html

ROOT CA

a) Crear directorio para CA

mkdir /root/ca

b) Crear directorios

cd /root/ca
mkdir certs crl newcerts private
chmod 700 private
touch index.txt
echo 1000 > serial

c) Modificar archivo de configuración

Ver archivo en carpeta

d) Generar llaves

openssl genrsa -aes256 -out private/ca.key.pem 4096

chmod 400 private/ca.key.pem

e) Crear el certificado

openssl req -config openssl.cnf -key private/ca.key.pem -new -x509 -days

7300 -sha256 -extensions v3_ca -out certs/ca.cert.pem

f) Verificar el certificado

openssl x509 -noout -text -in certs/ca.cert.pem

INTERMEDIATE CA
https://jamielinux.com/docs/openssl-certificate-authority/create-the-intermediate-pair.html
 g) Crear directorio para CA dentro de la raíz

mkdir /root/ca/intermediate

h) Crear directorios

cd /root/ca/intermediate
mkdir certs crl newcerts private
chmod 700 private
touch index.txt
echo 1000 > serial
echo 1000 > /root/ca/intermediate/crlnumber

i) Modificar archivo de configuración

Ver archivo en carpeta

j) Generar llaves

openssl genrsa -aes256 -out intermediate/private/intermediate.key.pem

4096
chmod 400 intermediate/private/intermediate.key.pem

k) Crear el CSR

openssl req -config intermediate/openssl.cnf -new -sha256

-key intermediate/private/intermediate.key.pem \
-out intermediate/csr/intermediate.csr.pem

l) Firmar el CSR

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

m) Verificar el certificado

openssl x509 -noout -text -in intermediate/certs/intermediate.cert.pem

n) Crear cadena de confianza

cat intermediate/certs/intermediate.cert.pem \
certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
 chmod 444 intermediate/certs/ca-chain.cert.pem

CREAR CERTIFICADOS PARA SERVIDORES Y CLIENTES

a) Crear llaves

openssl genrsa -aes256 -out intermediate/private/www.example.com.key.pem

2048
chmod 400 intermediate/private/www.example.com.key.pem

b) Crear CSR

openssl req -config intermediate/openssl.cnf

-key intermediate/private/www.example.com.key.pem \
-new -sha256 -out intermediate/csr/www.example.com.csr.pem
c) Firmar CSR

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
d) Verificar certificado

openssl x509 -noout -text \

-in intermediate/certs/www.example.com.cert.pem

CRL
a) Modificar el archivo de configuración para agregar crl

b) Crear la CRL

openssl ca -config intermediate/openssl.cnf \

-gencrl -out intermediate/crl/intermediate.crl.pem

c) Verificar la CRL

openssl crl -in intermediate/crl/intermediate.crl.pem -noout -text

Si se necesita revocar un certificado:

openssl ca -config intermediate/openssl.cnf \
-revoke intermediate/certs/bob@example.com.cert.pem
OCSP
a) Modificar el archivo de configuración para agregar OCSP

b) Crear las llaves OCSP

openssl genrsa -aes256 -out

intermediate/private/ocsp.example.com.key.pem 4096
c) Crear CSR OCSP

openssl req -config intermediate/openssl.cnf -new -sha256 \

-key intermediate/private/ocsp.example.com.key.pem \
-out intermediate/csr/ocsp.example.com.csr.pem
d) Firmar CSR

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
e) Ejecutar el servidor OCSP

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
f) En otra terminal, enviar una consulta al responder

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

FIRMAR DOCUMENTO

Firmar archivo

openssl dgst -sha256 -sign domain.pem -out file.txt.signature file.txt

Crear llave pública

openssl rsa -in domain.pem -outform PEM -pubout -out publickey.pem

Extraer llave pública de CA

openssl x509 -pubkey -noout -in llave.crt -out publickey.pem

Validación de firma

openssl dgst -sha256 -verify publickey.pem -signature archivo.txt.signature archivo.txt

Encriptar archivo con llave pública

openssl rsautl -encrypt -inkey publickey.pem -pubin -in file2.txt -out file3.txt

openssl rsautl -decrypt -inkey key.pem -in mensajito.txt -out message.dec

Conversión de formato PEM a DEM

openssl x509 -in domain.crt -outform der -out domain.der

Conversión de formato PEM a PCKS#7

openssl crl2pkcs7 -nocrl -certfile domain.crt -certfile rootCA.crt -out domain.p7b

Conversión de formato PEM a PCKS#12

openssl pkcs12 -inkey domain.pem -in domain.crt -export -out domain.pfx

CON HSM

Máquina de políticas y emisora

Generalidades

1. Verificar que OpenSSL está instalado y tenga la versión 3.0.2

openssl version

2. Instalar SoftHSM y pkcs11-tools

sudo apt install -y softhsm2 opensc gnutls-bin libengine-pkcs11-openssl

1.1

3. Descargar y extraer la última versión de la librería libp11

wget
https://github.com/OpenSC/libp11/releases/download/libp11-0.4.12/libp11-
0.4.12.tar.gz && tar xvf libp11-0.4.12.tar.gz

4. Ingresar al directorio de la biblioteca y ejecutar el archivo make

cd libp11-0.4.12 && ./configure && make && sudo make install

5. Se debe inicializar un token tanto para la CA de políticas como a la emisora. A cada uno
se le debe agregar su respectiva etiqueta.

sudo softhsm2-util --init-token --slot 0 --label entities_signature

6. Acceder a la carpeta pki

cd /etc/pki/

7. Crear una carpeta dentro de root que contiene las diferentes ca

sudo mkdir ca && cd ca

8. Crear una carpeta para la ca intermedia de políticas

mkdir policies_ca

9. Crear una carpeta para la CA intermedia emisora

mkdir issuing_ca
CA de políticas

1. Dar los permisos necesarios para la manipulación del directorio

chmod 777 policies_ca/

2. Crear las carpetas necesarias dentro del directorio policies_ca

cd policies_ca && mkdir certs crl csr newcerts

3. Crear el archivo index (base de datos de índices de certificados revocados)

sudo touch index.txt

4. Generar los números para el serial y el crlnumber

sudo echo 1000 > serial && echo 1000 > crlnumber

5. Copiar el archivo de configuración por defecto de OpenSSL al directorio policies_ca

sudo cp /etc/ssl/openssl.cnf /etc/pki/ca/policies_ca/

6. Editar el archivo de configuración para agregar el directorio por defecto.

sudo nano openssl.cnf

[ CA_default ]
dir = /etc/pki/ca/policies_ca

7. Editar el archivo de configuración para establecer el perfil del certificado

sudo nano openssl.cnf

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = cRLSignkey, keyCertSign

8. Creación de llaves para la CA de políticas

sudo pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -l

--keypairgen --key-type rsa:4096 --slot <slot number> --id 01 --label
"policies_ca_key"
 9. Creación del CSR de políticas con las llaves almacenadas en el HSM

sudo openssl req -new -sha512 -config

/etc/pki/ca/policies_ca/openssl.cnf -engine pkcs11 -keyform engine -key
01 -out /etc/pki/ca/policies_ca/csr/policies_ca.csr

10. La información del certificado de políticas es la siguiente

Country Name (2 letter code) [AU]: CR

State or Province Name (full name) [Some-State]: San Jose
Locality Name (eg, city) []: San Pedro
Organization Name (eg, company) [Internet Widgits Pty Ltd]: UCR ECCI ITI
Organizational Unit Name (eg, section) []: II 2022
Common Name (e.g. server FQDN or YOUR name) []: ITI ENTITIES SIGNATURE
Email Address []:

11. Copiar el CSR de la máquina actual a la que se encuentra la CA raíz

scp policies_ca.csr admin@<ip ca root>:/ect/tmp

12. Firmar el CSR de la CA de políticas con la CA raíz

sudo openssl ca -config /etc/pki/CA/ca.conf -engine pkcs11 -keyform

engine -keyfile <key_id> -extensions v3_ca -days 3650 -notext -md sha256
-in policies_ca.csr -out /tmp/ca_intermediate_entities.cert.pem

13. Exportar a la máquina de políticas el certificado firmado por la raíz

sudo scp ca_intermediate_entities.cert.pem

admin@172.16.202.27:/etc/pki/ca/policies_ca/certs

14. Crear la CRL respectiva

sudo openssl ca -config /etc/pki/ca/policies_ca/openssl.cnf -engine

pkcs11 -keyform engine -keyfile <key_id> -gencrl -crldays 30 -cert
/etc/pki/ca/policies_ca/certs/ca_intermediate_entities.
cert.pem -out /etc/pki/ca/policies_ca/crl/ca_intermediate_entities.crl
CA emisora

1. Dar los permisos necesarios para la manipulación del directorio

sudo chmod 777 issuing_ca/

2. Crear las carpetas necesarias dentro del directorio issuing_ca

cd issuing_ca && sudo mkdir certs crl csr newcerts

3. Crear el archivo index (base de datos de índices de certificados revocados)

sudo touch index.txt

4. Generar los números para el serial y el crlnumber

sudo echo 1000 > serial && echo 1000 > crlnumber

5. Copiar el archivo de configuración por defecto de OpenSSL al directorio issuing_ca

sudo cp /etc/ssl/openssl.cnf /etc/pki/ca/issuing_ca/

6. Editar el archivo de configuración para agregar el directorio por defecto.

sudo nano openssl.cnf

[ CA_default ]
dir = /etc/pki/ca/issuing_ca

7. Editar el archivo de configuración para establecer el perfil del certificado

sudo nano openssl.cnf

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = cRLSign, keyCertSign, digitalSignature, noRepudiation

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, nonRepudiation
crlDistributionPoints =
URI:http://172.16.202.27/crls_files/issues_crls/ca_intermediate_entities
_issuing.crl

8. Creación de llaves para la CA emisora

 sudo pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so -l
--keypairgen --key-type rsa:4096 --slot <slot number> --id 02 --label
"issuing_ca_key"

Creación de la CSR emisora con las llaves almacenadas en el HSM

sudo openssl req -new -sha512 -config /etc/pki/ca/issuing_ca/openssl.cnf

-engine pkcs11 -keyform engine -key <key_id> -out
/etc/pki/ca/issuing_ca/csr/issuing_ca.csr

9. La información del certificado de políticas es la siguiente

Country Name (2 letter code) [AU]: CR

State or Province Name (full name) [Some-State]: San Jose
Locality Name (eg, city) []: San Pedro
Organization Name (eg, company) [Internet Widgits Pty Ltd]: UCR ECCI ITI
Organizational Unit Name (eg, section) []: II 2022
Common Name (e.g. server FQDN or YOUR name) []: ITI ENTITIES SIGNATURE
ISSUING
Email Address []:

10. Firmar el CSR de la CA emisora con la CA de políticas

sudo openssl ca -config /etc/pki/ca/policies_ca/openssl.cnf -engine

pkcs11 -keyform engine -keyfile <key_id> -extensions v3_ca -days 3650
-notext -md sha256 -in /etc/pki/ca/issuing_ca/csr/issuing_ca.csr -out
/etc/pki/ca/issuing_ca/certs/ca_intermediate_issuing.cert.pem

11. Crear la CRL respectiva

sudo openssl ca -config /etc/pki/ca/issuing_ca/openssl.cnf -engine

pkcs11 -keyform engine -keyfile <key_id> -gencrl -crldays 30 -cert
/etc/pki/ca/issuing_ca/certs/ca_intermediate_issuing.cert.pem -out
/etc/pki/ca/issuing_ca/crl/ca_intermediate_entities_issuing.crl

12. Para usar el OCSP se debe añadir lo siguiente al archivo de configuración

sudo nano openssl.cnf

[ server_cert ]
basicConstraints = CA:FALSE
nsCertType = server
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
authorityInfoAccess = OCSP;URI:http://172.16.202.27

[ ocsp ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning

13. Crear un par de llaves cifradas que se requieren para que el responder de OCSP firme
la respuesta que envía a la parte solicitante.
sudo openssl genrsa -aes256 -out ocsp.issuing.com.key.pem 4096

14. Crear su respectivo CSR

sudo openssl req -config openssl.cnf -new -sha512 -key
ocsp.issuing.com.key.pem -out /etc/pki/ca/issuing_ca/csr/ocsp.csr.pem

15. La información del CSR de OCSP es la siguiente

Country Name (2 letter code) [AU]: CR
State or Province Name (full name) [Some-State]: San Jose
Locality Name (eg, city) []: San Pedro
Organization Name (eg, company) [Internet Widgits Pty Ltd]: UCR ECCI ITI
Organizational Unit Name (eg, section) []: II 2022
Common Name (e.g. server FQDN or YOUR name) []: OCSP ENTITIES
Email Address []:
16. Firmar el CSR que fue creado anteriormente
sudo openssl ca -config openssl.cnf -engine pkcs11 -keyform engine
-keyfile 02 -extensions ocsp -days 375 -notext -md sha512 -in
/etc/pki/ca/issuing_ca/csr/ocsp.csr.pem -out
/etc/pki/ca/issuing_ca/certs/ocsp.cert.pem

17. Crear la cadena de confianza del certificado de la CA raíz, CA de políticas y CA

emisora para verificar el estado de revocación de los certificados emitidos por la CA
emisora con OCSP.
cat /etc/pki/ca/issuing_ca/certs/ca_intermediate_issuing.cert.pem
/etc/pki/ca/policies_ca/certs/ca_intermediate_entities.cert.pem
/etc/pki/ca/issuing_ca/certs/ca.cert.pem >
/etc/pki/ca/issuing_ca/certs/ca_chain_issuing.cert.pem
 sudo chmod 444 /etc/pki/ca/issuing_ca/certs/ca_chain_issuing.cert.pem

4.6. Instalación de servidor web (Apache)

1. Instalar el paquete apache2

sudo apt install apache2 -y

2. Ajustar el firewall

sudo ufw allow 'Apache'

3. Verificar el estado del servicio

sudo systemctl status apache2

4. Modificar archivo de prueba

sudo nano /var/www/html/index.html

Se elimina el contenido existente con alt+t

Eliminar el contenido del archivo y colocar el siguiente código html:

<!DOCTYPE html>
<html>

<head>
<style id="mceDefaultStyles" type="text/css">
img:-moz-broken {
-moz-force-broken-image-icon: 1;
min-width: 24px;
min-height: 24px
}
</style>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" type="text/css" id="u0"
href="https://es.rakko.tools/tools/129/lib/tinymce/skins/ui/oxide/content.min.css">
<link rel="stylesheet" type="text/css" id="u1"
href="https://es.rakko.tools/tools/129/lib/tinymce/skins/content/default/content.min.css">
</head>

<body id="tinymce" class="mce-content-body " data-id="content" spellcheck="false" contenteditable="true">

<h3 data-mce-style="text-align: center;" style="text-align: center;"><span style="color: rgb(22, 145, 121);"
data-mce-style="color: #169179;"><strong>Universidad de Costa Rica</strong></span><br
data-mce-bogus="1">
</h3>
<h3 data-mce-style="text-align: center;" style="text-align: center;"><span style="color: rgb(22, 145, 121);"
data-mce-style="color: #169179;"><strong>Facultad de Ingeniería </strong></span><span
 style="color: rgb(22, 145, 121);" data-mce-style="color: #169179;"><strong></strong></span></h3>
<h3 data-mce-style="text-align: center;" style="text-align: center;"><span style="color: rgb(22, 145, 121);"
data-mce-style="color: #169179;"><strong>Escuela de Ciencias de la Computación e Informática</strong>
</span><br data-mce-bogus="1"></h3>
<p><span style="color: rgb(22, 145, 121);" data-mce-style="color: #169179;"><strong><br
data-mce-bogus="1"></strong></span></p>
<p><span style="color: rgb(22, 145, 121);" data-mce-style="color: #169179;"><strong><br
data-mce-bogus="1"></strong></span></p>
<h3 style="text-align: center;" data-mce-style="text-align: center;"><span style="color: rgb(22, 145, 121);"
data-mce-style="color: #169179;"><strong>CI 0158 Infraestructuras de llave
pública<br></strong></span></h3>
<h1 style="text-align: center;" data-mce-style="text-align: center;"><span

🔑🔐
style="color: rgb(22, 145, 121); font-size: 36pt;"
data-mce-style="color: #169179; font-size: 36pt;"><strong> </strong></span></h1>
<p><span style="color: rgb(22, 145, 121);" data-mce-style="color: #169179;"><strong><br
data-mce-bogus="1"></strong></span></p>
<p><span style="color: rgb(22, 145, 121);" data-mce-style="color: #169179;"><strong><br
data-mce-bogus="1"></strong></span></p>
<h3 data-mce-style="text-align: center;" style="text-align: center;"><span style="color: rgb(22, 145, 121);"
data-mce-style="color: #169179;"><strong>II Semestre 2022<br
data-mce-bogus="1"></strong></span></h3>
<p><span style="color: #169179;" data-mce-style="color: #169179;"><strong><br
data-mce-bogus="1"></strong></span>
</p>
<p><span style="color: rgb(22, 145, 121);" data-mce-style="color: #169179;"><strong><br
data-mce-bogus="1"></strong></span></p>
</body>

</html>

5. Cambiar la propiedad del directorio de CRLs y de todos los archivos debajo de él

para que sean propiedad del usuario de Apache

sudo chown -R www-data:www-data /etc/pki/CA/crl

6. Crear carpeta en el directorio raíz de Apache para los crls

sudo mkdir /var/www/html/crls_files

7. Atar los directorios para acceder a ellos

sudo mount --bind /etc/pki/CA/crl /var/www/html/crls_files

8. Acceder a la URL para verificar el acceso a la carpeta de CRLs {{IP}}/crls_files.

OCSP VS CRL

https://sectigostore.com/blog/ocsp-vs-crl-whats-the-difference/
https://www.keyfactor.com/blog/what-is-a-certificate-revocation-list-crl-vs-ocsp/

● Response Format
● The response received by the client is very different with CRLs and OCSP:
○ CRLs: The responder (the CA) lists the serial numbers of all the certificates the
CA revoked. The client browser downloads the whole list and searches for the
serial number of the certificate of the website it is trying to connect to. If that
serial number is not on the list, the browser considers that the certificate is not
revoked and allows the connection. Since updated CRLs aren’t required to be
published right away, it means that a certificate could be revoked a few hours
after the last CRL update and your browser wouldn’t know it.
○ OCSP: The OCSP responder sends the revocation status of the specific TLS
certificate requested by the browser — “good,” “revoked,” or “unknown.”
These revocation status checks are done on a connection-by-connection
basis, so the information is as up to date as possible.
● Speed and Resources
○ The CRL method requires the browser to download the list of all the revoked
certificates and parse it to look for the certificate serial number. As such, it can
take longer to come up with a result than it does to request a single
certificate’s revocation status with OCSP. Downloading the CRL also uses more
network resources than downloading the response for a single website, so
OCSP is less resource intensive.
● Support for Multiple Certificates
○ OCSP is fast and efficient when requesting a single certificate’s revocation
status. But for servers catering to multiple clients trying to access different
websites, CRLs are more efficient as it’s possible to verify the status of multiple
websites by downloading a single list. There’s no need to send multiple
requests, provided the websites have the same CA. However, if the websites
are certified by different CAs, OCSP is the better choice.
● Real-Time Updates
○ The CA/Browser Forum (CA/B Forum) says in its SSL/TLS Baseline
Requirements that CRLs must be “regularly updated” — but those intervals
vary depending on the issuing CA and other specific considerations. For
example, they could be updated every hour, every 24 hours, or even just once
a week, so there can be a time lag between the last update and the client
request.
○ If a website certificate is newly revoked after a CRL has been published, the
browser could end up connecting to an insecure site. OCSP provides real-time
updates and doesn’t have this issue.
● Network Failure
○ We’ve all faced situations where our networks fail. So, what happens when the
responder’s network is down? With OCSP, connections will likely be dropped
 as the responder will provide an “unknown” response. However, because
CRLs are stored offline once downloaded, the browser can refer to it again and
again without having to repeatedly connect to the CA.

What is OCSP Stapling?

● In order to know what OCSP Stapling is, you must first know about OCSP. OCSP or
Online Certificate Status Protocol is an internet protocol that checks the validity status
of a certificate in real-time. It is an alternative to CRL or Certificate Revocation Lists. It
is described in RFC 2560 - http://datatracker.ietf.org/doc/rfc2560/
● OCSP is a real-time check of the status of a certificate and is fundamental in the
design of Extended Validation SSL certificates.
● When a user makes an https:// connection with your web server, their browser
normally performs an OCSP check with the CA that issued the SSL certificate to
confirm that the certificate has not been revoked. In some cases, this may create a
momentary delay in the SSL handshake.
● OCSP Stapling improves performance by positioning a digitally-signed and
time-stamped version of the OCSP response directly on the webserver. This stapled
OCSP response is then refreshed at predefined intervals set by the CA. The stapled
OCSP response allows the web server to include the OCSP response within the initial
SSL handshake, without the need for the user to make a separate external connection
to the CA.
● OCSP Stapling is outlined in RFC 6066 - http://datatracker.ietf.org/doc/rfc6066/
● Note: When enabling and/or configuring OCSP Stapling on your servers, keep in mind
that the OCSP request from your server to the CA must be allowed access through
your firewall.
● Advantages
○ OCSP Stapling improves the connection speed of the SSL handshake by
combining two requests into one. This cuts down on the amount of time it
takes to load an encrypted webpage.
○ OCSP Stapling helps maintain the privacy of the end user as no connection is
made to the CRL for the OCSP request. Rather than see which websites a user
has visited, the CA will only see OCSP requests from the web site and not its
users.
○ There are scenarios where a computer has to connect to a portal or hotspot
access the internet, but it cannot verify the OCSP check (as access to the
iInternet hasn't been granted yet). In these cases, OCSP Stapling helps, as the
OCSP status is provided from the hotspot or portal.

● Disadvantages
○ Support for OCSP Stapling is not yet supported by all browsers. If either the
browser or the web server do not support or have OCSP Stapling enabled,
 then it simply is not used and validity status lookup will automatically revert to
OCSP checking directly with the CA.
Link de como habilitar el stapling
https://www.keycdn.com/support/ocsp-stapling
https://www.digicert.com/kb/ssl-support/apache-enable-ocsp-stapling-on-server.htm
https://www.digitalocean.com/community/tutorials/how-to-configure-ocsp-stapling-on-apa
che-and-nginx

Comando para comprobar el status

echo | openssl s_client -connect 172.16.202.27:443 -status 2>&1 | grep
"OCSP"

FIPS 140: Niveles de cumplimiento