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