Site vale: Notas sobre acceso a Administación Electrónica (Debian Wheezy/Jessie con dnie/ceres)

(Actualizado: julio 2015)

Estas son mis anotaciones sobre como he ido configurando una Debian Wheezy / Jessie (64bit) para acceder a las páginas de la Administración Electrónica para realizar todo tipo de trámites on-line.
Una de las mayores pegas con las que he tenido que lidiar son los applets de java que se suelen usar, tanto para firma como para autenticación.
Aunque según lo que he observado, cada vez más se tiende a utilizar la platatorma @firma, muchas sedes utilizan otro tipo de accesos/plataformas (applets java propios, Websigner, ...).

Cuando he tratado de acceder a portales de la sedes electrónicas de la Administración Pública Española, usando Debian 7/8, como mínimo he necesitado:

Máquina virtual java de Oracle
Un certificado de la fnmt o dnie+lector

A priori una lista de requisitos fácil de cumplir, pero llegar a que la cosa funcione realmente tiene sus 'truquillos'. Vayamos por partes.

Java

Versión 'hazte tu propio paquete':

Descargar el jre de java adecuado para 64 o 32bit (NO el rpm) de aqui
sudo apt-get install java-package
make-jpkg jre-7u51-linux-x64.tar.gz
sudo dpkg -i oracle-j2re1.7_1.7.0+update51_amd64.deb

Versión 'utiliza repositorio' (ventaja: actualizaciones):

Nota: Según he leído en webupd8, parece ser que este ppa es seguro para debian, ya que sólo se trata de un script al estilo del de update-flashplugin

echo "deb http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | tee -a /etc/apt/sources.list
echo "deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main" | tee -a /etc/apt/sources.list
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EEA14886

sudo apt-get update

sudo apt-get install oracle-java7-installer oracle-java7-unlimited-jce-policy

Nota: En todo caso, también he tenido que instalar el Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files, que también está incluido en el repositorio anterior.

Si no se usa el repositorio de webupd8team/java, descargar y descomprimir el fichero UnlimitedJCEPolicyJDK7.zip y copiar los *.jar al directorio lib/security del jre (en mi caso /usr/lib/jvm/java-7-oracle/jre/lib/security/).

Esto elimina ciertas "restricciones criptográficas" del java. Uno de los síntomas de que se necesita esta descarga es un mensaje de java del tipo "java.security.InvalidKeyException:illegal Key Size" cuando se trata de abrir un certificado pfx/p12 (por ejemplo en la firma de una notificación de la seguridad social con un navegador de 64bit)

Certificado:

Ir a la fnmt y obtener uno (si se tiene el dni electrónico operativo lo más cómodo es usarlo para obtener un certificado de forma inmediata y sin desplazamientos).

Lo siguiente es opcional aunque muy recomendable

Establecer una contraseña en el almacen de claves de Iceweasel/firefox. Está en Preferencias/Avanzados/Certificados/Dispositivos de seguridad/Disp.software de seguridad/Cambiar contraseña.
Hacer copia de seguridad (con una buena contraseña) del certificado personal: Preferencias/Avanzados/Certificados/Ver Certificados/Sus certificados/Hacer copia

Hacer copia del certificado

Descargar el certificado raiz de la fnmt y los certificados del DNI

ir a Preferencias/Avanzados/Certificados/Ver Certificados/Autoridades/Importar
Seleccionar certificado y marcar las tres casillas de uso
Repetir para todos los certificados descargados.

Importar certificado de CA

Uso de tarjetas criptográficas (dnie / ceres):

Evidentemente necesitamos un lector de tarjetas. Yo he probado con dos que me han funcionado perfectamente. Uno es el LTC31 de C3PO y el otro es el SMC SCM 3500 smartfold reader.

Para que este último sea 'reconocido' por pcscd he tenido que crear un fichero (descaradamente fusilado de /lib/udev/rules.d/60-gnupg.rules): /etc/udev/rules.d/60-smartcard-SCx35xx.rules

SUBSYSTEM!="usb", GOTO="gnupg_rules_end"
ACTION!="add", GOTO="gnupg_rules_end"

# USB SmartCard Readers
## SCM reader SCx35xx
ATTR{idVendor}=="04e6", ATTR{idProduct}=="5410", ENV{ID_SMARTCARD_READER}="1", ENV{ID_SMARTCARD_READER_DRIVER}="gnupg", GROUP="pcscd"

LABEL="gnupg_rules_end"

Instalamos lo necesario para soporte de smartcard

sudo apt-get install pcscd libccid pinentry-gtk2

Para usar el dnie: OpenSC

Ahora faltaría instalar opensc, pero necesitamos una versión que dé soporte al dnie.
En el caso de usar Debian 8 (Jessie), la versión de opensc disponible, la 0.14, ya funciona con el dnie. Aún así he necesitado editar /etc/opensc/opensc.conf y modificar estos ajustes:

enable_pinpad=false
plug_and_play=false

Para el caso de Debian 7 (Wheezy), se puede usar opensc-opendnie (he usado anteriormente la versión svn-5569). Esta rama de opensc con soporte para dnie, fue integrada en el proyecto opensc, si mal no recuerdo alrededor de agosto de 2013, después de la publicación de la version 0.13.

Yo he escogido compilar una instantánea reciente del proyecto opensc, concretamente esta del día 19 de enero de 2014 y me he creado un paquete.
A fecha de hoy es la que mejor resultado me ha dado.
Los deb los tengo disponibles para i386 y amd64 y los fuentes para generar el paquete están aquí: opensc-git-src.tar.gz.

NOTA: Si se quiere construir el paquete desde los fuentes, hacer lo habitual:

# descomprimir el opensc-git-src.tar.gz del enlace de más arriba
# Comprobar integridad: md5sum opensc_0.13.0g20140119193004.orig.tar.gz - debe coincidir con
#   el del fichero correspondiente en el listado de la página de descarga 
#   (pinchar sobre i)
dpkg-checkbuilddeps opensc_0.13.0g20140119193004-2.dsc # e instalar las dependencias que se indiquen
dpkg-source -x opensc_0.13.0g20140119193004-2.dsc
cd opensc-0.13.0g20140119193004/
dpkg-buildpackage -b
cd ..

Instalar el paquete (en este ejemplo para amd64) descargado del enlace de arriba (o el generado desde las fuentes) con:

sudo dpkg -i opensc_0.13.0g20140119193004-2_amd64.deb

NOTA: el fichero /etc/opensc/opensc.conf ya tiene incluidas estas modificaciones:

provider_library = /usr/lib/libpcsclite.so.1 cambiado a
- /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 para 64bit
- /usr/lib/i386-linux-gnu/libpcsclite.so.1 para 32bit
enable_pinpad=false
plug_and_play=false

Para usar una tarjeta ceres y el dnie:

Para el caso en el que necesitemos usar una tarjeta ceres, opensc no nos sirve (de momento).
Necesitamos instalar un 'controlador' suministrado por la fnmt, desde su página de descargas: hay que ir al final de la página, y en el apartado "Librerías MultiCard FNMT-DNIe" bajar e instalar las correspondientes a
"Debian Wheezy (GNU/LINUX Debian 7.0 (Wheezy) - XX bits"

El fichero descargado ( libpkcs11-fnmtdnie_1.2.2_Debian_7_64bits.deb, para la versión de 64bits) sirve tanto para Wheezy como para Jessie.

Instalar el paquete debian:

sudo dpkg -i libpkcs11-fnmtdnie_1.2.2_Debian_7_64bits.deb

Ajustes en el navegador (Iceweasel/Firefox):

Ir a Preferencias/Avanzados/Certificados/Dispositivos de seguridad/Cargar
Poner un nombre como "DNIE" o "Tarjeta Ceres" por ejemplo
Si se tiene dni electrónico:

Para Wheezy: escribir /usr/lib/opensc-pkcs11.so en el nombre de archivo.
Para Jessie 64bit: escribir /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so en el nombre de archivo
Para Jessie 32bit: escribir /usr/lib/i386-linux-gnu/opensc-pkcs11.so en el nombre de archivobñ

Si usamos una tarjeta ceres: escribir /usr/lib/libpkcs11-fnmtdnie.so en el nombre de archivo


Configurar acceso a dnie/tarjeta

En otra entrada de este blog, había escrito una versión alternativa de como usar una tarjeta ceres.
Hacía un downgrade de algunos paquetes para poder generar el paquete libpkcs11-fnmtdnie_1.2.0_{amd64,i386}.deb usando el código fuente disponible desde la página de descargas de la fnmt: necesitaba instalar opensc v0.11 (lo que obligaba a bajar a la versión de pcsc-lite 1.5.5) para poder compilar el paquete.
Total, un jaleo tremendo que al final no era necesario, ya que bastaba con instalar el paquete anteriormente dicho, para después usar /usr/lib/libpkcs11-fnmtdnie.so con Firefox. Eso sí, opensc-tool -D indicaba que soportaba las tajetas ceres.

Otros ajustes

He visto avisos sobre la configuración del navegador para el uso de páginas de la Administración, que indican que en caso de fallos al acceder, se cambie un ajuste en firefox, concretamente este:

security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref

Por lo que parece, no es que sea una opción recomendable, de hecho YO NO TENGO ACTIVADA ESA OPCIÓN y no he tenido problemas, aunque en caso necesario ...

...se activa poniendo about:config en la barra de direcciones del navegador, aceptando el aviso y escribiendo en Buscar: renego
Pinchamos dos veces en la línea donde aparezca el ajuste citado hasta que en la columna Valor ponga true. Más aquí.

Ajustes en firefox con about:config

También he visto que algunas páginas (aeat principalmente) recomiendan que esta propiedad...

signed.applets.codebase_principal_support

...sea activada. Parece ser que si se usa la página de aeat es un requisito.
Para activarla se hace de la misma forma que para la propiedad anterior, solo que buscando signed.applet

Ajustes en java

Abrir el panel de control de java (jcontrol), pestaña Seguridad, marcar Activar contenido en el navegador... ,
Para permitir la carga de applets a veces será necesario indicar que se fíe de ciertos sitios web. Para ello, pinchar en Editar lista de sitios y rellenar con los sitios web habituales que usaremos con java. Yo tengo algo como esto aunque es evidente que algunos dependeran de los servicios web que visitemos - Ayuntamientos, Comunidades Autónomas)

https://av-dnie.cert.fnmt.es

https://valide.redsara.es

https://sede.gobcan.es

http://www.gobiernodecanarias.org

https://www.gobiernodecanarias.org

http://delta.empleo.gob.es

https://delta.empleo.gob.es

https://explotacion.mtin.gob.es
https://sede.seg-social.gob.es
https://w2.seg-social.gob.es
https://w6.seg-social.gob.es (->este parece ser necesario para que cargue el applet de firma)

(por cierto que esta lista se guarda en el fichero ~/.java/deployment/security/exception.sites)

Panel de control java / seguridad

También necesitaremos instalar el certificado raiz de la fnmt que descargamos e instalamos antes en el navegador en el almacén de java:

Almacén de certificados para Autoridades de Certificación (java 8)

Por cierto que en el fichero /etc/environment tengo puesto lo que sigue para que java escoja los certificados que hayamos importado usando el panel de control de java:

export _JAVA_OPTIONS="-Djavax.net.ssl.keyStore=.java/deployment/security/trusted.clientcerts -Djavax.net.ssl.trustStore=.java/deployment/security/trusted.jssecacerts"

El fichero trusted.clientcerts corresponde con el almacén que que obtenemos al seleccionar en el gestor de certificados el tipo "Autenticación de cliente" (donde importamos nuestros certificados personales de la fnmt).
Y el fichero trusted.jssecacerts corresponde al tipo "CA de Sitio Seguro".

Realmente la línea es esta:

export _JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=on -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel  -Djavax.net.ssl.keyStore=.java/deployment/security/trusted.clientcerts -Djavax.net.ssl.trustStore=.java/deployment/security/trusted.jssecacerts"

Las dos primeras opciones son para que el aspecto de las aplicaciones java tengan una estética similar a las aplicaciones normales del sistema.

Un último detalle: el caso Websigner

Por lo que he podido averiguar, Websigner es una 'plataforma' de autenticación/firmado en forma de applet java usada en algunas sedes electrónicas de la Administración Española, creada por tb-solutions.

Para usarlo, bastaría con conectar a la página que lo use, se carga un applet que descarga 33 ficheros jar con nombre ws*.jar y tras el reinicio del navegador ya deberíamos poder hacer gestiones tanto con los certificados instalados en el navegador como con el dni electrónico.

En teoría. En la práctica, a día de hoy sólo he conseguido que funcione en Iceweasel/Firefox bajo Linux (no va en Firefox 27/Windows XP), después de que se hagan dos 'apaños' previos.

Hacer que websigner pueda encontrar las bibliotecas de los paquetes libnss3 y libnspr4 en /usr/lib (ver más adelante).
Autorizar escritura en directorio lib/ext de la maquina virtual java para que websigner pueda guardar los 33 jars que necesita.

Para lo primero: Instalar este deb: link-mozilla-nss-nspr-websigner-fix_0.2_all.deb que básicamente lo que hace es enlazar en /usr/lib/ los .so que contienen los paquetes libnss3 y libnspr4, para que el applet pueda funcionar correctamente. (Ver primera nota al final de este apartado si se necesita repetir este proceso muchas veces)

Básicamente lo mismo que esto que sigue, pero con ciertas comprobaciones previas:

for I in $(dpkg -L libnss3:$(dpkg --print-architecture) libnspr4:$(dpkg --print-architecture) | grep '.so$'); do
      test -f /usr/lib/$(basename $I) || ln -s $I /usr/lib/
done

Para lo segundo: MOMENTANEAMENTE hacemos escribible el directorio lib/ext de java:

Hay manuales que indican que, sólo durante la instalación del applet, se ejecute el navegador como root (con sudo). Yo la verdad es que prefiero hacer lo que sigue:

sudo chmod o+w $(readlink -f /etc/alternatives/java | sed -e 's/\/bin\/java$//')/lib/ext

Abrimos el navegador y vamos a está página del Ayuntamiento de Zaragoza (ver nota más adelante de por qué precisamente en esta página): http://www.zaragoza.es/recursos_unicos/firma/ayudaComponenteFirma.jsp (v6.3.0.10)
aceptamos el uso del plugin de java, recargamos la página y esperamos a que termine la descarga. Nos aparecerá una ventana como esta:


Descarga de los 33 jar de websigner

Cuando termine, cerramos el navegador y volvemos a dejar los permisos de lib/ext como estaban

sudo chmod o-w $(readlink -f /etc/alternatives/java | sed -e 's/\/bin\/java$//')/lib/ext
# Si hacemos un 
ls -l $(readlink -f /etc/alternatives/java | sed -e 's/\/bin\/java$//')/lib/ext/
# Tendríamos que ver 33 ficheros jar (entre otros) con nombres que comienzan por ws63

Si se ha instalado el deb que indicaba antes (link-mozilla-nss-nspr-websigner-fix_0.2_all.deb), podemos copiar los .jar al directorio /usr/local/lib/asf-websigner/jar/ para que sean 'reinstalados' en caso de actualizaciónes de java.

Finalmente volvemos a ir a la misma página de antes y, si todo fue bien, al final deberíamos tener algo como esto:

Verficación de Websigner

¿Por qué tiene que ser esta página del Ayuntamiento de Zaragoza?. No tiene que ser esa necesariamente. Simplemente es porque tiene la última versión que he localizado (la 6.3.0.10).

Podríamos haber ido a una sede del Gobierno de Canarias, por ejemplo aquí: https://sede.gobcan.es/industriaycomercio/ticketsso/tramites/3158, y hubieramos obtenido la versión 6.3.0.2.

Pero si visitamos alguna página que necesite una versión superior, va a mostrar un diálogo preguntando si queremos actualizar la versión:

WebSigner Pedirá actualización si detecta una versión más reciente

Si queremos actualizar tendremos que volver a permitir escritura en el directorio lib/ext de java (por ej. sudo chmod o+w /usr/lib/jvm/java-7-oracle/jre/lib/ext), actualizar y volver a dejar como estaba (o-w).

Total, un lío: si todo funciona con la versión más alta, pues dejémoslo así y nos ahorramos preguntas.
Si no, pues descargar la versión que nos funcione desde la página que vayamos a usar habitualmente.

Notas sobre Websigner:

El deb para enlazar las bibliotecas de libnss3 y libsnpr4, contiene un directorio /usr/local/lib/asf-websigner/jar donde podemos colocar los ws*.jar que se descargan, y después hacer un sudo dpkg-reconfigure link-mozilla-nss-nspr-websigner-fix: con esto el paquete enlaza/copia los jar a las máquinas virtuales java instaladas (las que esten registradas en el sistema de alternativas de debian), por lo que se simplifica el proceso de preparación del applet si se ha de hacer más de una vez: instalar paquete+copiar_jars+reconfigure => listo para usar websigner. De hecho incluso yo tengo los .jar integrados dentro del deb. Evidentemente, no puedo poner el deb con los jar incluidos ya que desconozco las condiciones / licencia bajo las que se distribuye. Hubiera sido más fácil, pero... en fin!. (más fácil hubiera sido que los jar se descargaran en un directorio bajo $HOME y no en un directorio de sistema, como hace por ejemplo el applet de la GISS. Alguna razón tendrían)
Las bibliotecas de mozilla nss3 y nspr4, supongo que las usa el applet para acceder a los almacenes y el pkcs11 de firefox/iceweasel. Es necesario el enlace de los ficheros .so a /usr/lib ya que observando los logs de java, el applet en cada inicio copia estos ficheros .so al directorio ~/.WebSigner/version/*/SystemLibs/ y después los carga desde ahí. El problema es que justo al inicio de la carga, borra el directorio completo y trata de volverlos a copiar. Si no encuentra de dónde sacarlos falla el applet. Y ¿por qué no los iba a encontrar? Porque SIEMPRE busca en /usr/lib o /lib. Debian desde la versión 7 utiliza multiarch lo que entre otras cosas implica que cada arquitectura tiene su propio directorio dedicado (por ejemplo /usr/lib/x86_64-linux-gnu/ para 64bits) y ya no usa como regla general /usr/lib/ para las bibliotecas, como es el caso de libnss3 y libnspr4. Si enlazo estos ficheros .so a /usr/lib/ soluciono el problema y no estoy (creo) liando demasiado el sistema ya que /usr/lib se supone que tiene bibliotecas de la 'arquitectura principal' (si es que existe tal cosa).
Cada página que usa websigner tiene integrada una versión que puede no ser la que esta instalada bajo lib/ext. Sin embargo si tenemos la última no he observado problemas a la hora de funcionar con el applet. Las versiones que he encontrado son la 6.3.0.10 (que parece ser la más reciente), la 6.3.0.3, y la 6.3.0.2, para la rama 6.3 cuyos nombres de fichero comienzan por ws63. También me tropecé una vez con una 6.0.0.1 (ws60 - nunca conseguí hacer que cargara ningún certificado, aún lo investigo) y con una 5.7.3.0 (no parece necesitar descarga alguna en lib/ext). Probablemente para las que no son 6.3 habrá que volver a poner lib/ext como escribible para permitir la carga tal y como se hizo con la 6.3

Algunos 'truquillos' finales

Applets que a veces no parecen cargar.
Con firefox, dependiendo de la versión, nos podemos encontrar con que tendremos que estar respondiendo preguntas tipo "Permitir ejecución" para el plugin de java. Yo particularmente lo tengo ajustado de este modo de manera que no está activado salvo para las páginas que me interesan. Cuando lo autorizo, lo siguiente que hago es recargar la página para que recargue el applet de java.

Dni electrónico.
El dni electrónico tiene sus 'manías'.
Si al acceder no puede conectar con el mensaje "Conexión segura fallida", reiniciar el navegador con la tarjeta insertada, o ir a las preferencias del navegador y abrir la ventana de certificados para forzar un inicio de sesión con la tarjeta.
El navegador y los applet de java se bloquean mutuamente el acceso a las tarjetas criptográficas. Normalmente se soluciona extrayendo el dni del lector (he leído que no se debe NUNCA extraer el lector con el dni insertado).
La 'lógica' que suelo emplear es reinsertar el dnie después de que cargue la página donde me he autentificado (sobre todo si se ha usado para ello el almacén del navegador - por la pinta de los cuadros de diálogo al final uno llega a saber si es java o el navegador el que pregunta).

Applet de la sede de la SS (pros@).
El applet usado en el servicio Mis Notificaciones de la Seguridad Social a fecha de hoy (julio/2015) sólo funciona para 32bit (certificado y/o dnie).
Para sistemas de 64bit da la opción de usar certificados cargándolos desde un fichero p12/pfx.
(Es una pena porque parece ser que aparentemente 'sólo' sería cuestión de que recompilaran dos ficheros (~/{dsiglibs,GISS}/libNss4JavaLinux*.so y ~/{dsiglibs,GISS}/libGtkSelectCertificates*.so a 64 bit, y que en la descarga inicial se bajara el fichero correcto en función de la plataforma detectada. Eso así a bote pronto. No se si en realidad sería más complicado).

Applet de firma en el servicio de Notificaciones (mostrando certificado y dnie) (32bit)

Documentos PDF.

Ya que estamos con la Seguridad Social, me he encontrado con casos en los que que a la hora abrir un pdf (concretamente el de una notificación que acabamos de firmar) se abre una pestaña en blanco y así se queda.
Una solución es la de pinchar con el botón derecho y escoger "Guardar enlace como...", guardarlo y abrir después el fichero pdf.

Si se quiere la versión "por el camino difícil: lo quiero en una pestaña/ventana del navegador", debo decir que he probado con programas como evince o qpdfview cargados en una ventana/pestaña del navegador a través de mozplugger y lo normal es que funcionen en la mayoría de sitios, pero no en este caso.

Para el que esté interesado, este es el contenido del fichero /etc/mozpluggerrc.d/62-pdfqpdfview.conf
(Ojo: En el fichero /etc/mozpluggerrc.d/62-pdfqpdfview.conf comentar la sección "application/pdf:pdf:PDF file"):

#########################
### PDF with qpdfview ###
#########################

application/pdf:pdf:PDF file
application/x-pdf:pdf:PDF file
text/pdf:pdf:PDF file
text/x-pdf:pdf:PDF file
       repeat noisy swallow(qpdfview) fill : qpdfview "$file"

application/x-postscript:ps:PostScript file
application/postscript:ps:PostScript file
       repeat noisy swallow(qpdfview) fill : qpdfview "$file"

Muestro la configuración para qpdfview que es el que mejor me ha funcionado con mozplugger/firefox en jessie.
Evince en wheezy con esta configuración iba bien, pero a partir de jessie no me admite swallow (no funciona bien incrustado en firefox, IIRC creo que por el tema CSD)
Okular por otra parte parece ir bien pero tiene la manía de perder el manejo con el teclado, y probando a cambiar needs_xembed no corrige nada.

Si además se precisa de un lector de pdf que realice verificación de pdf firmados, Adobe Reader es la única solución que conozco.
Una solución que me ha funcionado es la de utilizar Adobe Reader a través de pipelight, una manera de usar plugins de windows bajo una versión especial de wine.
Y según mi experiencia no va mal con Adobe Reader 11, de hecho a mi me ha ido mejor que con las versiones para linux, mientras las hubo.

Para el que quiera probar, las instrucciones muy resumidas son estas:

# Ojo: esto es para jessie. 
# Ver instrucciones de instalación en http://pipelight.net/cms/install/installation-debian.html
wget http://repos.fds-team.de/Release.key
sudo apt-key add Release.key
echo "deb http://repos.fds-team.de/stable/debian/ jessie main" | sudo tee /etc/apt/sources.list.d/pipelight.list
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install pipelight-multi
pipelight-plugin --accept --unlock adobereader   # lo de --accept es para aceptar la licencia del plugin 
pipelight-plugin --accept --enable adobereader   #
rm $HOME/.mozilla/firefox/*.default/pluginreg.dat  # Forzar 'redetección' de plugins en firefox
# Ahora activar el plugin en about:addons

Adobe Reader 11 como plugin bajo pipelight en Firefox 39 (debian jessie)

Delt@ (Declaración electrónica de Trabajadores Accidentados) de la SS.
En esta sede se usa websigner 5.7.3.0 y parece cargar correctamente los certificados instalados en el navegador. No he conseguido que cargue los certificados en tarjeta (ceres / dnie). Tampoco he podido hacer muchas pruebas ya que no tengo acceso a la plataforma
El applet muestra un 'Error cargando token externo: Error parsing configuration: java.security.ProviderException: Error parsing configuration'

Cuando no se muestra ningún certificado.
Hay sitios donde a la hora de firmar, el certificado de usuario no es accesible a través del navegador (ya del dnie ni hablamos), como el Servicio de notificaciones electrónicas.
Para que funcionen instalamos el certificado de usuario en el almacen de Java: panel de control (jcontrol) / Seguridad / Gestionar certificados /Tipo de certificado: autenticación de cliente / Importar
Pedirá la contraseña asignada en su momento al fichero p12 o pxf del certificado personal, y si es la primera vez que importamos un certificado, pedirá también una clave nueva para usar con el almacén de java:

Certificado personal importado en el almacén de claves de java

Hay sitios donde la identificación y/o firma se realiza cargando directamente el fichero de nuestro certificado personal a través de un applet, como ocurre por ejemplo en https://www.gobiernodecanarias.org/dragoweb/index.htm

Selección de fichero de certificado a través de applet java como medio de acceso - no se usa almacén del navegador

Pruebas

Bueno, hasta aquí todo debería ir bien. Y para comprobarlo lo mejor es ir directamente a probar en las siguientes páginas:

Site vale

Notas sobre acceso a Administación Electrónica (Debian Wheezy/Jessie con dnie/ceres)