-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux error SAF_19 #16
Comments
Hola Valentín,
¿Qué versión de Java usas?
El 10/2/2018 12:48 p. m., "Valentin" <notifications@github.com> escribió:
Buenas,
Tengo instalado Autofirma 1.6 en mi Linux (Manjaro 17), el cual no puedo
utilizar a través del portal portafirmas <https://portafirmas.um.es> de la
Universidad de Murcia. Utilizo Firefox 58
Cuando procedo a firmar, recibo el siguiente error:
[image: image]
<https://user-images.githubusercontent.com/5502443/36061792-cc1f5e54-0e5f-11e8-8020-3311c6534179.png>
Utilizando la aplicación gráfica, no hay ningún problema: Me sale el
diálogo del almacén de claves y puedo usar mi firma. Sin embargo, desde
Firefox tengo el siguiente error y no sé dónde se consultan los
certificados (el certificado está instalado en el almacén del navegador,
por lo que supongo que no lo coge de ahi).
Un saludo,
Valentín
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#16>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFopALZFPik5kasNvbYWOKXuT51a3-Wcks5tTYH6gaJpZM4SA5vT>
.
|
Buenas,
Salu2 |
Hace tiempo que no me pasa, pero antes era cosa de las libnss o un perfil corrupto de firefox. Yo probaría a crear un perfil nuevo, cargar en él tu certificado y reinstalar Autofirma (si no lo reinstalas no te añadirá su propio certificado). Autofirma lo instalas desde un paquete, no? |
Acabo de probarlo, y nada. Sigue saliendo el mismo error... Para hacerlo en limpio, he renombrado la carpeta .mozilla e instalado mi certificado y el CA de la FNMT. Luego he cerrado firefox y reinstalado el paquete autofirma. A continuación, entré en la web para probar nuevamente, pero sigue apareciendo el error. @alfem Si, uso el paquete de AUR pero modificado para instalar la 1.6: https://gist.github.com/vk496/1196ec3a13689cd66a77e96e4b1f0cca Salu2 |
He visto que el log se encuentra en .afirma. He probado a hacer nuevamente una ejecución en limpio, pero además renombrando la carpeta .pki, pero no ha surgido ningún resultado. Adjunto la saldia: <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE log SYSTEM "logger.dtd">
<log>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202147</millis>
<sequence>0</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.ProxyUtil</class>
<method>setDefaultProxy</method>
<thread>1</thread>
<message>Las conexiones para protocolo 'http' son por defecto de tipo: DIRECT</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202179</millis>
<sequence>1</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.ProxyUtil</class>
<method>setDefaultProxy</method>
<thread>1</thread>
<message>Las conexiones para protocolo 'https' son por defecto de tipo: DIRECT</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202179</millis>
<sequence>2</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.ProxyUtil</class>
<method>setProxySettings</method>
<thread>1</thread>
<message>No se usara Proxy para las conexiones de red</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202181</millis>
<sequence>3</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.SimpleAfirma</class>
<method>main</method>
<thread>1</thread>
<message>No se buscaran nuevas versiones de la aplicacion</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202185</millis>
<sequence>4</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.SimpleAfirma</class>
<method>printSystemInfo</method>
<thread>1</thread>
<message>Resolucion DPI de pantalla: 0
Sistema operativo: Linux
Version del SO: 4.14.16-1-MANJARO
Version de Java: 1.8.0_144
Arquitectura del JRE: 64
Java Vendor: Oracle Corporation
Localizacion por defecto: es_ES
Tamano actual en memoria: 75MB
Tamano maximo de memoria: 862MB
Memoria actualmente libre: 52MB</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202188</millis>
<sequence>5</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.SimpleAfirma</class>
<method>main</method>
<thread>1</thread>
<message>Invocacion por protocolo con URL:
afirma://service?ports=56438,60250,63316&v=1&idsession=p8NVMzqycWsRPhjU4o2D</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202199</millis>
<sequence>6</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ProtocolInvocationLauncher</class>
<method>launch</method>
<thread>1</thread>
<message>Se inicia la invocacion por servicio: afirma://service?ports=56438,60250,63316&v=1&idsession=p8NVMzqycWsRPhjU4o2D</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202206</millis>
<sequence>7</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>startService</method>
<thread>1</thread>
<message>Se utilizara el siguiente almacen para establecer el socket SSL: /usr/lib/AutoFirma/autofirma.pfx</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202365</millis>
<sequence>8</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>startService</method>
<thread>1</thread>
<message>Iniciando servicio local de firma: afirma://service?ports=56438,60250,63316&v=1&idsession=p8NVMzqycWsRPhjU4o2D</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202366</millis>
<sequence>9</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>getPorts</method>
<thread>1</thread>
<message>Se ha recibido un idSesion para la transaccion: p8NVMzqycWsRPhjU4o2D</message>
</record>
<record>
<date>2018-02-12T11:10:02</date>
<millis>1518430202368</millis>
<sequence>10</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>tryPorts</method>
<thread>1</thread>
<message>Establecido el puerto 56438 para el servicio Cliente @firma</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203483</millis>
<sequence>11</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>startService</method>
<thread>1</thread>
<message>Detectada conexion entrante</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203551</millis>
<sequence>12</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>getCommandUri</method>
<thread>19</thread>
<message>Recibido comando de tipo: echo=</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203552</millis>
<sequence>13</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>doEchoPetition</method>
<thread>19</thread>
<message>Comando URI recibido por HTTP: echo=</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203554</millis>
<sequence>14</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>sendData</method>
<thread>19</thread>
<message>Mandando respuesta a la peticion: echo=</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203558</millis>
<sequence>15</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>startService</method>
<thread>1</thread>
<message>Detectada conexion entrante</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203565</millis>
<sequence>16</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>getCommandUri</method>
<thread>20</thread>
<message>Recibido comando de tipo: cmd=</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203566</millis>
<sequence>17</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>doCmdPetition</method>
<thread>20</thread>
<message>Comando URI recibido por HTTP: afirma://selectcert?op=selectcert&properties=ZmlsdGVycz1zdWJqZWN0LmNvbnRhaW5zOlg5NDAwOTYx</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203568</millis>
<sequence>18</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.core.misc.protocol.ProtocolInvocationUriParser</class>
<method>parserUri</method>
<thread>20</thread>
<message>URI recibida: afirma://selectcert?op=selectcert&properties=ZmlsdGVycz1zdWJqZWN0LmNvbnRhaW5zOlg5NDAwOTYx</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203596</millis>
<sequence>19</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.mozilla.shared.SharedNssUtil</class>
<method>getSharedUserProfileDirectory</method>
<thread>20</thread>
<message>Detectado directorio de perfil de NSS: ̴/.pki/nssdb</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203597</millis>
<sequence>20</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.mozilla.MozillaKeyStoreUtilities</class>
<method>loadNSS</method>
<thread>20</thread>
<message>Configuracion de NSS para SunPKCS11:
name=NSSCrypto-AFirma
library=/usr/lib64/libsoftokn3.so
attributes=compatibility
slot=2
showInfo=false
allowSingleThreadedModules=true
nssArgs="configdir='sql:/USERHOME/.pki/nssdb' certPrefix='' keyPrefix='' flags='readOnly'"</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203617</millis>
<sequence>21</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.mozilla.MozillaKeyStoreUtilities</class>
<method>loadNSS</method>
<thread>20</thread>
<message>Proveedor PKCS#11 para NSS anadido para perfil compartido: SunPKCS11-NSSCrypto-AFirma</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203622</millis>
<sequence>22</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.AOKeyStoreManager</class>
<method>init</method>
<thread>20</thread>
<message>Inicializamos el almacen de tipo: DNIe y tarjetas FNMT-TIF</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203650</millis>
<sequence>23</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.KeyStoreUtilities</class>
<method>addPreferredKeyStoreManagers</method>
<thread>20</thread>
<message>No se ha encontrado un DNIe: java.security.ProviderException: No se ha podido inicializar el proveedor de DNIe: es.gob.jmulticard.apdu.connection.NoReadersFoundException: No se detectaron lectores de tarjetas en el sistema</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203651</millis>
<sequence>24</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.AOKeyStoreManager</class>
<method>init</method>
<thread>20</thread>
<message>Inicializamos el almacen de tipo: G&D SmartCafe con Applet PKCS#15</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203656</millis>
<sequence>25</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.KeyStoreUtilities</class>
<method>addPreferredKeyStoreManagers</method>
<thread>20</thread>
<message>No se ha encontrado una tarjeta G&D SmartCafe: java.security.ProviderException: No se ha podido inicializar el proveedor: es.gob.jmulticard.apdu.connection.NoReadersFoundException: No se detectaron lectores de tarjetas en el sistema</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203657</millis>
<sequence>26</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.mozilla.MozillaKeyStoreUtilities</class>
<method>getMozillaPKCS11Modules</method>
<thread>20</thread>
<message>Se incluiran los modulos nativos de DNIe/CERES si se encuentran configurados</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203659</millis>
<sequence>27</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.mozilla.MozillaKeyStoreUtilities</class>
<method>getMozillaPKCS11Modules</method>
<thread>20</thread>
<message>Obtenidos los modulos externos de Mozilla desde 'pkcs11.txt'</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203662</millis>
<sequence>28</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.keystores.mozilla.MozillaUnifiedKeyStoreManager</class>
<method>init</method>
<thread>20</thread>
<message>No se han encontrado modulos PKCS#11 externos instalados en Firefox</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203663</millis>
<sequence>29</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ProtocolInvocationLauncherSelectCert</class>
<method>processSelectCert</method>
<thread>20</thread>
<message>Obtenido gestor de almacenes de claves: Gestor de almacenes de claves NSS con nombre NSS</message>
</record>
<record>
<date>2018-02-12T11:10:03</date>
<millis>1518430203666</millis>
<sequence>30</sequence>
<logger>es.gob.afirma</logger>
<level>SEVERE</level>
<class>es.gob.afirma.standalone.protocol.ProtocolInvocationLauncherSelectCert</class>
<method>processSelectCert</method>
<thread>20</thread>
<message>No hay certificados validos en el almacen: es.gob.afirma.keystores.AOCertificatesNotFoundException: No se han encontrado certificados en el almacen acordes a los filtros establecidos</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208837</millis>
<sequence>31</sequence>
<logger>es.gob.afirma</logger>
<level>SEVERE</level>
<class>es.gob.afirma.standalone.protocol.ProtocolInvocationLauncherErrorManager</class>
<method>showError</method>
<thread>20</thread>
<message>Ha ocurrido un error realizando la operación.
(SAF_19: No hay ningun certificado válido en su almacén. Compruebe las fechas de caducidad e instale un certificado válido.)</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208838</millis>
<sequence>32</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>calculateNumberPartsResponse</method>
<thread>20</thread>
<message>Se mandaran 1partes</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208839</millis>
<sequence>33</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>calculateNumberPartsResponse</method>
<thread>20</thread>
<message>tam total=122</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208840</millis>
<sequence>34</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>calculateNumberPartsResponse</method>
<thread>20</thread>
<message>Tamano de la parte 1 =122</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208841</millis>
<sequence>35</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>sendData</method>
<thread>20</thread>
<message>Mandando respuesta a la peticion: Se mandaran 1 partes</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208873</millis>
<sequence>36</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>startService</method>
<thread>1</thread>
<message>Detectada conexion entrante</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208877</millis>
<sequence>37</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>getCommandUri</method>
<thread>24</thread>
<message>Recibido comando de tipo: send=</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208878</millis>
<sequence>38</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>doSendPetition</method>
<thread>24</thread>
<message>Comando URI recibido por HTTP: @1@1</message>
</record>
<record>
<date>2018-02-12T11:10:08</date>
<millis>1518430208879</millis>
<sequence>39</sequence>
<logger>es.gob.afirma</logger>
<level>INFO</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>sendData</method>
<thread>24</thread>
<message>Mandando respuesta a la peticion: Mandada la parte 1 de 1</message>
</record>
<record>
<date>2018-02-12T11:11:38</date>
<millis>1518430298881</millis>
<sequence>40</sequence>
<logger>es.gob.afirma</logger>
<level>WARNING</level>
<class>es.gob.afirma.standalone.protocol.ServiceInvocationManager</class>
<method>lambda$static$0</method>
<thread>25</thread>
<message>Se ha caducado la conexion. Se deja de escuchar en el puerto...</message>
</record>
</log> |
Tienes instalado también el paquete ibnss3-tools ? |
Hola, No lo tenía instalado (en Arch no está marcado como dependencia). Lo he instalado (lib32-nss) y vuelto a probar, pero sigue saliendo el mismo error. Salu2 |
lib32-nss? Pero tienes 64 bits, no? Yo comprobaría que tienes estos enlaces a las librerías nss: https://github.com/gecos-team/java-nss-fix/blob/trusty/gcs/install_scripts/pos/create_symlinks |
Buenas, Si, tengo el de 64 bits. El paquete para Arch se llama así. Respecto a los enlaces simbólicos, no tengo ninguno de los que termina en .1d Salu2 |
Yo firmo con Firefox 52.6.0 (64-bit) ESR (Extended Support Release). Podrías probar a cerrar tu Ffox, e instalar esta versión de forma independiente (en /opt por ejemplo). A ver si hay suerte. |
Hola. :-( |
Otras cosillas que comprobar:
|
Parece que el applet de autofirma utiliza el almacén de llaves ubicado en ~/.pki/nssdb. Yo he resuelto este problema generando enlaces simbólicos sobre el almacén de llaves de firefox donde previamente he añadido mi certificado digital. MOZ_PROFILE=$(grep Path $HOME/.mozilla/firefox/profiles.ini|cut -d "=" -f2) \
&& if [ ! -d $HOME/.pki/nssdb ]; then mkdir -p $HOME/.pki/nssdb; fi \
&& ln -sf $HOME/.mozilla/firefox/$MOZ_PROFILE/*.db $HOME/.pki/nssdb/ Entorno:
|
Tendría que comprobarlo pero aunque el instalador oficial mete el certificado en .pki/nssdb, en realidad creo que no lo usa para nada. Ese fichero es para Gnome-Keyring, no para Firefox. |
@i-eperez Muchas gracias! Efectivamente, haciendo enlaces simbólicos de las db de firefox a ~/.pki/nssdb, funciona perfectamente. Salu2 |
Que cosa más rara. Mi Firefox guarda los certificados en el directorio del perfil, en un fichero cert8 que está en formato dbm, mientras que en .pki/nssdb hay un cert9, que está en formato sqlite3. |
Finalmente he firmado desde Windows 10, pero en ese caso, aunque configuraba AutoFirma para usar el almacén de claves de Firefox, desde el applet solo busca en Internet Explorer. Gracias. |
@alfem no es muy fácil seguir la traza del código, pero si ves en Lo que no entiendo es de dónde sale el Mañana probaré a hacer lo que decís del enlace simbólico. De todos modos, mi caso (Fedora 64 bits) además de esto parece que tampoco encuentra siempre las librerías de Firefox de 64 bits puesto que aunque en este comentario parezca que se haya tenido en cuenta a la distribución esto debe de ser de alguna versión antigua y EOL; en las versiones actuales de Fedora, |
Buenas noches. Estaba dándole caña a todo el proceso de Autofirma y dándome de cabezazos mientras debugueaba a ciegas. Entorno: |
Yo acabo de empaquetar y probar la 60ESR y no consigo firmar. Salta el SAF_19, incluso enlazando el .pki. Habra que "cavar" un poco más. |
Uf. Ya firmo con Firefox60ESR y Autofirma 1.6.1. Y he comprobado que no tengo el directorio .pki/nssdb |
@alfem ¿y cómo lo has conseguido?, yo uso ubuntu 18.04 con Firefox 60 ESR y no hay manera |
Uso GECOS, y la última estable está basada en Ubuntu 16.04 (aunque va con Cinnamon como escritorio) http://gecos-team.github.io/ Ahora que la nueva Mint ha salido empezaremos a probar Autofirma contra Ubuntu 18.04. A ver qué pasa. |
Acabo de probar en una ubuntu 18.04 con firefox60.0.2esr y Autofirma 1.6.1, y la firma desde varias web funciona correctamente. Eso sí, los paquetes de firefox y autofirma son "un poco especiales" para GECOS. |
Buenos días! Era una cosa que me traía de cabeza, |
Buenos días Tengo autofirma 1.6.2 y firefox 61.0.1 (64bits) instalados en Ubuntu 16.04 (64 bits) y tengo ese mismo error (SAF 19) que no consigo solucionar creando los enlaces simbólicos que se indicaban en el comentario de i-eperez... Creo que quizá debo tener un error previo porque no me funciona la aplicación lanzándola desde el escritorio ni cuando es invocada desde firefox. Bueno, funciona pero no puede firmar porque me sale el error SAF 19 Esta es la salida que se encuentra en el directorio .afirma Quizá el error tiene que ver con También me extraña esta línea Al instalar autofirma el terminal también daba algún error Seleccionando el paquete autofirma previamente no seleccionado. Replacing debian:AutoFirma_ROOT.pem Y al ejecutar el programa desde consola: jul 18, 2018 7:24:45 PM es.gob.afirma.standalone.ProxyUtil setDefaultProxy jul 18, 2018 7:24:45 PM es.gob.afirma.keystores.AOKeyStoreManager init Espero que alguién sea capaz de ponerme en la pista de los errores... no tengo una gran experiencia a este nivel y me acabo perdiendo un poco. Gracias de antemano. |
Sí que es raro. Parece que tienes una ubuntu 64bits, pero con las librerías i386. ¿Podrías lanzar esto y pegar el resultado?
|
Acabo de probar la solución de @i-eperez y ¡funciona! Mis datos son: Sistema operativo: Linux (Xubuntu 18.04 64 bits) Eso sí, debo indicar me ha funcionado con java-8-oracle como máquina de java. Cuando cambio a java-10-oracle (10.0.2), que es la última versión disponible, el programa deja de funcionar. Os indico qué sale en AutoFirma cuando lo ejecuto en el terminal con Java 10.
|
Hola Alfem, siento la tardanza en contestar... Este es el resultado de dpkg -l libnss* Deseado=desconocido(U)/Instalar/eliminaR/Purgar/retener(H) Creo que tuve que instalar librerías de 32bits para un programa de robótica, no recuerdo bien si finalmente fueron todas o solo las necesarias... Gracias de antemano |
Pues de libnss3 de i386:
|
Y has instalado tú ese paquete? Puedes desinstalarlo? |
Hola. |
Hola, $ AutoFirma |
He conseguido firmar con el combo de desactivar el JMulticard y la opción firefox -P para borrar el segundo perfil en firefox que tenía |
Ayudé alguien con este error, y lo siguiente es lo que funcionó. Sistema: Ubuntu 20.10, Firefox 84. Requisito previo: certificado instalado en Firefox.
Lo que no fue necesario fue modificar La raíz del problema el proceso de instalación del paquete de Autofirma que, a parte modificar la sesión de usuario (primera vez que veo eso en 19 años de usar distribuciones basadas en Debian), espera encontrar unas condiciones que no son seguras ni, actualmente, probables: Java 8 y un perfíl único de Firefox (aún solo actualizarlo puede producir otro perfíl). |
Buenas, después de mil años intentando firmar, sin éxito, mediante certificado digital, acabo de conseguirlo con el DNIe (compré un lector barato en aliexpress). Estoy en Debian 10 y usando |
Buenas. Yo he conseguido firmar cambiando el jdk que estaba usandose (java 9) al de java 8, mediante el comando que @bard comentó anteriormente: Antes recibía el siguiente error:
Estoy en Ubuntu 16.04. |
Hola, yo tengo una instalación nueva de LUbuntu 20.04. Al instalar Autofirma 1.6.5 me daba la excepción Cuando digo que ahora me funciona, en realidad es de forma parcial. Sólo funciona bien si arranco desde consola, si lo hago desde el .Desktop se bloquea mientras firma documentos, y desde el navegador parece que no consigue conectar con el applet de AutoFirma. |
Hola,
La instalación que tengo es:
¿Alguna pista de qué puede estar pasando en el Firefox que me esté bloqueando o no alcanzando a la aplicación de Autofirma? He leído muchos foros pero no consigo resolver el problema y me da la impresión que en este hilo es donde más habéis tratado con él. GRACIAS !! Luis Aporto información adicional de la respuesta de Autofirma al arrancar y al restaurar la aplicación. Disculpad el tamaño ... Aporto también lo que me da el Autofirma cuando lo arranco con la interfaz gráfica:
Y aquí incluyo la información de Autofirma cuando restauro la aplicación ....
|
Prueba a lanzar este comando: xdg-mime query default x-scheme-handler/afirma También sería interesante ver la salida de Firefox cuando intentas acceder a Valide para realizar alguna operación. |
Gracias Alfonso ( @alfem ), la salida del comando es la siguiente ...
El fichero se encuentra aqui:
And afirma.desktop contains:
And the executable /usr/bin/AutoFirma is here:
Parece ok, no? Respecto a seguir la salida de firefox , ¿me podrías indicar algún tipo de comando / fichero / herramienta donde pudiera encontrar la salida/problemas que dieran alguna pista. Disculpa, no estoy familiarizado con Firefox ni con herramientas web. Gracias, Luis |
Sí, parece ok.
Sólo tienes que lanzar firefox desde la línea de comandos, igual que has hecho con Autofirma. Después navegas a la web de valide, y trata de hacer algo con la firma. Verás que en el terminal donde lanzaste Firefox hay un montón de lineas de depuración, que a veces dan pistas. |
Gracias @alfem Esto es lo que saca el Firefox durante el fallo de conexión con AutoFirma. Por la pantalla de la web dice: java.util.concurrent.TimeoutException: No se pudo contactar con AutoFirma En la consola desde la que he lanzado Firefox:
He instalado la librería libslf4j-java , la instalación parece OK, pero en resultado sigue siendo el mismo desafortunadamente que arriba.
|
De momento todo está ok. La librería libslf4j-java no hace falta instalarla. Por aclarar lo que pasa, te cuento un poco por encima cómo funciona esto: Al tratar de firmar con Firefox, éste llama a una url de tipo "afirma" que tiene este formato: afirma://websocket?v=3&idsession=wxWqKf0VsoKJue94KFKr Este tipo de url hace que se lance el programa Autofirma en background, y que se quede esperando un tiempo a que Firefox le pase lo que tiene que firmar. En tu caso, o bien AutoFirma no se está lanzando, o bien no pueden comunicarse porque no pueden establecer un canal seguro. Para comprobar lo primero, puedes hacer esto:
Si es así, entonces sólo falta ver qué le pasa al canal seguro. ¿Tienes más de un perfil en Firefox? |
Hola @alfem Alfonso, He hecho la prueba que me has dicho. Durante todo el proceso con el grep obtengo la misma respuesta y se mantiene incluso después de recibir el error. Esto es lo que responde el terminal ...
Asi que parece que lanza (o trata de lanzar) el Autofirma pero la comunicación no se establece bien y termina en un java.util.concurrent.TimeoutException: No se pudo contactar con AutoFirma ¿No? Gracias |
Así que parece que aunque Firefox lanza el AutoFirma correctamente, no se comunican. Normalmente es porque el certificado para cifrar esa comunicación no coincide en ambos extremos. Pasa cuando se instala y desinstala AutoFirma varias veces, o porque tienes más de un perfil en Firefox. Mira en Firefox->Ajustes->Privacidad y Seguridad->Certificados->Ver Certificados. Selecciona "Autoridades" y busca a ver si tienes el de Autofirma ROOT LOCAL Ese es el que usa Firefox para hablar con el Autofirma en background. Si le das doble clic, podrás ver la fecha en que se creó. Debería coincidir con la fecha en que instalaste AutoFirma. |
He confirmado dos cosas:
|
Todo parece correcto. Sólo se me ocurre que sea porque usas Java8 y Autofirma 1.7 va con Java11. |
Hola Alfonso @alfem , Cuando utilizo el Java 11, me falla Autofirma 1.7.1 ... no se me abre ni siquiera la interfaz gráfica. Mira, esto es lo que me devuelve la terminal cuando cambio de Java:
Cuando vuelvo a Java 8, la interfaz gráfica me funciona, pero sigo con el problema de la interfaz con Firefox. Gracias. |
¿Como instalaste el java11? ¿con openjdk-11-jre? |
Ho
Francamente no lo recuerdo, creo que fue a través de la consola siguiendo algún tutorial. Lo que veo es que entrando en el gestor gráfico de aplicaciones no lo veo activado .... Te da alguna pista? ¿Crees que debo de desinstalarlo e instalarlo de algún otro modo? |
Tienes instalado el paquete openjdk-11-jre-headless. Lo de "headless" significa que es para ejecutar programas java que no muestren ventanas o diálogos gráficos. Agrega el primer paquete que te sale, el openjdk-11-jre, y así te debería funcionar Autofirma con java 11. |
Muchas gracias Alfonso @alfem !!!! Problema solucionado !!! Instalé el paquete que me has indicado y el Autofirma 1.7.1 se ha abierto bien tanto desde la aplicación gráfica como desde la llamada desde Firefox. Resumo la solución por si ayuda a otra persona:
Linux Mint - Cinnamon Muchas gracias por todo Alfonso por tu soporte (y paciencia). Un saludo, Luis Benítez |
#357 He probado todo lo que se comenta aquí pero no he conseguido saltar este error. |
Por si alguin todavía no lo conoce: https://github.com/alfem/FireFirma Pone todo lo necesario, configurado y listo para usar, en un sólo fichero. |
Exige la existencia de alguna librería de Java >= 11 sin exigir ninguna versión o proveedor particular. En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia de Java para la instalación: hay usarios que no quieren instalarse ninguna otra versión que la que ya tienen. Esto provoca mucho quebraderos de cabeza para usuarios que se instalan Autofirma sin leerse las instrucciones, acabando con instalaciones rotas - no es intuitivo para el usuario instalarse las dependencias manualmente. Para conciliar esto utilizamos los virtual packages de Debian: se supone que un paquete que da la funcionalidad de un JRE 11 debería de declarar en la sección Provides: del paquete que aporta java11-runtime. Si no hay ningún paquete que ya provea al sistema de un runtime de Java compatible con las versiones 11 o 17, se instala default-jre, versión >= 11. Nótese que para que dpkg tenga conocimiento de esa instalación previa de Java, debe de haberse instalado también con dpkg o apt. Según de cómo de acomodador se quiera ser a los usuarios con su instalación custom de Java fuera de dpkg, esto podría ser un breaking change para ellos. En mi opinión, este es un uso menor, viendo la cantidad de comentarios de la comunidad al respecto, como veremos. Así se resuelven muchos problemas de instalación: - un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el posteador) - resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto gracias a una aclaración indicando su problema con las dependencias. - closes ctt-gob-es#258, que simplemente pregunta desconcertado. - En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema instalando Java de Oracle. - En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o no de Autofirma varía de versión a versión. - close ctt-gob-es#259, el issue mencionado al principio de este commit message. - tenemos un tutorial/explicación y todo en ctt-gob-es#302 También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora, que sufre de exactamente lo mismo. De hecho: - ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java headless (el log errores menciona java.awt, abstract window toolkit). Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no headless. Referencias: https://wiki.debian.org/Java - sección Understanding Java Virtual packages names. La misma idea de usar virtual package names surge en varias preguntas de StackOverflow: - Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme - Depender de Java pero sin ser estricto en versiones https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
Exige la existencia de alguna librería de Java >= 11 sin exigir ninguna versión o proveedor particular. En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia de Java para la instalación: hay usarios que no quieren instalarse ninguna otra versión que la que ya tienen. Esto provoca mucho quebraderos de cabeza para usuarios que se instalan Autofirma sin leerse las instrucciones, acabando con instalaciones rotas - no es intuitivo para el usuario instalarse las dependencias manualmente. Para conciliar esto utilizamos los virtual packages de Debian: se supone que un paquete que da la funcionalidad de un JRE 11 debería de declarar en la sección Provides: del paquete que aporta java11-runtime. Si no hay ningún paquete que ya provea al sistema de un runtime de Java compatible con las versiones 11 o 17, se instala default-jre, versión >= 11. Nótese que para que dpkg tenga conocimiento de esa instalación previa de Java, debe de haberse instalado también con dpkg o apt. Según de cómo de acomodador se quiera ser a los usuarios con su instalación custom de Java fuera de dpkg, esto podría ser un breaking change para ellos. En mi opinión, este es un uso menor, viendo la cantidad de comentarios de la comunidad al respecto, como veremos. Así se resuelven muchos problemas de instalación: - un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el posteador) - resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto gracias a una aclaración indicando su problema con las dependencias. - closes ctt-gob-es#258, que simplemente pregunta desconcertado. - En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema instalando Java de Oracle. - En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o no de Autofirma varía de versión a versión. - close ctt-gob-es#259, el issue mencionado al principio de este commit message. - tenemos un tutorial/explicación y todo en ctt-gob-es#302 También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora, que sufre de exactamente lo mismo. De hecho: - ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java headless (el log errores menciona java.awt, abstract window toolkit). Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no headless. Referencias: https://wiki.debian.org/Java - sección Understanding Java Virtual packages names. La misma idea de usar virtual package names surge en varias preguntas de StackOverflow: - Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme - Depender de Java pero sin ser estricto en versiones https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
Exige la existencia de alguna librería de Java >= 11 sin exigir ninguna versión o proveedor particular. En el issue ctt-gob-es#259 se nos motiva por qué no se exige ninguna dependencia de Java para la instalación: hay usarios que no quieren instalarse ninguna otra versión que la que ya tienen. Esto provoca mucho quebraderos de cabeza para usuarios que se instalan Autofirma sin leerse las instrucciones, acabando con instalaciones rotas - no es intuitivo para el usuario instalarse las dependencias manualmente. Para conciliar esto utilizamos los virtual packages de Debian: se supone que un paquete que da la funcionalidad de un JRE 11 debería de declarar en la sección Provides: del paquete que aporta java11-runtime. Si no hay ningún paquete que ya provea al sistema de un runtime de Java compatible con las versiones 11 o 17, se instala default-jre, versión >= 11. Nótese que para que dpkg tenga conocimiento de esa instalación previa de Java, debe de haberse instalado también con dpkg o apt. Según de cómo de acomodador se quiera ser a los usuarios con su instalación custom de Java fuera de dpkg, esto podría ser un breaking change para ellos. En mi opinión, este es un uso menor, viendo la cantidad de comentarios de la comunidad al respecto, como veremos. Así se resuelven muchos problemas de instalación: - un usuario en ctt-gob-es#16 estuvo días con problemas por no tener Java (no el posteador) - resolves ctt-gob-es#244, donde varios usuarios vieron su problema resuelto gracias a una aclaración indicando su problema con las dependencias. - closes ctt-gob-es#258, que simplemente pregunta desconcertado. - En ctt-gob-es#263, al menos un usuario reporta haber solucionado su problema instalando Java de Oracle. - En ctt-gob-es#250, al final del hilo, un usuario reporta que el funcionamiento o no de Autofirma varía de versión a versión. - close ctt-gob-es#259, el issue mencionado al principio de este commit message. - tenemos un tutorial/explicación y todo en ctt-gob-es#302 También está la PR ctt-gob-es#268, que pide aclarar la instalación para Fedora, que sufre de exactamente lo mismo. De hecho: - ctt-gob-es#230 y ctt-gob-es#355 parecen ser tambien problemas de tener instalado java headless (el log errores menciona java.awt, abstract window toolkit). Otros 2 usuarios reportaban errores similares en ctt-gob-es#172, y otro usuario en ctt-gob-es#168 sabe que tiene headless pero no que necesita las versión no headless. Referencias: https://wiki.debian.org/Java - sección Understanding Java Virtual packages names. La misma idea de usar virtual package names surge en varias preguntas de StackOverflow: - Depender de Java pero no de ninguna implementación particular https://unix.stackexchange.com/questions/291783/can-i-indicate-that-a-deb-package-depends-on-java-but-not-specify-what-impleme - Depender de Java pero sin ser estricto en versiones https://unix.stackexchange.com/questions/550060/set-minimal-jre-version-to-deb-package-dependency y https://stackoverflow.com/questions/36181613/how-to-configure-java-7-or-java-8-dependency-in-debian-deb-package
Buenas,
Tengo instalado Autofirma 1.6 en mi Linux (Manjaro 17), el cual no puedo utilizar a través del portal portafirmas de la Universidad de Murcia. Utilizo Firefox 58
Cuando procedo a firmar, recibo el siguiente error:
Utilizando la aplicación gráfica, no hay ningún problema: Me sale el diálogo del almacén de claves y puedo usar mi firma. Sin embargo, desde Firefox tengo el siguiente error y no sé dónde se consultan los certificados (el certificado está instalado en el almacén del navegador, por lo que supongo que no lo coge de ahi).
Un saludo,
Valentín
The text was updated successfully, but these errors were encountered: