En el siguiente enlace aparece un ejemplo del uso de iText para la firma electrónica de documentos pdf.
Fte: http://itextpdf.sourceforge.net/howtosign.html
martes, 4 de mayo de 2010
Guia rapida para firmar electronicamente pdf en java
Guía Rápida Firmar PDF
Pasos a seguir para probar este proyecto:
1 - Descargar el proyecto de gxopen del siguiente link: http://www.gxopen.com/gxopen/servlet/hversion?645,2
2 - El archivo zip que se baja del gxopen contiene los siguientes archivos:
firmapdfalfauno.xpz: Archivo de exportación GeneXus que contiene un WBP y un Proc de pruebas para ver el funcionamiento del programa signapdf.java
prueba.pfx : Certificado pfx para realizar pruebas, actualmente se encuentra vencido pero puede generar un nuevo certificado. Crear certificado .p12
signapdf.class : Compilado del programa signapdf.java
signapdf.java: Programa que se encarga de firmar el pdf, este programa contiene código java que utilizando la iText.jar se encarga de firmar un archivo pdf que recibe como parámetro.
passwordpruebapfx.txt : Solo contiene el password del certificado prueba.pfx
3 - En el classpath hay que hacer referencia a los siguientes jars: gxclassr.zip;GxUtils.jar;iText.jar;bcprov-jdk16-137.jar
El jar de bouncycastle hay que usar el de la versión que corresponda con la JRE que estemos usando, en mi equipo tengo instalado la JRE 1.6_02 por ese motivo usa la bcprov-jdk16-137.jar.
Este jar se puede bajar del siguiente link: http://www.bouncycastle.org/latest_releases.html
Fte: http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Gu%C3%ADa+R%C3%A1pida+Firmar+PDF,
Pasos a seguir para probar este proyecto:
1 - Descargar el proyecto de gxopen del siguiente link: http://www.gxopen.com/gxopen/servlet/hversion?645,2
2 - El archivo zip que se baja del gxopen contiene los siguientes archivos:
firmapdfalfauno.xpz: Archivo de exportación GeneXus que contiene un WBP y un Proc de pruebas para ver el funcionamiento del programa signapdf.java
prueba.pfx : Certificado pfx para realizar pruebas, actualmente se encuentra vencido pero puede generar un nuevo certificado. Crear certificado .p12
signapdf.class : Compilado del programa signapdf.java
signapdf.java: Programa que se encarga de firmar el pdf, este programa contiene código java que utilizando la iText.jar se encarga de firmar un archivo pdf que recibe como parámetro.
passwordpruebapfx.txt : Solo contiene el password del certificado prueba.pfx
3 - En el classpath hay que hacer referencia a los siguientes jars: gxclassr.zip;GxUtils.jar;iText.jar;bcprov-jdk16-137.jar
El jar de bouncycastle hay que usar el de la versión que corresponda con la JRE que estemos usando, en mi equipo tengo instalado la JRE 1.6_02 por ese motivo usa la bcprov-jdk16-137.jar.
Este jar se puede bajar del siguiente link: http://www.bouncycastle.org/latest_releases.html
Fte: http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Gu%C3%ADa+R%C3%A1pida+Firmar+PDF,
viernes, 9 de abril de 2010
Viafirma: Plataforma de firma y autenticación digital
Viafirma: Plataforma de firma y autenticación digital
El objetivo del proyecto es la creación de una plataforma de firma digital que venga a simplificar el desarrollo de aplicaciones que requieran usar Certificados Digitales. Cualquier aplicación puede hacer uso de la autenticación y firma digital utilizando los servicios que el sistema ofrece, abstrayendo a las aplicaciones de los prolemas relacionados con el uso de certificados digitales, como son la criptografía de clave pública, la validación usando CRLs o OCSP, la lectura de certificados, el uso del dni electrónico, etc.
Noticias
30/10/2009 . Publicada versión 1.3.11 de la plataforma.
ID-003205: Solucionado incompatibilidad con JVM de IBM sobre AIX.
ID-003202: Control de certificados caducados.
ID-003180: Mejoras en la seguridad de WS (allowed)
ID-003180: Pruebas de compatibilidad con .Net (cliente .Net no incluido en la versión GPL)
ID-003180: Web services basados en SOAP Document en lugar de en RPC.
ID-003178: Código básico para la generación de pdfs sellados.
ID-003165: Mejorado el soporte de certificados de Avansi y FNMT
ID-003156: Actualización a OpenId4java 0.9.5
ID-003155: Log4j basado en properties
ID-003121: Corregir los mensajes de error.
27/8/2008 . Publicada versión 1.3.2 de la plataforma, las principales mejoras son el soporte de los certificados de la Autoridad de Certificación Firma Profesional y la corrección de un problema en el proceso de validación del DNI electrónico, el listado completo mejoras y bugs solucionados es la siguiente:
ID-0002512: Soporte de certificados de la autoridad de certificación FirmaProfesional.
ID-0002534: Permitir controlar el tamaño máximo de los ficheros admitidos para su firma.
ID-0002569: Revisión semántica de terminos utilizados en la web.
ID-0002399: Eliminadas excepciones en la consola del Applet de firma en entornos Windows.
ID-0002557: Bug en la validación OCSP de DNIe. Gracias a Oscar Burgos por su colaboración al informar del Bug.
ID-0002589: Actualizar a la última versión de JAX-WS, proyecto metro 1.3
23/7/2008 . Publicada versión 1.3.1 de la plataforma, la lista de nuevas funcionalidades, mejoras y bugs solucionados es la siguiente:
Soporte de firma y autenticación con certificados de la Autoridad de Certificación de la Abogacía (ACA).
Sistema de control sobre la modificacion y versionado de la custodia.
Sistema de control sobre la modificacion y versionado de la custodia.
ID-0002501: Mejora del javascript que carga el applet de firma, para que funcione en clientes sin conexión a internet.
ID-0002400: Soprte de certificados de Camerfirma.
ID-0002500: Soporte de diferentes urls de acceso e impresión, para configuración de Viafirma dentro de DMZ
ID-0002250: Mejorar la documentación y ejemplos de integrador, instalador y cliente.
ID-0002104: Bug en el parseo de atributos del Certificado de AVANSI CxA.
ID-0002412: Nuevo método en el api cliente para la recuperación del XmlSignature custodiado.
ID-0002419: La clase de resultado de firma FirmaInfoViafirma ahora contiene toda la información relacionada con el usuario firmante, nif, nombre, etc..
ID-0002418: Metodos para la verificación de la firma desde el documento original custodiado. checkOrignalDocumentSigned y checkDocumentSigned.
ID-0002451: Custodia basada en Oracle Manager
ID-0002213: BUG: Problema con el Soporte de Alfresco 2.1 en la Custodia.
ID-0002215: Permitir modo test demo y modo plataforma.
ID-0002462: Nuevo mecanismo para el soporte de CAs basado en plugin.
ID-0002435: Permitir que la interfaz de Viafirma se adapte al interfaz visual de la aplicación cliente que la llama. Mediante la inclusión de un css
ID-0002219: Permitir que el mecanismo de seguridad de los Servicios Web basados en IP (ALLOWED) acepte mascaras de red y no solo IPs.
ID-0002382: BUG: Problemas con la validaciónde certificados de ACA en la CRL los certificados ACA
Funciones de la plataforma Viafirma
Autenticación . Cuando una aplicación Web requiera autenticar a sus usuarios mediante Certificado digital (incluido el DNIe) podrá delegar en la plataforma para que sea ésta la encargada de solicitar el Certificado al usuario, recuperar la información, comprobar su validez y devolver a la aplicación la información obtenida.
Firma Digital . Cuando una aplicación Web requiera que sus usuarios firmen la documentación entregada, realicen transacciones no repudiables o cualquier otro tipo de información que requiera no repudio, podrá delegar en la plataforma para que sea ésta la que firme, almacene, custodie y verifique la transacción o información presentada.
Custodia Digital . Un pilar muy importante de la firma digital es la custodia de los documentos firmados para que estos puedan ser recuperados y comprobados. Para ello se implementa un sistema de custodia documental basado en XMLSignature.
Características técnicas de Viafirma
Utilización de Algoritmos estándares de criptografía como el Advanced Encryption Standard (AES) que es el sustituto natural de Data Encryption Standard (DES), que actualmente se considera inseguro.
Uso conjunto de QR Code y Códigos de barra UCC 128 para el sellado de documentos Pdf. Generando comprobantes de firma que contienen códigos QR con toda la información del proceso de firma.
Uso de XMLSignature y XAdES como formato de datos para el intercambio y custodia de los certificados y documentos firmados.
Uso de OpenId como protocolo de intercambio de información entre el Cliente y el Servidor de autenticación y firma.
Para facilitar la obtención de certificados, soporta el acceso a certificados (X.509 ) almacenados en ficheros PKCS12s , así como el acceso a Microsoft Windows Keystore (CAPI) , Java User Key Store y Acceso a Llaveros de Mac OS X .
J2EE 1.4. Implementado 100% Java , lo hace un producto multiplataforma y con una arquitectura bien definida y fácilmente ampliable, necesitando solamente un contenedor que implemente la especificación Servlet 2.3/JSP 1.2 .
Independencia de la infraestructura base del Certificado X.509 estándar, habiendo sido probado correctamente con multitud de certificados, entre los que se encuentran :
- Certificado de Avansi CxA.
- Certificado de persona física de la FNMT (Se requiere la firma de un convenio para la validacción y acceso a las CRLs de la FNMT).
- Certificados de persona física de ANCERT.
- Certificados de persona física de Camerfirma.
- eDNI español (DNI electrónico de la Dirección general de la Policía y de la Guardia Civil).
- Certificados de la Autoridad de Certificación de la Abogacía (ACA).
Uso de Bouncy Castle Crypto APIs, que es una librería criptográfica que implementa JCE 1.2 (Java Cryptography Extension de Sun).
Validación de Certificados digitales utilizando CRLs publicadas mediante HTTP o contenidas dentro de LDAP (como en el caso de la FNMT).
Validación de Certificados digitales mediante OCSP.
Mecanismo de cache para minimicar el acceso a las crls.
Diagrama de arquitectura de viafirma
© 2006-2009 Viavansi
Fte: http://www.viafirma.org/
API para la firma Electronica
Welcome to the OpenOCES project
Overview
OpenOCES is a project dedicated to the development of free software components for the Danish OCES PKI. Since OCES is based on the X.509 standard, some of the OpenOCES subprojects, such as OpenSign, can be used in any X.509 based PKI. Read more about the OpenOCES project and OCES in general here.
Currently, OpenOCES hosts 3 projects:
OpenSign - an applet for signing text and logon
OpenOCES API - a convenience API for handling OCES certificates and signatures generated by OpenSign
OpenCert - a standalone application for issuance of OCES certificates
Latest news
OpenSign v1.6.5 has been released
16 October 2008
OpenSign v1.6.5 has been released.
This release includes important security improvements. Secondly the signed binary applets are now signed by DanID instead of TDC. The old TDC code signing certificate will be revoked within weeks, so everybody is urged to upgrade to OpenSign v1.6.5 as soon as possible.
Read the full release announcement here.
Preannouncement of OpenSign v1.6.5
10 October 2008
On October 16 2008 a new version 1.6.5 of OpenSign will be released.
Note that the released version will be signed by DanID. TDC has transferred all PKI activities to DanID including the management of OpenOCES.org. DanID is a company fully owned by PBS.
The TDC certificate which is used for signing the current stable release of OpenSign and OpenLogon will be revoked shortly after the release.
Searchable mail archives now available
9 August 2007
We now have searchable archives of our mailing lists. The search archives are available from the mailing list overview.
OpenSign v1.6.4 has been released
13 June 2007
This release implements two fixes from the unstable v1.7.x branch. Most importantly it fixes a bug causing certificates accessed through Microsoft CryptoAPI to be unavailable when the applet is executed in protected mode on Windows Vista. Secondly, this release fixes a bug causing the applets to not work properly from within the Opera browser.
Read the full release announcement here.
Open Source Your Summer
10 June 2007
We officially announce our Open Source Your Summer '07 Initiative (OSYS '07). The initiative provides an opportunity for students to work on an OpenOCES project under favourable conditions.
Read more details here.
OpenSign v1.7.0 has been released
9 May 2007
This release fixes a bug causing certificates accessed through Microsoft CryptoAPI to be unavailable when the applet is executed in protected mode on Windows Vista. The release also features a new keystore type contributed by Felix Garcia Borrego.
Read the full release announcement here.
OpenSign v1.6.3 has been released
9 May 2007
This release introduces caching of information obtained through Microsoft CryptoAPI for improved performance. Read the full release announcement here.
OpenSign v1.6.2 has been released
25 Marts 2007
This release contains minor fixes and enhancements including sorting af certificates and a Microsoft Vista temporary workaround. Read the full release announcement here.
OpenSign v1.6.1 has been released
29 November 2006
This release fixes an unfortunate plugin checksum mismatch in OpenSign v1.6.0. Read the full release announcement here.
Fte: http://www.openoces.org/
Overview
OpenOCES is a project dedicated to the development of free software components for the Danish OCES PKI. Since OCES is based on the X.509 standard, some of the OpenOCES subprojects, such as OpenSign, can be used in any X.509 based PKI. Read more about the OpenOCES project and OCES in general here.
Currently, OpenOCES hosts 3 projects:
OpenSign - an applet for signing text and logon
OpenOCES API - a convenience API for handling OCES certificates and signatures generated by OpenSign
OpenCert - a standalone application for issuance of OCES certificates
Latest news
OpenSign v1.6.5 has been released
16 October 2008
OpenSign v1.6.5 has been released.
This release includes important security improvements. Secondly the signed binary applets are now signed by DanID instead of TDC. The old TDC code signing certificate will be revoked within weeks, so everybody is urged to upgrade to OpenSign v1.6.5 as soon as possible.
Read the full release announcement here.
Preannouncement of OpenSign v1.6.5
10 October 2008
On October 16 2008 a new version 1.6.5 of OpenSign will be released.
Note that the released version will be signed by DanID. TDC has transferred all PKI activities to DanID including the management of OpenOCES.org. DanID is a company fully owned by PBS.
The TDC certificate which is used for signing the current stable release of OpenSign and OpenLogon will be revoked shortly after the release.
Searchable mail archives now available
9 August 2007
We now have searchable archives of our mailing lists. The search archives are available from the mailing list overview.
OpenSign v1.6.4 has been released
13 June 2007
This release implements two fixes from the unstable v1.7.x branch. Most importantly it fixes a bug causing certificates accessed through Microsoft CryptoAPI to be unavailable when the applet is executed in protected mode on Windows Vista. Secondly, this release fixes a bug causing the applets to not work properly from within the Opera browser.
Read the full release announcement here.
Open Source Your Summer
10 June 2007
We officially announce our Open Source Your Summer '07 Initiative (OSYS '07). The initiative provides an opportunity for students to work on an OpenOCES project under favourable conditions.
Read more details here.
OpenSign v1.7.0 has been released
9 May 2007
This release fixes a bug causing certificates accessed through Microsoft CryptoAPI to be unavailable when the applet is executed in protected mode on Windows Vista. The release also features a new keystore type contributed by Felix Garcia Borrego.
Read the full release announcement here.
OpenSign v1.6.3 has been released
9 May 2007
This release introduces caching of information obtained through Microsoft CryptoAPI for improved performance. Read the full release announcement here.
OpenSign v1.6.2 has been released
25 Marts 2007
This release contains minor fixes and enhancements including sorting af certificates and a Microsoft Vista temporary workaround. Read the full release announcement here.
OpenSign v1.6.1 has been released
29 November 2006
This release fixes an unfortunate plugin checksum mismatch in OpenSign v1.6.0. Read the full release announcement here.
Fte: http://www.openoces.org/
CryptoApplet Open Source para la firma electronica
CryptoApplet
Presentación
CryptoApplet es una aplicación Java para la realización de firma electrónica avanzada. Su funcionamiento es muy simple. Dada una entrada de datos y una configuración definida en el servidor, un cliente web podrá realizar una firma digital sobre los datos, y devolverá como resultado una representación de la firma en el formato definido en la configuración.
Los formatos de representación de firma soportados por CryptoApplet son los siguientes:
Firma "en bruto".
CMS/PKCS#7.
XAdES-X-L en formato DigiDoc.
Firma PDF.
La gestión de los certificados con los que se va a firma se lleva a cabo de forma transparente para el usuario mediante el acceso directo al CryptoAPI si se utiliza Microsoft Internet Explorer o PKCS#11 si se usa Firefox (en Windows XP o GNU/Linux). También permite utilizar los certificados almacenados en el Clauer si el sistema cliente tiene el software del Clauer instalado.
El applet también es capaz de ejecutarse en los sistemas operativos Microsoft Windows XP y GNU/Linux con el único requerimiento de tener instalada la Máquina Virtual Java de SUN (versión 1.5 o superior).
Para más información, ver la sección de documentación que se incluye a continuación.
Novedades
El desarrollo del CryptoApplet se ha migrado a Forja UJI.
La versión 2 Beta de la aplicación de firma ya se encuentra disponible en la sección de descargas. Algunas de las mejoras que se pueden destacar:
Soporte completo para la ejecución en Explorer/Windows Vista con el UAC activado.
Lista de los certificados instalados en los navegadores de la familia Mozilla sin necesidad de solicitar la clave de acceso.
Soporte para el DNI electrónico (DNI-e) tanto en Intenet Explorer como en Mozilla.
Menú de carga del controlador de dispositivo PKCS#11 que permite añadir nuevos dispositivos de firma instalados en el cliente.
Archivo de configuración de firma en PDF que permite seleccionar los campos "Reason", "Location", "Contact" de la firma en PDF, así como los certificados raíz de las autoridades con las que se permitirá realizar la firma del documento PDF.
Parametrización de la aplicación con JavaScript.
Mejoras en la usabilidad y en el aspecto.
Documentación
Se pueden encontrar resueltas las dudas más frecuentes en la lista de correo de usuarios del CryptoApplet. Se puede realizar la suscripción a esta lista, si se desea, desde aquí.
Para preguntar cualquier duda o hacer alguna sugerencia, se puede enviar un correo electrónico a cryptoapplet at llistes.uji.es.
Se puede revisar la documentación de la versión 1 del applet. Aunque esta no incluye los desarrollos más nuevos de la versión 2, puede servir de ayuda.
Ejemplos
Firma "en bruto".
CMS/PKCS#7.
XAdES-X-L en formato DigiDoc
Firma PDF.
XAdES-X-L por lotes
Verificador XAdES-X-L
Descarga
Todo el software relacionado con esta aplicación se puede descargar desde la página de descarga.
Fte: http://proyectostic.uji.es/pr/cryptoapplet/
Presentación
CryptoApplet es una aplicación Java para la realización de firma electrónica avanzada. Su funcionamiento es muy simple. Dada una entrada de datos y una configuración definida en el servidor, un cliente web podrá realizar una firma digital sobre los datos, y devolverá como resultado una representación de la firma en el formato definido en la configuración.
Los formatos de representación de firma soportados por CryptoApplet son los siguientes:
Firma "en bruto".
CMS/PKCS#7.
XAdES-X-L en formato DigiDoc.
Firma PDF.
La gestión de los certificados con los que se va a firma se lleva a cabo de forma transparente para el usuario mediante el acceso directo al CryptoAPI si se utiliza Microsoft Internet Explorer o PKCS#11 si se usa Firefox (en Windows XP o GNU/Linux). También permite utilizar los certificados almacenados en el Clauer si el sistema cliente tiene el software del Clauer instalado.
El applet también es capaz de ejecutarse en los sistemas operativos Microsoft Windows XP y GNU/Linux con el único requerimiento de tener instalada la Máquina Virtual Java de SUN (versión 1.5 o superior).
Para más información, ver la sección de documentación que se incluye a continuación.
Novedades
El desarrollo del CryptoApplet se ha migrado a Forja UJI.
La versión 2 Beta de la aplicación de firma ya se encuentra disponible en la sección de descargas. Algunas de las mejoras que se pueden destacar:
Soporte completo para la ejecución en Explorer/Windows Vista con el UAC activado.
Lista de los certificados instalados en los navegadores de la familia Mozilla sin necesidad de solicitar la clave de acceso.
Soporte para el DNI electrónico (DNI-e) tanto en Intenet Explorer como en Mozilla.
Menú de carga del controlador de dispositivo PKCS#11 que permite añadir nuevos dispositivos de firma instalados en el cliente.
Archivo de configuración de firma en PDF que permite seleccionar los campos "Reason", "Location", "Contact" de la firma en PDF, así como los certificados raíz de las autoridades con las que se permitirá realizar la firma del documento PDF.
Parametrización de la aplicación con JavaScript.
Mejoras en la usabilidad y en el aspecto.
Documentación
Se pueden encontrar resueltas las dudas más frecuentes en la lista de correo de usuarios del CryptoApplet. Se puede realizar la suscripción a esta lista, si se desea, desde aquí.
Para preguntar cualquier duda o hacer alguna sugerencia, se puede enviar un correo electrónico a cryptoapplet at llistes.uji.es.
Se puede revisar la documentación de la versión 1 del applet. Aunque esta no incluye los desarrollos más nuevos de la versión 2, puede servir de ayuda.
Ejemplos
Firma "en bruto".
CMS/PKCS#7.
XAdES-X-L en formato DigiDoc
Firma PDF.
XAdES-X-L por lotes
Verificador XAdES-X-L
Descarga
Todo el software relacionado con esta aplicación se puede descargar desde la página de descarga.
Fte: http://proyectostic.uji.es/pr/cryptoapplet/
Firma Electronica Conceptos
Introducción al concepto de firmas electrónicas
El paradigma de firmas electrónicas (también llamadas firmas digitales) es un proceso que hace posible garantizar la autenticidad del remitente (función de autenticación) y verificar la integridad del mensaje recibido.
Las firmas electrónicas también poseen una función de reconocimiento de autoría, es decir, hacen posible garantizar que el remitente ha enviado verdaderamente el mensaje (en otras palabras, se aseguran de que el remitente no pueda negar el envío del mensaje).
¿Qué es una función hash?
Una función hash es una función que hace posible obtener un hash (también llamado resumen de mensaje) de un texto, es decir, obtener una serie moderadamente corta de caracteres que representan el texto al cual se le aplica esta función hash. La función hash debe ser tal que asocie únicamente un hash con un texto plano (esto significa que la mínima modificación del documento causará una modificación en el hash). Además, debe ser una función unidireccional para que el mensaje original no pueda ser recuperado a partir del hash. Si existiera una forma de encontrar el texto plano desde el hash, se diría que la función hash presenta una "trapdoor".
Crear una huella digital de un documento utilizando la función hash
Como tal, puede decirse que la función hash representa la huella digital de un documento.
Los algoritmos hash más utilizados son:
* MD5 (MD que significa Message Digest; en castellano, Resumen de mensaje). Desarrollado por Rivest en 1991, el MD5 crea, a partir de un texto cuyo tamaño es elegido al azar, una huella digital de 128 bits procesándola en bloques de 512 bits. Es común observar documentos descargados de Internet que vienen acompañados por archivos MD5: este es el hash del documento que hace posible verificar su integridad.
* SHA (Secure Hash Algorithm; en castellano, Algoritmo Hash Seguro) crea una huella digital que tiene 160 bits de longitud.
SHA-1 es una versión mejorada de SHA que data de 1994. Produce una huella digital de 160 bits a partir de un mensaje que tiene una longitud máxima de 264 bits y los procesa en bloques de 512 bits.
VERIFICACIÓN DE LA INTEGRIDAD
Al enviar un mensaje junto con su hash, es posible garantizar la integridad de dicho mensaje, es decir, el destinatario puede estar seguro de que el mensaje no ha sido alterado (intencionalmente o por casualidad) durante la comunicación.
Cuando un destinatario recibe un mensaje simplemente debe calcular el hash del mensaje recibido y compararlo con el hash que acompaña el documento. Si se falsificara el mensaje (o el hash) durante la comunicación, las dos huellas digitales no coincidirían.
SELLADO DE DATOS
Al utilizar una función hash se puede verificar que la huella digital corresponde al mensaje recibido, pero nada puede probar que el mensaje haya sido enviado por la persona que afirma ser el remitente.
Para garantizar la autenticidad del mensaje, el remitente simplemente debe cifrar (generalmente decimos firmar) el hash utilizando su clave privada (el hash firmado se denomina sello) y enviar el sello al destinatario.
Al recibir el mensaje, el destinatario deberá descifrar el sello con la clave pública del remitente, luego deberá comparar el hash obtenido con la función hash del hash recibido como adjunto. Esta función de creación de sellos se llama sellado.
MÁS INFORMACIÓN
SHA1 Secure Hash Algorithm - Version 1.0
RFC 3174 (rfc3174) - US Secure Hash Algorithm 1 (SHA1)
RFC 1321 (rfc1321) - The MD5 Message-Digest Algorithm
Última actualización el jueves, 16 de octubre de 2008, 15:43:34 .
Certificados
INTRODUCCIÓN AL CONCEPTO DE CERTIFICADOS
Los algoritmos de cifrado asimétrico se basan en el hecho de compartir una clave pública entre varios usuarios. En general, esta clave se comparte mediante un directorio electrónico (normalmente en formato LDAP) o una página Web.
Sin embargo, este modo de compartir presenta un inconveniente importante: nada garantiza que la clave pertenezca al usuario con el que está asociada. Un hacker puede corromper la clave pública que aparece en el directorio remplazándola con su propia clave pública. Por consiguiente, el hacker podrá descifrar todos los mensajes que se cifraron con la clave que aparece en el directorio.
Un certificado permite asociar una clave pública con una entidad (una persona, un equipo, etc.) para garantizar su validez. El certificado es como la tarjeta de identificación de la clave, emitido por una entidad llamada Entidad de certificación (que frecuentemente se abrevia CA, por sus siglas en inglés).
La entidad de certificación es responsable de emitir los certificados, de asignarles una fecha de validez (similar a la fecha de vencimiento de los alimentos) y de revocarlos antes de esta fecha en caso de que la clave (o su dueño) estén en una situación de riesgo.
ESTRUCTURA DE LOS CERTIFICADOS
Los certificados son pequeños archivos divididos en dos partes:
La parte que contiene la información
La parte que contiene la firma de la entidad de certificación
La estructura de los certificados está estandarizada por la norma X.509 (más precisamente, X.509v3) de la UIT, que define la información que contiene el certificado:
La versión de X.509 a la que corresponde el certificado;
El número de serie del certificado;
El algoritmo de cifrado utilizado para firmar el certificado;
El nombre (DN, siglas en inglés de Nombre distinguido) de la entidad de certificación que lo emite;
La fecha en que entra en vigencia el certificado;
La fecha en que finaliza el período de validez del certificado;
El objeto de utilización de la clave pública;
La clave pública del dueño del certificado;
La firma del emisor del certificado (huella digital).
La entidad de certificación firma toda esta información (información + clave pública del solicitante) y esto implica que una función hash crea una huella digital de esta información y luego este hash se cifra con la clave privada de la entidad de certificación. La clave pública se distribuye antes de tiempo para permitir a los usuarios verificar la firma de la entidad de certificación con su clave pública.
Cuando un usuario desea comunicarse con otra persona, sólo debe obtener el certificado del receptor. Este certificado contiene el nombre y la clave pública del receptor, y está firmado por la entidad de certificación. De esta forma, es posible verificar la validez del mensaje aplicando, primero, la función hash a la información contenida en el certificado y, segundo, descifrando la firma de la entidad de certificación con la clave pública y comparando los dos resultados.
FIRMAS DEL CERTIFICADO
Existen varios tipos de certificados en función del nivel de sus firmas:
Los certificados firmados localmente son certificados de uso interno. Al estar firmados por un servidor local, este tipo de certificados permiten garantizar los intercambios confidenciales dentro de una organización, por ejemplo, en una Intranet. Los certificados firmados localmente se pueden usar para autentificar usuarios.
Los certificados firmados por una entidad de certificación son necesarios cuando se deben garantizar los intercambios seguros con usuarios anónimos, por ejemplo, en el caso de una página Web segura al que pueda acceder el público general. La certificación de un tercero garantiza al usuario que el certificado pertenece efectivamente a la organización a la que dice pertenecer.
TIPOS DE USO
Los certificados se utilizan principalmente en tres tipos de contextos:
Los certificados de cliente se almacenan en la estación de trabajo del usuario o se integran en un contenedor como una tarjeta inteligente, y permiten identificar a un usuario y asociarlo con ciertos privilegios. En la mayoría de los casos, se transmiten al servidor cuando se establece una conexión y el servidor asigna privilegios en función de la acreditación del usuario. Son verdaderas tarjetas de identificación digitales que usan un par de claves asimétricas con una longitud de 512 a 1024 bits.
Los certificados de servidor se instalan en un servidor Web y permiten conectar un servicio con el dueño del servicio. En el caso de página Web, permiten garantizar que la dirección URL de la página Web y especialmente su dominio pertenecen realmente a tal o cual compañía. También permiten proteger las transacciones con usuarios gracias al protocolo SSL.
Los certificados VPN (Red privada virtual) se instalan en un equipo de red y permiten cifrar flujos de comunicación de extremo a extremo entre dos puntos (por ejemplo, dos ubicaciones de una compañía). En este tipo de escenario, los usuarios tienen un certificado cliente, los servidores aplican un certificado de servidor y el equipo de comunicación usa un certificado especial (generalmente un certificado IPSec).
PUBLICADO POR ADAN SANCHEZ EN 15:59 0 COMENTARIOS
Paginas relacionadas
Libro Electrónico de Seguridad Informática y Criptografía
http://www.lpsi.eui.upm.es/SInformatica/diapositivas.htm
ExpoCrip: Software para Generación de Claves, Cifra y Firma RSA, ElGamal y DSS
http://www.criptored.upm.es/software/sw_m001l.htm
PUBLICADO POR ADAN SANCHEZ EN 15:19 0 COMENTARIOS
Fte: http://zytrust1.blogspot.com/2009_04_01_archive.html
El paradigma de firmas electrónicas (también llamadas firmas digitales) es un proceso que hace posible garantizar la autenticidad del remitente (función de autenticación) y verificar la integridad del mensaje recibido.
Las firmas electrónicas también poseen una función de reconocimiento de autoría, es decir, hacen posible garantizar que el remitente ha enviado verdaderamente el mensaje (en otras palabras, se aseguran de que el remitente no pueda negar el envío del mensaje).
¿Qué es una función hash?
Una función hash es una función que hace posible obtener un hash (también llamado resumen de mensaje) de un texto, es decir, obtener una serie moderadamente corta de caracteres que representan el texto al cual se le aplica esta función hash. La función hash debe ser tal que asocie únicamente un hash con un texto plano (esto significa que la mínima modificación del documento causará una modificación en el hash). Además, debe ser una función unidireccional para que el mensaje original no pueda ser recuperado a partir del hash. Si existiera una forma de encontrar el texto plano desde el hash, se diría que la función hash presenta una "trapdoor".
Crear una huella digital de un documento utilizando la función hash
Como tal, puede decirse que la función hash representa la huella digital de un documento.
Los algoritmos hash más utilizados son:
* MD5 (MD que significa Message Digest; en castellano, Resumen de mensaje). Desarrollado por Rivest en 1991, el MD5 crea, a partir de un texto cuyo tamaño es elegido al azar, una huella digital de 128 bits procesándola en bloques de 512 bits. Es común observar documentos descargados de Internet que vienen acompañados por archivos MD5: este es el hash del documento que hace posible verificar su integridad.
* SHA (Secure Hash Algorithm; en castellano, Algoritmo Hash Seguro) crea una huella digital que tiene 160 bits de longitud.
SHA-1 es una versión mejorada de SHA que data de 1994. Produce una huella digital de 160 bits a partir de un mensaje que tiene una longitud máxima de 264 bits y los procesa en bloques de 512 bits.
VERIFICACIÓN DE LA INTEGRIDAD
Al enviar un mensaje junto con su hash, es posible garantizar la integridad de dicho mensaje, es decir, el destinatario puede estar seguro de que el mensaje no ha sido alterado (intencionalmente o por casualidad) durante la comunicación.
Cuando un destinatario recibe un mensaje simplemente debe calcular el hash del mensaje recibido y compararlo con el hash que acompaña el documento. Si se falsificara el mensaje (o el hash) durante la comunicación, las dos huellas digitales no coincidirían.
SELLADO DE DATOS
Al utilizar una función hash se puede verificar que la huella digital corresponde al mensaje recibido, pero nada puede probar que el mensaje haya sido enviado por la persona que afirma ser el remitente.
Para garantizar la autenticidad del mensaje, el remitente simplemente debe cifrar (generalmente decimos firmar) el hash utilizando su clave privada (el hash firmado se denomina sello) y enviar el sello al destinatario.
Al recibir el mensaje, el destinatario deberá descifrar el sello con la clave pública del remitente, luego deberá comparar el hash obtenido con la función hash del hash recibido como adjunto. Esta función de creación de sellos se llama sellado.
MÁS INFORMACIÓN
SHA1 Secure Hash Algorithm - Version 1.0
RFC 3174 (rfc3174) - US Secure Hash Algorithm 1 (SHA1)
RFC 1321 (rfc1321) - The MD5 Message-Digest Algorithm
Última actualización el jueves, 16 de octubre de 2008, 15:43:34 .
Certificados
INTRODUCCIÓN AL CONCEPTO DE CERTIFICADOS
Los algoritmos de cifrado asimétrico se basan en el hecho de compartir una clave pública entre varios usuarios. En general, esta clave se comparte mediante un directorio electrónico (normalmente en formato LDAP) o una página Web.
Sin embargo, este modo de compartir presenta un inconveniente importante: nada garantiza que la clave pertenezca al usuario con el que está asociada. Un hacker puede corromper la clave pública que aparece en el directorio remplazándola con su propia clave pública. Por consiguiente, el hacker podrá descifrar todos los mensajes que se cifraron con la clave que aparece en el directorio.
Un certificado permite asociar una clave pública con una entidad (una persona, un equipo, etc.) para garantizar su validez. El certificado es como la tarjeta de identificación de la clave, emitido por una entidad llamada Entidad de certificación (que frecuentemente se abrevia CA, por sus siglas en inglés).
La entidad de certificación es responsable de emitir los certificados, de asignarles una fecha de validez (similar a la fecha de vencimiento de los alimentos) y de revocarlos antes de esta fecha en caso de que la clave (o su dueño) estén en una situación de riesgo.
ESTRUCTURA DE LOS CERTIFICADOS
Los certificados son pequeños archivos divididos en dos partes:
La parte que contiene la información
La parte que contiene la firma de la entidad de certificación
La estructura de los certificados está estandarizada por la norma X.509 (más precisamente, X.509v3) de la UIT, que define la información que contiene el certificado:
La versión de X.509 a la que corresponde el certificado;
El número de serie del certificado;
El algoritmo de cifrado utilizado para firmar el certificado;
El nombre (DN, siglas en inglés de Nombre distinguido) de la entidad de certificación que lo emite;
La fecha en que entra en vigencia el certificado;
La fecha en que finaliza el período de validez del certificado;
El objeto de utilización de la clave pública;
La clave pública del dueño del certificado;
La firma del emisor del certificado (huella digital).
La entidad de certificación firma toda esta información (información + clave pública del solicitante) y esto implica que una función hash crea una huella digital de esta información y luego este hash se cifra con la clave privada de la entidad de certificación. La clave pública se distribuye antes de tiempo para permitir a los usuarios verificar la firma de la entidad de certificación con su clave pública.
Cuando un usuario desea comunicarse con otra persona, sólo debe obtener el certificado del receptor. Este certificado contiene el nombre y la clave pública del receptor, y está firmado por la entidad de certificación. De esta forma, es posible verificar la validez del mensaje aplicando, primero, la función hash a la información contenida en el certificado y, segundo, descifrando la firma de la entidad de certificación con la clave pública y comparando los dos resultados.
FIRMAS DEL CERTIFICADO
Existen varios tipos de certificados en función del nivel de sus firmas:
Los certificados firmados localmente son certificados de uso interno. Al estar firmados por un servidor local, este tipo de certificados permiten garantizar los intercambios confidenciales dentro de una organización, por ejemplo, en una Intranet. Los certificados firmados localmente se pueden usar para autentificar usuarios.
Los certificados firmados por una entidad de certificación son necesarios cuando se deben garantizar los intercambios seguros con usuarios anónimos, por ejemplo, en el caso de una página Web segura al que pueda acceder el público general. La certificación de un tercero garantiza al usuario que el certificado pertenece efectivamente a la organización a la que dice pertenecer.
TIPOS DE USO
Los certificados se utilizan principalmente en tres tipos de contextos:
Los certificados de cliente se almacenan en la estación de trabajo del usuario o se integran en un contenedor como una tarjeta inteligente, y permiten identificar a un usuario y asociarlo con ciertos privilegios. En la mayoría de los casos, se transmiten al servidor cuando se establece una conexión y el servidor asigna privilegios en función de la acreditación del usuario. Son verdaderas tarjetas de identificación digitales que usan un par de claves asimétricas con una longitud de 512 a 1024 bits.
Los certificados de servidor se instalan en un servidor Web y permiten conectar un servicio con el dueño del servicio. En el caso de página Web, permiten garantizar que la dirección URL de la página Web y especialmente su dominio pertenecen realmente a tal o cual compañía. También permiten proteger las transacciones con usuarios gracias al protocolo SSL.
Los certificados VPN (Red privada virtual) se instalan en un equipo de red y permiten cifrar flujos de comunicación de extremo a extremo entre dos puntos (por ejemplo, dos ubicaciones de una compañía). En este tipo de escenario, los usuarios tienen un certificado cliente, los servidores aplican un certificado de servidor y el equipo de comunicación usa un certificado especial (generalmente un certificado IPSec).
PUBLICADO POR ADAN SANCHEZ EN 15:59 0 COMENTARIOS
Paginas relacionadas
Libro Electrónico de Seguridad Informática y Criptografía
http://www.lpsi.eui.upm.es/SInformatica/diapositivas.htm
ExpoCrip: Software para Generación de Claves, Cifra y Firma RSA, ElGamal y DSS
http://www.criptored.upm.es/software/sw_m001l.htm
PUBLICADO POR ADAN SANCHEZ EN 15:19 0 COMENTARIOS
Fte: http://zytrust1.blogspot.com/2009_04_01_archive.html
Incrustar Firma Electronica en PDF con PHP
VersyPDF.PHP es una librería PHP para crear y modificar documentos PDF al vuelo.
VersyPDF.PHP es una librería de alta calidad y de nivel industrial para PDFs que cumple con los requisitos de las diversas aplicaciones más demandantes. Usando VersyPDF.PHP puedes desarrollar aplicaciones comerciales confiables e independientes que puedan leer, escribir y modificar documentos PDF.
Funcionalidades:
Leer/Escribir documentos PDF a/desde memoria o a algún archivo a disco.
Crea nuevo texto, diseños vectoriales e imágenes.
Incrusta rápidamente imágenes TIFF, JPEG, PNG y BMP.
Permite incrustar letras TrueType y Tipo 1 para una reproducción precisa del texto.
Permite texto Unicode y las codificaciones estándares del PDF.
Herencia parcial dinámica de letras para producir archivos más pequeños.
Control total sobre el posicionamiento del texto y el espaciado de caracteres.
Permite todos los espacios de colores del PDF y opciones avanzadas previas a la impresión.
Control total sobre el posicionamiento del contenido y todos los atributos gráficos disponibles en el PDF.
Reutilice recursos como imágenes, letras y espacios de colores mediante la compartición de objetos, para obtener documentos más pequeños y eficientes.
Admite destinos explícitos y nombrados. Los destinos con nombre permiten que los cambios al documento no invaliden marcas existentes.
API extensa para creación y edición de marcas.
Trabaja con hilos.
Aplique seguridad a los documentos nuevos.
Linealización (para rápida visualización en web)
Compresión de los documentos PDF de salida
Inserte o añada nuevo contenido a páginas existentes.
Rotar páginas.
Compresión JBIG2, CCITT Fax, Flate/PNG, JPEG/DCT.
Admite el identificador de seguridad estándar PDF (cifrado de 40 y 128 bits)
Remoción de objetos no usados. Esta opción puede ayudar a crear archivos más pequeños.
Llenado de Formularios PDF
Lee valores de los campos de formularios PDF
Crea nuevos campos de formularios
Divide páginas
Mezcla y añade páginas
Admite firma digital
Admite muchas de las acciones
Admite muchas de las anotaciones
Análisis de las imágenes EMF
La biblioteca VersyPDF.PHP no requiere ningún programa de terceros para crear o modificar archivos PDF.
Fte: http://www.carlitrosweb.com/2007/12/14/insertar-firma-digital-en-un-pdf-con-php
VersyPDF.PHP es una librería de alta calidad y de nivel industrial para PDFs que cumple con los requisitos de las diversas aplicaciones más demandantes. Usando VersyPDF.PHP puedes desarrollar aplicaciones comerciales confiables e independientes que puedan leer, escribir y modificar documentos PDF.
Funcionalidades:
Leer/Escribir documentos PDF a/desde memoria o a algún archivo a disco.
Crea nuevo texto, diseños vectoriales e imágenes.
Incrusta rápidamente imágenes TIFF, JPEG, PNG y BMP.
Permite incrustar letras TrueType y Tipo 1 para una reproducción precisa del texto.
Permite texto Unicode y las codificaciones estándares del PDF.
Herencia parcial dinámica de letras para producir archivos más pequeños.
Control total sobre el posicionamiento del texto y el espaciado de caracteres.
Permite todos los espacios de colores del PDF y opciones avanzadas previas a la impresión.
Control total sobre el posicionamiento del contenido y todos los atributos gráficos disponibles en el PDF.
Reutilice recursos como imágenes, letras y espacios de colores mediante la compartición de objetos, para obtener documentos más pequeños y eficientes.
Admite destinos explícitos y nombrados. Los destinos con nombre permiten que los cambios al documento no invaliden marcas existentes.
API extensa para creación y edición de marcas.
Trabaja con hilos.
Aplique seguridad a los documentos nuevos.
Linealización (para rápida visualización en web)
Compresión de los documentos PDF de salida
Inserte o añada nuevo contenido a páginas existentes.
Rotar páginas.
Compresión JBIG2, CCITT Fax, Flate/PNG, JPEG/DCT.
Admite el identificador de seguridad estándar PDF (cifrado de 40 y 128 bits)
Remoción de objetos no usados. Esta opción puede ayudar a crear archivos más pequeños.
Llenado de Formularios PDF
Lee valores de los campos de formularios PDF
Crea nuevos campos de formularios
Divide páginas
Mezcla y añade páginas
Admite firma digital
Admite muchas de las acciones
Admite muchas de las anotaciones
Análisis de las imágenes EMF
La biblioteca VersyPDF.PHP no requiere ningún programa de terceros para crear o modificar archivos PDF.
Fte: http://www.carlitrosweb.com/2007/12/14/insertar-firma-digital-en-un-pdf-con-php
miércoles, 17 de marzo de 2010
Añadir paginación a un Grid en Flex
Flex DataGrid Paging Example with Source
http://develop.gurufaction.com/src/App.mxml and the example application can be viewed here http://develop.gurufaction.com/App.swf
Fte:http://gurufaction.blogspot.com/2007/02/flex-datagrid-paging-example-with.html
http://develop.gurufaction.com/src/App.mxml and the example application can be viewed here http://develop.gurufaction.com/App.swf
Fte:http://gurufaction.blogspot.com/2007/02/flex-datagrid-paging-example-with.html
miércoles, 3 de marzo de 2010
jueves, 4 de febrero de 2010
Ejemplo de Servicio Web y Clientes para Servicio Web con AXIS 2
Fte: http://www.eclipse.org/webtools/community/tutorials/BottomUpAxis2WebService/bu_tutorial.html
Eclipse WTP Tutorials - Creating Bottom Up Web Service via Apache Axis2
By Lahiru Sandakith
WSO2 Inc.
June 29, 2007
Introduction
This tutorial is meant to demonstrate the use of the newly introduced Axis2 Web Services tools in the Web Tools Platform Project using the WTP 2.0 drivers. Also this shows how to create a simple Web service and Web service client from a JAVA class. The JAVA class in this scenario converts between the Celsius and Farenheit temperature scales and its the same class that used in the Axis web services tutorials.
Set Up
Before creating the Web service, there are two prerequisites:
Download Eclipse WTP 2.0 and unzip it.
Configure Apache Tomcat inside Eclipse WTP.
Creating a bottom up JAVA bean Web service and Web service client using Axis2 WTP Tools
This tutorial need a Axis2 runtime. You can download the latest axis2 binary distribution from here.
Note : Currently Axis2 version 1.2 is the supported version for the Web Services Scenarios
Download the latest Axis2 runtime from the above link and extract it.
Now we point Eclipse WTP to downloaded Axis2 Runtime. Open Window -> Preferences -> Web Services -> Axis2 Emitter
Select the Axis2 Runtime tab and point to the correct Axis2 runtime location. Alternatively at the Axis2 Preference tab, you can set the default setting that will come up on the Web Services Creation wizards. For the moment we will accept the default settings.
Click OK.
Next we need to create a project with the support of Axis2 features. Open File -> New -> Other... -> Web -> Dynamic Web Project
Click next
Select the name Axis2WSTest as the Dynamic Web project name (you can specify any name you prefer), and select the configured Tomcat runtime as the target runtime.
Click next.
Select the Axis2 Web service facet
Click Finish.
This will create a dynamic Web project in the workbench
Import the wtp/Converter.java class into Axis2WSTest/src (be sure to preserve the package).
Build the Project, if its not auto build.
Select Converter.java, open File -> New -> Other... -> Web Services -> Web Service
Click next.
The Web service wizard would be brought up with Web service type set to Bottom up Java bean Web Service with the service implementation automatically filled in. Move the service scale to Start service.
Click on the Web Service runtime link to select the Axis2 runtime.
Click OK.
Ensure that the correct server and service project are selected as displayed below.
Click next.
This page is the service.xml selection page. if you have a custom services.xml, you can include that by clicking the Browse button. For the moment, just leave it at the default.
Click next.
This page is the Start Server page. It will be displayed if the server has not been started. Click on the Start Server button. This will start the server runtime.
Click next.
This page is the Web services publication page, accept the defaults.
Click Finish.
Now, select the Axis2WSTest dynamic Web project, right-click and select Run -> Run As -> Run on Server to bring up the Axis2 servlet.
Click Next.
Make sure you have the Axis2WSTest dynamic Web project on the right-hand side under the Configured project.
Click Finish.
This will deploy the Axis2 server webapp on the configured servlet container and will display the Axis2 home page. Note that the servlet container will start up according to the Server configuration files on your workspace.
Click on the Services link to view the available services. The newly created converter Web service will be shown there.
Click on the Converter Service link to display the ?wsdl URL of the newly created Web service. Copy the URL.
Now we'll generate the client for the newly created service by referring the ?wsdl generated by the Axis2 Server. Open File -> New -> Other... -> Web Services -> Web ServiceClient
Paste the URL that was copied earlier into the service definition field.
Click on the Client project hyperlink and enter Axis2WSTestClient as the name of the client project. Click OK.
Back on the Web Services Client wizard, make sure the Web service runtime is set to Axis2 and the server is set correctly. Click Next.
Next page is the Client Configuration Page. Accept the defaults and click Finish.
The Clients stubs will be generated to your Dynamic Web project Axis2WSTestClient.
Now we are going to write Java main program to invoke the client stub. Import the ConverterClient.java file to the workspace into the wtp package in the src folder of Axis2WSTestClient.
Then select the ConverterClient file, right-click and select Run As -> Java Application. Here's what you get on the server console:
Another way to test and invoke the service is to select Generate test case to test the service check box on the Axis2 Client Web Service Configuration Page when going through the Web Service Client wizard.
If that option is selected, the Axis2 emitter will generate JUnit testcases matching the WSDL we provide to the client. These JUnit testcases will be generated to a newly added source directory to the Axis2WSTestClient project called test.
Next thing we need to do is to insert the testcase with the valid inputs as the Web servivce method arguments. In this case, let's test the ConverterConverterSOAP11Port_httpTest.java by provide values for Celsius and Farenheit for the temperature conversion. As an example, replace the generated TODO statement in each test method to fill in the data with values as:
testfarenheitToCelsius() -> farenheitToCelsius8.setFarenheit(212);
testStartfarenheitToCelsius() -> farenheitToCelsius8.setFarenheit(212);
testcelsiusToFarenheit() -> celsiusToFarenheit10.setCelsius(100);
testStartcelsiusToFarenheit() -> celsiusToFarenheit10.setCelsius(100);
Here the testcases were generated to test both the synchronous and asynchronous clients.
After that, select the testcase, right-click, select Run As -> JUnit Test. You will be able to run the unit test successfully invoking the Web service.
Summary
In this example, we show using the Web Services wizard followed by using the Web Service client wizard. You could also choose to generate both service and client using the Web Services wizard:
The Web Service wizard orchestrates the end-to-end generation, assembly, deployment, installation and execution of the Web service and Web service client. Now that your Web service is running, there are a few interesting things you can do with this WSDL file. Examples:
You can choose Web Services -> Test with Web Services Explorer to test the service.
You can choose Web Services -> Publish WSDL file to publish the service to a public UDDI registry.
Resources
You can also refer to the Axis Web services tutorials:
Using Web Service Explorer to test a Web service
Creating Bottom Up Web Service via Axis
Creating Top Down Web Service via Axis
Consuming Web service using Web Service Client via Axis
Eclipse WTP Tutorials - Creating Bottom Up Web Service via Apache Axis2
By Lahiru Sandakith
WSO2 Inc.
June 29, 2007
Introduction
This tutorial is meant to demonstrate the use of the newly introduced Axis2 Web Services tools in the Web Tools Platform Project using the WTP 2.0 drivers. Also this shows how to create a simple Web service and Web service client from a JAVA class. The JAVA class in this scenario converts between the Celsius and Farenheit temperature scales and its the same class that used in the Axis web services tutorials.
Set Up
Before creating the Web service, there are two prerequisites:
Download Eclipse WTP 2.0 and unzip it.
Configure Apache Tomcat inside Eclipse WTP.
Creating a bottom up JAVA bean Web service and Web service client using Axis2 WTP Tools
This tutorial need a Axis2 runtime. You can download the latest axis2 binary distribution from here.
Note : Currently Axis2 version 1.2 is the supported version for the Web Services Scenarios
Download the latest Axis2 runtime from the above link and extract it.
Now we point Eclipse WTP to downloaded Axis2 Runtime. Open Window -> Preferences -> Web Services -> Axis2 Emitter
Select the Axis2 Runtime tab and point to the correct Axis2 runtime location. Alternatively at the Axis2 Preference tab, you can set the default setting that will come up on the Web Services Creation wizards. For the moment we will accept the default settings.
Click OK.
Next we need to create a project with the support of Axis2 features. Open File -> New -> Other... -> Web -> Dynamic Web Project
Click next
Select the name Axis2WSTest as the Dynamic Web project name (you can specify any name you prefer), and select the configured Tomcat runtime as the target runtime.
Click next.
Select the Axis2 Web service facet
Click Finish.
This will create a dynamic Web project in the workbench
Import the wtp/Converter.java class into Axis2WSTest/src (be sure to preserve the package).
Build the Project, if its not auto build.
Select Converter.java, open File -> New -> Other... -> Web Services -> Web Service
Click next.
The Web service wizard would be brought up with Web service type set to Bottom up Java bean Web Service with the service implementation automatically filled in. Move the service scale to Start service.
Click on the Web Service runtime link to select the Axis2 runtime.
Click OK.
Ensure that the correct server and service project are selected as displayed below.
Click next.
This page is the service.xml selection page. if you have a custom services.xml, you can include that by clicking the Browse button. For the moment, just leave it at the default.
Click next.
This page is the Start Server page. It will be displayed if the server has not been started. Click on the Start Server button. This will start the server runtime.
Click next.
This page is the Web services publication page, accept the defaults.
Click Finish.
Now, select the Axis2WSTest dynamic Web project, right-click and select Run -> Run As -> Run on Server to bring up the Axis2 servlet.
Click Next.
Make sure you have the Axis2WSTest dynamic Web project on the right-hand side under the Configured project.
Click Finish.
This will deploy the Axis2 server webapp on the configured servlet container and will display the Axis2 home page. Note that the servlet container will start up according to the Server configuration files on your workspace.
Click on the Services link to view the available services. The newly created converter Web service will be shown there.
Click on the Converter Service link to display the ?wsdl URL of the newly created Web service. Copy the URL.
Now we'll generate the client for the newly created service by referring the ?wsdl generated by the Axis2 Server. Open File -> New -> Other... -> Web Services -> Web ServiceClient
Paste the URL that was copied earlier into the service definition field.
Click on the Client project hyperlink and enter Axis2WSTestClient as the name of the client project. Click OK.
Back on the Web Services Client wizard, make sure the Web service runtime is set to Axis2 and the server is set correctly. Click Next.
Next page is the Client Configuration Page. Accept the defaults and click Finish.
The Clients stubs will be generated to your Dynamic Web project Axis2WSTestClient.
Now we are going to write Java main program to invoke the client stub. Import the ConverterClient.java file to the workspace into the wtp package in the src folder of Axis2WSTestClient.
Then select the ConverterClient file, right-click and select Run As -> Java Application. Here's what you get on the server console:
Another way to test and invoke the service is to select Generate test case to test the service check box on the Axis2 Client Web Service Configuration Page when going through the Web Service Client wizard.
If that option is selected, the Axis2 emitter will generate JUnit testcases matching the WSDL we provide to the client. These JUnit testcases will be generated to a newly added source directory to the Axis2WSTestClient project called test.
Next thing we need to do is to insert the testcase with the valid inputs as the Web servivce method arguments. In this case, let's test the ConverterConverterSOAP11Port_httpTest.java by provide values for Celsius and Farenheit for the temperature conversion. As an example, replace the generated TODO statement in each test method to fill in the data with values as:
testfarenheitToCelsius() -> farenheitToCelsius8.setFarenheit(212);
testStartfarenheitToCelsius() -> farenheitToCelsius8.setFarenheit(212);
testcelsiusToFarenheit() -> celsiusToFarenheit10.setCelsius(100);
testStartcelsiusToFarenheit() -> celsiusToFarenheit10.setCelsius(100);
Here the testcases were generated to test both the synchronous and asynchronous clients.
After that, select the testcase, right-click, select Run As -> JUnit Test. You will be able to run the unit test successfully invoking the Web service.
Summary
In this example, we show using the Web Services wizard followed by using the Web Service client wizard. You could also choose to generate both service and client using the Web Services wizard:
The Web Service wizard orchestrates the end-to-end generation, assembly, deployment, installation and execution of the Web service and Web service client. Now that your Web service is running, there are a few interesting things you can do with this WSDL file. Examples:
You can choose Web Services -> Test with Web Services Explorer to test the service.
You can choose Web Services -> Publish WSDL file to publish the service to a public UDDI registry.
Resources
You can also refer to the Axis Web services tutorials:
Using Web Service Explorer to test a Web service
Creating Bottom Up Web Service via Axis
Creating Top Down Web Service via Axis
Consuming Web service using Web Service Client via Axis
miércoles, 27 de enero de 2010
Usando certificados SSL de cliente como sistema de autenticación web
A menudo creamos aplicaciones web con un backend de gestión que, por ser también web, exponemos públicamente a cualquiera que consiga averiguar la URL. Habitualmente estos sistemas son de acceso restringido, sólo un pequeño grupo de usuarios lo utiliza.
En escenarios donde tenemos un número de usuarios acotado y se necesita autentificación, se puede utilizar un mecanismo de certificados que aporten mayor seguridad al sistema, de esta manera solo aquellos usuarios que tengan el certificado en cuestión tendrán acceso a la máquina.
Hoy veremos como permitir el acceso a nuestra aplicación a aquellos usuarios que dispongan de un certificado que previamente les habremos enviado mientras que si no lo tienen no podrán acceder de ningún modo. Este método se puede combinar, además, con el tradicional usuario/clave para dar mayor seguridad. Podremos incluso verificar que el nombre de usuario que se intenta utilizar se corresponde con el certificado de usuario que le hemos enviado y no intenta autentificarse con otro.
Conceptos básicos sobre certificados SSL
El método que vamos a ver se basa en certificados SSL. Se utilizan para asegurar la información entre un cliente y el servidor y prevenir escuchas ya que la información viaja encriptada. Ésta es su función y la hace aunque no esté firmado por una autoridad certificadora (CA) oficial o, incluso, aunque esté caducado. Sigue asegurando las comunicaciones.
Los navegadores web reconocen, por defecto, una serie de autoridades certificadoras como Verisign o Thawte, aunque hay muchas más. Puedes verlas todas en las opciones de tu navegador. Pero, ¿qué es realmente lo que hace una Autoridad Certificadora? Firmar. Firma tu certificado SSL asegurando que os pertenece a ti y a tu dominio. Cuando un cliente accede a tu dominio y descarga el certificado SSL, busca dentro de sus certificados de CA’s si hay alguno que lo haya firmado. Si lo encuentra, acepta tu certificado y no ocurre nada especial, pero si no encuentra la CA lanza un aviso indicando que no se reconoce la autoridad que lo firma. Esto no quiere decir que el certificado no sea válido, lo único que ocurre es que no sabe quien lo firma. Esto significa, por tanto, que tú mismo puedes ser tu propia autoridad certificadora y firmar tus certificados, funcionarán perfectamente y cumplirán su cometido de asegurar las comunicaciones cliente/servidor.
Comercialmente o en sistemas de acceso público en general, no se recomiendan certificados autofirmados ya que el aviso de autoridad de certificación no reconocida generará desconfianza entre tus usuarios, pero en entorno intranet o de paneles de adminsitración es un método ideal.
El servidor puede requerir, además, otro certificado al cliente, de manera que ámbos extremos autentifiquen la comunicación. Esto es precisamente lo que vamos a hacer hoy en este artículo.
Según lo que hemos explicado, los certificados autofirmados son igual de seguros que los firmados por una autoridad certificadora. Como en el ejemplo que estamos viendo estamos asegurando el acceso a nuestra aplicación para un grupo reducido de usuarios, no hay ningún problema en utilizar un certificado firmado por nosotros mismos ya que nuestros usuarios sabrán que no hay ningún problema. Pero esto no es todo, por esta misma razón podemos decir a los usuarios que se instalen el certificado público de nuestra CA, tal y como hacen las CA oficiales, y automáticamente el navegador comenzará a confiar en nuestros certificados ya que, ahora sí, tiene un certificado de una CA que firma los certificados SSL.
Como resumen, nuestro trabjo consistirá en:
Crear nuestra autoridad certificadora y su certificado.
Crear el certificado SSL para nuestro servidor web firmado por nuestra CA.
Crear los certificados de cliente para nuestros usuarios.
Habilitar la lectura de los datos SSL desde PHP.
Servidor web SSL
Utilizaremos el paquete Openssl para generar los certificados. Si aún no lo tienes instalado en tu servidor, es el momento. Explicaré de manera rápida como crear crear certificados SSL para asegurar las comunicaciones ya que es el primer paso necesario para añadir certificados de cliente, sin embargo no es el objeto principal de este artículo y hay mucha documentación, googlea un poco .
Primero creamos el certificado y la clave privada de nuestra autoridad de certificación:
openssl req -x509 -newkey rsa:2048 -days 3650 -keyout CAXplotaKey.pem -out CAXplotacert.pem
Lo más importante de este comando es el parámetro days, ya que no queremos que dentro de un año nos caduque el certificado de nuestra propia entidad. Yo le pongo 10 años. Este comando genera dos archivos, la clave privada con la que firmaremos nuestros futuros certificados y el certificado con la clave pública que instalaremos, si queremos no recibir avisos, en el navegador. Este comando te pedirá algunos datos (nombre de empresa, país…) y, sobre todo, una contraseña. Deberás recordarla cada vez que vayas a firmar un certificado SSL, así que no la olvides. Ya tenemos nuestra CA creada.
Creamos ahora el certificado SSL para nuestro dominio:
openssl genrsa -des3 -out claveprivada.pem 2048
openssl req -new -key claveprivada.pem -out certificado.pem
El primer comando crea la clave privada de nuestro certificado. Te pedirá otra contraseña, esta vez para la clave privada. Recuérdala también.
El segundo comando genera la petición de certificado sobre la clave privada anterior. Te pedirá la contraseña de la clave privada anterior.
En este punto tenemos cuatro archivos, la clave y el certificado de tu CA y la clave y la solicitud de tu certificado SSL. Sólo queda firmar el certificado con nuestra CA y ya podremos utilizarlo.
Para poder firmarlo debemos generar primero un fichero de texto con algunos parámetros de configuración:
cat configservidor.cnf
basicConstraints = critical,CA:FALSE
extendedKeyUsage = serverAuth
Y firmamos el certificado.
openssl x509 -CA CAXplotacert.pem -CAkey CAXplotaKey.pem -req -extfile configservidor.cnf -in certificado.pem -days 3650 -CAcreateserial -sha1 -out certificado-servidor.pem
Ya tenemos un certificado SSL preparado para utilizar en nuestro servidor web. En nuestro caso es certificado-servidor.pem. Vamos a configurar Apache para que lo utilice.
Habrá que editar httpd.conf y añadir
LoadModule ssl_module modules/mod_ssl.so
Listen 443
Es probable que, si no has compilado tu propio Apache y has instalado un paquete precompilado, tengas ya algún ssl.conf. Activándolo tendrás este paso preparado. En mi caso, un CentOS5, sólo hay que incluir /etc/httpd/conf.d/ssl.conf.
Finalmente hay que indicar en el virtual host que quieres asegurar que use nuestro nuevo certificado. Para hacerlo añadimos un nuevo virtual que escuche en el puerto 443 y añadimos las siguientes líneas:
SSLEngine on
SSLCertificateFile /ruta/a/certificado-servidor.pem
SSLCertificateKeyFile /ruta/a/claveprivada.pem
Si ahora reinicias Apache y accedes a tu dominio con https verás que en tu navegador aparece el candado indicando que la información es segura. Verás también que te aparece un aviso de que no se confía en la autoridad certificadora. Veremos más adelante como solucionarlo.
Añadiendo certificados de cliente
Ahora que ya tenemos nuestro servidor web seguro con nuestros certificado autofirmado llega el momento de crear certificados para nuestros clientes de manera que si alguien intenta acceder a nuestra aplicación sin uno de ellos se le prohíba el paso.
Crearemos primero un archivo de configuración con los parámetros que necesitaremos.
cat configcliente.cnf
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth
Con esto daremos instrucciones de que es un certificado cliente a la hora de firmar el certificado.
Creamos ahora, igual que hacíamos antes, la clave privada y la solicitud de certificado.
openssl genrsa -des3 -out clave-cliente.pem 2048
openssl req -new -key clave-cliente.pem -out certificado-cliente-req.pem
Como antes, al generar la clave te pedirá una contraseña que deberás introducir después, al hacer la solicitud de certificado. Los datos que te pide esta solicitud, como ocurría antes, los podrás leer posteriormente para comprobar datos o lo que estimes oportuno, así que es importante que prestes atención.
Firmamos ahora el certificado con nuestra CA:
openssl x509 -CA CAXplotacert.pem -CAkey CAXplotaKey.pem -req -in certificado-cliente-req.pem -days 3650 -extfile configcliente.cnf -CAcreateserial -sha1 -out certificado-cliente.pem
Como véis, el proceso es el mismo para generar el certificado de servidor, pero cambiamos el contenido del archivo de configuración que le indica que es un certificado cliente, no servidor.
Vale, bien, pero ¿no quedamos que es el cliente el que debe instalar el certificado? Sí, ahí vamos ahora. El certificado que acabamos de generar lo debes instalar en tu navegador web, no en el servidor, así que habrá que convertirlo a algún formato que puedan entender. Para esto hacemos lo siguiente:
openssl pkcs12 -export -in certificado-cliente.pem -inkey clave-cliente.pem -certfile CAXplotacert.pem -out cliente.p12
Nos pedirá la contraseña de la clave privada del certificado y nos solicitará otra para el que va a generar. Es importante poner contraseña al certificado final ya que es el que vas a enviar a tus usuarios y pretendes que sólo estos puedan utilizarlo, así que poner una contraseña nunca está demás.
Ya tienes tu certificado cliente.p12. Puedes probarlo tu mismo. Ah no, espera, que no hemos configurado el servidor web para que solicite sí o sí un certificado al cliente. Añade a la configuración SSL de tu virtual host de Apache:
SSLCACertificateFile /path/a/CAXplotacert.pem
SSLVerifyClient require
Y reinicia tu servidor web. Si ahora intentas acceder a tu dominio verás como salta una ventana solicitando un certificado que no tienes. Desde las opciones de tu navegador, busca la sección de certificados SSL y añade un nuevo certificado. Selecciona tu cliente.p12. Te pedirá la contraseña que pusiste al convertirlo a pk12. Ya está. Accede ahora y verás como te aparece el certificado en la ventana de certificiados disponibles y, si lo seleccionas, te deja acceder a tu aplicación.
Revocar certificados
A veces puede ser necesario prohibir el paso con determinados certificados, bien porque el usuario ya no colabora o trabaja contigo, bien porque hay posibilidades de que el certificado haya sido robado, etc. Una opción es, a la hora de crear el certificado, y si sabes de antemano que el usuario lo necesitará pocos días (cuenta de prueba, usuario esporádico o cualquier razón similar), generarlo con una validez limitada (10 días, un mes, etc.), de modo que pasado este tiempo el certificado caduca y el usuario no puede entrar. El problema más importante lo tendrás cuando necesites prohibir el acceso a usuarios con certificados a largo plazo. Para hacerlo debemos crear una lista de revocación de certificados.
En mi caso (CentOS5 y RHEL5) tuve algunos problemas de configuración. Openssl debería de mantener una lista de los certificados que emite y sus números de serie sin embargo tal como hemos generado nuestros certificados no lo hace. Para solucionarlo, creamos a mano la lista.
touch /etc/pki/CA/index.txt
Ahora debemos editar el archivo de configuración de Openssl para reflejar algunos parámetros. Por defecto indica una ruta relativa hacia los directorios donde dejará los certificados, pero no me funcionó bien hasta que no le puse rutas absolutas. Modificamos pues la ruta al directorio y le indicamos donde están la clave privada y el certificado de nuestra CA.
Editar /etc/pki/tls/openssl.cnf
dir = /etc/pki/CA # Where everything is kept
certificate = /path/a/CAXplotacert.pem # The CA certificate
private_key = /path/a/CAXplotaKey.pem # The private key
Ahora sí, podemos revocar un certificado de manera tan sencilla como:
openssl ca -revoke certificado-cliente.pem
A partir de la lista con el estado de los certificados debemos crear una lista de revocación que usaremos para indicar al servidor web los certificados que no debe permitir.
openssl ca -gencrl -out recovados.crl
Es posible que al lanzar este comando te apareza otro error relacionado con crlnumber. Esto viene relacionado con lo que os indicaba antes y es simplemente que no existe el archivo de números de serie. Para solucionarlo, simplemente lo creamos:
echo "01" > /etc/pki/CA/crlnumber
Y volvemos a generar la lista de revocación. Cada vez que revoques un certificado deberás repetir esta operación para tener la nueva lista.
Ya sólo falta indicarle a Apache qué certificados no debe permitir. Añadimos a la configuración de nuestro virtual host, en el mismo sitio donde configuramos anteriormente el certificado SSL, la siguiente línea:
SSLCARevocationFile path/a/revocados.crl
Eso es todo, ya tenemos nuestro servido SSL funcionando, nuestra aplicación protegida con certificados de cliente y la opción para revocar certificados.
Comprobando los certificados con PHP
Queremos ir un poco más allá. Queremos que, desde nuestra aplicación, podamos leer el certificado SSL del cliente y comprobar quién es. Seguro que a ti se te ocurren mejores cosas que hacer con estos datos . Lo primero que tendremos que hacer será configurar Apache para que pase los datos del certificado. En la configuración de tu virtual host añades:
SSLOptions +StdEnvVars +ExportCertData
Ya está. Si ahora haces un print_r($_SERVER) en la aplicación donde tienes instalado tu certificado SSL de cliente verás entre todos los datos algo como:
[SSL_CLIENT_S_DN] => /C=ES/ST=Valencia/L=Valencia/O=Osusnet/CN=blog.osusnet.com/emailAddress=osusENosusnet.com
[SSL_CLIENT_S_DN_C] => ES
[SSL_CLIENT_S_DN_ST] => Valencia
[SSL_CLIENT_S_DN_L] => Valencia
[SSL_CLIENT_S_DN_O] => Osusnet
[SSL_CLIENT_S_DN_CN] => blog.osusnet.com
[SSL_CLIENT_S_DN_Email] => osusENosusnet.com
Tienes toda la información que necesitas, son los datos que se solicitaban al crear la solicitud de certificado. Generando estos parámetros de manera adecuada podrás saber quién entra a tu aplicación a partir del certificado cliente que usa.
Eso es todo por hoy. De una manera muy sencilla hemos añadido un poco más de seguridad a una aplicación web de acceso privado y con un número de usuarios acotado. También hemos aprendido y poco más sobre certificados SSL y hemos visto cómo firmar nuestros propios certificados, igual de fiables que los comerciales. Espero que os sirva de algo .
Fte: http://blog.osusnet.com/2008/10/11/usando-certificados-ssl-de-cliente-como-sistema-de-autenticacion-web/
En escenarios donde tenemos un número de usuarios acotado y se necesita autentificación, se puede utilizar un mecanismo de certificados que aporten mayor seguridad al sistema, de esta manera solo aquellos usuarios que tengan el certificado en cuestión tendrán acceso a la máquina.
Hoy veremos como permitir el acceso a nuestra aplicación a aquellos usuarios que dispongan de un certificado que previamente les habremos enviado mientras que si no lo tienen no podrán acceder de ningún modo. Este método se puede combinar, además, con el tradicional usuario/clave para dar mayor seguridad. Podremos incluso verificar que el nombre de usuario que se intenta utilizar se corresponde con el certificado de usuario que le hemos enviado y no intenta autentificarse con otro.
Conceptos básicos sobre certificados SSL
El método que vamos a ver se basa en certificados SSL. Se utilizan para asegurar la información entre un cliente y el servidor y prevenir escuchas ya que la información viaja encriptada. Ésta es su función y la hace aunque no esté firmado por una autoridad certificadora (CA) oficial o, incluso, aunque esté caducado. Sigue asegurando las comunicaciones.
Los navegadores web reconocen, por defecto, una serie de autoridades certificadoras como Verisign o Thawte, aunque hay muchas más. Puedes verlas todas en las opciones de tu navegador. Pero, ¿qué es realmente lo que hace una Autoridad Certificadora? Firmar. Firma tu certificado SSL asegurando que os pertenece a ti y a tu dominio. Cuando un cliente accede a tu dominio y descarga el certificado SSL, busca dentro de sus certificados de CA’s si hay alguno que lo haya firmado. Si lo encuentra, acepta tu certificado y no ocurre nada especial, pero si no encuentra la CA lanza un aviso indicando que no se reconoce la autoridad que lo firma. Esto no quiere decir que el certificado no sea válido, lo único que ocurre es que no sabe quien lo firma. Esto significa, por tanto, que tú mismo puedes ser tu propia autoridad certificadora y firmar tus certificados, funcionarán perfectamente y cumplirán su cometido de asegurar las comunicaciones cliente/servidor.
Comercialmente o en sistemas de acceso público en general, no se recomiendan certificados autofirmados ya que el aviso de autoridad de certificación no reconocida generará desconfianza entre tus usuarios, pero en entorno intranet o de paneles de adminsitración es un método ideal.
El servidor puede requerir, además, otro certificado al cliente, de manera que ámbos extremos autentifiquen la comunicación. Esto es precisamente lo que vamos a hacer hoy en este artículo.
Según lo que hemos explicado, los certificados autofirmados son igual de seguros que los firmados por una autoridad certificadora. Como en el ejemplo que estamos viendo estamos asegurando el acceso a nuestra aplicación para un grupo reducido de usuarios, no hay ningún problema en utilizar un certificado firmado por nosotros mismos ya que nuestros usuarios sabrán que no hay ningún problema. Pero esto no es todo, por esta misma razón podemos decir a los usuarios que se instalen el certificado público de nuestra CA, tal y como hacen las CA oficiales, y automáticamente el navegador comenzará a confiar en nuestros certificados ya que, ahora sí, tiene un certificado de una CA que firma los certificados SSL.
Como resumen, nuestro trabjo consistirá en:
Crear nuestra autoridad certificadora y su certificado.
Crear el certificado SSL para nuestro servidor web firmado por nuestra CA.
Crear los certificados de cliente para nuestros usuarios.
Habilitar la lectura de los datos SSL desde PHP.
Servidor web SSL
Utilizaremos el paquete Openssl para generar los certificados. Si aún no lo tienes instalado en tu servidor, es el momento. Explicaré de manera rápida como crear crear certificados SSL para asegurar las comunicaciones ya que es el primer paso necesario para añadir certificados de cliente, sin embargo no es el objeto principal de este artículo y hay mucha documentación, googlea un poco .
Primero creamos el certificado y la clave privada de nuestra autoridad de certificación:
openssl req -x509 -newkey rsa:2048 -days 3650 -keyout CAXplotaKey.pem -out CAXplotacert.pem
Lo más importante de este comando es el parámetro days, ya que no queremos que dentro de un año nos caduque el certificado de nuestra propia entidad. Yo le pongo 10 años. Este comando genera dos archivos, la clave privada con la que firmaremos nuestros futuros certificados y el certificado con la clave pública que instalaremos, si queremos no recibir avisos, en el navegador. Este comando te pedirá algunos datos (nombre de empresa, país…) y, sobre todo, una contraseña. Deberás recordarla cada vez que vayas a firmar un certificado SSL, así que no la olvides. Ya tenemos nuestra CA creada.
Creamos ahora el certificado SSL para nuestro dominio:
openssl genrsa -des3 -out claveprivada.pem 2048
openssl req -new -key claveprivada.pem -out certificado.pem
El primer comando crea la clave privada de nuestro certificado. Te pedirá otra contraseña, esta vez para la clave privada. Recuérdala también.
El segundo comando genera la petición de certificado sobre la clave privada anterior. Te pedirá la contraseña de la clave privada anterior.
En este punto tenemos cuatro archivos, la clave y el certificado de tu CA y la clave y la solicitud de tu certificado SSL. Sólo queda firmar el certificado con nuestra CA y ya podremos utilizarlo.
Para poder firmarlo debemos generar primero un fichero de texto con algunos parámetros de configuración:
cat configservidor.cnf
basicConstraints = critical,CA:FALSE
extendedKeyUsage = serverAuth
Y firmamos el certificado.
openssl x509 -CA CAXplotacert.pem -CAkey CAXplotaKey.pem -req -extfile configservidor.cnf -in certificado.pem -days 3650 -CAcreateserial -sha1 -out certificado-servidor.pem
Ya tenemos un certificado SSL preparado para utilizar en nuestro servidor web. En nuestro caso es certificado-servidor.pem. Vamos a configurar Apache para que lo utilice.
Habrá que editar httpd.conf y añadir
LoadModule ssl_module modules/mod_ssl.so
Listen 443
Es probable que, si no has compilado tu propio Apache y has instalado un paquete precompilado, tengas ya algún ssl.conf. Activándolo tendrás este paso preparado. En mi caso, un CentOS5, sólo hay que incluir /etc/httpd/conf.d/ssl.conf.
Finalmente hay que indicar en el virtual host que quieres asegurar que use nuestro nuevo certificado. Para hacerlo añadimos un nuevo virtual que escuche en el puerto 443 y añadimos las siguientes líneas:
SSLEngine on
SSLCertificateFile /ruta/a/certificado-servidor.pem
SSLCertificateKeyFile /ruta/a/claveprivada.pem
Si ahora reinicias Apache y accedes a tu dominio con https verás que en tu navegador aparece el candado indicando que la información es segura. Verás también que te aparece un aviso de que no se confía en la autoridad certificadora. Veremos más adelante como solucionarlo.
Añadiendo certificados de cliente
Ahora que ya tenemos nuestro servidor web seguro con nuestros certificado autofirmado llega el momento de crear certificados para nuestros clientes de manera que si alguien intenta acceder a nuestra aplicación sin uno de ellos se le prohíba el paso.
Crearemos primero un archivo de configuración con los parámetros que necesitaremos.
cat configcliente.cnf
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth
Con esto daremos instrucciones de que es un certificado cliente a la hora de firmar el certificado.
Creamos ahora, igual que hacíamos antes, la clave privada y la solicitud de certificado.
openssl genrsa -des3 -out clave-cliente.pem 2048
openssl req -new -key clave-cliente.pem -out certificado-cliente-req.pem
Como antes, al generar la clave te pedirá una contraseña que deberás introducir después, al hacer la solicitud de certificado. Los datos que te pide esta solicitud, como ocurría antes, los podrás leer posteriormente para comprobar datos o lo que estimes oportuno, así que es importante que prestes atención.
Firmamos ahora el certificado con nuestra CA:
openssl x509 -CA CAXplotacert.pem -CAkey CAXplotaKey.pem -req -in certificado-cliente-req.pem -days 3650 -extfile configcliente.cnf -CAcreateserial -sha1 -out certificado-cliente.pem
Como véis, el proceso es el mismo para generar el certificado de servidor, pero cambiamos el contenido del archivo de configuración que le indica que es un certificado cliente, no servidor.
Vale, bien, pero ¿no quedamos que es el cliente el que debe instalar el certificado? Sí, ahí vamos ahora. El certificado que acabamos de generar lo debes instalar en tu navegador web, no en el servidor, así que habrá que convertirlo a algún formato que puedan entender. Para esto hacemos lo siguiente:
openssl pkcs12 -export -in certificado-cliente.pem -inkey clave-cliente.pem -certfile CAXplotacert.pem -out cliente.p12
Nos pedirá la contraseña de la clave privada del certificado y nos solicitará otra para el que va a generar. Es importante poner contraseña al certificado final ya que es el que vas a enviar a tus usuarios y pretendes que sólo estos puedan utilizarlo, así que poner una contraseña nunca está demás.
Ya tienes tu certificado cliente.p12. Puedes probarlo tu mismo. Ah no, espera, que no hemos configurado el servidor web para que solicite sí o sí un certificado al cliente. Añade a la configuración SSL de tu virtual host de Apache:
SSLCACertificateFile /path/a/CAXplotacert.pem
SSLVerifyClient require
Y reinicia tu servidor web. Si ahora intentas acceder a tu dominio verás como salta una ventana solicitando un certificado que no tienes. Desde las opciones de tu navegador, busca la sección de certificados SSL y añade un nuevo certificado. Selecciona tu cliente.p12. Te pedirá la contraseña que pusiste al convertirlo a pk12. Ya está. Accede ahora y verás como te aparece el certificado en la ventana de certificiados disponibles y, si lo seleccionas, te deja acceder a tu aplicación.
Revocar certificados
A veces puede ser necesario prohibir el paso con determinados certificados, bien porque el usuario ya no colabora o trabaja contigo, bien porque hay posibilidades de que el certificado haya sido robado, etc. Una opción es, a la hora de crear el certificado, y si sabes de antemano que el usuario lo necesitará pocos días (cuenta de prueba, usuario esporádico o cualquier razón similar), generarlo con una validez limitada (10 días, un mes, etc.), de modo que pasado este tiempo el certificado caduca y el usuario no puede entrar. El problema más importante lo tendrás cuando necesites prohibir el acceso a usuarios con certificados a largo plazo. Para hacerlo debemos crear una lista de revocación de certificados.
En mi caso (CentOS5 y RHEL5) tuve algunos problemas de configuración. Openssl debería de mantener una lista de los certificados que emite y sus números de serie sin embargo tal como hemos generado nuestros certificados no lo hace. Para solucionarlo, creamos a mano la lista.
touch /etc/pki/CA/index.txt
Ahora debemos editar el archivo de configuración de Openssl para reflejar algunos parámetros. Por defecto indica una ruta relativa hacia los directorios donde dejará los certificados, pero no me funcionó bien hasta que no le puse rutas absolutas. Modificamos pues la ruta al directorio y le indicamos donde están la clave privada y el certificado de nuestra CA.
Editar /etc/pki/tls/openssl.cnf
dir = /etc/pki/CA # Where everything is kept
certificate = /path/a/CAXplotacert.pem # The CA certificate
private_key = /path/a/CAXplotaKey.pem # The private key
Ahora sí, podemos revocar un certificado de manera tan sencilla como:
openssl ca -revoke certificado-cliente.pem
A partir de la lista con el estado de los certificados debemos crear una lista de revocación que usaremos para indicar al servidor web los certificados que no debe permitir.
openssl ca -gencrl -out recovados.crl
Es posible que al lanzar este comando te apareza otro error relacionado con crlnumber. Esto viene relacionado con lo que os indicaba antes y es simplemente que no existe el archivo de números de serie. Para solucionarlo, simplemente lo creamos:
echo "01" > /etc/pki/CA/crlnumber
Y volvemos a generar la lista de revocación. Cada vez que revoques un certificado deberás repetir esta operación para tener la nueva lista.
Ya sólo falta indicarle a Apache qué certificados no debe permitir. Añadimos a la configuración de nuestro virtual host, en el mismo sitio donde configuramos anteriormente el certificado SSL, la siguiente línea:
SSLCARevocationFile path/a/revocados.crl
Eso es todo, ya tenemos nuestro servido SSL funcionando, nuestra aplicación protegida con certificados de cliente y la opción para revocar certificados.
Comprobando los certificados con PHP
Queremos ir un poco más allá. Queremos que, desde nuestra aplicación, podamos leer el certificado SSL del cliente y comprobar quién es. Seguro que a ti se te ocurren mejores cosas que hacer con estos datos . Lo primero que tendremos que hacer será configurar Apache para que pase los datos del certificado. En la configuración de tu virtual host añades:
SSLOptions +StdEnvVars +ExportCertData
Ya está. Si ahora haces un print_r($_SERVER) en la aplicación donde tienes instalado tu certificado SSL de cliente verás entre todos los datos algo como:
[SSL_CLIENT_S_DN] => /C=ES/ST=Valencia/L=Valencia/O=Osusnet/CN=blog.osusnet.com/emailAddress=osusENosusnet.com
[SSL_CLIENT_S_DN_C] => ES
[SSL_CLIENT_S_DN_ST] => Valencia
[SSL_CLIENT_S_DN_L] => Valencia
[SSL_CLIENT_S_DN_O] => Osusnet
[SSL_CLIENT_S_DN_CN] => blog.osusnet.com
[SSL_CLIENT_S_DN_Email] => osusENosusnet.com
Tienes toda la información que necesitas, son los datos que se solicitaban al crear la solicitud de certificado. Generando estos parámetros de manera adecuada podrás saber quién entra a tu aplicación a partir del certificado cliente que usa.
Eso es todo por hoy. De una manera muy sencilla hemos añadido un poco más de seguridad a una aplicación web de acceso privado y con un número de usuarios acotado. También hemos aprendido y poco más sobre certificados SSL y hemos visto cómo firmar nuestros propios certificados, igual de fiables que los comerciales. Espero que os sirva de algo .
Fte: http://blog.osusnet.com/2008/10/11/usando-certificados-ssl-de-cliente-como-sistema-de-autenticacion-web/
martes, 12 de enero de 2010
Servicios Web en Java I
Web que explica como realizar un servicio Web en Java.
Fte: http://emilio.aesinformatica.
viernes, 8 de enero de 2010
Software por la patilla
Fte: http://rafinguer.blogspot.com/
"Software por la patilla"
- Raticos tecnológicos: Software por la patilla (ver en Google Sidewiki)
Suscribirse a:
Entradas (Atom)