Proyecto 1 - Configuración y desarrollo de una Autoridad de Certificación

Integrantes: Carlos Bermudez – Javier Vargas
Subproyecto 1
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. Allí 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 encriptar la clave
con 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 una 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.vargas-bermudez.key.pem 2048
# chmod 400 intermediate/private/www.vargas-bermudez.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.vargas-bermudez.com.key.pem \
-new -sha256 -out intermediate/csr/www.vargas-bermudez.com.csr.pem
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.vargas-bermudez.com.csr.pem \
-out intermediate/certs/www.vargas-bermudez.com.cert.pem
# chmod 444 intermediate/certs/www.vargas-bermudez.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.vargas-bermudez.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.vargas-bermudez.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.vargas-bermudez.com.key.pem
www.vargas-bermudez.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.vargas-bermudez.com.cert.pem
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.
Subproyecto 2
Firmar documentos
Se firmará un certificado para un cliente usando la CA intermedia.
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/javier-carlos.key.pem 2048
# chmod 400 intermediate/private/javier-carlos.key.pem
Crear un certificado
Hay que usar la clave privada para crear un CSR.
# cd /root/ca
# openssl req -config intermediate/openssl.cnf \
-key intermediate/private/javier-carlos.key.pem \
-new -sha256 -out intermediate/csr/javier-carlos.csr.pem
Para crear un certificado se usa la CA intermediaria para firmar el CSR.
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-out intermediate/certs/javier-carlos.cert.pem \
-in intermediate/csr/javier-carlos.csr.pem \
-cert intermediate/certs/intermediate.cert.pem \
-keyfile intermediate/private/intermediate.key.pem
# chmod 444 intermediate/certs/www.javier-carlos.cert.pem
Opción 1 - Generar certificado PFX para ser usado en Adobe Acrobat Pro
# openssl pkcs12 -export -out intermediate/certs/firma.pfx -inkey
intermediate/private/javier-carlos.key.pem -in
intermediate/certs/javier-carlos.cert.pem
Usar archivo PFX para generar PDF firmado
Ingresamos al Adobe Acrobat Pro y elegimos la opción “Firmar”
Elegimos la opción “Colocar firma” y arrastramos dentro del pdf un rectángulo en
donde se quiere colocar la firma
Elegimos el archivo PFX que habíamos generado y colocamos la clave
Luego presionamos en el botón “Firmar” y guardamos el PDF Firmado
preferentemente con otro nombre, por ejemplo si el primero se llamaba “Pdf de prueba” a
este nuevo podrimos llamarle “Pdf de prueba firmado”.
Opción 2 – Firmar y verificar documentos con Openssl
Una vez firmado el certificado del cliente, nos encontramos con que tenemos 3
archivos:
•
•
•
intermediate/private/javier-carlos.key.pem (clave privada del cliente)
intermediate/certs/javier-carlos.cert.pem (certificado firmado del cliente)
documento.txt (documento a ser firmado)
Como paso siguiente debemos extraer la clave pública del certificado del cliente
# openssl x509 –pubkey –noout –in interediate/certs/javier-carlos.cert.pem
> intermediate/private/publica.pem
Ahora debemos firmar el documento.txt con la clave privada del cliente:
# openssl dgst -sha256 -sign intermediate/private/javier-carlos.key.pem out sign.sha256 documento.txt
# openssl base64 -in sign.sha256 -out mifirma
Verificamos la firma con los siguientes comandos:
# openssl base64 -d -in mifirma -out sign.sha256
# openssl dgst -sha256 -verify intermediate/private/publica.pem -signature
sign.sha256 documento.txt
Como el documento.txt no está adulterado nos aparece:
Verified: OK
Si luego adulteramos documento.txt y volvemos a verificar con:
# openssl dgst -sha256 -verify intermediate/private/publica.pem signature sign.sha256 documento.txt
nos aparece:
Verification: Failure