Cuando las máquinas sustituyeron a la política

0saves

La política es para dioses o para máquinas. ¿Qué es aquello que tendrían que hacer los políticos y en lo que todos coincidimos? Gestionar el dinero público. ¿Pueden las personas tener autogobierno al margen de los políticos? ¿Pueden las máquinas sustituir las funciones políticas, del mismo modo que han ido sustituyendo al ser humano desde hace 200 años? Dicho más suavemente, ¿se puede reducir el poder de los políticos al mínimo posible, utilizando ordenadores? Desde luego no se ha intentado.

Los regímenes democráticos que tenemos hoy en día fueron pensados en épocas en las que no existían máquinas que realizan millones de cálculos por segundo, todas unidas en milisegundos por una red mundial como es Internet y estándares de seguridad para Autenticación, Firma electrónica, Confidencialidad y Disponibilidad. Parece que ha llovido bastante. Ahora tenemos las Redes Sociales, que han demostrado su poder, y todavía no hemos visto nada en telecomunicaciones ya que las Redes de Nueva Generación proporcionarán una conectividad y movilidad a las personas jamás conocida hasta el momento.

Esto no es un partido político. Existen partidos hoy en día que son muy 2.0 (sociales) en el sentido en que se comprometen a llevar al parlamento aquello se que vote electrónicamente por Internet. Tampoco es 100% una aplicación de eDemocracia, es más, un 200%. Lee Argumentos en favor de la eDemocracia o Democracia Electrónica. Se propone aquí, la programación informática y a gran escala de Presupuestos Generales para una población cualquiera. Podría ser una evolución de Aplicación web para la gestión directa de impuestos, ya que esta aplicación que hice en la universidad básicamente cumple la función de foro o Red Social entre ciudadanos y empresas, pero no entra para nada en el aspecto económico. Lo que se describe en este post es la parte complementaria, una aplicación informática que automatice operaciones económicas muy sencillas en base a votos o dicho de otro modo, implementar una economía informatizada para la gestión del dinero público.

Tampoco es como en Matrix. Es algo mucho más sencillo. Cualquier programador puede programar una aplicación que gestione la economía de un hogar. La entrada del programa son ingresos y gastos. La salida del programa es un presupuesto. Tanto la lista de ingresos como la de gastos es generada por las personas afectadas mediante un menú. Nada más fácil. Los imprevistos no son problema. La simulación en base a unos valores tampoco es problema. La conexión con Redes Sociales tampoco es un problema. El uso del DNI electrónico o DNIe tampoco. El uso de prioridades tampoco.

Mi objetivo no es lucrarme, lee el texto de la licencia al final de esta entrada. Una aplicación como ésta tiene que ser en software libre, porque si no perdería su sentido. Con software libre, todo el mundo tiene acceso al código del programa y ver lo que sucede. Por otra parte aunque me gusta programar, lo mío no es el desarrollo de software así que si no viene alguien y patenta este software, colaboraré en la parte de votación electrónica. Puede parecer una treta: “haces una aplicación que domine el mundo y luego me dedico a la parte de seguridad…muy listo” :)  o también “haces una aplicación que domine el mundo para que dependa de mi $oftware…muy listo”, sin embargo te comento que el software libre es tal porque está libre de patentes y es de código abierto, es decir todo el mundo tiene acceso al código del programa, puede modificarlo y distribuirlo.

Tampoco es un plan para que los informáticos dominen el mundo porque técnicamente los informáticos ya dominan el mundo (vale, controlan pero no dominan). El objetivo principal es investigar si todo esto es posible y, si no sustituir, reducir el poder de los políticos al mínimo posible. El objetivo secundario es darme publicidad, lo siento, pero vivimos en un mundo real.

Esto debería ser el embrión o anuncio de un Proyecto de Software Libre que todavía no tiene nombre ni la mayor parte de requisitos técnicos. Serán necesarias colaboraciones principalmente en el área de economía, matemáticas y estadística, y a lo mejor algo de inteligencia artificial y minería de datos. Por supuesto desarrolladores de todo tipo y en general quien quiera. Espero ansiosamente ideas de los demás. Hasta donde llega mi análisis de ducha, los requisitos de una aplicación como ésta son los siguientes.

Ecuación fundamental de funcionamiento

 Presupuesto = Ingreso – Gasto

Sí, es tan fácil que parece una broma, ¿cómo no se me había ocurrido antes?. Gracias J. L. Balbás. Tanto los ingresos como los gastos pueden ser generados a través de un menú y en tiempo real por las personas, como es natural en un mundo informatizado. Ej: en la plataforma Prestashop, para tiendas online, yo puedo crear tranquilamente un impuesto, con su porcentaje, y aplicado a productos o categorías.

El mecanismo final para llevarlo a cabo es la votación electrónica y probablemente la simulación en base a valores. La simulación es para que las personas puedan ver el efecto de una operación económica o de una previsión, por ejemplo de paro o recesión, o de la aplicación de un impuesto.

Ingresos

La parte de ingresos la forma principalmente un conjunto de impuestos asociadas a “cosas” como nóminas, productos y actividades comerciales. A saber, impuestos como el IRPF, IVA etc. Estas retenciones deben ser creadas fácilmente desde un interfaz gráfico, del mismo modo que se hacen cosas similares a diario en las aplicaciones. La forma de crear una retención concreta y final (la que se aplica) sería el resultado de la votación electrónica de todos los ciudadanos implicados. La más votada o quizá la media de todas.

Por otra parte en algunos casos es posible que la retención sea creada, sugerida o simulada automáticamente es decir, dado un gasto, el programa puede por ejemplo calcular la distribución ideal (en base a criterios) de IRPF para cubrir ese gasto en la población. Se pueden tener en cuenta también valores de previsión económica como paro, recesión, inflación….etc. También pueden ser pre-diseñadas por programa y ofrecidas al usuario.

Quedaría por ver qué clase de rentenciones y sobre qué productos o conceptos se aplica. Aquí entran en juego más aspectos puros de Economía que desconozco y reclamo. Además hay que ver si se utilizan los ingresos del año anterior, del mes anterior o lo que sea.

Gastos

La parte de gastos la forma principalmente los gastos que tenga la población, como la prestación de servicios públicos. Estos gastos pueden ser creados con la misma filosofía desde un interfaz gráfico. Ya que en general los presupuestos pocas veces se cumplen a rajatabla, nada impide crear nuevas retenciones o eliminar gastos en tiempo real. Además como mencioné antes, entre otras virguerías, dado un gasto se podría calcular la distribución de impuestos en la población, o por ejemplo hacerlo en función de valores como recesión económica o paro laboral.

La forma de crear un gasto concreto y final sería la misma que en los ingresos, la más votada, la media, la mediana, la que mejor optimice los recursos…

Independencia de la ideología

Observar detenidamente cómo un programa así es independiente de la ideología, ya que se limita a automatizar operaciones económicas en base a votos y previsiones y con la ayuda de simulaciones. De hecho, es posible que haya módulos preconfigurados, por ejemplo con 18% de IVA, el IRPF que sea….etc. De hecho, es posible incluso que estos valores se autoajusten según otros valores, por ejemplo de recesión, paro o edad de la población.

Es posible también que existan módulos adaptados a una ideología, por ejemplo liberal (con pocos impuestos) o comunista (donde si no me equivoco, tu nómina pertenece al estado). De hecho, puede ser que existan módulos adaptados a una estructura de población, por ejemplo Estado Autonómico, donde tanto los ingresos como los gastos estén repartidos jerárquicamente según unas competencias, las cuales también podrían ser asignadas mediante menús.

No sé si reirme o llorar.

Posibles mecanismos de interactuación con el programa

  • Mediante una aplicación web en cualquier lenguaje.
  • Mediante una aplicación de escritorio o móvil que sea descargable.
  • Mediante Redes Sociales: por ejemplo, debería poderse tomar votos a partir de mensajes en Twitter, algo como un hashtag que haga referencia a la propuesta de gasto o ingreso y con el texto “Sí” en el contenido.
  • Mediante aplicaciones residentes en dispositivos específicos para votación. Del mismo modo que hoy cuando vas a votar hay cabinas contiguas, puede haber máquinas con un teclado y una pantalla, que permita a las personas de menos habilidad informática realizar todo esto. Algo como los Puntos de Actualización del DNIe.

En todos los casos debe haber previa autenticación (en cada uso o regularmente) con DNI electrónico y/o certificado Ceres-FNMT, ¿o incluso algo como PGP?.

La clave del éxito

La clave del éxito está en ponérselo fácil a las personas. Supongamos que Pepe se descarga la aplicación en su móvil. El manejo de la aplicación tiene que ser lo más sencillo posible. Es necesario traducir las partidas presupuestarias a un lenguaje llano y fácil de entender, así como abstraer de todo lo que no sea estrictamente necesario, principalmente aspectos técnico-económicos. Que las personas puedan fácilmente decidir lo que hacen con su dinero. De hecho, cuanto menos tiempo haya que dedicarle mejor. Todo lo que pueda ser automatizado debe ser automatizado. Puede ser incluso que el uso de la aplicación sea de unas horas o minutos pero sólo (por ejemplo) cada 4 años, o a final de mes :) o (por ejemplo) cada vez que el paro aumente o disminuya el 1% de la población activa.

La información es clave y la colaboración también. Al margen del plano técnico y para que nos entendamos, conozco personalmente y tengo familiares funcionarios. Algunos incluso llevan hasta 40 años ejerciendo. Todos y cada uno de ellos saben qué es lo que sobra en su trabajo. Por otra parte tenemos Jueces, Policías, Colegios Profesionales y otras cosas que ni siquiera conozco. No digo que podamos olvidarnos al 100% de los políticos, yo creo que en el mundo en que vivimos es necesario un mínimo de representación por lo menos hacia el exterior. Sólo digo que la democracia que conocemos hoy en día fue diseñada en tiempos donde no existían tantos recursos tecnológicos, y que un buen porcentaje de lo dicho aquí puede ser llevado a cabo. Si crees que nada de esto es posible, es que no vives en el siglo XXI. Te quedaste en los 80, lo siento :)

Otras lucubraciones de ducha

No tiene por qué valer sólo para gestionar dinero. Las leyes pueden ser generadas con este mismo sistema, los abogados del estado (o quien sea) pueden legislar las propuestas que hayan sido aprobadas por las personas a través de este supermegaprograma. A saber, reformas del código penal etc. Son tantas cosas que…y en realidad en este caso nada es nuevo, ya que cualquier foro cumple los requisitos técnicos.

-

Este artículo tiene licencia Creative Commons (Reconocimiento-No comercial-Compartir igual). Lo suyo es que este proyecto esté sujeto a una licencia Creative Commons (Reconocimiento-No comercial-Compartir igual).

Argumentos en favor de la eDemocracia o Democracia Electrónica

0saves

¿Qué es la eDemocracia o Democracia Electrónica? Esto es algo relativamente nuevo y básicamente consiste en referendos vía Internet, extendiendo así la democracia a algo más que una vez cada cuatro años. Es indudable que ideas similares al DNI electrónico o DNIe serán utilizados en una eDemocracia y por ello encaja en esta web. Los principales argumentos en contra de algo tan bonito pueden ser:

  • Posibilidad de fraude
  • La gente no está preparada
  • Barrera tecnológica

Vamos a ver…

Posibilidad de fraude

Nada más fácil de rebatir. Tendrás que esforzarte más. ¿Quién nos dice que el sistema actual es limpio?¿Acaso no existen pucherazos hoy? Por otra parte, existen el software libre, los notarios, jueces e incluso la Brigada de Investigación Tecnológica de la Policía. Del mismo modo se pueden contratar a los mejores hackers al igual que hacen las mejores empresas.

Por otra parte, en Internet existen  miles de millones de servidores, sin embargo los ataques exitosos se dan una vez cada lustro. Además estos ataques suelen ser consecuencia de errores humanos tales como software desactualizado o mal configurado, o también simples despistes. Entre el 80-90% (si no recuerdo mal) de los servidores web del mundo están soportados por plataformas de software libre y no parece que pase nada. También existen estándares de seguridad mundial que usamos a diario.

La gente no está preparada

Vas mejorando, pero yo no soy sociólogo. El principal contra-argumento que se me ocurre es que la eDemocracia no es una utopía, sino un camino que se puede ir haciendo poco a poco. Podemos empezar por votar cositas pequeñas.

Barrera tecnológica

De acuerdo, el DNIe no es que funcione muy bien, y además no todo el mundo se mueve con soltura en Internet. El principal contra-argumento de nuevo es que la eDemocracia no es una utopía, sino un camino que se puede ir haciendo poco a poco. Podemos empezar por votar cositas pequeñas.

 

Espero que haya gustado este post. Si ves que sí, te recomiendo echar un ojo a Aplicación web para la gestión directa de impuestos.

Aplicación Cliente/Servidor en Java SSL con el DNIe

0saves

Te recomiendo que pruebes el servicio de Soporte Online.

Esta entrada enlaza y comenta brevemente una práctica que realicé en la universidad. Puedes descargarla aquí. Es una aplicación en Java con el API SSL sobre VM1.6 que realiza una conexión SSL haciendo uso del DNI electrónico (DNIe) y también certificados Ceres-FNMT. Es decir, no estamos configurando ningún servicio, sino que vamos a implementar directamente un servicio, en este caso un servicio muy básico. Tras la conexión se presenta al cliente un menú donde puede ver el contenido de su certificado. Además el servidor es concurrente multithread, con control del número máximo de hilos y control de variables que necesitan exclusión mutua. Por otra parte, se ve cómo Crear un KeyStore de servidor Java para el DNIe.

 

Aplicación Web de eDemocracia con PHP y el DNIe

0saves

Te recomiendo que pruebes el servicio de Soporte Online.

Esta entrada enlaza y comenta brevemente una práctica que hice en una asignatura y que da la casualidad de que está publicada en la web del departamento junto con las de los otros alumnos. Se trata de la Aplicación web para la gestión directa de impuestos. Es una aplicación Web en PHP, Apache y MySQL a modo de red social entre ciudadanos y poderes públicos y privados, que se conectan a la web con el DNI electrónico o DNIe y también con certificados Ceres-FNMT. Como aplicación informática es mala pero sinceramente….mola.

Su mayor utilidad para el lector es que se describe cómo configurar un Servidor Web Apache con acceso DNIe y también cómo acceder en lenguaje PHP a las variables de sesión SSL y realizar la Validación OCSP del DNIe en PHP y Apache con el Responder de la Dirección General de la Policía. Además hace uso de los certificados Ceres-FNMT aunque en este caso no se realiza la validación OCSP por ser un servicio de pago.

La idea es que las empresas se conectan con certificados Ceres-FNMT y los ciudadanos con el DNI electrónico o también con los de Ceres-FNMT. Los ciudadanos enuncian, comentan y votan propuestas (ej: hace falta una carretera), mientras que las empresas proponen ofertas a esa propuesta (ej: un presupuesto). Estas ofertas también son votadas, conformando todo ello un proceso eDemocrático básico y sin demasiadas complicaciones. Está todo programado desde 0, sin ningún tipo de escalabilidad ni reutilización de código, por lo que en un escenario real esta aplicación no puede ser desplegada a no ser que quieras torturar tu mente.

 

Acceso WiFi con el DNIe

0saves

Te recomiendo que pruebes el servicio de Soporte Online.

Esta entrada enlaza y comenta brevemente mi Proyecto Fin de Carrera Sistema de Control de Acceso en Redes Wireless con el DNI electrónico. Sistema de control de acceso en redes WiFi implementado con software libre y con el DNI electrónico (DNIe) como dispositivo de autenticación de cliente. Servidor en Debian 4 (Etch) y clientes en Debian 4 y Windows XP Service Pack 3. Está publicado en formato escrito en EAE-publishing con ISBN 978-3-8443-4649-7 y a la venta en al menos los siguientes enlaces:

Además está premiado con un accésit, en los Premios 2009 a los mejores Proyectos Fin de Carrera en el área de la Seguridad en la Información y en las Comunicaciones, de la Cátedra UPM Applus+ de Seguridad y Desarrollo de la Sociedad de la Información. La versión escrita contiene el apéndice A, donde se mencionan las más jugosas actualizaciones y bugs corregidos del software utilizado en el proyecto, principalmente FreeRADIUS y wpa_supplicant. Además, se describen de forma muy amigable y con dibujos incluidos los principales estándares de seguridad en el sector, así como métodos y herramientas utilísimas tanto para principiantes como para especialistas. Puedes descargar la presentación que realicé en su momento aquí.

 

Servidor Web Apache con acceso DNIe

0saves

Te recomiendo que pruebes el servicio de Soporte Online.

En esta ocasión vamos a ver cómo configurar un servidor web Apache de toda la vida para autenticar usuarios con el DNI electrónico o DNIe y si se quiere también los certificados Ceres-FNMT. Se va a hacer bajo plataforma Windows XP Service Pack 3.

 

Si utilizas una versión de Apache mayor o igual que 2.3.x no es necesario que hagas la Validación OCSP del DNIe en PHP y Apache, ya que se puede hacer desde el fichero de configuración. Por otra parte si también aceptas certificados de otras autoridades como Ceres-FNMT lo más fácil es hacer la validación OCSP en PHP porque la configuración del servidor se complicaría teniendo un host virtual por cada autoridad certificadora, en ese caso 2.

 

Actualmente la última versión estable de Apache es 2.2.x por lo que descargaríamos el siguiente fichero, que ya viene junto con OpenSSL:

httpd-2.2.19-win32-x86-openssl-0.9.8r.msi

Durante la sencilla instalación nos pedirá:

  • El nombre del dominio, en este caso aplicacionesdnielectronico.com o por el contrario localhost
  • El nombre del servidor, en este caso www.aplicacionesdnielectronico.com o por el contrario localhost
  • El email del administrador del servidor

En lo demás podemos dejar las opciones por defecto. Terminada la instalación, deberíamos ver la página de bienvenida de Apache con el texto “It works!” tecleando la siguiente URL en el navegador, si instalamos en localhost:

http://localhost/

A continuación procederemos a configurar el servidor seguro. Antes de nada necesitamos hacer dos cosas:

  • Crear una autoridad certificadora: generar certificado de autoridad y certificado de servidor. Este certificado de autoridad debe ser instalado en los navegadores o saltará una alerta a los usuarios del tipo “Está seguro de querer ir a esta página?”. El certificado y clave de servidor deberá ser configurado únicamente en el servidor Apache. En este caso se tiene el certificado en apache.crt y la clave privada en apache.key.
  • Descargar el certificado de Autoridad Raíz de la Dirección General de la Policía (DGP) ACRAIZ-SHA1.crt de la siguiente web. Con apache no necesitamos los certificados de autoridad intermedia porque éstos ya se encuentran en el DNIe junto con el certificado de ciudadano, por lo que apache puede cogerlos de la sesión SSL:

http://www.dnielectronico.es/seccion_integradores/certs.html

 

Para configurar el servidor seguro primero hay que indicar precisamente eso, que lo queremos. Bajo el directorio de instalación, localizamos el fichero de configuración general conf\httpd.conf y descomentamos (quitamos la “#”) la siguiente línea:

#LoadModule ssl_module modules/mod_ssl.so

A continuación pasamos a configurar el servidor seguro propiamente dicho, editando el fichero conf\extra\httpd-ssl.conf y dejando exactamente todo como estaba, excepto lo que se mencione aquí. Primero, la ruta al certificado de servidor creado:

SSLCertificateFile “C:/apache/conf/apache.crt”

Luego la ruta a la clave privada correspondiente. Si ésta está protegida con contraseña, la pedirá al inicio del arranque del servidor:

SSLCertificateKeyFile “C:/apache/conf/apache.key”

Si vamos a realizar la Validación OCSP del DNIe en PHP y Apache tenemos que añadir exactamente lo siguiente justo antes (o también dentro) de la directiva FilesMatch, para que se exporten los certificados en formato PEM dentro de las variables de sesión SSL:

SSLOptions +ExportCertData

Abajo del todo, descomentar la siguiente línea, para incluir la configuración SSL:

#Include conf/extra/httpd-ssl.conf

Hecho todo esto y rearrancado el servidor, deberíamos ver la misma página de bienvenida pero esta vez tecleando lo siguiente:

https://localhost/

A continuación introduciremos lo necesario para autenticar usuarios con el DNIe. Pasamos a editar el fichero conf\extra\httpd-ssl.conf. Primero configuramos el certificado Autoridad Raíz de la Dirección General de la Policía (DGP) ACRAIZ-SHA1.crt con la directiva siguiente:

SSLCACertificateFile “C:/apache/conf/ACRAIZ-SHA1.crt”

Si nos diese algún problema, puede que tengamos que poner el certificado en formato PEM. Para convertir el certificado ACRAIZ-SHA1.crt a formato PEM se utiliza el siguiente comando:

openssl x509 -inform DER -in ACDNIE001-SHA1.crt -outform PEM -out ACDNIE001 SHA1.pem

NOTA: Si da error, quitar la opción “-inform DER”

Después requeriremos certificado de cliente descomentando la siguiente directiva:

#SSLVerifyClient require

Hecho todo esto, no tenemos más que introducir la misma URL del servidor seguro, introducir el PIN y seleccionar el Certificado de Autenticación del DNIe.

 

Si además de esto queremos que sólo una parte de los usuarios de DNIe entren a nuestro servidor, podemos utilizar un “minilenguaje” que trae Apache en la directiva SSLRequire, donde podemos filtrar en función de diversas variables en el servidor, como por ejemplo el Common-Name del certificado. Esto también podemos hacerlo a través de PHP.

 

Validación OCSP nativa de Apache

Si utilizas una versión de Apache mayor o igual que 2.3.x no es necesario que hagas la Validación OCSP del DNIe en PHP y Apache, ya que se puede hacer desde el fichero de configuración. Para ello primero activamos la configuración OCSP con la directiva:

SSLOCSPEnable on

Después indicamos la URL

SSLOCSPDefaultResponder http://ocsp.dnielectronico.es/

 

Crear un KeyStore de servidor Java para el DNIe

0saves

Te recomiendo que pruebes el servicio de Soporte Online.

En esta entrada veremos cómo crear un almacén de claves en Java, comúnmente conocido como keystore. Este fichero nos servirá para autenticar clientes con el DNI electrónico o DNIe y dado el caso, si queremos también con certificados de la Fábrica Nacional de Moneda y Timbre – Real Casa de la Moneda, FNMT – RCM o simplemente Ceres-FNMT. El fichero utilizado podrá ser utilizado en principio en cualquier servidor Java como puede ser un Tomcat, JBoss, o una aplicación cliente/servidor programada a mano, pero siempre en el lado del servidor. Si lo que quieres es acceder al DNIe en una aplicación de escritorio o por otra parte acceder en “modo cliente”, lo que necesitas es ver la configuración del cliente en Aplicación Cliente/Servidor en Java SSL con el DNIe.

 

Por otra parte si pensabas crear un KeyStore para “almacenar” el DNIe debes saber que nuestra clave privada de ciudadano nunca sale de la tarjeta para que no se pueda duplicar. Esto es así gracias al estándar PKCS#11.

 

Antes de nada, es necesario descargar e instalar el JDK, en este caso el 1.6 para estar a la última:

jdk-6u26-windows-i586.exe

Lo instalamos por ejemplo en la siguiente carpeta:

C:\Archivos de programa\Java\jdk1.6.0_26\

Pasamos a generar el certificado de servidor. Dejaremos el alias por defecto “mykey” para el acceso al clave del servidor, y como contraseña la misma que la del almacén. Nos posicionamos bajo el subdirectorio bin/ y tecleamos:

bin>keytool -genkey -keystore almacenClaves -keyalg RSA

Obtendremos una salida como la siguiente, donde se nos pedirá la contraseña para el almacén, y una serie de datos para el certificado de servidor:

Escriba la contraseña del almacen de claves:

Volver a escribir la contraseña nueva:

Cuales son su nombre y su apellido?

[Unknown]:  Sergio Yebenes

Cual es el nombre de su unidad de organizacion?

[Unknown]:  Casa

Cual es el nombre de su organizacion?

[Unknown]:  Casa

Cual es el nombre de su ciudad o localidad?

[Unknown]:  Madrid

Cual es el nombre de su estado o provincia?

[Unknown]:  Madrid

Cual es el codigo de pais de dos letras de la unidad?

[Unknown]:  ES

Es correcto CN=Sergio Yebenes, OU=Casa, O=Casa, L=Madrid, ST=Madrid, C=ES?

[no]:  si

 

Escriba la contraseña clave para <mykey>

(INTRO si es la misma contraseña que la del almacen de claves):

Tras pulsar Enter ya se tiene el certificado y clave de servidor en almacenClaves. A continuación vamos a importar el Certificado de Autoridad Raíz de la DGP, concretamente el fichero ACRAIZ-SHA1.crt. Lo descargamos de la siguiente web:

http://www.dnielectronico.es/seccion_integradores/certs.html

Importamos con el siguiente comando. Vemos y memorizamos que ponemos un alias “DNIraiz” a este certificado:

bin>keytool -keystore almacenClaves -import -alias DNIraiz -file ACRAIZ-SHA1.crt

Obtendremos la siguiente salida y responderemos si al final.

Escriba la contraseña del almacen de claves:

Propietario: CN=AC RAIZ DNIE, OU=DNIE, O=DIRECCION GENERAL DE LA POLICIA, C=ES

Emisor: CN=AC RAIZ DNIE, OU=DNIE, O=DIRECCION GENERAL DE LA POLICIA, C=ES

Numero de serie: d28570fdaea7d65f118415c631b5cb

Valido desde: Thu Feb 16 11:37:25 CET 2006 hasta: Fri Feb 08 23:59:59 CET 2036

Huellas digitales del certificado:

MD5:  15:5E:F5:11:7A:A2:C1:15:0E:92:7E:66:FE:3B:84:C3

SHA1: B3:8F:EC:EC:0B:14:8A:A6:86:C3:D0:0F:01:EC:C8:84:8E:80:85:EB

Nombre del algoritmo de firma: SHA1withRSA

Version: 3

Extensiones:

#1: ObjectId: 2.5.29.15 Criticality=true

KeyUsage [

Key_CertSign

Crl_Sign

]

#2: ObjectId: 2.5.29.19 Criticality=true

BasicConstraints:[

CA:true

PathLen:2147483647

]

#3: ObjectId: 2.5.29.14 Criticality=false

SubjectKeyIdentifier [

KeyIdentifier [

0000: 8E 45 F4 9F 73 C5 FF 2F   1B 05 DB 01 47 60 1B 03  .E..s../....G`..

0010: 8A 81 B7 BA                                        ....

]

]

#4: ObjectId: 2.5.29.32 Criticality=false

CertificatePolicies [

[CertificatePolicyId: [2.5.29.32.0]

[PolicyQualifierInfo: [

qualifierID: 1.3.6.1.5.5.7.2.1

qualifier: 0000: 16 16 68 74 74 70 3A 2F   2F 77 77 77 2E 64 6E 69  ..http://www.dni

0010: 65 2E 65 73 2F 64 70 63                            e.es/dpc

]]  ]

]

Confiar en este certificado? [no]:  si

Se ha añadido el certificado al almacen de claves

Podemos ver el contenido del KeyStore con el siguiente comando:

bin>keytool -keystore almacenClaves -list

Escriba la contraseña del almacen de claves:

Tipo de almacen de claves: JKS

Proveedor de almacen de claves: SUN

Su almacen de claves contiene 2 entradas

dniraiz, 26-feb-2011, trustedCertEntry,

Huella digital de certificado (MD5): 15:5E:F5:11:7A:A2:C1:15:0E:92:7E:66:FE:3B:84:C3

mykey, 26-feb-2011, PrivateKeyEntry,

Huella digital de certificado (MD5): 64:0A:26:BE:D7:F0:EE:F7:AD:E1:E4:E7:79:C2:72:2B

Si queremos también autenticar clientes con certificados Ceres-FNMT no hay más que importar el correspondiente certificado de autoridad:

bin>keytool -keystore almacenClaves -import -alias FNMT -file FNMTClase2CA.cer

Dicho certificado puede ser descargado de la siguiente web:

http://www.cert.fnmt.es/

Si lo que quieres es acceder al DNIe en una aplicación de escritorio o por otra parte acceder en “modo cliente”, lo que necesitas es ver la configuración del cliente en Aplicación Cliente/Servidor en Java SSL con el DNIe. Lo del modo cliente lo digo porque en este artículo has visto cómo crear un keystore para el servidor, el que va a validar el DNIe.

 

Servidor Web Apache Tomcat (Java) con acceso DNIe

0saves

Te recomiendo que pruebes el servicio de Soporte Online.

En esta ocasión vamos a ver cómo configurar un servidor web Apache-Tomcat para autenticar usuarios a través del DNI electrónico o DNIe. Apache-Tomcat es un servidor que ejecuta aplicaciones web en lenguaje Java, al igual que hacen otros servidores similares como pueden ser JBoss o Glassfish.

 

Tal y como se ve en la web de Apache-Tomcat la versión 7.0.x exige una versión de java al menos 1.6. Por el contrario, la versión 6.0.x de Tomcat exige al menos Java 1.5. Se pueden tener fácilmente los dos servidores y las dos versiones de Java en nuestra máquina y conmutar en función de la variable del sistema JAVA_HOME, teniendo claro que en este caso Tomcat 7 no funcionará con Java 1.5. Inicialmente se utilizará la versión 7.0.19, que utiliza una versión 1.6 de java.

 

Por otra parte, los sockets seguros en Tomcat pueden funcionar con Java Secure Socket Extension (JSSE) o por el contrario con OpenSSL o lo que ellos llaman “modo APR” o “conector APR”. La configuración a añadir varía en cada caso e inicialmente lo haremos con OpenSSL. En mi caso, ya tenía instalado OpenSSL en mi máquina.

 

Apache-Tomcat 7 con Java 1.6 y APR-OpenSSL

Se va a hacer sobre una plataforma Windows para reducir al mínimo la documentación que se genere e ir al grano, la integración con la PKI del DNIe. Primero, se instala el Java Development Kit versión 1.6, en este caso instalamos el fichero siguiente:

jdk-6u26-windows-i586.exe

en la carpeta siguiente:

C:\Archivos de programa\Java\jdk1.6.0_26

Con eso habremos instalado tanto el JRE como el JDK. Después creamos la variable del sistema con la que le diremos a Tomcat dónde está Java. Crearemos la siguiente variable:

JAVA_HOME

con exactamente el siguiente contenido en este caso:

C:\Archivos de programa\Java\jdk1.6.0_26

de modo que nuestro Tomcat 7 utilizará la JVM 1.6 para ejecutarse. A continuación instalaremos Tomcat de una manera muy fácil. Descargamos y descomprimimos donde queramos el fichero siguiente:

apache-tomcat-7.0.19-windows-x86.zip

lo que nos creará un directorio como el siguiente:

apache-tomcat-7.0.19\

Ejecutaremos ya mismo el servidor con una utilidad que trae, concretamente:

apache-tomcat-7.0.19\bin\startup.bat

Probamos que vemos la página de bienvenida del servidor no seguro, introduciendo en el navegador la siguiente URL:

http://localhost:8080/

A continuación procederemos a configurar el servidor seguro. Antes de nada necesitamos hacer dos cosas:

  • Crear una autoridad certificadora: generar certificado de autoridad y certificado de servidor. Este certificado de autoridad debe ser instalado en los navegadores o saltará una alerta a los usuarios del tipo “Está seguro de querer ir a esta página?”. El certificado y clave de servidor deberá ser configurado únicamente en el servidor Tomcat. En este caso se tiene el certificado en server.crt y la clave privada en server.key
  • Descargar el certificado de Autoridad Raíz de la Dirección General de la Policía (DGP) ACRAIZ-SHA1.crt de la siguiente web. Con apache no necesitamos los certificados de autoridad intermedia porque éstos ya se encuentran en el DNIe junto con el certificado de ciudadano, por lo que apache puede cogerlos de la sesión SSL:

http://www.dnielectronico.es/seccion_integradores/certs.html

  •  Convertir el certificado ACRAIZ-SHA1.crt a formato PEM con el siguiente comando

openssl x509 -inform DER -in ACDNIE001-SHA1.crt -outform PEM -out ACDNIE001 SHA1.pem

NOTA: Si da error, quitar la opción “-inform DER”

Hecho eso pasamos a editar el siguiente fichero de configuración de Tomcat:

apache-tomcat-7.0.19\conf\server.xml

Suponiendo que descomprimimos apache-tomcat-7.0.19 bajo C: y que creamos un subdirectorio apache-tomcat-7.0.19\conf\certs conteniendo los ficheros server.crt, server.key y ACDNIE001 SHA1.pem. Añadiremos el siguiente contenido bajo la sección <Service name=”Catalina”>:

<!– Define a SSL Coyote HTTP/1.1 Connector on port 8443 –>

<Connector protocol=”org.apache.coyote.http11.Http11AprProtocol”

port=”8443″ maxThreads=”200″

scheme=”https” secure=”true” SSLEnabled=”true”

SSLCACertificateFile=”C:\apache-tomcat-7.0.19\conf\certs\ACRAIZ-SHA1.pem”

SSLCertificateFile=”C:\apache-tomcat-7.0.19\conf\certs\server.crt”

SSLCertificateKeyFile=”C:\apache-tomcat-7.0.19\conf\certs\server.key”

SSLVerifyClient=”require”

SSLProtocol=”TLSv1″/>

Esa definición debería quedar a continuación de la definición del servidor no seguro, que se debería parecer a algo como lo siguiente:

<Connector port=”8080″ protocol=”HTTP/1.1″

connectionTimeout=”20000″

redirectPort=”8443″ />

Podemos probar el servidor seguro rearrancando de la misma forma con startup.bat. Introduciremos la siguiente URL en el navegador:

https://localhost:8443/

Introduciremos el PIN y seleccionaremos el Certificado de Autenticación, con lo que deberíamos ver la página de bienvenida del servidor seguro.

 

Apache-Tomcat 6 con Java 1.5 y APR-OpenSSL

En este caso se va a realizar la misma configuración pero con la versión 6.0.32 de Apache-Tomcat, la cual necesita al menos una versión de Java 1.5. Se verá con claridad lo fácil que es tener varias JREs en la misma máquina, y elegir a voluntad cuál queremos que se ejecute con nuestra aplicación, en este caso Tomcat.

 

Instalamos la versión 1.5 de Java, concretamente en este caso el fichero:

jdk-1_5_0_22-windows-i586-p.exe

bajo la siguientecarpeta:

C:\Archivos de programa\Java\jdk1.5.0_22

Cambiamos la variable JAVA_HOME cuyo contenido ahora será exactamente el siguiente:

C:\Archivos de programa\Java\jdk1.5.0_22

Copiaremos la misma configuración SSL que utilizamos para Tomcat 7 pero adaptaremos las 3 rutas a los 3 ficheros server.crt, server.key y ACRAIZ-SHA1.pem. Suponiendo que descomprimimos apache-tomcat-6.0.32 bajo C: y que creamos un subdirectorio apache-tomcat-6.0.32\conf\certs conteniendo los ficheros server.crtserver.key y ACDNIE001 SHA1.pem, quedaría algo como lo siguiente, bajo la misma sección <Service name=”Catalina”>:

<!– Define a SSL Coyote HTTP/1.1 Connector on port 8443  –>

<Connector protocol=”org.apache.coyote.http11.Http11AprProtocol”

port=”8443″ maxThreads=”200″

scheme=”https” secure=”true” SSLEnabled=”true”

SSLCACertificateFile=”C:\apache-tomcat-6.0.32\conf\certs\ACRAIZ-SHA1.pem”

SSLCertificateFile=”C:\apache-tomcat-6.0.32\conf\certs\server.crt”

SSLCertificateKeyFile=”apache-tomcat-6.0.32\conf\certs\server.key”

SSLVerifyClient=”require”

SSLProtocol=”TLSv1″/>

Podemos probar el servidor seguro rearrancando de la misma forma con startup.bat. Introduciremos la siguiente URL en el navegador:

https://localhost:8443/

Introduciremos el PIN y seleccionaremos el Certificado de Autenticación, con lo que deberíamos ver la página de bienvenida del servidor seguro.

 

La validación OCSP hasta donde yo sé hay que hacerla a nivel de programación, no es posible utilizar el fichero de configuración. Próximamente…

 

Apache-Tomcat 6 y 7 con JSSE

En este caso vamos a ver cómo configurar Apache-Tomcat con un socket seguro tipo JSSE. Para ello antes de nada hay que Crear un KeyStore de servidor Java para el DNIe, en este caso de nombre “almacenClaves” y contraseña de acceso “123456″ que contendrá el certificado de servidor y el de Autoridad Raíz de la DGP. Lo crearemos con el JDK1.6 y pondremos el JAVA_HOME apuntando al mismo JDK. Como el KeyStore contiene tanto el certificado de servidor como el de la DGP, lo utilizaremos como keystorefile y también como truststorefile. El certificado de la DGP se importa con alias “DNIraiz” para poder ser referenciado fácilmente. Hecho eso, la configuración a añadir en el fichero conf\server.xml, sería la siguiente, para un conector de tipo bloqueante:

<– Define a blocking Java SSL Coyote HTTP/1.1 Connector on port 8443 –>

<Connector protocol=”org.apache.coyote.http11.Http11Protocol”

port=”8443″ SSLEnabled=”true”

maxThreads=”150″ scheme=”https” secure=”true”

clientAuth=”true” sslProtocol=”TLS”

keystoreFile=”C:\Archivos de programa\Java\jdk1.6.0_26\bin\almacenClaves”

truststoreFile=”C:\Archivos de programa\Java\jdk1.6.0_26\bin\almacenClaves”

keystorePass=”123456″

truststorePass=”123456″

keyAlias=”DNIraiz” />

Para configurar un socket seguro con JSSE pero no-bloqueante, se cambiaría el tipo de conector en la primera línea, que quedaría como lo siguiente:

<Connector protocol=”org.apache.coyote.http11.Http11NioProtocol”

Aunque no ha sido probado, lo mejor para curarse en salud es generar el KeyStore con el mismo JDK que pongamos en el JAVA_HOME.

Posibles errores

Si el certificado de Autoridad Raíz del DNIe tiene extensión .crt y se configura como tal, el servidor Tomcat lanza una excepción en el socket seguro durante en el arranque, pero sin embargo arranca el no seguro. La excepción se parecería a:

…………………

GRAVE: Failed to initialize end point associated with ProtocolHandler ["http-apr

-8443"]

java.lang.Exception: Unable to configure locations for client authentication (er

ror:00000000:lib(0):func(0):reason(0))

at org.apache.tomcat.jni.SSLContext.setCACertificate(Native Method)

…………………

GRAVE: No pude inicializar el conector [Connector[HTTP/1.1-8443]]

…………………

 

Otro error que puede ser muy fácil que aparezca se debe al subconsciente. Nosotros hemos configurado el socket en “modo” OpenSSL pero sin embargo en mi caso, inicialmente creé el típico KeyStore de java y configuré Tomcat para que leyese del KeyStore, y por ello me saltó la siguiente excepción:

…………………

GRAVE: Failed to initialize end point associated with ProtocolHandler ["http-apr

-8443"]

java.lang.Exception: El atribiuto del conector SSLCertificateFile debe de ser de

finido al usar SSL con APR

at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:470)

at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.jav

a:492)

…………………

GRAVE: No pude inicializar el conector [Connector[HTTP/1.1-8443]]

org.apache.catalina.LifecycleException: Fall¾ la inicializaci¾n del manejador de

protocolo: {0}

at org.apache.catalina.connector.Connector.initInternal(Connector.java:9

12)

…………………

 

Validación OCSP del DNIe en PHP y Apache

0saves

Te recomiendo que pruebes el servicio de Soporte Online.

En esta entrada de blog se describe cómo hacer la validación OCSP del DNI electrónico o DNIe con el Responder de la Dirección General de la Policía (DGP) utilizando lenguaje PHP. Este lenguaje es un lenguaje para programar aplicaciones en un servidor web y normalmente se apoya en un servidor de bases de datos tipo MySQL o SQL Server. Antes de pasar a programar el script PHP hay que tener en cuenta el estado de entrada. Un cliente web o navegador a realizado satisfactoriamente una conexión SSL presentando un certificado de cliente, en este caso el DNIe. Para ello principalmente habremos configurado un Servidor Web Apache con acceso DNIe.

 

El protocolo OCSP (Online Certificate Status Protocol) es un estándar por el cual nosotros podemos consultar en tiempo real el estado de revocación de un certificado. Con “en tiempo real” quiero decir que lo que se hace es consultar a un servidor que ofrece ese servicio. En lugar de eso nosotros podríamos disponer de un archivo estático o CRL (Certificate Revocation List) cuyo contenido es una lista de los certificados (o números de serie) revocados por la autoridad, sin embargo OCSP es indudablemente mejor como servicio.

 

Recuerda que si utilizas una versión de Apache mayor o igual que 2.3.x no es necesario que hagas la validación OCSP en PHP, ya que se puede hacer desde el fichero de configuración. Por otra parte si también aceptas certificados de otras autoridades como Ceres-FNMT lo más fácil es hacer la validación OCSP en PHP porque la configuración del servidor se complicaría al tener un host virtual por cada autoridad certificadora, en ese caso 2. Recuerda además que este método puede que sea mucho más lento, porque estaremos utilizando comandos de la máquina y escribiendo y leyendo ficheros, todo ello por cada consulta OCSP.

 

Suponiendo que podemos conectarnos al servidor web Apache con el DNIe, al inicio de nuestro script previsiblemente el cliente tiene un DNIe con firma válida o por el contrario un certificado de Ceres-FNMT si es que lo quisimos así. Podemos acceder a toda la información de sesión SSL a través de las variables de sesión PHP. Para saber cuál es la organización que emite el certificado de cliente o cuál es el Common-Name del certificado (es decir el titular del certificado, el ciudadano si es un DNIe), podemos consultar respectivamente:

$_SERVER['SSL_CLIENT_I_DN_O']

$_SERVER['SSL_CLIENT_S_DN_CN']

 

El Common-Name de un DNI tiene la forma siguiente. La primera línea sería un CN del certificado de autenticación y la segunda para el certificado de firma.

<Nombre><Apellido1><Apellido1> (AUTENTICACIÓN)
<Nombre><Apellido1><Apellido1> (FIRMA)

 

Una vez sabemos quién tenemos delante podemos dejarle pasar o no en función de su nombre, usando una base de datos MySQL por ejemplo, y a continuación podemos proceder a consultar la revocación del certificado vía OCSP. Lo haremos ejecutando desde PHP un comando OpenSSL y para ello necesitamos cuatro cosas: la dirección del OCSP Responder, el certificado de cliente, el de la autoridad intermedia y el de la autoridad raíz.

 

Primero, la dirección del OCSP podemos guardarla en una variable así:

$OCSPUrl = ‘http://ocsp.dnie.es/’;

 

Segundo, el certificado de cliente, que ha salido del DNIe, podemos obtenerlo con las variables de sesión SSL y guardarlo en un fichero PEM en disco:

file_put_contents(‘cert_c.pem’, $_SERVER['SSL_CLIENT_CERT']);

 

Tercero, el certificado de la autoridad intermedia podemos obtenerlo con las variables de sesión SSL y guardarlo en un fichero PEM en disco:

 file_put_contents(‘cert_i.pem’, $_SERVER['SSL_CLIENT_CERT_CHAIN_0']);

 

Cuarto, el certificado de autoridad raíz no podemos (¡ni debemos!) obtenerlo con las variables de sesión SSL, por lo que deberemos tenerlo en disco de antemano y en formato PEM. Guardaremos la ruta a este fichero en una variable por ejemplo:

$RootCA = ‘ACRAIZ-SHA1.pem’;

 

Finalmente, ejecutaremos el comando OCSP de OpenSSL:

$output = shell_exec(‘ocsp -CAfile ‘.$RootCA.’ -issuer cert_i.pem -cert cert_c.pem -url ‘.$OCSPUrl);

 

E interpretaremos la respuesta:

$output2 = preg_split(‘/[\r\n]/’, $output);

$output3 = preg_split(‘/: /’, $output2[0]);

$ocsp = $output3[1];

if ($ocsp == “good”)

$malo = false;

else $malo = true; /* será “revoked” o “unknown” */

 

NOTA: Cuidado con las rutas al comando OpenSSL y a los ficheros. Cuidado además con la concurrencia, se debe generar un número aleatorio con rand() y concatenarlo a los nombres de certificados que almacenamos temporalmente en disco.

 

Red Privada Virtual con OpenVPN y el DNIe

0saves

Te recomiendo que pruebes el servicio de Soporte Online.

En esta entrada se pretende integrar el software OpenVPN con el DNI electrónicoDNIe. Una Virtual Private Network (VPN) o Red Privada Virtual (RPV) es una red virtual entre ordenadores que ya pertenecen a una red. Esto significa que a través de una red pública como es Internet, nosotros podemos configurar una red con direccionamiento IP privado y (repito) cuyos nodos estarán en cualquier parte de Internet. La comunicación entre estos nodos va cifrada y autenticada con los algoritmos pertinentes. El estándar de facto para este tema es IPSec y para el tema concreto de la autenticación el protocolo IKE.

 

OpenVPN es una implementación en software libre que hace que podamos entender fácilmente lo que es una Red Privada Virtual. Consiste en un servidor y N clientes que acceden a este servicio a través de su IP y puerto bien conocidos. Personalmente lo he estado usando 2 años para acceder desde la WiFi de la universidad al PC que tengo en casa, donde tengo todos los datos, documentos y trabajos. Vale, para este caso ya sé que existe Google Docs y FileZilla. La primera desventaja con respecto a IPSec es que la comunicación entre clientes pasa siempre por el servidor, introduciendo una latencia y cuello de botella considerables. Sin embargo he de decir que con 1MB de subida en casa me ha llegado incluso para escuchar sin interrupciones archivos de música en MP3 de 4-5MB de tamaño medio. Hay que tener en cuenta que aquí no hay Calidad de Servicio o QoS, por lo que previsiblemente lo que hace el software es copiar el fichero en un directorio temporal, sin embargo constato que son unos segundos lo que tarda en cargarlo. Si dichos archivos estuviesen en otro cliente en lugar de en el servidor (como es el caso), la velocidad se reduciría a la mitad en general.

 

Cuando iba a empezar a integrarlo con el DNIe (de mi madre) han ido apareciendo ya los primeros problemas. Tal y como puede verse en el siguiente enlace:

http://sourceforge.net/mailarchive/message.php?msg_id=27799983

ahí tenemos a un tal Sergio Yébenes enfrentándose con valor una vez más y en medio de Julio a una tecnología poco amistosa o, por otro lado, a algún tipo de empanamiento personal. Como pueden ver, la utilidad que trae OpenVPN para extraer el ID de nuestro certificado de autenticación devuelve algo como lo siguiente:

opensc\bin>openvpn --show-pkcs11-ids UsrPkcs11.dll
Certificate
DN: /C=ES/O=DIRECCION GENERAL DE LA POLICIA/OU=DNIE/CN=AC DNIE 001
Serial: 642066C9997BAEE14402DA6EA422D649
Serialized id:
DGP\x2DFNMT//\x86\xE5\x21\x21pQ\x19/DNI\x20electr├│nico/5338364535323132313730353131393230303831323139313230373538

 

Eso es el certificado de la autoridad intermedia que firma este DNIe, en este caso la autoridad 001 (son 3) y es el único dato accesible en el DNIe sin la introducción del PIN. Por lo que, primero, no podemos ver el Serialized id de nuestro certificado, necesario para el cliente OpenVPN, a no ser que exista una opción “–pin” en el comando, que parece que no es el caso. Segundo, los backslashes hacen fallar al cliente OpenVPN, por lo que la probabilidad de empanamiento aumenta, al estar trabajando en Windows XP. El comando de OpenVPN tiene la opción –pkcs11-cert-private, con la que es posible decirle que es necesario hacer login para acceder a los certificados. Parece que se parece a lo que queremos, sin embargo seguimos sin saber el ID, y además esa opción no se puede usar en modo standalone, es decir que sólo funciona cuando se lanza el cliente OpenVPN propiamente dicho.

 

Vemos cómo este sujeto pregunta si sería posible construir el serialized-id de openvpn a partir de lo que podamos hacer con el comando pkcs11-tool, como por ejemplo listar los objetos presentes en la tarjeta:

opensc\bin>pkcs11-tool -O --login --module UsrPkcs11.dll
Using slot 0 with a present token (0x1)
Logging in to "DNI electr├│nico".
Please enter User PIN: Public Key Object; RSA 2048 bits
  label:      KpuFirmaDigital
  ID:         4638364535323132313730353131393230303831323139313230373538
  Usage:      verify
Public Key Object; RSA 2048 bits
  label:      KpuAutenticacion
  ID:         4138364535323132313730353131393230303831323139313230373538
  Usage:      verify
Private Key Object; RSA
  label:      KprivFirmaDigital
  ID:         4638364535323132313730353131393230303831323139313230373538
  Usage:      sign
Private Key Object; RSA
  label:      KprivAutenticacion
  ID:         4138364535323132313730353131393230303831323139313230373538
  Usage:      sign
Certificate Object, type = X.509 cert
  label:      CertCAIntermediaDGP
  ID:         5338364535323132313730353131393230303831323139313230373538
Certificate Object, type = X.509 cert
  label:      CertFirmaDigital
  ID:         4638364535323132313730353131393230303831323139313230373538
Certificate Object, type = X.509 cert
  label:      CertAutenticacion
  ID:         4138364535323132313730353131393230303831323139313230373538

 

Hasta nuevas noticias, esta entrada de blog se congela.

 

NOTA: aunque consigamos configurar el sistema, OpenVPN es uno de esos servicios que no nos permite gestionar usuarios aparte de darles certificado, por lo que a nuestra VPN accederá todo aquél que tenga DNIe. Por otra parte, podemos usar un portal cautivo o algún tipo de pasarela web previa a la conexión con la VPN. Además, A fecha actual OpenVPN no realiza comprobación OCSP de los certificados, por lo que la utilización de esa pasarela deberá paliar este defecto.