Saltar al contenido

admin

Certificado Digital

  • admin 

Un certificado digital (también conocido como certificado de clave públicacertificado de identidad) es un documento digital mediante el cual un tercero confiable (una autoridad de certificación) garantiza la vinculación entre la identidad de un sujeto o entidad (por ejemplo: nombre, dirección y otros aspectos de identificación) y una clave pública.

Este tipo de certificados se emplea para comprobar que una clave pública pertenece a un individuo o entidad. La existencia de firmas en los certificados aseguran por parte del firmante del certificado (una autoridad de certificación, por ejemplo) que la información de identidad y la clave pública perteneciente al usuario o entidad referida en el certificado digital están vinculadas.

Un aspecto fundamental que hay que entender es que el certificado para cumplir la función de identificación y autenticación necesita del uso de la clave privada (que sólo el titular conoce). El certificado y la clave pública se consideran información no sensible que puede distribuirse perfectamente a terceros. Por tanto el certificado sin más no puede ser utilizado como medio de identificación, pero es pieza imprescindible en los protocolos usados para autenticar a las partes de una comunicación digital, al garantizar la relación entre una clave pública y una identidad.

El ejemplo por excelencia es la firma electrónica: aquí el titular tiene que utilizar su clave privada para crear una firma electrónica. A esta firma se le adjuntará el certificado. El receptor del documento que quiera comprobar la autenticidad de la identidad del firmante necesitará la clave pública que acompaña al certificado para que a través de una serie de operaciones criptográfica se comprueba que es la pareja de la clave privada utilizada en la firma. Es esta operación de asociación al dato secreto del firmante lo que hará la función de comprobar su identidad.

Si bien existen variados formatos para certificados digitales, los más comúnmente empleados se rigen por el estándar UIT-T X.509. El certificado debe contener al menos lo siguiente:

  • La identidad del propietario del certificado (identidad a certificar),
  • La clave pública asociada a esa identidad,
  • La identidad de la entidad que expide y firma el certificado,
  • El algoritmo criptográfico usado para firmar el certificado.

Los dos primeros apartados son el contenido fundamental del certificado (identidad y clave pública asociada), en tanto que los otros dos son datos imprescindibles para poder validar el certificado.

Esta información se firma de forma digital por la autoridad emisora del certificado. De esa forma, el receptor puede verificar que esta última ha establecido realmente la asociación.

Contenido

  • 1 Formato de certificado digital
  • 2 Emisores de certificados
  • 3 Véase también
  • 4 Enlaces externos

Formato de certificado digital

Un certificado emitido por una entidad de certificación autorizada, además de estar firmado digitalmente por ésta, debe contener por lo menos lo siguiente:

  • Nombre, dirección y domicilio del suscriptor.
  • Identificación del suscriptor nombrado en el certificado.
  • El nombre, la dirección y el lugar donde realiza actividades la entidad de certificación.
  • La clave pública del usuario.
  • La metodología para verificar la firma digital del suscriptor impuesta en el mensaje de datos.
  • El número de serie del certificado.
  • Fecha de emisión y expiración del certificado.

Emisores de certificados

Artículo principal: Autoridad de certificación

Cualquier individuo o institución puede generar un certificado digital, pero si éste emisor no es reconocido por quienes interactúen con el propietario del certificado, el valor del mismo es prácticamente nulo. Por ello los emisores deben acreditarse: así se denomina al proceso por el cuál entidades reconocidas, generalmente públicas, otorgan validez a la institución certificadora, de forma que su firma pueda ser reconocida como fiable, transmitiendo esa fiabilidad a los certificados emitidos por la citada institución.

La gran mayoría de los emisores tiene fines comerciales, y otros, gracias al sistema de anillo de confianza pueden otorgar gratuitamente certificados en todo el mundo, como:

  • CAcert.org, emisor administrado por la comunidad con base legal en Australia.

Pero para que un certificado digital tenga validez legal, el prestador de Servicios de Certificación debe acreditarse en cada país de acuerdo a la normativa que cada uno defina.

  • En España, la Fábrica Nacional de Moneda y Timbre, el Ministerio de Industria, Turismo y Comercio, la Agència Catalana de Certificació, la Autoritat de Certificació de la Comunitat Valenciana, etc.

Servicios Web con Perl

  • admin 

El lenguaje Perl cuenta principalmente con dos módulos que pueden ser usados para crear servicios web de manera fácil y rápida, desde cero o reutilizando aplicaciones de Perl ya existentes.Éstos módulos son SOAP::Lite y WSDL::Generator. A continuación se explicarán cada uno de ellos y se mostrará un ejemplo de su uso.

Tabla de contenidos

SOAP::Lite

SOAP::Lite es un conjunto de módulos de Perl que proveen una interfaz simple y liviana para el protocolo SOAP, tanto en el lado cliente como en el del servidor. SOAP::Lite es actualmente el kit de desarrollo de web services para Perl más difundido y utilizado. Su página en SourceForge ha registrado más de 10,700 descargas en casi 2 años.

SOAP::Lite provee clases para implementar funcionalidades de un cliente SOAP, varios servidores, soporte a datos y muchas otras tareas. La siguiente es una lista resumida de sus características:

Soporte de Protocolos

  • Soporta las especificaciones SOAP 1.1 y SOAP 1.2.
  • Incluye XMLRPC::Lite, una implementación del protocolo XML-RPC en el lado del cliente y del servidor. Entre los protocolos de trasporte disponibles, están HTTP, SMTP, POP3 y TCP.
  • Soporta publicación y peticiones UDDI del lado del cliente, a través de un API.

Interoperabilidad

  • Se han realizado pruebas de interoperabilidad con diferentes implementaciones: Apache SOAP, Frontier, Microsoft SOAP, Microsoft .NET, DevelopMentor, XMethods, 4s4c, Phalanx, Kafka, SQLData, Lucin (en Java, Perl, C++, Python, VB, COM, XSLT).

Protocolos de Transporte

  • Provee implementaciones de servidores TCP con multiservidor “no-bloqueante”
  • Soporta transporte sobre Jabber, MQSeries y SMTP.
  • Provee compresión transparente para HTTP.
  • Soporta el protocolo HTTPS.
  • Provee soporte para proxy.
  • Provee implementaciones de servidor POP3.
  • Soporta M-POST y redirección HTTP.

Soporte para WSDL

  • Soporta el esquema WSDL con “stub” y acceso en tiempo de ejecución. Soporta descripciones de servicio por directivas y cortas (tModel).

Otras

  • Provee implementaciones de servidores CGI, daemon, mod_perl, Apache::Registry yFastCGI.
  • Incluye los módulos de Apache mod_soap y mod_xmlrpc, los cuales permiten crear servidores SOAP o XML-RPC con algunas líneas en los archivos .htaccess o httpd.conf.
  • Soporta el enlace dinámico y estático de clases y métodos.
  • Provee un intérprete de comandos para sesiones SOAP interactivas.
  • Incluye una gran cantidad de ejemplos.

WSDL::Generator

WSDL::Generator es un módulo de Perl para crear archivos de descripción de servicios (WSDL) automáticamente a partir de módulos de perl expuestos como servicios web. Éste módulo, desarrollado por Pierre Denis <pdenis@fotango.com>, es tal vez el único que se ha creado hasta ahora con ésta funcionalidad en el mundo de Perl. SOAP::Lite y WSDL::Generator en la Práctica

Ejemplo

A continuación, se muestra un ejemplo de la utilización del lenguaje Perl para exponer un servicio web sencillo. En la documentación de los módulos puede encontrarse una descripción extendida de todas las funcionalidades que poseen y cómo utilizarlas.

El siguiente es el código fuente de un módulo de Perl que implementa una clase llamada “Cafetera”, con un único método llamado “prepararCafe”, que recibe como parámetro el número de tasas y devuelve como resultado un mensaje indicando el número de tasas preparadas:

Código del archivo Cafetera.pm <perl>

#!/usr/bin/perl -w
# Servicio web de ejemplo
package Cafetera;
use strict;
# Este es el constructor
sub new{
 my $proto = shift;
 my $class = ref($proto) || $proto;
 my $tasas = 0;
 bless($tasas,$class);
}
sub prepararCafe{
 shift;
 my $tasas = shift;
 print STDERR "Llamado con el parámetro $tasas";
 return "Se prepararon ".$tasas." tasas";
}
1;

</perl> A continuación se muestra el uso del módulo SOAP::Lite para exponer el módulo Cafetera como un servicio web, usando el servidor tipo SOAP::Transport::HTTP::Daemon:

Código del archivo servidor.pl <perl>

#!/usr/bin/perl -w
# Servidor SOAP
use SOAP::Transport::HTTP;
use Cafetera;
#En el parámetro dispatch_to se especifica la ruta a los módulos disponibles
my $daemonio = SOAP::Transport::HTTP::Daemon
 -> new(LocalAddr => 'localhost', LocalPort => 8070)
 -> dispatch_to('/home/tesis/thewala/preparacion/P.5-IP/productos/servicio-en-perl','Cafetera')
;
print "La url del daemonio es:".$daemonio->url()." ";
$daemonio->handle();

</perl> Desde éste momento, cualquier aplicación puede empezar a consumir el servicio web, si sabe cómo invocarlo. A continuación se muestra un cliente del servicio hecho en Perl con SOAP::Lite:

Código del archivo cliente.pl <perl>

#!/usr/bin/perl -w
use strict;
use SOAP::Lite;
my $soap = SOAP::Lite
 ->uri('http://localhost:8070/Cafetera')
 ->proxy('http://localhost:8070/')
;
my $resultado= $soap->prepararCafe(5)->result;
print "Preparando cafe: ".$resultado." ";

</perl> Para que aplicaciones hechas en otros lenguajes o que no saben cómo invocar el servicio puedan acceder al mismo, se debe crear el archivo de descripción WSDL. A continuación se muestra el guión o “script” de perl que utiliza WSDL::Generator para crear el archivo WSDL:

Código del archivo generar-wsdl.pl <perl>

#!/usr/bin/perl -w
use WSDL::Generator;
my $init = {
 'schema_namesp' => 'http://localhost:8070/Cafetera.xsd',
 'services' => 'Cafetera',
 'service_name' => 'Cafetera',
 'target_namesp' => 'http://localhost:8070/Cafetera.wsdl',
 'documentation' => 'Servicio Web de Prueba',
 'location' => 'http://localhost:8070/Cafetera'
};
my $w = WSDL::Generator->new($init);
Cafetera->prepararCafe(5);
print $w->get(Cafetera);

</perl> La salida de este guión de Perl constituye el documento wsdl que debe ser publicado para que cualquiera pueda acceder al servicio Cafetera. La siguiente es la salida del guión, la cuál puede guardarse en el archivo Cafetera.wsdl:

Código del archivo Cafetera.wsdl <xml>

<?xml version="1.0"?>
<definitions
 name="Cafetera"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 targetNamespace="http://localhost:8070/Cafetera.wsdl"
 xmlns:tns="http://localhost:8070/Cafetera.wsdl"
 xmlns="http://schemas.xmlsoap.org/wsdl/"
 xmlns:xsdl="http://localhost:8070/Cafetera.xsd">
<types>
 <xsd:schema targetNamespace="http://localhost:8070/Cafetera.xsd">
  <xsd:element name="prepararCafeRequest" type="xsd:string" />
  <xsd:element name="prepararCafeResponse" type="xsd:string" />
 </xsd:schema>
</types>
<message name="prepararCafeRequest">
 <part name="prepararCafeRequestSoapMsg" element="xsdl:prepararCafeRequest"/>
</message>
<message name="prepararCafeResponse">
 <part name="prepararCafeResponseSoapMsg" element="xsdl:prepararCafeResponse"/>
</message>
<portType name="CafeteraCafeteraPortType">
 <operation name="prepararCafe">
  <input message="tns:prepararCafeRequest" />
  <output message="tns:prepararCafeResponse" />
 </operation>
</portType>
<binding name="CafeteraCafeteraBinding" type="tns:CafeteraCafeteraPortType">
 <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="prepararCafe">
  <soap:operation style="document" soapAction=""/>
  <input>
   <soap:body use="literal"/>
  </input>
  <output>
   <soap:body use="literal"/>
  </output>
 </operation>
</binding>
<service name="Cafetera">
<documentation>
 Servicio Web de Prueba
</documentation>
<port name="CafeteraCafeteraPort" binding="tns:CafeteraCafeteraBinding">
 <soap:address location="http://localhost:8070/Cafetera"/>
</port>
</service>
</definitions>

</xml>

Referencias

 

Usar certificados de cliente de la FNMT en una Aplicación Web

Existe poquísima información al respecto en Internet, muchos posts de gente, mucha historieta pero nada concreto. Voy a intentar, por lo tanto, dar las instrucciones para configurar un servidor de internet (en mi caso IIS, aunque la configuración es similar para el resto) para poder pedir al usuario que utilice un certificado emitido por la FNMT.

Paso I: La Seguridad
Si no tenemos una conexión https con SSL, GAME OVER, fin de la partida. Es requisito indispensable comunicarnos con el cliente mediante una conexión cifrada para poder interactuar con los certificados. Pero, ¿cómo lo hacemos para conseguir un certificado?. En desarrollo podemos seguir los siguientes pasos (en producción necesitareis un certificado emitido por una CA Root reconocida):

Existen muchos sitios en internet donde se describe este proceso, os pongo esta url donde explican como generar nuestro propio certificado con OpenSSL:
http://www.locualo.net/programacion/activar-ssl-iis-certificado-digital-prueba/00000079.aspx

Paso II: La Teoría
Vamos a ver un poco de la teoría para saber cómo funciona el tema de los certificados. Una vez que sepamos como funciona, entenderemos los pasos a dar. El circuito de los certificados es el siguiente:

1. El cliente accede a la url https://…. (para la cual es necesario un certificado de cliente)
2. El servidor envía su certificado al cliente para establecer el canal seguro. El cliente debe confiar en la entidad que ha generado ese certificado y comprobar que es válido. En caso de no confiar aparecerá un mensaje en el explorador indicándonoslo (la mayoría de la gente no lo lee).
3. Una vez que el cliente ha confiado en el servidor, se establece el canal seguro.
4. El servidor tiene configurado que para el recurso que intenta ver el cliente es necesario que presente un certificado de cliente, emitido por una entidad certificadora en la que él confíe y además que está en la lista de los certificados admitidos para el recurso en cuestión.
5. El explorador del cliente recibe estas condiciones del servidor y muestra una ventana con los certificados instalados que cumplan los requisitos del servidor.
6. El usuario elige su certificado y éste es mandado al servidor.
7. El servidor comprueba la lista de revocación de certificados de la entidad que emitió el certificado para ver si sigue siendo válido.
8. En caso que el certificado sea válido, podremos acceder al recurso y en la sesióntendremos guardado el certificado para usarlo.

En la siguiente imagen os muestro el flujo:

Paso III: La Confianza
Como habéis podido observar, la clave del asunto es la confianza entre los diferentes elementos (cliente y servidor). Vamos a ver cómo configurar nuestro servidor para: 1) requerir el certificado del cliente y 2)confiar en la fnmt para que acepte sus certificados.

Para requerir el certificado del cliente iremos al «Administrador de Servicios de IIS», buscaremos el recurso, sitio web o directorio virtual que necesitará certificado y pulsamos en «Propiedades» del menú contextual. En la pestaña «Seguridad de Directorios» pulsamos sobre el botón «Modificar» de la parte inferior. Nos aparecerá la siguiente pantalla:

Marcaremos la opción «Requerir Canal Seguro» y «Requerir Certificados de Cliente». Pulsamos sobre Aceptar y hemos terminado. Ahora el IIS espera un certificado del cliente para acceder al recurso, sin embargo, todavía no le hemos dicho que debe confiar en la FNMT como entidad certificadora.

Para confiar en la FNMT, tendremos que abrir una consola mmc (Ejecutar–> mmc), Archivo–>Agregar o Quitar Complemento. En la pantalla que aparece pulsaremos de nuevo sobre Agregar y seleccionaremos el complemento «Certificados»:

Pulsamos sobre «Agregar», seleccionamos la opción «Mi Cuenta de usuario» y cerramos la pantalla de agregar complementos. En la consola mmc, expandimos «Entidades emisoras raíz de confianza–>Certificados» y buscamos a la FNMT:

En caso que no esté, tendremos que importarlo. Lo primero será conseguir la definición del certificado de la FNMT. La podéis conseguir desde aquí:

http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer

Guardamos el fichero .cer en nuestro servidor y en la consola mmc pulsamos con el botón derecho sobre «Certificados» y elegimos «Todas las tareas–>Importar». Saltará un asistente para importar un certificado, seleccionaremos el fichero que nos acabamos de descargar y siguiente hasta el final.

Una vez importado, veremos las propiedades del certificado y habilitaremos la opción»Autenticación del Cliente». De esta forma habilitamos a los certificados de la FNMT para que sirvan como certificados de cliente.

Con esto hemos dado nuestra confianza a la FNMT como CA Root, sin embargo, todavía no funciona porque tenemos que incluir a la FNMT como entidad válida para nuestro recurso, en la CTL (Certificate Trusted List). Para ello, volvemos a la consola del IIS y nos vamos a las propiedades del sitio web en el que esté el recurso del certificado. Seleccionamos la pestaña «Seguridad de Directorios» y pulsamos sobre el botón «Modificar» de la parte inferior. Aparecerá la pantalla siguiente:

En la parte inferior tenemos la lista de certificados de confianza, pulsamos sobre «Modificar» y en la lista que aparece, pulsamos sobre «Agregar desde el almacén» e incluimos el de la FNMT. Pulsamos «Siguiente» hasta el final y ya tenemos todo hecho.

Paso IV: Final
Ya tenemos nuestro entorno habilitado para utilizar certificados de cliente. En producción tendremos que tener un certificado emitido por una entidad reconocida, pero el resto es igual.