Exportación de certificado X.509 codificado en PEM

La digitalización en la administración pública no lleva precisamente un ritmo rápido... y tampoco lo ponen fácil a usuarios finales...

Veremos como para dar de alta un proveedor en FACe, o gestionar su renovación, nos solicitan certificado en formato PEM. Por simplificar, tal como en un fichero de texto Word o una hoja de Excel tenemos diferentes formatos y versiones con los que podemos trabajar, con el certificado nos pasa lo mismo.

En este caso PEM se codifica en Base64 encerrado entre la cabecera "-----BEGIN CERTIFICATE-----" y el fin de contenido con "-----END CERTIFICATE-----".

Sin entrar en detalles técnicos, por ilustrar con un ejemplo, el texto "Este frase sería codificada" en base 64 contendría: "RXN0ZSBmcmFzZSBzZXLDrWEgY29kaWZpY2FkYQ=="

Este tipo de certificados se basan en el estándar "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" siguiendo la normativa RFC 5280. Gracias a ello podemos identificar el propietario, emisor (Autoridad de Certificación), fecha de caducidad, fecha de misión... basándonos en infraestructura de clave pública (PKI - Public Key Infraestructure)

Por tanto lo que nos están pidiendo es un "certificado X.509 codificado en formato PEM".
En un escenario habitual en un entorno Windows donde tenemos almacenado el certificado accedemos ejecutando el comando "mmc.exe" (existen otras opciones de visualización pero esta funciona en todas las versiones de Windows hasta ahora)

Nos aparecerá una ventana de consola, y bajo la opción del menú "Archivo" la opción: "Agregar o quitar complemento"

A continuación seleccionamos "Certificado" entre los complementos disponibles y pulsamos en agregar: 

Seleccionamos "Mi cuenta de usuario" teniendo en cuenta que los certificados mostrados son los del usuario que ha iniciado sesión en el equipo:

Dentro de "Personal" / "Certificados" nos mostrará todos los disponibles del usuario actual. El icono del listado, muestra una pequeña llave en aquellos certificados de los que disponemos la parte privada:

Haciendo clic con el botón derecho sobre el certificado pulsamos en "Todas las tareas" y "Exportar". Debemos seleccionar el formato de codificación X.509, no debemos exportar la clave privada en este caso:

Indicamos una ruta de nuestro ordenador para guardar el certificado, pulsando con el botón derecho sobre el certificado "Abrir con..." y seleccionamos el editor de texto Bloc de notas nos mostrará:

Con este contenido a podemos copiar y pegar en la página de FACe de proveedores.

 


Firma de ficheros con sistema PROS@ de la seguridad social

La interacción digital con la administracón pública no es precisamente lo que debería ser, no es la primera vez ni será la última en aparecer problemas de base. Han pasado años y seguimos con los mismos o mayores problemas recurrentes. Desde que se introdujera el DNI electrónico a bombo y platillo, ahora tambien puedes seguir sin utilizarlo desde tu movil con NFC, los servicios disponibles no son útiles y utilizados.

Después de las habituales recomendaciones de la administración, contrarias a cualquier buena práctica de seguridad en las que tenemos:

  • Añadir los dominios a las excepciones de seguridad en Java
  • Añadir los dominios a la zona de Sitios de Confianza de Interner Explorer, permitir o preguntar todas las opciones de seguridad (sin comentarios)
  • Comprobar el certificado electrónico en el navegador correspondientes

Si bien el cliente @Firma ha quedado obsoleto y el nuevo ha pasado a ser autofirm@ es sorprendente que desde la web de la seguridad social se sigan utilizando controles ActiveX que por defecto se bloquean, no solo Java sino propios:

Es posible realizar un inventario activando el registro de utilización en Internet Explorer 11, guardando un registro en:

%LOCALAPPDATA%\Microsoft\Internet Explorer\AuditMode\VersionAuditLog.csv

Desbloqueando el control ActiveX sigue permitiendo firma... por el momento.

Como mínima reflexión... ¿para que queremos un DNI electrónico con tantas posibilidades? si luego debemos tener: carné de conducir, tarjeta de la seguridad social (diferente por autonomías), tarjeta sanitaria europea (por si viajas), tarjeta ciudadana (por municipios incluso), tarjeta de transportes, carné joven (si no has llegado a la adultescencia, por comunidades), carné de alberguista, carnés profesionales, familia numerosa, carné de donantes, competencia profesional para transporte público por carretera, tarjeta de federado en alguna disciplina... despropósito general, gasto asegurado.

Relacionado: Bloqueo de componentes antiguos ActiveX en 2014

SSL Error en Dell OpenManage Systems Management Tools

Cada fabricante de hardware tiene su propia suite, más o menos amigable, para facilitar a los administradores una gestión de servidores desde uno solo a un Data Center completo:  Dell, HPE, Fujitsu, IBM, Lenovo, SuperMicro... con posibilidades de integración de Sistemas Operativos, monitorización, despliegue, networking, provisionamiento... en este caso se trata de OpenManage de Dell; curiosamente tras instalar en varios servidores uno de ellos, con la misma configuración que el resto, no era posible conectar con el software OMSA via web en la dirección y puertos por defecto:

https://localhost:1311

Después de verificar la instalación sobre Windows Server 2012 R2 y comprobar los servicios iniciados:

  • DSM SA Connection Service: servicios web para conexión
  • DSM SA Data Manager: recopilación de datos, monitorización
  • DSM SA Event Manager: registro de eventos en el sistema operativo
  • DSM SA Shared Services: inventario inicial para SNMP y CIM

Seguía apareciendo un error genérico sobre Internet Explorer 404 como inaccesible, sobre Firefox apareció un error más descriptivo:

An error occurred during a connection to localhost:1311 SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)

Con lo que desactivando en about:config del navegador los dos parámetros:

  • security.ssl3.dhe_rsa_aes_128_sha
  • security.ssl3.dhe_rsa_aes_256_sha

Ya era posible acceder al gestor y desde:

Preferencias -> Configuración General  -> Certificado X.509

Cambiar el certificado por uno válido en IE y reiniciar el servicio "DSM SA Connection Service"

 

Resetear contraseña root en Linux

La mayoría de sistemas operativos permite, con acceso local o virtual en el arranque, resetear la contraseña de usuario de administrador. En este caso explicaremos como hacerlo desde en CentOS en modo de usuario único del sistema con GRUB:

  1. Interrumpimos el inicio normal del sistema operativo, en este caso CentOS pulsando una tecla:
  2. Seleccionamos la versión pulsando "e" para editar las opciones


  3. Esta es la que aparece por defecto en nuestro caso:

    A la que añadiremos la palabra "single " seguida de un espacio:

    Pulsamos intro y volvemos al menú anterior

  4. Ahora en lugar de pulsar la "e" para editar, debemos pulsar "b" para iniciar y tendremos acceso root al sistema:


  5. Con el control como administrador ya podemos ejecutar el comando "passwd" para cambiar la contraseña perdida

La idea general de acceso es la misma para otros gestores de arranque.

Facturas electrónicas, administración pública y Java

La idea es buena realmente y debemos tender a utilizarla, si es que tuviera la mínima estabilidad y funcionara correctamente. Remitir las facturas de forma electrónica de todas aquellas empresas proveedoras de la administración pública en un formato reconocido por ambas partes.

Hasta ahi todo suena bien, pero en la práctica pasa igual que en otros ámbitos políticos; la coordinación entre administraciones es ruinosa o inexistente.

  • El "servicio técnico" remite una plantilla de comprobación, un manual de los pasos a seguir, sea cual sea la pregunta.
  • No se trata de prácticas recomendadas añadir toda una serie de excepciones en las configuraciones de los equipos cliente para lograr hacer funcionar algo fuera de estándares.
  • JAVA lleva tiempo siendo un engorro como plugin para navegadores y sus constantes actualizaciones un quebradero de cabeza para muchos usuarios finales y proveedores, la visión inicial de escribir código una vez y ejecutarlo en cualquier sitio no va unido a esta plataforma.
  • Las limitaciones de acceso a los almacenes de seguridad de los sistemas operativos o navegadores donde residen los certificados son un escollo por el que hay que pasar, pero es necesario buscar alternativas que faciliten su uso autorizado.

Desde otro punto de vista, por que no utilizar autenticación en dos pasos, reconocimiento de iris, huellas dactilares... de manera alternativa...

Mejor todavía... ¿por que no obligar a remitir en tiempo real las facturas generadas y recibidas entre todo tipo de empresas? técnicamente posible, políticamente en España inalcanzable en estos momentos...

¿A que viene todo esto? Después de probar en varios equipos, navegadores, sistemas operativos la firma online en el portal FACE el applet de Java solo se queda bloqueado en esta web, (en el resto de webs del mundo si funciona) pero según palabras de varios funcionarios el problema era nuestro...

Resulta que con la versión 8 de Java Actualización 77 (compilación 1.8.0_77_b03) si funciona pero con las dos siguientes a fecha de hoy (cambios de las versiones 91 y 92) se queda bloqueado el applet, ya no hay ni tiempo ni interés en reportarlo pero aquí queda una más... solución temporal.

Cada vez más interesado en Windows Hello :)


Enlaces relacionados: Cliente @firma