Problemas de Autofirma con el navegador web.

AutoFirma es una aplicación ideal e intuitiva para firmar digitalmente documentos. Hay veces en que no se usa de forma interactiva por el usuario, sino que se lanza desde una página web para firmar un documento o petición generada al vuelo. Es lo que sucede, por poner un ejemplo cercano, con la pagina web de Registro de la Junta de Extremadura.

El problema que se presenta a veces es que directamente AutoFirma en esta página web no funciona. Hay muchos motivos para que no funcione, ya que los procesos de firma y manejo de certificados digitales dependen de muchos factores y servicios web externos y cuando falla la versión y/o la comunicación con alguno, falla todo. El mensaje de error que obtenía era este:

Cuando me sucede esto, lo que suelo hacer es, con el mismo ordenador, probar en servicios de conocida robustez que usan el certificado digital, y asi descartar que sea un problema local de la página donde estoy trabajando. Para probar el certificado digital, la página de la Carpeta Ciudadana es ideal. Para probar AutoFirma, la página de test de autofirma de los Registradores de la Propiedad es también muy buena. Si fallan estas páginas al probarlas podemos estar casi seguros de que el problema es de la configuración de nuestras máquinas.

Descartando que tenemos AutoFirma actualizado, la versión correcta de Java (a día de hoy openjdk 11.X) y nuestro certificado digital en regla lo único que nos queda es confirmar que AutoFirma está correctamente configurado en nuestro ordenador.

Uno de los motivos más frecuentes es que el certificado raíz de AutoFirma_ROOT.cer no ha quedado bien instalado (o se ha desinstalado) en el navegador web. Pasa mas de lo que debiera. Este certificado está en la ruta /usr/lib/AutoFirma/AutoFirma_ROOT.cer y hay que proceder a instarlo dentro del perfil del navegador del usuario.

Hay 3 formas de hacerlo:

• Desde la propia aplicación de AutoFirma: abrimos la aplicación y vamos a Herramientas-Restaurar Instalación. Esta opción, por algún motivo que se me escapa, nos pedirá la contraseña de root para instalar el certificado localmente, pero solucionará el problema.
  
• A mano en el navegador: añadir el fichero /usr/lib/AutoFirma/AutoFirma_ROOT.cer dentro de la opción de "Autoridades/Entidades Emisoras" de la configuración de certificados de los navegadores, marcando todas las opciones de configuración que nos ofrecen.
• Mediante línea de comando, con este script tan majo:

  # cat configura-cert-autofima.sh 
  #!/bin/bash
  certificado="/usr/lib/AutoFirma/AutoFirma_ROOT.cer"
  
  echo "Instalando $certificado en Chrome y Firefox"
  
  if ! test -e "$certificado" 
  then
     echo "No encuentro $certificado"
     exit 0
  fi
  
  #Cerramos chrome
  pkill --oldest chrome
  echo "Instalando certificado $certificado en Chrome"
  certutil -A -n "AutoFirmaRoot" -t "CT,C,C" -i "$certificado" -d $HOME/.pki/nssdb
  echo ""
  echo "Instalado. Puede verificar que  está correcto haciendo:"
  echo '     certutil -L -d sql:$HOME/.pki/nssdb'
  
  #Cerramos firefox
  pkill --oldest firefox
  
  echo "Instalando certificado $certificado en Firefox"
  perfiles=$(ls $HOME/.mozilla/firefox/ | grep .default)
  for i in $perfiles
  do
       certutil -A -n "AutoFirmaRoot" -t "CT,C,C" -i  "$certificado" -d $HOME/.mozilla/firefox/$i
  done
  echo "Instalado. Puede verificar que está instalado mirando en la configuración de Certificados (Servidores/Autorizados) en su Firefox."
  
  exit 0
  

Una vez hecho esto vamos a la página de Test de Autofirma de Registradores y vemos si ya funciona la firma digital:

Si funciona aquí, ya podemos probarlo en el Registro de la Junta a ver si hay suerte. Adjunto esta guía, díficil de encontrar y algo obsoleta, con los problemas más frecuentes del Registro Telemático.

Monitorización del SAI con nut en Debian 12.

Ya hemos tratado varias veces en el pasado de este blog el tema de la monitorización del SAI del servidor desde Debian. Vamos a hacer ahora una recopilación de todo lo aplicado otras veces montado sobre Debian 12, que es el sistema que usamos a día de hoy. Vamos allá.

SAI que tenemos: un Salicru SPS One, que conectado por USB se detecta así:

# lsusb
...
Bus 002 Device 004: ID 0665:5161 Cypress Semiconductor USB to Serial
...

Paquetes a instalar:

# apt-get install nut-client nut-server nut-cgi

Antes de empezar la configuración se aconseja tener un servidor de correo activo para poder enviar los mensajes de cambio de estado del SAI. En el Apartado 2 de esta entrada del blog cuento como montar el sistema que mejor me ha funcionado: postfix reenviando los correos a través de una cuenta de gmail.com

Vamos ahora a ver los distintos ficheros de configuración. El primero es ups.conf, que tiene los datos para conecar al SAI. Una buena manera de saber que ponemos aquí es usar la salida del comando "nut-scanner".

# cat /etc/nut/ups.conf
maxretry = 3
[salicru]
driver = "nutdrv_qx"
port = "auto"
vendorid = "0665"
productid = "5161"
product = "HID UPS"
serial = ""
vendor = "HID UPS"

Los otros ficheros quedarían:

# cat /etc/nut/upsd.conf 
LISTEN 127.0.0.1
LISTEN 172.1.1.2 # PONER LA IP de la maquina donde se ejecuta la monitorización
LISTEN 0.0.0.0 3493

# cat /etc/nut/upsd.users
[admin]
password = mipasswordfavorita
actions = set
actions = fsd
instcmds = ALL
upsmon primary

# cat /etc/nut/hosts.conf 
MONITOR salicru@localhost "SAI Salicru Servidor"

# cat /etc/nut/nut.conf
MODE=standalone

# cat /etc/nut/upsmon.conf 
RUN_AS_USER nut
MONITOR salicru@localhost 1 admin mipasswordfavorita primary
MINSUPPLIES 1
SHUTDOWNCMD "/usr/local/bin/apagar_servidores.sh"
NOTIFYCMD "/sbin/upssched"
NOTIFYMSG ONLINE "UPS: Normal state"
NOTIFYMSG ONBATT "UPS: On battery"
NOTIFYMSG LOWBATT "UPS: Battery low"
NOTIFYMSG FSD "UPS: Starting shutdown"
NOTIFYMSG COMMOK "UPS: Communication restored"
NOTIFYMSG COMMBAD "UPS: Communication lose"
NOTIFYMSG SHUTDOWN "UPS: Shutting down"
NOTIFYMSG NOCOMM "UPS: No communication"
NOTIFYMSG REPLBATT "UPS: Replace battery"
NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC
NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC
NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC
NOTIFYFLAG FSD SYSLOG+WALL+EXEC
NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC
NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC
NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
NOTIFYFLAG NOCOMM SYSLOG+WALL+EXEC
NOTIFYFLAG REPLBATT SYSLOG+WALL+EXEC
POLLFREQ 5
POLLFREQALERT 5
HOSTSYNC 15
DEADTIME 15
POWERDOWNFLAG /etc/killpower
RBWARNTIME 43200
NOCOMMWARNTIME 300
FINALDELAY 5

# cat /etc/nut/upsset.conf 
# Network UPS Tools - upsset.conf sample file
#
# This file is provided to ensure that you do not expose your upsd server
# to the world upon installing the CGI programs.  Specifically, it keeps
# the upsset.cgi program from running until you have assured it that you
# have secured your web server's CGI directory.
#
# By default, your web server will probably let anyone access upsset.cgi
# once it is installed.  This means that anyone could attempt to crack
# upsd logins since they would appear to be coming from your web server,
# rather than the outside world, slipping through any ACL/ACCESS definitions.
#
# For this reason, you *MUST* first secure your CGI programs before
# enabling upsset in this configuration file.  If you can't do this in
# your web server, then you should *not* run this program.
#
# For Apache, the .htaccess file can be used in the directory with the
# programs.  You'll need something like this:
#
#   <Files upsset.cgi>
#       deny from all
#       allow from your.network.addresses
#   </Files>
#
# You will probably have to set "AllowOverride Limit" for this directory in
# your server-level configuration file as well.
#
# If this doesn't make sense, then stop reading and leave this program alone.
#
# Assuming you have all this done (and it works), then you may uncomment
# the line below and start using upsset.cgi through your web browser.
#
###
I_HAVE_SECURED_MY_CGI_DIRECTORY
###

# cat /etc/nut/upssched.conf
CMDSCRIPT  /usr/local/bin/avisoups.sh
PIPEFN /tmp/upssched.pipe
LOCKFN /tmp/upssched.lock
AT ONBATT * START-TIMER  ups-on-battery-shutdown  600
AT ONLINE * CANCEL-TIMER  ups-on-battery-shutdown
AT ONBATT * START-TIMER ups-on-battery 5
AT ONLINE * CANCEL-TIMER ups-on-battery
AT ONLINE * EXECUTE ups-back-on-line
AT REPLBATT * EXECUTE ups-change_battery
AT LOWBATT * EXECUTE ups-low-battery
AT COMMOK * EXECUTE ups-comunication-ok
AT COMMBAD * EXECUTE ups-comunication-bad
AT NOCOMM * EXECUTE ups-nocomm
AT FSD * EXECUTE ups-fsd
AT SHUTDOWN * EXECUTE ups-shutdown

Para probar que funciona podemos reiniciar los servicios e intentar conectar manualmente con SAI a ver si nos da los datos de carga, voltaje y demás:

# service nut-server restart
# service nut-monitor restart
# upsc salicru
Init SSL without certificate database
battery.charge: 100
battery.voltage: 27.10
battery.voltage.high: 26.00
battery.voltage.low: 20.80
battery.voltage.nominal: 24.0
device.type: ups
driver.name: nutdrv_qx
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: auto
driver.parameter.product: HID UPS
driver.parameter.productid: 5161
driver.parameter.serial: 
driver.parameter.synchronous: auto
driver.parameter.vendor: HID UPS
driver.parameter.vendorid: 0665
driver.version: 2.8.0
driver.version.data: Mustek 0.07
driver.version.internal: 0.32
driver.version.usb: libusb-1.0.26 (API: 0x1000109)
input.current.nominal: 6.0
input.frequency: 50.1
input.frequency.nominal: 50
input.voltage: 232.7
input.voltage.fault: 232.7
input.voltage.nominal: 230
output.voltage: 234.8
ups.beeper.status: enabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 10
ups.productid: 5161
ups.status: OL
ups.type: offline / line interactive
ups.vendorid: 0665

Con lo anterior se ha instalado un interface web al que podemos acceder en la URL: "http://ip-maquina/cgi-bin/nut/upsstats.cgi?host=salicru@localhost". De los diferentes ficheros .cgi que permiten gestionar vía web el SAI me gusta dejar, por temas de seguridad, el fichero "upsset.cgi" sin permisos:

 ls -l /usr/lib/cgi-bin/nut/
total 140
-rwxr-xr-x 1 root root 45416 ene 25  2023 upsimage.cgi
-rwx------ 1 root root 43336 ene 25  2023 upsset.cgi
-rwxr-xr-x 1 root root 47456 ene 25  2023 upsstats.cgi

Ahora muestro los scripts que uso para manejar los eventos y comunicarlos al servidor:

# cat /usr/local/bin/apagar_servidores.sh
#!/bin/bash
# Ejecutado desde  upsmon.conf cuando se la la orden de apagado de servidores.

function mailSend() {

   echo "$2" | mail -s "$1" -a "From: Avisos.ies <tu.correo@gmail.com>"  tu.correo@educarex.es

}

FECHA=$(date)
estado=$(upsc salicru ups.status 2> /dev/null)
en_bateria=$(echo $estado | tr ' ' '\n' | grep "OB")

if [ -z $en_bateria ]  #Si en up.status no parece OB, no estamos en bateria. Es un SHUTDOWNCMD innecesario
then
   MESSAGE_MAIL="Evento SHUTDOWNCMD pero estado $estado. No apagamos el servidor"
   mailSend  "$FECHA => $MESSAGE_MAIL"  "[UPS] Evento SHUTDOWNCMD"
   echo "$FECHA => SAI: $MESSAGE_MAIL" >> /var/log/sai.log  # /var/log/sai.log permisos 644 y nut:nut
else
   MESSAGE_MAIL="Apagado servidor por evento SHUTDOWNCMD"
   mailSend  "$FECHA => $MESSAGE_MAIL"  "[UPS] Evento SHUTDOWNCMD"
   echo "$FECHA => SAI: $MESSAGE_MAIL" >> /var/log/sai.log  # /var/log/sai.log permisos 644 y nut:nut
   ssh root@tercero "/sbin/shutdown -h +0"
   sleep 10
   /sbin/shutdown -h +0
fi

exit 0

# cat /usr/local/bin/avisoups.sh
#!/bin/bash

function mailSend() {

   echo "$2" | mail -s "$1" -a "From: Avisos.ies <tu.correo@gmail.com>"  tu.correo@educarex.es

}

MESSAGE_MAIL=""
EVENT_TYPE=$1
APAGADO=0
FECHA=$(date)

case "$EVENT_TYPE" in
    "ups-on-battery-shutdown")
        MESSAGE_MAIL="UPS on battery: shutdown now"
        APAGADO=1
        ;;
    "ups-on-battery")
        MESSAGE_MAIL="UPS on battery: warning"
        ;;
    "ups-comunication-bad")
        MESSAGE_MAIL="Communications with UPS lost"
        ;;
    "ups-change_battery")
        MESSAGE_MAIL="UPS battery needs to be replaced"
        ;;
    "ups-back-on-line")
        MESSAGE_MAIL="UPS on line power"
        ;;
    "ups-low-battery")
        MESSAGE_MAIL="UPS battery is low"
        ;;
    "ups-comunication-ok")
        MESSAGE_MAIL="Communications with UPS established"
        ;;
    "ups-nocomm")
        MESSAGE_MAIL="No communication with UPS"
        ;;
    "ups-fsd")
        MESSAGE_MAIL="UPS FSD: forced shutdown received"
        APAGADO=1
        ;;
    "ups-shutdown")
        MESSAGE_MAIL="UPS shutdown: shutdown received"
        APAGADO=1
        ;;
esac

mailSend  "$FECHA => $MESSAGE_MAIL"  "[UPS] Event $EVENT_TYPE de SAI Virgen de Guadalupe:"
echo "$FECHA => SAI: $MESSAGE_MAIL" >> /var/log/sai.log

if [ $APAGADO = "1" ]
then
    sleep 30
    /usr/local/bin/apagar_servidores.sh
fi

Por último, si tenemos monit podemos controlar que los servicios están levantados:

# cat /etc/monit/conf.d/monitrc.nut
check process nut-monitor with pidfile /var/run/nut/upsmon.pid
   group nut
   start program = "/bin/systemctl start nut-monitor.service"
   stop  program = "/bin/systemctl stop nut-monitor.service"
   if not exist then restart
   if 5 restarts within 5 cycles then timeout

check process nut-server matching "/lib/nut/upsd"
   group nut  
   start program = "/bin/systemctl start nut-server.service"
   stop  program = "/bin/systemctl stop nut-server.service"
   if not exist then restart
   if 5 restarts within 5 cycles then timeout

Y con esto lo tenemos ya, el porqué de todas las cosas que se configuran en estos ficheros está explicado en los anteriores artículos dedicados a nut en este blog. Espero que este sea la entrada definitiva.