aTemp      : array[0..5000] of Char;
sClassName : String;

ContElementos: integer;
begin
ContElementos := 0;
Result := ”;
hWindow := FindWindow(Nil,PChar(TituloVentana));
if hWindow = 0 then begin
ShowMessage(‘Error al intentar cargar la aplicaión. Intente otra vez.’);
exit;
end;

hChild := GetWindow(hWindow, GW_CHILD);
while hChild <> 0 do Begin
if GetClassName(hChild, aTemp, SizeOf(aTemp)) > 0 then begin
sClassName := StrPAS(aTemp);

if sClassName = ‘TEdit’ then begin
ContElementos := ContElementos + 1;
case ContElementos of
4: begin
StrPCopy(aTemp,sText);
SendMessage(hChild,WM_SETTEXT,SizeOf(aTemp),Integer(@aTemp));
end;
end;
end;
end;
hChild := GetWindow(hChild, GW_HWNDNEXT);
end;
end;

== Introducción ==

En la actualidad cada vez más gente utiliza servicios basado en Internet, como correo electrónico, servicios web, transacciones en linea y muchos más. Quienes ofrecen estos servicios deben de proporcionar una manera de garantizar la privacidad y seguridad de estas comunicaciones.
Muchos servicios de red son configurados de tal manera de que la comunicación cliente/servidor sea segura, esto se logra cifrando la comunicación, es decir, estableciendo un canal seguro para enviar información sensible para el usuario, como pueden ser: nombres de usuarios, contraseñas, números de tarjetas de crédito y otro información que es confidencial. Estos canales seguros también llamados tuneles son creados usando criptografía simétrica y asimétrica, muchos servicios tales como servidores Web, SMTP, IMAP, POP y muchos otros más usan criptografía de llave publica usando certificados SSL x509, todo con el fin de asegurar la identidad y confidencialidad de los usuarios.
Empresas como Thawte y VeriSign proveen servicios comerciales para la expedición de certificados SSL, estas son las conocias Autoridades Certificadoras de confianza. Un ejemplo, los navegadores web más comunes reconocen a estas dos empresas como Autoridades Certificadoras de confianza, para obtener un certificado SSL por una de las conocidas CA, es necesario que les demuestres que tu eres quien dices ser y que tienes los derechos para usar el certificado, por ejemplo no expiden un certificado a algún individuo o empresa sin identificación oficial que lo apruebe.
Los certificados SSL expedidos por estas CA cuestan dinero, algunas veces vale la pena comprar uno por ejemplo para un servidor web que ofrecerá servicios de comercio electrónico y que debe garantizar la confidencialidad de sus usuarios. Pero muchas otras veces se requiere usar conexiones seguras para otros servicios como correo electrónico (SMTP, IMAP, POP3) por Internet y no se tiene el presupuesto para pagar por un certificado SSL.
En este documento se explica como crea tu propia Autoridad Certificadora y usarla para fines personales o de uso interno en tu empresa, explicaremos como crear Peticiones para firma de certificados (CSR por sus siglas en Inglés), firmarlas
y generar certificados usando herramientas libres y de código abierto como OpenSSL. 

=== Sobre los Certificados x.509 ==
Estos certificados usan el protocolo SSL/TLS para asegurar la privacidad y autenticidad de las comunicaciones digitales.  Por ejemplo en un sitio web un certificado SSl provee:
* Ofrecer transacciones economicas seguras. proteccion de datos sensibles: datos bancarios, tarjetas de credito.
* Garantizar la privacidad de la informacion suministrada por el eusuario de la página web, protegiendo el proceso de transmisión de datos entre el usuario y el servidor.
BIen, un sistema que permita una comunicación segura debe de proveer las siguientes caraterisicas o funcionalidades:  
* Confidencialidad: el contenido de la comunicacion ha de ser inutil para una tercera parte que lo pudiera interceptar.
* Autenticacióñ: el sistema ha de asegurarnos que una tercera parte no puede usurpar la identidad de alguna de las dos partes que intervienen en la comunicacion.
* Integridad: nos debe de garantizar que la informacion transimitda, ademas de no ser interceptada, no pueda ser modificada por una tercera parte.
* No repudio: debe garantizar que ninguno de los participantes en una comunicacion pueda negar parte de la misma. Es un concepto ligado al de autenticación, y así será considerado.
- Criptografia Simetrica: Algoritmos de cifrado simétrico son IDEA, RC5, etc.
- Criptografía asimétrica o de clave pública: PGP, SSL,
- Certificados x.509
SSL utiliza certificados x.509 para el intercampio de claves públicas. Estos certificados x.509 contienen además de la clave pública del interlocutor, información acerca de su identidad, así como información complementaria sobre algoritmos utilizados para la generaión de claves, plazos de validez del propio certificado, etc. Por otra parte, estos certificados contienen una firma digital que garantiza la integridad de sus contenidos, ya sea por la clave privada del mismo interlocutor (certificados autofirmados), o por la clave privada de una tercera parte (certificado firmado por una cA). SOn los de ese último tipo, los firmados por una cA, los ncesarios para garantizar los cuatro requerimientos iniciales.
Los datos de un sujeto que se incluyen en un certificado x.509 son:
* CN: nombre común o nombre largo
* E-Mail: Dirección de correo electrónico
* O: NOmbre de su organización
* OU: Departamento
* L: Localidad
* SP: Provincia o estado.
* C: País

x.509 es un estandar para una Infraestructura de Llave Publica (PKI), el cual especifica el formato para certificados de claves publicas, y un algoritmo de validacion de la ruta del certificado.

La version actual de x509 es la version 3 y es la que se usa ampliamente.

En el sistema x.509, una CA emite un certificado asociado a una clave púlica a un Nombre Distinguido particular en la tradición de c.500 o a un Nombre Alternativo tal como en una direccion de correo eletrónico o una entrada de DNS.

Los certificados raíz de confianza de una organización puden distribuirse a todos los empleados de manera que ellos pueden usar el sistema de infraestructura de clave pública de la compañía. Navegadores web como IE, NEtscape/Mozilla y OPera vienen pre-instalados con certificados raíz, de manera que certificados SSL de grandes vendedores que hayan pagado por el privilegio de ser pre-instalados funcionen al instante.

x.509 incluye tambien estándares para implementación de CRLs, y con frecuencia aspectos de sistemas PKI. La forma aprovada por la IETF de chequear la validez de un certificado es el Online Certificate Status Protocol (OCSP).

 Extensiones de archivo de certificados [editar]

Las extensiones de archivo de certificados X.509 son:

    * .CER - Certificado codificado en CER, algunas veces es una secuencia de certificados
    * .DER - Certificado codificado en DER
    * .PEM - Certificado codificado en Base64, encerrado entre "-----BEGIN CERTIFICATE-----" y "-----END CERTIFICATE-----"
    * .P7B - Ver .p7c
    * .P7C - Estructura PKCS#7 SignedData sin datos, solo certificado(s) o CRL(s)
    * .PFX - Ver .p12
    * .P12 - PKCS#12, puede contener certificado(s) (público) y claves privadas (protegido con clave)
PKCS #7 es un estándar para firmar o cifrar datos (ellos lo llaman "sobreado"). Dado que el certificado es necesario para verificar datos firmados, es posible incluírlos en la estructura SignedData. Un archivo .P7C es simplemente una estructura SignedData, sin datos para firmar.

PKCS #12 evolucionó del estándar PFX (Personal inFormation eXchange) y se usa para intercambiar objetos públicos y privados dentro de un archivo.

Un archivo .PEM puede contener certificados o claves privadas, encerrados entre las líneas BEGIN/END apropiadas.

 Estructura de un certificado [editar]

La estructura de un certificado digital X.509 v3 es la siguiente:

    * Certificado
          o Versión
          o Número de serie
          o ID del algoritmo
          o Emisor
          o Validez
                + No antes de
                + No después de
          o Tema
          o Tema información de clave pública
                + Algoritmo de clave pública
                + Tema clave pública
          o Identificador único de emisor (opcional)
          o Identificador único de tema (opcional)
          o Extensiones (optional)
                + ...
    * Algoritmo de certificado de firma
    * Certificado de firma

Los identificadores únicos de emisor y tema fueron introducidos en la versión 2, y las extensiones en la versión 3.
== Términos ==

CA: Autoridad Certificadora.

Llave Privada: Esta es una llave privada RSA generada para crear un CSR, también es usada para firmar los certificados.

Certificado Raíz: Este certificado es comúnmente utilizado por los programas clientes para validar la autenticidad de el certificado de un servidor, algunos de los atributos que contienen los certificados de un servidor es el nombre de la Autoridad Certificadora que firmo el certificado.
CSR: Petición para firma de certificado, estos son enviados a la CA para
firmarse.

Certificado.

== Inicializando la CA.==
Lo primero que haremos es crear la llave privada RSA y el certificado raíz para nuestra CA, la llave privada solo sera usada cuando tengamos que firmar un CSR por lo que debe de mantenerse en un lugar seguro y de preferencia que no este conectado a alguna red, ya que si llegara a caer en manos equivocadas podría comprometer la seguridad de nuestros sistemas. NOTA: La llave privada raíz RSA sera protegida con un "frase de paso" (Passphrase), sin esta no podrá ser utilizada.
El certificado raíz deberá de ser instalado en cada sistema cliente que use los servicios.
NOTA: Certificates must be checked for expiration, to avoid at best browser warnings, and at worst service outages due to expired certificates.
La creación de la CA requiere de la herramienta openssl, comprobaremos que la tengamos instalada:
$ which openssl
/usr/bin/openssl

Si no se tiene instalada utilizar la herramienta de gestión de paquetes de tu distribución.
1.  Creación de un directorio donde mantendremos los archivos de la CA. Si usamos una área personalizada para nuestra CA previene que las actualizaciones por parte de nuestro distribuidor modifique nuestra configuración o sobrescriba nuestros archivos y/o scripts. por lo que usaremos un directorio aparte de /etc/ssl donde normalmente esta la configuración de openssl. En nuestros ejemplos crearemos una CA para tuxjm.net por ejemplo usaremos el directorio llamado TuxjmCA, digamos que lo tenemos en /opt/TuxjmCA.
# mkdir -p /opt/TuxjmCA
# cd /opt/TuxjmCA
La configuración global normalmente se almacena en un archivo de configuración llamado openssl.cnf que regularmente se encuentra en /etc/ssl/
En nuestro caso usaremos un archivo de configuración en que estará almacenado en /opt/TuxjmCA
Copiar el archivo de configuración de openssl:
# cp /etc/ssl/openssl.cnf /opt/TuxjmCA/openssl.cnf
Editaremos este archivo para definir información básica para la generación de certificados.
Editar algunos parametros básicos:
Ya que todos los comandos y certificados los manejaremos bajo el directorio
/opt/TuxjmCA
entonces editaremos estos parametros:
dir             = ./demoCA              # Where everything is kept Cambiarlo por:
dir             = /opt/TuxjmCA              # Where everything is kept
Si se quieren poner algunos valores a la hora de crear los certificados hacerlos en la sección de: [ req_distinguished_name ], para mas opciones,
ver: man 5 config, guardar el archivo y entonces empezaremos a crear los certificados.
Algunos de estos parametros se pueden predeterminar, así están por default:
# egrep '_default.*=' openssl.cnf
countryName_default             = AUstateOrProvinceName_default     = Some-State
0.organizationName_default      = Internet Widgits Pty Ltd #1.organizationName_default     = World Wide Web Pty Ltd #organizationalUnitName_default = Normalmente prefiero fijar countryName_default, stateOfPrivenceName_default y 0.organizationName_default.

los tengo así:

# egrep '_default.*=' openssl.cnf
countryName_default             = MX
stateOrProvinceName_default     = Baja California
0.organizationName_default      = Tuxjm Inc.
#1.organizationName_default     = World Wide Web Pty Ltd
#organizationalUnitName_default =

Aunque si firmas certificados para servidores que tienes en otros estados seria
recomendable dejar el campo de stateOrPrivincename_default como viene originalmente.

El archivo openssl.cnf hace referencia a algunos archivos y directorios
que normalmente existen en /etc/ssl, pero nosotros estaremos en otro
por lo que los crearemos en nuestro directorio /opt/TuxjmCA

# cd /opt/TuxjmCA

Crearemos algunos directorios que serán utilizados para tener organizados nuestros
certificados y llaves privadas RSA.

# mkdir certs crl csr newcerts private

Cambiaremos los permisos para el directorio private para que solo el usuario root
pueda accederlo:

# chmod go-rwx private

Crear e inicializar el archivo serial que mantiene los números de serie de
nuestros certificados SSL.

# echo "01" > serial

Crear el archivo que mantiene el índice de la base de datos de certificados: index.txt

# touch index.txt

- Crear la el certificado raíz y la llave privada de nuestra CA:

# cd /opt/TuxjmCA

====
# openssl req -config openssl.cnf -new -x509 -days 3650 -keyout private/cakey.pem -out cacert.pem
Generating a 1024 bit RSA private key
...............++++++
...............++++++
writing new private key to 'private/cakey.pem'
Enter PEM pass phrase: SÚPER_MEGA_CONTRASEÑA_o_Passphrase
Verifying - Enter PEM pass phrase: SÚPER_MEGA_CONTRASEÑA
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:MX
State or Province Name (full name) [Some-State]:Baja California
Locality Name (eg, city) []:Tijuana
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tuxjm
Organizational Unit Name (eg, section) []:Tuxjm Certificate Authority
Common Name (eg, YOUR name) []:ca.tuxjm.net
Email Address []:jmedina@tuxjm.net

====

Esto creara dos archivos, uno de el certificado raíz, el cual puede ser
publicado a los que vayan a usar nuestra infraestructura de llave publica,
y el archivo de la llave privada, el cual se usara para firmar las
Certificados de Requerimiento de Certificados (CSR), este archivo se
debe de tener en un lugar seguro.

# ls -l cacert.pem private/cakey.pem
 -rw-r--r-- 1 root root 1330 2006-12-16 17:26 cacert.pem
 -rw-r--r-- 1 root root  963 2006-12-16 17:26 private/cakey.pem

Bien, aunque el certificado raíz no sera usado para algún servicio, podemos
comprobar su funcionamiento, así:

# openssl s_server -cert cacert.pem -key private/cakey.pem -www
Enter pass phrase for private/cakey.pem: SÚPER_MEGA_CONTRASEÑA
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT

Si el comando se ejecuta sin problemas, significa que los certificados
están bien hechos, este comando anterior levanto un servidor web en modo seguro
es decir con soporte HTTPS, puedes apuntar tu navegador a la dirección:
https://localhost:4433 y veras que te pide verificar el certificado, ahí mismo
puedes ver su información.

== Exportando el certificado raíz de nuestra CA. ==

El certificado raíz de nuestra CA debe de ser instalado en todos los sistemas
que estarán interactuando con los certificados firmados por nuestra CA. Nuestro
certificado es el archivo cacert.pem el cual esta en formato PEM por default.

Ver el capitulo: Notas en la exportación de certificados a los clientes.

Una CA firma los CSR enviados por los clientes para producir un certificado. El
certificado es enviado es regresado a el cliente para usarse con alguna
aplicación. En nuestros ejemplos los CSR serán guardados con terminación .csr,
usaremos el formato hostname.csr, donde hostname es el FQDN usado en el atributo
x509 common name.

== Creación de un CSR usando openssl ==

Para crear un CSR en sistemas *nix usamos la herramienta openssl en la linea de
comando.

Ejemplo para crear un CSR para un servidor web:

# openssl req -nodes -new -keyout private/www.tuxjm.net.key -out csr/www.tuxjm.net.csr
Generating a 1024 bit RSA private key
..............................++++++
..............++++++
writing new private key to 'private/www.tuxjm.net.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:MX
State or Province Name (full name) [Some-State]:Baja California
Locality Name (eg, city) []:Tijuana
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Tuxjm
Organizational Unit Name (eg, section) []:Hosting
Common Name (eg, YOUR name) []:www.tuxjm.net
Email Address []:jmedina@tuxjm.net

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: (SOLO_DAR_ENTER)
An optional company name []: (SOLO_DAR_ENTER)

En la parte de los atributos EXTRA ahí solo daremos enter para el challenge password
y el nombre de la compañía opcional.

En el comando usamos el parametro "-nodes" indica que la llave privada RSA no estará
protegida por una contraseña, esto puede ser un problema de seguridad pero hay
ocasiones donde no podemos tener una contraseña en el llave privada, por ejemplo
tenemos un servidor web que reinicio en la madrugada y dicho servidor se encuentra a
varios kilometros de distancia, el servidor web no iniciara si no se le teclea la
contraseña de la llave privada.

Entonces, el comando anterior nos genero dos archivos.

La llave privada para nuestro CSR y e CSR.

# ls -l csr/www.tuxjm.net.csr private/www.tuxjm.net.key
-rw-r--r-- 1 root root 729 2006-12-16 17:46 csr/www.tuxjm.net.csr
-rw-r--r-- 1 root root 891 2006-12-16 17:46 private/www.tuxjm.net.key

Para poder tener nuestro certificado SSL para uso en nuestro servidor web.
deberemos de enviar el CSR a la CA para que sea firmado y se genere un certificado.
EL archivo de la llave privada RSA no es necesario que se envié y se deberá de mantener
en un lugar seguro.

=== Creación de Certificados ===

La CA firma CSR enviados por los clientes para producir un certificado.
El certificado es regresado a el cliente para en alguna aplicación.

Como recordamos en la parte anterior acordamos que íbamos a guardar los CSR
con finalización .csr.

Supongamos que el cliente ya nos envío su CSR, y lo guardamos en /opt/TuxjmCA/csr,
entonces procederemos a firmarlo con nuestra CA.

# openssl ca -config openssl.cnf -out certs/www.tuxjm.net.crt -in csr/www.tuxjm.net.csr -policy policy_anything
Using configuration from openssl.cnf
Enter pass phrase for /opt/TuxjmCA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number: 1 (0x1)
        Validity
            Not Before: Jun 24 08:48:38 2007 GMT
            Not After : Jun 23 08:48:38 2008 GMT
        Subject:
            countryName               = MX
            stateOrProvinceName       = Baja California
            localityName              = Tijuana
            organizationName          = Tuxjm
            organizationalUnitName    = Hosting
            commonName                = www.tuxjm.net
            emailAddress              = webmaster@tuxjm.net
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier:
                E5:F9:54:1F:C4:81:5F:DF:15:03:D2:28:65:1B:42:B7:08:DB:DC:BC
            X509v3 Authority Key Identifier:
                keyid:8E:33:DF:93:09:03:DD:ED:81:FE:BE:B4:98:5B:DD:56:A9:7F:0C:4B
                DirName:/C=MX/ST=Baja California/L=Tijuana/O=Tuxjm Inc./OU=Tuxjm Certificate Authority/CN=ca.tuxjm.net/emailAddress=jmedina@tuxjm.net
                serial:D5:28:CC:8C:17:C5:5E:7C

Certificate is to be certified until Jun 23 08:48:38 2008 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

En este paso es donde se debe de verificar la información del solicitante
si se aprueba entonces simplemente se firma el certificado.

Esto nos generara el certificado SSL que sera retornado a el solicitante.

El archivo que retornaremos es certs/www.tuxjm.net.crt.

Por default openssl guarda una copia de el certificado para un uso a futuro,
como la revocación el certificado. Los certificados son almacenados bajo
el directorio newcerts, pero con el nombre de archivo basados en el numero
de serie, y no el nombre del host de la petición.

=== Revocación de Certificados ===

Si un certificado en particular ya no se considera como confiable, este
puede ser revocado por la CA. La revocación en si es fácil; la parte difícil
es distribuir una lista de revocación a todos los clientes y aplicaciones
que usan los certificados de nuestra CA.

La CA debe de guardar los certificados que firma bajo un directorio de la CA
para una fácil revocación. Guardando los certificados como hostname.crt es una
manera de hacer esto; una copia de el certificado también es guardado bajo el
directorio newcerts, aunque es nombrado con el numero de serie.

Esto lo podemos comprobar comparando el fingerprint de el certificado recién
generado con el nombre del host y el basado en el numero de serie:

# openssl x509 -noout -fingerprint < certs/www.tuxjm.net.crt
SHA1 Fingerprint=39:2D:87:9F:07:6F:27:01:15:67:FD:18:5F:DB:F5:14:F9:C4:5E:AA
# openssl x509 -noout -fingerprint < newcerts/01.pem
SHA1 Fingerprint=39:2D:87:9F:07:6F:27:01:15:67:FD:18:5F:DB:F5:14:F9:C4:5E:AA

== Revocando un certificado ==

Supongamos que queremos revocar el certificado jamedina.tuxjm.net
por lo que su archivo sera jamedina.tuxjm.net.crt y se encuentra en
certs/jamedina.tuxjm.net

# openssl ca -revoke certs/jamedina.tuxjm.net.crt
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./private/cakey.pem:
Revoking Certificate 01.
Data Base Updated

== Generando la Lista de Certificados Revocados (CRL) ==

# openssl ca -gencrl -out /opt/TuxjmCA/crl/crl.pem
Using configuration from /usr/lib/ssl/openssl.cnf
Enter pass phrase for ./private/cakey.pem:

El comando anterior nos creo el archivo crl/crl.pem

# ls -l crl/crl.pem
-rw-r--r-- 1 root root 556 2006-12-19 00:09 crl/crl.pem

Ver la lista de certificados revocados en formato texto:

http://www.openssl.org/docs/apps/crl.html

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

 -CAfile cacert.pem 

Publicar la lista de de certificados revocados (CRL)
El cual debe de ser distribuido a nuestros clientes que usen nuestra CA.

== Referencias ==

OpenSSL: http://www.openssl.org/

OpenSSL Command-Line HOWTO: http://www.madboa.com/geek/openssl/

Servicios de Certificación:

http://www.david-guerrero.com/papers/certificacion/certificacion.html

X.509:

http://es.wikipedia.org/wiki/X.509

OpenSSL Documentation: http://sial.org/howto/openssl/
        OpenSSL Self-signed Test Certificates:

http://sial.org/howto/openssl/self-signed/

        OpenSSL Certificate Authority Setup: http://sial.org/howto/openssl/ca/
        Generating Certificate Signing Requests (CSR):

http://sial.org/howto/openssl/csr/

        Example TLS Certificate Configuration:

http://sial.org/howto/openssl/examples/

        Exporting OpenSSL Certificates: http://sial.org/howto/openssl/exporting/
        OpenSSL S/MIME: http://sial.org/howto/openssl/smime/
        Monitoring for certificate expiration:

http://sial.org/howto/openssl/check-expire/

Para verificar la firma necesitamos la llave privada

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

Mostrar detalles del certificado

Comprobar los datos de un certificado

Para ver la información general sobre un certificado:

Para ver el emisor del certificado

Para ver el propietario del certificado

Para ver su periodo de validez

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

El el valor hash

Ver la huella digital MD5

Mostrar la huella digital SHA1 de un certificado

Mostrar el contenido de un certificado

Mostrar el número de serie de un certificado

Mostrar el propietario de un certificado en formato RFC2253

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

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 \

Recoger certificado remoto

Podemos ver un script para recoger certificados:

Cambiar el formato de un certificado

Convertir un certificado a solicitud de certificado

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

Convertir un certificado de formato PEM a 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

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

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

# exportar el certificado pero cambiándole la clave

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:

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

Por ejemplo:

Indica que el certificado ha sobrepasado su periodo de vigencia.

openssl no verifica certificados autofirmados.

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

Casi todos lo usuarios de linux, sobre todo aquellos que lo llevéis en un portátil y uséis la conexión wifi, tendréis instalado OpenSLL, pero por lo menos en mi caso, salgo dejar que el sistema lo utilizará automáticamente para las conexiones a redes inalámbricas no lo utilizaba para nada. Pero como la curiosidad a veces nos juega malas pasadas, el otro día me decidí a investigar si servía para algo más y se podía utilizar de forma manual, y vaya si se puede. Se pueden hacer un montón de cosas con él, eso si, todas ellas relacionadas con el cifrado y descifrado. Así que el siguiente artículo es una especie de recetario y de apuntes de como utilizarlo para no tener que llevarlo todo en la cabeza, que no se la vuestra, pero la mía se despista con facilidad. Por supuesto, todo lo que se va a comentar a continuación se va a hacer desde la consola.

Acceder a openssl: Tecleamos en la consola

~# openssl

Nos saldrá un promt con el siguiente formato.

OpenSSL>

Salir de openssl:

OpenSSL> quit

OpenSSL> q

OpenSSL> exit

Ayuda:

OpenSSL> ?

Nos mostrará una lista de los comandos disponibles.

– Cifrado simétrico –

Encriptar

DES:

OpenSSL> enc -des -in entrada.txt -pass pass:contraseña -out salidaDes.txt

AES:

OpenSSL> enc -aes128 -in entrada.txt -pass pass:contraseña -out salidaAes.txt

Desencriptar

DES:

OpenSSL> enc -d -des -in salidaDes.txt -pass pass:contraseña -out salidaDes2.txt

AES:

OpenSSL> enc -d -aes128 -in salidaAes.txt -pass pass:contraseña -out salidaAes2.txt

– Cifrado asimétrico –

Generar llave del algoritmo asimétrico RSA: Vamos a generar una llave privada de 1020 bits

OpenSSL> genrsa -out privada1.key 1024

Cifrar la clave privada con DES para evitar su uso fraudulento:

OpenSSL> genrsa -out privada2.key -passout pass:contraseña -des 1024

Se realiza este cifrado porque la clave privada se genera como un fichero de texto que cualquiera podría leer, para evitar esto la ciframos.

Generar claves públicas derivadas:

OpenSSL> rsa in privada1.key -pubout -out publica1.key

OpenSSL> rsa in privada2.key -pubout -out publica2.key -passin pass:contraseña

Encriptar

OpenSSL> rsautl -pubin -encrypt -in entrada.txt -out salidaRsa.txt -inkey publica1.key

Desencriptar:

OpenSSL> rsautl -decrypt -in salidaRsa.txt -out salidaRsa2.txt -inkey privada1.key

– Funciones hash –

Generar:

OpenSSL> dgst -md5 -out entrada.hsh entrada.txt

– Firma digital –

Generar un par de claves RSA como hemos visto anteriormente:

OpenSSL> genrsa -out privada.key 1024

OpenSSL> rsa in privada.key -pubout -out publica.key

Firmar el archivo digitalmente:

OpenSSL> dgst -c -sign privada.key -out firmado.sig entrada.txt

El archivo “firmado.sig” contendrá la firma digital en formato binario.

Verificar firma:

OpenSSL> dgst -c -verify publica.key -signature firmado.sig entrada.txt

OpenSSl mostrará un “Verified OK” si todo ha sido correcto, o un “Verification Failure” si algo ha fallado.

Conversión de firmas binarias a texto: Como ya he dicho antes las firmas generadas tienen un formato binario, con lo cual para su envió por correo, por ejemplo, es interesantes pasarlas a texto. Así que vamos a generar una versión en base64.

OpenSSL> base64 -in firmado.sig -out firmado.b64

Como puedes observar, el fichero generado es legible y fácilmente agregable a cualquier texto.

Conversión de firmas en texto a binarias: Para verificar las firmas que nos han llegado en modo texto tendremos que pasarlas a modo binario antes.

OpenSSL> base64 -d -in firmado.b64 -out firmado1.sig

– Certificados digitales –

Crear certificado y archivo de configuración de la autoridad certificadora (”CA”):

Generar un par de claves RSA como hemos visto anteriormente:

OpenSSL> genrsa -out CAprivada.key 1024

OpenSSL> rsa in CAprivada.key -pubout -out CApublica.key

Crear el archivo de configuración:

Crear el archivo “CAconfig.conf” con el siguiente contenido:

[ req ]
default_bits            =  1024
default_keyfile         =  CAprivada.key
distinguished_name      =  req_distinguished_name
attributes              =  req_attributes
x509_extensions         =  v3_ca
dirstring_type          =  nobmp
[ req_distinguished_name ]
countryName             = Identificador del País (2 letras)
countryName_default     = MX
countryName_min         = 2
countryName_max         = 2
localityName            = Localidad (ej., ciudad)
organizationalUnitName  = Nombre de unidad organizacional (ej., oficina)
commonName              = Nombre común (ej., TU nombre)
commonName_max          = 64
emailAddress            = Dirección de correo electrónico
emailAddress_max        = 40
[ req_attributes ]
challengePassword       = Contraseña para “challenge”
challengePassword_min   = 4
challengePassword_max   = 20
[ v3_ca ]
subjectKeyIdentifier    = hash
authorityKeyIdentifier  = keyid:always,issuer:always
basicConstraints        = CA:true

Crear el certificado de la autoridad:

OpenSSL> req -new -key CApriv.key -out ca.cer -config CAconfig.cnf -x509 -days 3650

Generar claves para un usuario:

OpenSSL> genrsa -out privadaUser.key 1024

OpenSSL> rsa in privadaUser.key -pubout -out publicaUser.key

Generar un requerimiento del certificado para este usuario:

OpenSSL> req -new -key privadaUser.key –out req.pem -config CAconfig.cnf

Firmar el requerimiento y generar el certificado del usuario:

OpenSSL> x509 -inform PEM -outform PEM -keyform PEM -CAform PEM -CAkeyform PEM –in req.pem -out certUser.cer -days 365 -req -CA ca.cer -CAkey CAprivado.key -sha1 –CAcreateserial -text

Bueno, hasta aquí la chuleta de hoy. También debéis saber que OpenSSl permite la creación de de certificados digitales para sitios web, pero como esto da por si solo para un post completo, lo dejaremos para otro día si a alguien le interesa.

Espero que la chuleta os sirva de ayuda. Si alguien tiene alguna duda o algo que aportar, como siempre os animo a dejarlos en los comentarios. Nos vemos.

http://infow.wordpress.com/2009/01/11/openssl-la-navaja-suiza-del-cifrado/

Pensar en ese medio como fenómeno de soledad compartida; que la música es la protagonista, no los locutores, y sorprender permanentemente, fueron algunos de los principios, comenta Patricia Peñaloza Este mes se recuerda que hace 25 años nació una de las estaciones de radio más influyentes del último cuarto del siglo XX en la ciudad de México, Rock 101. “Si lo hubiera organizado deliberadamente, no habría salido tan bien”, dice en entrevista Luis Gerardo Salas, fundador, orquestador, de esa legendaria emisora, indeleble en la vida de una generación que vio en aquélla un alivio contra al hecho de sufrir un México aislado, con escasos lugares para comprar discos o revistas, u oír rock en vivo; un México en que los conciertos de bandas foráneas o la información al día, vía algo parecido a Internet, eran futurismo puro.

Conceptos como “Idea musical” o “Puro, total y absoluto rocanrol” fueron recreados por Ibero 90.9 (Gabriela Warketin, Ricardo Zamora, Uriel Weizel, Julia Palacios) el domingo 31 de mayo y el lunes primero de junio, con entrevistas, música y promos de la época, así como con las obligadas viñetas (pache-textos que rubricaban el final de cada canción). Fue un trabajo periodístico serio, lúcido, que saturó la transmisión en línea del 90.9, y que no recurrió a la nostalgia, sino al reconocimiento documental, objetivo, de la frecuencia que quizá no fue única en abrir camino, pero sí la que indicó como posible hacer una radio divertida, mas no frívola; culta mas no pretenciosa; crítica, mas no panfletaria; selecta mas no elitista.

Al principio del mes Horizonte (Imer) y RMX (Imagen) hicieron sendos homenajes; Carlos Puig (W Radio) y Jessie Cervantes (EXA) entrevistaron a Salas, y el incansable “club de fans” atestó el Moonbar con cerca de dos mil asistentes: Rockstock transportado al Camino Real.

La fiesta de los fans

–¿Qué siente al ver que aún hay gente que recuerda la emisora con efusión, incluyendo jóvenes que apenas nacían entonces?

–Cuando acabó la estación en 1994, viví algo traumático, como si me hubieran matado un hijo. Mucho tiempo no quise oír nada de lo que pasábamos. En mi I-pod no hay música de esa época. Pero ese trauma fue curado, removido, ahora que 90.9 hizo este trabajo, que se realizó la fiesta de los fans, los programas… Me hicieron revalorar lo que hicimos. Sentí gran responsabilidad, pues vi que afectamos la vida de muchos. Creo que abrimos una brecha arquetípica de cómo hacer radio en México; otros siguieron ese patrón, se volvió un paradigma.

–¿Qué principios identifica como propios de ese paradigma?

–Pensar en la radio como un fenómeno de soledad compartida; ver a la radio como lo que ocurre entre canción y canción; que la música es la protagonista, no los locutores; sorprender permanentemente; establecer reglas claras de creatividad y de concepto, para luego romperlas; tener empatía con el entorno; tener humildad para reconocer que afuera hay gente igual o más informada, y saber que si estoy tras un micrófono no es porque sea superior, sino porque tengo algo qué decir, una voz propia. Una estación es como una persona, con rasgos propios, identificables.

–A algunos que hicieron radio después, les molesta que usualmente diga haber creado un paradigma: gente como José Álvarez (ex director de Radioactivo) o ex locutores como Olallo Rubio. Varios de esa camada dicen nunca haber oído Rock 101, y que sus ideas para hacer radio fueron propias… ¿Qué rasgos siente que siguen vivos en Reactor 105 o Ibero 90.9?

–Sería arrogante decirlo, pues tampoco creo que el ciento por ciento provenga de Rock 101. En ellos prevalecen valores universales; la creatividad, la búsqueda de formas nuevas de comunicación… Lo que sí creo es que es imposible negar paternidades. Yo asumo que me influyó el trabajo de Mario Vargas, de WFM; Sergio Rod, de Radio Mil; Adolfo Fernández, de Radio Universal; Luis Cabero de Radio Capital; Bolívar Domínguez, de La Pantera… Siento que en Ibero hay gente que ama la radio, por lo cual tuvo la humildad para reconocer que hubo algo bueno en Rock 101.

–Y de esa responsabilidad que sintió, ¿no le nace la inquietud de volver al ruedo? (desde 2001 no hace radio, tras W-Radical).

–Si lo hiciera, no desacreditaría a nadie. Partiría de respetar lo que todos están haciendo, pues todos hacen su mejor esfuerzo.

Imaginación: respeto

–El mundo es otro: sobre-información, redes sociales, I-pods con los que cada quien selecciona lo que quiere oír, conciertos al día… Ante ello, ¿aún tiene sentido hacer radio? ¿Qué ofrecería hoy en una estación para jóvenes?

–Trabajo en ello. Los jóvenes viven un mundo menos cuadrado y estigmatizado, pero no tan distinto. Y hacer radio sigue teniendo sentido porque el ser humano es el mismo. Y aunque hay mucha información, la gente aún elige sus cuatro mismos canales, sus mismos 10 libros, sus mismos 20 discos… –¿A qué rasgos de la naturaleza humana seguiría apelando, entonces?

–A la imaginación y al respeto. El primero es uno de los atributos humanos más valiosos, difícil de alcanzar, y bellísimo cuando logras comunicarte a través de él. Y puedes ser imaginativo mientras respetes el nivel intelectual de tus escuchas, no lo menosprecies. No importa qué medio uses, sino en qué medida despiertes el asombro, cuánto respetes a tu auditorio. Eso seguirá generando vínculos, comunidades…

–¿O sea que es un hecho que dará a luz un nuevo concepto? ¿Por televisión, radio, Internet?

–No quiero aún revelar nada. Sólo puedo decir que sí… y que ocurrirá antes de un año. Anterior Siguiente

FUENTE:

http://www.jornada.unam.mx/2009/06/09/index.php?section=espectaculos&article=a09n1esp