CentOS / Red Hat Configure an NTP Client And Server

How do I configure an NTP (Network Time Protocol) client or server under CentOS / RHEL / Fedora Linux to manage the system clock over a network?

The Network Time Protocol (NTP) is used to synchronize a computer's time with another reference time source. Under CentOS / RHEL you can use NTP or OpenNTPD server software. Both package provides client and server software programs for time synchronization.

Install ntp

The ntp package contains utilities and daemons that will synchronize your computer's time to Coordinated Universal Time (UTC) via the NTP protocol and NTP servers. The ntp packageincludes ntpdate (a program for retrieving the date and time from remote machines via a network) and ntpd (a daemon which continuously adjusts system time). Install the ntp package:
# yum install ntp

How do I configure an NTP Client?

Simply open /etc/ntp.conf file, enter:
# vi /etc/ntp.conf
Make sure the following line exists:
server ntp.server.com
Where,

• ntp.server.com : the hostname or IP address of the site NTP server. If your ntp server located at 192.168.1.5, enter server 192.168.1.5. You can also use public ntp server located at ntp.org.

You can also run ntpd using cron:
# echo '30 * * * * root /usr/sbin/ntpd -q -u ntp:ntp' > /etc/cron.d/ntpd
The above instructs crond to run ntpd and after setting the clock just exit, and the -u option instructs it to run as the ntp user.

Configure an NTP Server

If you have lots of server and desktop system, configure your own NTP server. Your NTP server contacts a central NTP server,provided by your ISP or a public time
server located at ntp.org, to obtain accurate time data. The server then allows other machines on your network to request the time data. Our sample setup:
192.168.1.5 ==> CentOS / Fedora / RHEL NTPD Server. 202.54.1.5 ==> ISP remote NTP server. 192.168.1.0/24 ==> NTP clients including desktop systems.First, install and enable ntpd on 192.168.1.5:
# yum install ntp
# chkconfig ntpd on
Now open /etc/ntp.conf:
# vi /etc/ntp.conf
Make sure the following line exits:
restrict default ignore
Above will deny all access to any machine, server or client. However, you need to specifically authorized policy settings. Set it as follows:
restrict 202.54.1.5 mask 255.255.255.245 nomodify notrap noquery server 202.54.1.5Replace 202.54.1.5 and mask with actual remote ISP or ntp.org NTP server IP. Save and close the file.

Configure NTP clients to access your NTP Server

Now, you need to allow legitimate NTP clients to access the Server. For example, allow 192.168.1.0/24 network to synchronize to this server located at 192.168.1.5. Open /etc/ntp.conf and add policy as follows:
# Hosts on local network are less restricted. restrict 192.168.1.0 mask 255.255.255.0 nomodify notrapUpdate your firewall settings, open /etc/sysconfig/iptables.
# vi /etc/sysconfig/iptables
Add the following line, before the final LOG and DROP lines for the RH-Firewall-1-INPUT chain:
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPTSave and close the file. Finally, start ntpd:
# service ntpd start
# service iptables restart
# netstat -tulpn 

Llaves, repositorios y Secure APT

• Ver
• Comentarios 

Índice

1. Introducción
2. Como funciona
3. Como APT utiliza Release.gpg
4. Como añadir una llave pública
5. Caso: Repositorios oficiales de Debian
6. Referencias y más información

Introducción

A partir de la versión 0.6, apt comenzó a usar criptografía para validar los paquetes descargados, a esto se le llama comúnmente “Secure Apt” (o “apt-secure”).
La criptografía de llave (o clave) pública se basa en el par de llaves: una llave pública y una privada. Si bien la llave pública se da a todo el mundo, la llave privada debe permanecer en secreto, así es posible usar una llave privada para firmar un archivo (no para encriptarlo) y cualquiera que tenga la llave pública puede comprobar que el archivo fue firmado por esa llave, esto nos asegura que nadie que no tenga esa llave puede falsificar la firma.
GPG (GNU Privacy Guard) es la herramienta que se utiliza en Secure-Apt para firmar los ficheros y comprobar sus firmas. GPG cifra los mensajes usando pares de claves individuales asimétricas generadas por los usuarios. Las claves públicas pueden ser compartidas con otros usuarios de muchas maneras, un ejemplo de ello es depositándolas en los servidores de claves.
Apt-key es un programa que se usa para gestionar el anillo de llaves de gpg para asegurar Apt. El anillo de llaves se guarda en el archivo /etc/apt/trusted.gpg (no confundir con el archivo /etc/apt/trustdb.gpg con el que está relacionado). Apt-key puede ser usado para mostrar las llaves en el anillo de llaves, y para añadir o remover una llave.
Así si un paquete viene de un archivo sin firma o con una firma de la que apt no tiene una clave, se considerará como no confiable y se nos mostrará la correspondiente advertencia, es decir, apt-get (actualmente) sólo nos advierte de los archivos sin firmar pero no impide su descarga y posterior instalación. Sin embargo para los paquetes que vienen firmados, APT utiliza este sistema de criptografía GPG para validar los .deb descargados y asegurarse de que no han sido alterados en modo alguno.

2. Como funcionan

1. Un archivo de Debian contiene un archivo llamado Release, el cual se actualiza cada vez que cualquiera de los paquetes en el archivo cambian. Entre otras cosas, el fichero Release contiene algunos md5sums por cada paquete listado en él.
2. Al realizar un update, APT descarga los archivos Packages.gz, Release y Release.gpg.
3. Al descargar un paquete .deb, APT comprueba que su md5sum coincide con la que figura en Packages.
4. APT se asegura la no alteración del archivo Packages comprobándo que su md5sum coincide con el que figura en el archivo Release.
5. Ahora para asegurarse de que el archivo Release no ha sido alterado, APT comprueba su firma a través del archivo Release.pgp, es decir Secure-Apt añade una firma gpg para el fichero Release en el fichero Release.gpg (que se envía junto al fichero Release) y para poder realizar esta comprobación APT necesita conocer la llave pública del que firma el archivo.

3. Como APT utiliza Release.gpg

Secure Apt siempre descarga los ficheros Release.gpg cuando está descargando los ficheros Release, y si no puede descargar el archivo Release.gpg, o si la firma está mal, lo advertirá, y nos dirá que el fichero Packages al cual apunta el fichero Release, y todos los paquetes enumerados dentro, son de una fuente sin autentificar. Por este motivo, durante un apt-get update, apararece el famoso:

W: GPG error: http://ftp.us.debian.org testing Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F

(Aquí el inciso de que si tenemos sospechas de que se debe a una actualización de la base de claves de Debian -usual cuando se lanza una nueva versión- basta con instalar el paquete debian-archive-keyring actualizado para resolverlo.) Como ya hemos mencionado, podemos ignorar ese aviso e intentar instalar un paquete, al hacerlo Apt nos advertirá de nuevo:

WARNING: The following packages cannot be authenticated!
  libglib-perl libgtk2-perl
Install these packages without verification [y/N]?

Como vemos APT nos permite aceptar la instalación de paquetes sin verificar, pero el problema (peligro) es que no podríamos saber si ese paquete es el paquete que realmente queremos instalar, o si es otro distinto al que queremos y lleva dentro una desagradable sorpresa.
NOTA: podemos deshabilitar esas comprobaciones ejecutando apt con –allow-unauthenticated.
Como vemos la seguridad del sistema entero depende de que haya un fichero Release.gpg, el cual firma un fichero Release, y de APT comprobando que esa firma use gpg. Para comprobar la firma, APT debe conocer la llave pública de la persona que firmó el fichero. Esas llaves se mantienen en el anillo de llaves de APT (/etc/apt/trusted.gpg), y administrando esas llaves es donde aparece Secure Apt.
Por defecto, los sistemas Debian vienen preconfigurados con la llave del archivo Debian en el anillo de llaves, así a modo de ejemplo podemos ver que llaves públicas tenemos haciendo:
# apt-key list
obtenemos

/etc/apt/trusted.gpg
--------------------
pub   1024D/6070D3A1 2006-11-20 [expires: 2009-07-01]
uid                  Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>

Aquí 6070D3A1 es la identificación de la llave pública, y podemos ver que esta llave sólo es válida por tiempo, Debian rota estas llaves como última línea de defensa contra algunas brechas de seguridad que rompen una llave. Con ello APT consigue certificar el archivo oficial de Debian.
Si se añade algún otro repositorio al archivo /etc/apt/sources.list, tendremos que darle a APT su llave, es decir, deberemos añadir su llave pública al anillo de llaves para que APT pueda certificar su contenido.

4. Como añadir una llave pública

El proceso se divide en dos etapas:
1. Obtener la llave pública
2. Exportar esa llave y añadirla
Pongamos un ejemplo:
Si añadimos el repositorio de debian-multimedia a nuestro archivo /etc/apt/sources.list:
deb http://www.deb-multimedia.org stable main non-free
En principio no tenemos su llave pública, por tanto al actualizar el índice de paquetes de nuestros repositorios:
# aptitude update
Se nos mostrará la siguiente advertencia:

W: GPG error: http://www.deb-multimedia.org stable main Release: The following signatures
couldn't be verified because the public key is not available: NO_PUBKEY 07DC563D1F41B907

Debemos fijarnos en el número que nos muestra: 07DC563D1F41B907
GPG tiene una forma estándar de distribuir llaves, utiliza servidores de llaves y desde uno de ellos gpg puede descargarse la llave pública, para elo ejecutamos:

# gpg --keyserver subkeys.pgp.net --recv-keys 07DC563D1F41B907

Una vez obtenida, sólo nos falta exportarla y añadirla:

# gpg --export --armor 07DC563D1F41B907 | apt-key add -

Y finalizamos el proceso con un:

# apt-get update

NOTA: en el caso concreto de deb-multimedia, el procedimiento se puede simplificar instalando el paquete deb-multimedia-keyring

5. Caso: Repositorios oficiales de Debian

Disponemos de los paquetes:
debian-keyring, contiene las firmas de los desarrolladores de Debian, que es utilizada para verificar cada paquete.
debian-archive-keyring, el proyecto Debian firma digitalmente sus archivos «Release». Este paquete contiene las claves que se utilizan para ello.

Extraido: http://www.esdebian.org/wiki/llaves-repositorios-secure-apt

Operaciones con certificados

Extraido de: http://www.bdat.net/documentos/certificados_digitales/x359.html

Verificar una firma

Para verificar la firma necesitamos la llave privada

openssl req -in newcert.req -noout -verify -key cert.key

La llave privada puede encontrarse en el mismo fichero que el certificado como vimos en ejemplos anteriores.

Mostrar detalles del certificado

openssl req -in newcert.req -noout -text

Comprobar los datos de un certificado

Para ver la información general sobre un certificado:

openssl s_server -cert mycert.pem -www

Para ver el emisor del certificado

openssl x509 -noout -in cert.pem -issuer

Para ver el propietario del certificado

openssl x509 -noout -in cert.pem -subject

Para ver su periodo de validez

openssl x509 -noout -in cert.pem -dates

Con más de una opción a la vez

openssl x509 -noout -in cert.pem -issuer -subject -dates

El el valor hash

openssl x509 -noout -in cert.pem -hash

Ver la huella digital MD5

openssl x509 -noout -in cert.pem -fingerprint

Mostrar la huella digital SHA1 de un certificado

openssl x509 -sha1 -in cert.pem -noout -fingerprint

Mostrar el contenido de un certificado

openssl x509 -in cert.pem -noout -text

Mostrar el número de serie de un certificado

openssl x509 -in cert.pem -noout -serial

Mostrar el propietario de un certificado en formato RFC2253

openssl x509 -in cert.pem -noout -subject -nameopt RFC2253

Mostrar el propietario de un certificado en una línea en un terminal con UTF8

openssl x509 -in cert.pem -noout -subject -nameopt oneline,-escmsb

Cambiar el alias de un certificado

Crear un certificado del confianza para uso de clientes SSL cambiando su alias a "Steve's Class 1 CA"
openssl x509 -in cert.pem -addtrust clientAuth \

-setalias "Steve's Class 1 CA" -out trust.pem

Recoger certificado remoto

openssl s_client -connect host:puerto

Podemos ver un script para recoger certificados:

#!/bin/sh # # usage: retrieve-cert.sh remote.host.name [port] # REMHOST=$1 REMPORT=${2:-443} openssl s_client -connect ${REMHOST}:${REMPORT} 2>&1 |\ sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Cambiar el formato de un certificado

Convertir un certificado a solicitud de certificado

openssl x509 -x509toreq -in cert.pem -out req.pem -signkey key.pem

Convertir una solicitud de certificado en un certificado autofirmado usando extensiones para una CA

openssl x509 -req -in careq.pem \ -extfile openssl.cnf -extensions v3_ca \ -signkey key.pem -out cacert.pem

Convertir un certificado de formato PEM a DER

openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER

Importar y exportar certificados PKCS#12

Los ficheros PKCS#12 se pueden exportar desde diversas aplicaciones, como por ejemplo Microsoft IIS. Con frecuencia están asociados a la extensión .pfx.
Paa crear un certificado PKCS#12 primero necesitamos una llave privada y un certificado. Durante el proceso de conversión tiene la posibilidad de de introducir una contraseña de exportación para el certificado, que puede ser nula.
# Primero creamos un fichero con la llave privada y el certificado autofirmado

openssl req \ -x509 -nodes -days 365 \ -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

# exportamos mycert.pem como fichero PKCS#12: mycert.pfx

openssl pkcs12 -export \ -out mycert.pfx -in mycert.pem \ -name "Mi certificado"

Si alguien le envía un certificado PKCS#12 necesario y protegido por contraseña, se puede exportar en formato PEM estándar.
# exportar certificado sin clave

openssl pkcs12 -in mycert.pfx -out mycert.pem -nodes

# exportar el certificado pero cambiándole la clave

openssl pkcs12 -in mycert.pfx -out mycert.pem

Verificaciones de certificados

Las aplicaciones enlazadas con la biblioteca OpenSSL pueden verificar certificados firmados por un CA reconocido.
Para verificar un certificado usamos la orden verify de openssl:

openssl verify cert.pem

Si el certificado es correcto la aplicación responde con un ?OK?. Si no es correcto emite el mensaje correspondiente.
Por ejemplo:

error 10 at 0 depth lookup:certificate has expired.

Indica que el certificado ha sobrepasado su periodo de vigencia.

error 18 at 0 depth lookup:self signed certificate.

openssl no verifica certificados autofirmados.

Tipos de formatos de Certificados

Extraido de: http://publikaccion.blogspot.com.ar/2007/05/tipos-de-formatos-de-certificados.html

Los certificados de firmas digitales se basan en los algoritmos de firma DSA y en el algoritmo RSA para criptografía de clave pública según los algoritmos PKCS. El formato del certificado depende de la aplicación, ya que no hay unanimidad en los estándars de los formatos. Se suele disponer de claves privadas cuando nos referimos a los formatos PEM y DER. El formato por defecto para la aplicación OpenSSL es PEM. Para aplicaciones Java el formato DER suele encajar mejor con las necesidades de la aplicación en cuanto a la importación de claves privadas y certificados.

De modo genérico, los formatos PEM se suelen emplear en el mundo Unix/Linux, PKCS12 en el mundo Microsoft y el formato DER en el mundo Java.

Los archivos de certificado son objetos codificados en formato ASN-1 según el estándar DES (Data Encryption Standard). Los archivos también se pueden encriptar empleando un algoritmo CIPHER simétrico como 3 DES.

Un archivo de certificado PEM si encriptar tiene este aspecto

-----BEGIN CERTIFICATE-----
MB4CGQDUoLoCULb9LsYm5+/WN992xxbiLQlEuIsCAQM=
-----END CERTIFICATE-----

La cadena que comienza por MB4C es el objeto codificado en Base 64 y en ASN-1.

Un archivo encriptado tendrá cabeceras que describen el tipo de encriptación empleada, así como el vector de inicialización.

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,C814158661DC1449
AFAZFbnQNrGjZJ/ZemdVSoZa3HWujxZuvBHzHNoesxeyqqidFvnydA==
-----END RSA PRIVATE KEY-----

Las 2 cabeceras Proc-Type y DEK-Info declaran el tipo de encriptado, y la cadena que comienza por AFAZ es el objeto codificado en Base 64, encriptado y codificado en ASN-1.

Debido a que los navegadores hacen uso de aplicaciones Java, exportan o importan los certificados en formato de archivo PKCS12 (que son archivos que empaquetan las claves privadas y públicas en un sólo archivo empleando el algoritmo PKCS#12). Otras aplicaciones emplean el formato PEM de modo que las claves privadas y públicas deben estar desempaquetadas, de modo que el usuario debe recordar el formato de archivo para cada aplicación y debe proceder a la conversión entre formatos según sus necesidades.

PEM

Puede contener todas las claves privadas (RSA y DSA), las claves públicas (RSA y DSA) y los certificados (x509). Este es el formato por defecto de OpenSSL. Almacena los datos en formato DER codificado Base64, entre cabeceras ascii, de modo que es apropiado para transferencias en modo texto entre sistemas. Su extensión suele ser .pem.

DER

Puede contener todas las claves privadas, las claves públicas y los certificados. Se almacena según el formato DER ASN1. No posee cabecera - PEM es el envoltorio del texto de la cabecera de DER. Es el formato por defecto de la mayoría de navegadores web. Su extensión suele ser .der.

PKCS#12

También conocido como archivos PFX (Personal Information Exchange format). Puede contener todas las claves privadas, las claves públicas y los certificados. Se almacena en formato binario. Este formato habilita la transferencia de certificados y sus claves privadas correspondientes de un ordenador a otro o de un ordenador a un medio externo (removable media). El PKCS#12 (o Public Key Cryptography Standard #12) es un formato que es apropiado para llevar de un sitio a otro o almacenar y restaurar dicho certificado y sus claves privadas asociadas. Esto se puede hacer entre productos del mismo proveedor o incluso de proveedores distintos. Su extensión suele ser .p12.

PKCS#7

El PKCS#7 (o Public Key Cryptography Standard #7) habilita la transferencia de un certificado y todas las rutas de los certificados y sus certificaciones de un ordenador a otro, o de un ordenador a un medio externo (removable media). Los archivos PKCS#7 poseen la extensión .p7b, y son compatibles con el estándar ITU-T X.509. Este formato permite atributos como countersignatures estén asociadas con las firmas y que atributos como signing time pueden ser autentificados con contenido de mensaje.

Shortcuts: comandos OpenSSL para generar claves, certificados y testear conexiones

Extraido de: http://itfreekzone.blogspot.com.ar/2013/04/shortcuts-comandos-openssl-para-generar.html

OpenSSL es una herramienta extremadamente potente, la cual permite hacer todo tipo de manejos relacionados a TLS/SSL, desde creación de claves y certificados, realizar conexiones tipo telnet a servicios que se ejecutan sobre SSL, hasta generar hashes de archivos, entre otras cosas.
A continuación les dejo un listado de comandos útiles a realizar con OpenSSL. La mayoría se centran en la creación y manipulación de claves y certificados, algo que todo administrador ha tenido que hacer alguna vez.
Ya había escrito sobre la creación de certificados en el artículo Certificados Digitales, donde podrán encontrar una explicación más detallada sobre ello. En éste la idea es dejar un acceso rápido a comandos que nos serán muy útiles, además de proveer varios comandos adicionales a los descriptos anteriormente.
Cabe mencionar que muchos de estos comandos los aprendí gracias al artículo The Most Common OpenSSL Commands y los completé con el excelente OpenSSL Command-Line HOWTO y Creating an SSL Certificate of Authority.


Claves

Generar clave RSA de 4096 bits encriptada con 3des:
  $ openssl genrsa -des3 -out superkey.key 4096

Desencriptar la clave privada
  $ openssl rsa -in superkey.key -out super-decrypted.key

Extraer la clave privada de un archivo en formato PKCS#12:
  $ openssl pkcs12 -in certificad.pfx -out clave.pem -nodes -nocerts

Verificar clave RSA:
  $ openssl rsa -in interbankingtestmil-open.pkcs -check


Convertir formatos

Convertir clave de formato tradicional a pkcs8:
  $ openssl pkcs8 -in key.pem -topk8 -out pkcskey.pkcs

Convertir un certificado PEM y una clave privada en un archivo formato PKCS#12 (.pfx o p12)
  $ openssl pkcs12 -export -out certificado.pfx -inkey clave.pem -in certificado.crt -certfile certificadoCA.crt


Certificados

Crear una CA Propia con validez de 10 años y clave RSA de 4096 bits:
  $ openssl req -new -x509 -days 3650 -extensions v3_ca -newkey rsa:4096 -keyout private/newca.pem -out newca.crt //-config /etc/ssl/openssl.cnf

Generar un request de certificado:
  $ openssl req -new -key superkey.key -out certrequest.csr

Autofirmar request de certificado (CSR):
  $ openssl x509 -req -days 3650 -in cert-request.csr -signkey ca.key -out certificado.crt

Firmar request con CA:
  $ openssl ca -in cert-request.csr -out certificado.crt -days 3650

Crear clave y certificado autofirmado en un solo paso:
  $ openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt

Extraer el certificado incluído en un contenedor PKCS#12:
  $ openssl pkcs12 -in certificad.pfx -out certificado.crt -nodes -nokeys

Ver los campos de un request de certificado:
  $ openssl req -noout -text -in certrequest.csr

Ver campos del certificado:
  $ openssl x509 -in certificado.crt -text -noout

Ver campos de un contenedor PKCS#12:
  $ openssl pkcs12 -info -in certificado.pfx


Otras utilidades

Conectar a un servicio que se ejecuta sobre SSL (por ejemplo HTTPS):
  $ openssl s_client -connect servidor:443

Calcular el hash MD5, SHA1, SHA2, etc de un archivo y de un texto
  $ openssl dgst [-md5|-md4|-md2|-sha1|-sha|-mdc2|-ripemd160|-dss1] archivo
  $ echo "texto" | openssl dgst [-md5|-md4|-md2|-sha1|-sha|-mdc2|-ripemd160|-dss1]

Generando las claves SSH

Extraido de:  http://www.imh.es/es/comunicacion/dokumentazio-irekia/manuales/instalar-un-servidor-ssh-en-linux/generando-las-claves-ssh

Se analiza el proceso de generación de claves públicas y privadas

Para poder utilizar SSH, primero debemos generar las claves. Al generarlas, obtenemos dos ficheros, uno con el contenido de la clave privada, y el otro con el contenido de la clave publica.

En el servidor SSH pondremos nuestra clave publica, y la clave privada deberemos guardarla y tendremos cuidado de no dársela a nadie.

De esta forma, si tuviéramos 5 servidores a gestionar, configuraríamos nuestra clave publica en los 5, y a través de la clave privada configurada en nuestra maquina, accederíamos a todos los servidores sin ningún problema.

Generando las claves en Linux

Para crear las claves, tenemos que estar validados como el usuario que las va a utilizar. Si las generamos como root, solo el root podrá utilizarlas.

ssh-keygen -t rsa

aceptamos la carpeta que nos propondrá dentro del home ~/.ssh/id_rsa

Luego introducimos la clave ssh o paraphrase que nos pide. Conviene que esta clave sea distinta a la que tenemos como usuarios en el servidor.
Tras hacer esto, genera dos ficheros:

• Clave privada: ~/.ssh/id_rsa
• Clave publica: ~/.ssh/id_rsa.pub

Luego hay que modificar los permisos de la carpeta ssh:

chmod 755 ~/.ssh.

Formato Certificados X.509

Extraido de:  https://blogs.oracle.com/mgil/entry/font_id_wszh_size_5
Este documento, pretende mostrar de una forma fácil y simple la manera de convertir certificados en los diferentes formatos posibles.

• Conversión de certificados X.509 o claves RSA desde formato PEM hacia DER y viceversa.
  
• Conversión de certificados X.509 o claves RSA en certificados Public-Key Cryptography Standard #12 (PKCS#12).
  

X.509 o claves RSA ---> Certificados PEM o DER

Lo primero es tener una instalación de OpenSSL activa y operativa para pode ejecutar el comandos "openssl" desde una consola o terminal. Los certificados X.509 y las claves RSA pueden ser almacenados en diferentes formatos. Dos formatos comunes son DER (un formato binario utilizado principalmente por Java y plataformas Macintosh) y PEM (una representación base64 de los certificados DER con información de cabecera y pie final, que es utilizado principalmente por plataformas UNIX y Linux). Existe otro formato de certificado obsoleto llamado NET (Netscape Certificate) que ha sido utilizado en las primeras versiones de IIS (hasta la 4, incluida) y algunos otros formatos que no se cubren en este documento.
Una clave y su correspondiente certificado así como el certificado root y certificados intermedios, pueden ser almacenados en un único PKCS#12 (extensiones .P12 o .PFX), como explicaremos más adelante.
Utilizaremos el comando "openssl" para convertir los certificados entre los diferentes formatos de la siguiente manera.

• Para convertir un certificado X.509 de PEM a DER:
  

# openssl x509 –in input.crt –inform PEM –out output.crt –outform DER

• Para convertir un certificado X509 de DER a PEM

# openssl x509 –in input.crt –inform DER –out output.crt –outform PEM

• Para convertir una clave RSA de PEM a DER:

# openssl rsa –in input.key –inform PEM –out output.key –outform DER

• Para convertir una clave RSA de DER a PEM:

# openssl rsa –in input.key –inform DER –out output.key –outform PEM

Si las claves que estamos importando, estuviesen cifradas con algún algoritmos de cifrado simétrico conocido, se solicitará la password en la ejecución del comando.
Para convertir una clave a o desde el formato obsoleto NET, sustituiremos NET por PEM o DER como queramos. La clave será almacenada de forma cifrada utilizando un algoritmo de cifrado simétrico pobre llamado RC4, de modo que una passphrase será pedida, aunque passphrase en blanco son aceptadas.
Las claves son información sensible que deben de ser almacenadas de forma cuidadosa y cifradas utilizando cifradores robustos y passphrase adecuadas. Podemos utilizar cualquiera de los siguientes cifradores simétricos DES, TripleDES, IDEA, 128AES, 192AES o 256AES, para proteger nuestro certificado, simplemente añadiendo el flag correspondiente (des, des3, idea, aes128, aes192 o aes256) en la línea de comando.
Si no se dispone de acceso a a passphrase de una clave cifrada, no será posible recuperar la clave y será necesario generar una nueva clave con sus correspondientes certificados.

X.509 o claves RSA ---> Certificados PKCS#12

Explicamos como convertir certificados X.509 o claves RSA en formato Public-Key Cryptography Standard #12 (PKCS#12). Para ello necesitaremos al igual que antes una instalación activa de OpenSSL.

El estándar PKCS#12, especifica un formato portable para almacenar y transportar certificados, claves privadas y secretos varios. Es el formato preferido por muchos operaciones de gestión de certificados y es soportado por la mayoría de browsers y familias recientes de sistema operativo Windows. Tiene la ventaja de que es capaz de almacenar el certificado con su correspondiente clave, con el certificado root (de la CA) y otros certificados posibles de la cadena en un único fichero.
Primero nos aseguraremos de que el certificado esta en formato PEM. Para ello deberemos de realizar cualquiera de las operaciones descritas en el apartado anterior para convertir el certificado X.509 o clave RSA en formato DER hacia formato PEM. Si tuviesemos que convertir una clave RSA de NET a PEM, necesitariamos la passphrase, en caso negativo no podríamos recuperar el certificado, en caso de que la tengamos, ejecutamos:

# openssl rsa –in input.key –inform NET –out output.key –outform PEM

Una vez que tenemos el certificado en formato PEM, utilizaremos de nuevo el comando "openssl" para leer el certificado codificado PEM y sus correspondientes claves para exportarlo en un único certificado PKCS#12.

# openssl pkcs12 -export -in input.crt -inkey input.key -out bundle.p12

Por defecto, la clave será cifrada utilizando TripleDES de modo que nos solicitará un password para el certificado exportado (por supuesto puede dejarse en blanco).

El certificado PEM formateado y cualquier otro certificado de la cadena serán concatenados en un único fichero (por ejemplo, root.crt) e incluidos en el fichero PKCS#12 de la siguiente manera.

# openssl pkcs12 -export -in input.crt -inkey input.key -certfile root.crt -out bundle.p12

Dándole "cera" al algoritmo RSA

Extraido de http://www.madesyp.com/news/15112012.php

Publicado por Pedro C. el 15-11-2012

Hay mucha gente que se entera por Microsoft© de los "fallos de seguridad" y en esta entrada, vamos a ver cómo romper una clave RSA en GNU/Linux o Windows aprovechando la factorización de los números y la potencia de cálculo actual que tenemos en los equipos caseros.
Ya anunció desde Junio de 2012 que las claves RSA con menos de 1024 bits son consideradas inseguras porque se puede deducir la clave "privada" a partir de la clave "pública" y publicó un boletín de seguridad. Actualmente la práctica es emplear 2048 bits. Sin embargo, en el mundillo, llevamos ya mucho tiempo diciendo y demostrando dicha afirmación. De hecho, l@s que habéis venido a los Cursos de Seguridad, lo hemos practicado "a mano" con números "pequeños".
Como consecuencias de la actualización, aparecerá un error cuando un Certificado SSL para un sitio web tenga una longitud de clave inferior a 1024 bits, al crear correos encriptados o firmados con S/MIME, al instalar controles ActiveX o incluso al instalar aplicaciones que se firmen con claves inferiores a dicha longitud. Aquí tenemos un "salvoconducto" ya que la excepción es que no son bloqueadas si fueron firmadas antes del 1 de Enero de 2010... jejeje...
Para ponerlo en práctica y a partir de la publicación de Daniel Lerch adaptándola a los tiempos actuales, lo primero que haremos es instalar OpenSSL en Windows o GNU/Linux y crearnos una clave "débil" de 512 bits para posteriormente romperla y obtener a partir de la clave pública su clave privada.
Lo primero, crear la clave privada con 256 bits:

openssl genrsa –out privada.pem 256
more privada.pem

-----BEGIN RSA PRIVATE KEY-----
MIGrAgEAAiEA3x7cFSnjgi7T5jgnFlW2lOYgxozmKj4zs80HaSf/Y78CAwEAAQIh
ANwZyy2tdttTaoFu31AvGb4NhSPhQkVSdH9Bb+E7f+GBAhEA8EW6Td2GFkwi1TL2
dA/Y3wIRAO25t31L+qBy8aJz06IGcSECEQCIXVqWVLKENyPR0oGzb0cLAhAY63z2
n35YT3RRCT9IHtDBAhA0kHMpCgP+a7L+UzirjCp6
-----END RSA PRIVATE KEY-----
    

Ahora, crearemos la clave pública a partir de la privada:

openssl rsa –pubout < privada.pem > publica.pem
more publica.pem

-----BEGIN PUBLIC KEY-----
MDwwDQYJKoZIhvcNAQEBBQADKwAwKAIhAN8e3BUp44Iu0+Y4JxZVtpTmIMaM5io+
M7PNB2kn/2O/AgMBAAE=
-----END PUBLIC KEY-----
    

Por supuesto, recordareis gpg y "subir nuestra clave pública" a los servidores. En éste caso, no lo vamos a hacer, pero vamos a cifrar un mensaje y para ello, recordareis que se hace con la clave pública.

echo Hola Mundo! > mensaje.txt
more mensaje.txt
Hola Mundo!

openssl rsautl –encrypt –pubin –inkey publica.pem –in mensaje.txt –out cifrado.txt
    

Si pusiéramos more cifrado.txt veríamos "chinos" ya que es un formato binario. Para poder verlo desencriptado, y puesto que disponemos de la clave privada para poder hacerlo, tendríamos que poner:

openssl rsautl –decrypt –inkey privada.pem –in cifrado.txt
Hola Mundo!

    

Con toda la tranquilidad y seguridad del mundo, ese mensaje cifrado sería enviado a Guacheras que con nuestra clave pública y su clave privada sería capaz de desencriptarlo. Es decir, Guacheras tiene nuestra "débil clave pública". Se sienta un "ratico" y antes de que le entre más sueño que a unos gaticos al "lao" de la lumbre, extrae la información que le interesa de la clave pública:

openssl rsa –in publica.pem –pubin –text –modulus

Public-Key: (256 bit)
Modulus:
    00:df:1e:dc:15:29:e3:82:2e:d3:e6:38:27:16:55:
    b6:94:e6:20:c6:8c:e6:2a:3e:33:b3:cd:07:69:27:
    ff:63:bf
Exponent: 65537 (0x10001)
Modulus=DF1EDC1529E3822ED3E638271655B694E620C68CE62A3E33B3CD076927FF63BF
-----BEGIN PUBLIC KEY-----
MDwwDQYJKoZIhvcNAQEBBQADKwAwKAIhAN8e3BUp44Iu0+Y4JxZVtpTmIMaM5io+
M7PNB2kn/2O/AgMBAAE=
-----END PUBLIC KEY-----
    

Y se guarda el módulo en hexadecimal y el exponente (en decimal). Lo primero que hace, es convertir el módulo a decimal. Con bc para Windows o bc para GNU/Linux, a mano o con un pequeño programa en C de Daniel Lerch:

vi hex2dec.c    
    
#include <stdio.h>
#include <openssl/bn.h>

int main (int argc, char **argv)
{
  BIGNUM *n = BN_new();
  if (argc!=2)
    {
      printf("%s <hex>\n", argv[0]);
      return 0;
    }
  if (!BN_hex2bn(&n, argv[1]))
    {
      printf("error: BN_hex2bn()");
      return 0;
    }
  printf("%s\n", BN_bn2dec(n));
  BN_free(n);
}

gcc hex2dec.c –lssl

./a.out DF1EDC1529E3822ED3E638271655B694E620C68CE62A3E33B3CD076927FF63BF
    

Obtenemos el número mágico producto de los dos primos "p" y "q":

100920289600778325609262470154337840622994795853937388642916029430161685308351
    

Ese número es el que vamos a factorizar para encontrar "p" y "q" con lo cual, nos permitirá obtener su clave privada. No hay que asustarse con las cifras. Sólo son 78 dígitos... La actual fortaleza, está establecida en la resistencia a la factorización que ofrecen números con muchos más dígitos.
Para ello, vamos a emplear msieve que es una librería en C implementando algoritmos para trabajar con la factorización de números enteros "largos". Contiene los algoritmos SIQS (Self Initialized Quadratic Sieve) y GNFS (General Number Field Sieve) para poder trabajar con las últimas factorizaciones públicas conocidas. Como seguro que no queréis compilar nada desde GNU/Linux para Windows y probablemente queráis aprovechar vuestro i7 o el soporte de CUDA, teneis las versiones para Windows completamente preparadas para trabajar. En GNU/Linux hay que compilarlo. No fiaros de los binarios que "circulan" ya que lo mismo os "hacen clientes de cómputo" sin que os enteréis...
Por tanto, vamos a emplear la versión con soporte para x64 y CUDA de la sección MSIEVE. Descomprimimos el fichero y nos vamos a la carpeta donde se encuentre. A veces es necesario crear el fichero vacío "worktodo"

touch worktodo
msieve –v 100920289600778325609262470154337840622994795853937388642916029430161685308351
    

El programa intentará factorizar el número pasado. Ya podemos ir a tomar un café... pero ojo, rápido que no tarda mucho!!! Cuando acabe, veremos tanto "p" como "q"

Msieve v. 1.50 (SVN Official Release)
Wed Nov 14 07:20:10 2012
radom seeds: 11414170 bc6ececd
factoring 1009202896007783256092624701543378406229947958539373886429160294301
61685308351 (78 digits)
searching for 15-digits factors
commencing quadratic sieve (78-digit input)
using multiplier of 1
using VC8 64kb sieve core
sieve internal: 6 blocks of size 65536
processing polynomials in batches of 17
using a sieve bound of 924083 (36404 primes)
using a large prime bound of 92408300 (26 bits)
using trial factoring cutoff of 26 bits
polynomial 'A' values have 10 factors

sieving in progress (press Ctrl-C to pause)
36519 relations (18552 full + 17967 combined from 199596 partial), need 36500
begin with 218147 relations
reduce to 52183 relations in 2 passes
attempting to read 52183 relations
recovered 52183 relations
recovered 42620 polynomials
attempting to build 36519 cycles
found 36519 cycles in 1 passes
distribution of cycle lengths:
    length 1 : 18552
    length 2 : 17967
largest cycle: 2 relations
matrix is 36404 x 36519 (5.3 MB) with weight 1103122 (30.21/col)
sparse part has weight 1103122 (30.21/col)
filtering completed in 3 passes
matrix is 26164 x 26228 (4.2 MB) with weight 881311 (33.60/col)
sparse part has weight 881311 (33.60/col)
saving the first 48 matrix rows for later
matrix includes 64 packed rows
matrix is 26116 x 26228 (2.9 MB) with weight 668466 (25.49/col)
sparse part has weight 497517 (18.97/col)
commencing Lanczos iteration
memory use: 2.9 MB
lanczos halted after 414 iterations (dim = 26116)
recovered 18 nontrivial dependencies
prp39 factor: 315991331527846152418692424103646097697
prp39 factor: 319376766168931793939205909238749583583
elapsed time 00:03:22
    

Ya únicamente nos resta conocidos los dos números primos y el exponente empleado, obtener la "clave privada". Podemos emplear utilidades como la del artículo de Daniel Lerch, pero en éste caso, hemos optado por hacerlo online desde la página http://math.co.ro/cgi-bin/genpriv?p=PRIMO_P&q=PRIMO_Q&e=EXPONENTE

wget "http://math.co.ro/cgi-bin/genpriv?p=315991331527846152418692424103646097697 \
      &q=319376766168931793939205909238749583583&e=65537"
    

Editamos el fichero para eliminar la cabecera y voilá:

Llave privada de 315991331527846152418692424103646097697,
319376766168931793939205909238749583583 y 65537 by Eduardo Ruiz Duarte (beck) 
toorandom@gmail.com
-----BEGIN RSA PRIVATE KEY-----
MIGrAgEAAiEA3x7cFSnjgi7T5jgnFlW2lOYgxozmKj4zs80HaSf/Y78CAwEAAQIh
ANwZyy2tdttTaoFu31AvGb4NhSPhQkVSdH9Bb+E7f+GBAhEA8EW6Td2GFkwi1TL2
dA/Y3wIRAO25t31L+qBy8aJz06IGcSECEQCIXVqWVLKENyPR0oGzb0cLAhAY63z2
n35YT3RRCT9IHtDBAhA0kHMpCgP+a7L+UzirjCp6
-----END RSA PRIVATE KEY-----    
    

Guacheras ha conseguido la clave privada a partir de la pública!!! ¿Qué hacer con una clave privada? La imaginación ya la ponéis vosotr@s...
Os ofrecemos una plaza GRATUITA en cualquier Curso Privado a elegir a quien primero obtenga la clave privada y la mande como prueba a ex-alumnos@madesyp.com de la siguiente clave pública:

-----BEGIN PUBLIC KEY-----
MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANeYWuPr69WGKfHmQv7AveanAzghrIxg
/xlKafTe29YytGCCQRkWH84cOs4FRU8QVgdgufJEs24C2Sm0Q1E7KdMCAwEAAQ==
-----END PUBLIC KEY-----
    

Recordaros que en los Cursos especializados de Seguridad Informática y Administración de Sistemas que ofrecemos en Academia MADESYP realizamos y establecemos las contramedidas con todo esto y mucho más...
Ser buenos y no hagáis maldades!!!