Re: Problemas con Autofirma en Linux, integración en el navegador #172
Comments
|
En Firefox. Asegúrate que tienes un solo perfil "/usr/bin/firefox -p" |
|
Excelente, ha funcionado! Puede que esto esté en un FAQ y se me haya pasado, pero si no está documentado en ningún sitio, estaría interesante incluirlo. |
|
al iniciarlo desde "/usr/bin/AutoFirma" Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class java.awt.Toolkit at java.desktop/java.awt.Color.(Color.java:275) at es.gob.afirma.standalone.LookAndFeelManager.(LookAndFeelManager.java:60) at es.gob.afirma.standalone.SimpleAfirma.main(SimpleAfirma.java:549) tengo el jre8-openjdk y el jdk11-openjdk |
|
@carlosnewmusic , |
|
hola, tengo el mismo problema que alexpdp7, solo no tengo doble perfil ni masterpassword, tengo java 8....explico en #214 con mas detalle |
Tuve el mismo problema y lo solucione' instalando Oracle JDK en lugar de OpenJDK |
|
Gracias @atomass por tu comentario, muy clarificador. No como el tal Juan Jose Pablos, un pedante que encima ayuda poco. |
|
Deja de hacer el ridículo @t0mjoad , tus afinidades personales son de ámbito privado, si no tienes familia o amigos a los que comentarles estas cosas, mejor no lo hagas. Tu opinión sobre una persona aleatoria del planeta es irrelevante. A Internet se viene llorado de casa. Esto es un informe sobre "Autofirma Linux y navegadores web" |
|
sé perfectamente lo que es, una basura que usa software propietario de oracle en vez del openjdk, y con un creador mediocre que ningunea a la gente mientras no es ni siquiera capaz de generar documentación estandarizada. Te crees que eres Linus y eres más malo que el programador de Tizen. |
|
Por comentar esto antes de desuscribirme de este hilo
En este caso, mi problema no era de doble perfil, sino que se resolvía restaurando la instalación. Insisto que estaría bien documentar este proceso si no se puede mejorar de otra manera. |
|
@alexpdp7 Yo creo que lo mejor es que cierres este informe. Si consideras que las FAQ están incompletas, ve a https://github.com/ctt-gob-es/clienteafirma/wiki/AutoFirma:-Problemas-en-la-instalaci%C3%B3n#por-qu%C3%A9-no-funciona-autofirma-con-firefox-reci%C3%A9n-instalado-o-con-mi-nuevo-perfil Quizás se acepten los cambios. @t0mjoad Dado que tu comprensión lectora es limitada, me gustaría resumirte: Internet es un lugar enorme donde puedes encontrar donde contar tus líos mentales
|
|
Joder, tengo fedora 33 y mi error es: |
Una solución que me funcionó en Fedora 34:
|
Muuuuchisimas gracias druizz90. Me ha funcionado tambien en fedora 33 a la perfeccion. Ahora si funciona la app esta d kk autofirma. |
|
Vuelvo a tener problemas con autofirma en fedora 33. autofirma Que puedo hacer ? hay alguna forma de que esto funcione para siempre ? |
|
Buenos días,
La instalación que tengo es:
En el manual de Autofirma acabo de leer: _NOTA: Se han encontrado problemas de compatibilidad con el Firefox por defecto Pero no se si algo aplicable a mi -creo que mi Firefox no corre en KDE y es el oficial de la página de web de Firefox. Las salidas de Autofirma en la consola están en el otro hilo. Alguien se ha encontrado con este problema, ¿alguna pista? Gracias a todos !! |
Problema solucionado. Lo podéis encontrar en el hilo: #16 al final del todo. Gracias por el soporte !! |
|
Algo para revisar es si Firefox está instalado en Ubuntu desde un snap o desde un paquete deb. Si esta instalado desde un snap hay que desinstalarlo |
|
Tras múltiples quebraderos de cabeza, os pongo aquí mi solución, totalmente funcional, para un entorno con Firefox, Ubuntu 22.04 y openjdk versión 11.0.16. No es necesario desinstalar el Firefox instalado en Ubuntu desde snap, pero con éste no funcionará AutoFirma. Pero podemos instalar un nuevo Firefox descargándolo desde https://ftp.mozilla.org/pub/firefox/releases/ y eligiendo allí una versión moderna, la platafor de 64-bit y el idioma que deseemos (por ejemplo "105.0. > linux-x86_64 > en-GB" para tener la versión 105 en inglés). Para instalar este Firefox, descargamos el fichero *.tar.bz2 y lo descomprimimos en un directorio al que podamos acceder(por ejemplo ~/Firefox/, creado por nosotros mismos). En ese directorio tendremos el ejecutable "firefox". Pues bien, cerramos (si está abierto) el Firefox instalado desde snap y arrancamos el nuevo Firefox que acabamos de descargar. Éste debe tener sólo un perfil de usuario. Sobre este nuevo Firefox debemos instalar los certificados digitales personales que queramos utilizar, y hay que asegurarse de que el certificado de autoridades Autofirma ROOT está presente (si no habreá que descargarlo de algún sitio, como http://e-administracion.ulpgc.es/sites/default/files/AutoFirmaROOT.crt). Tras ello, cerramos Firefox y arrancamos la aplicación Java AutoFirma, desde la que elegimos "Herramientas > Restaurar instalación". Con ello, conseguiremos que la aplicación web reconozca nuestros certificados digitales y que se puedan firmar documentos con ellos desde ese nuevo Firefox (por ejemplo en https://valide.redsara.es/valide/firmar/ejecutar.html. NOTA: Este nuevo Firefox se actualizará si accedemos a su menú "Help > About Firefox), pero ello no da al traste con la configuración de AutoFirma. NOTA 2: El perfil de usuario del nuevo Firefox que se crea al arrancarlo por primera vez se guarda en el mismo directorio que los perfiles de usuario que tenga el Firefox procedente de snap, es decir, en ~/.mozilla/firefox/). En mi caso, el perfil del nuevo Firefox se crea en un subdirectorio ajqd7gd9.SnapFree y el que tenía del antiguo Firefox era xqkyr2zn.default-release; quizás el hecho de que el perfil del nuevo Firefox empiece por "a" hace que AutoFirma lo reconozca primero. Por si en vuestro sistema el perfil del nuevo Firefox tiene un nombre que va ordenado alfabéticamente por detrás del perfil del Firefox antiguo, instalad los certificados digitales también en el antiguo Firefox. Suerte!!! |
|
He arreglado estos errores instalando la última versión de java sudo apt install default-jdk default-jre |
|
Ibarbech, gracias por tu aporte y me alegro que en tu sistema funcione, pero en el mío, donde no tenía instalados los default-* que mencionas, los he instalado y sigo igual: desde Firefox instalado mediante snap (a día de hoy, versión 110.0.1) no puedo firmar documentos. Los paquetes default-jdk y default-jre me da la impresión de que son simplemente una forma diferente de llamar al Java que tengas ya instalado en tu sistema. En sus descripciones se puede leer "This dependency package points to the Java runtime, or Java compatible development kit recommended for this architecture". Así que a lo mejor todo dependa en última instancia del Java que tengas instalado. ¿Puedes decirnos cuál es tu versión? Para saberlo, puedes ejecutar cualquiera de estos dos comandos (te indico para ellos lo que tengo yo, OpenJDK 11): Saludos. |
|
Si claro aquí tienes la salida de ambos comandos. readlink -f "$(which java)"
/usr/lib/jvm/java-11-openjdk-amd64/bin/java
java -version
openjdk version "11.0.18" 2023-01-17
OpenJDK Runtime Environment (build 11.0.18+10-post-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM (build 11.0.18+10-post-Ubuntu-0ubuntu122.04, mixed mode, sharing)Por lo que puedes ver obtengo la misma salida Saludos |
Si usas Firefox instalado mediante snap, la version actual de Autofirma (1.7.1) no va a encontrar el directorio de tu perfil de Firefox. Una solución que proponen en otros hilos, es hacer un enlace del directorio por defecto, donde va a buscarlo autofirma, al directorio del snap. Algo como esto (ojo no lo he probado, puede necesitar ajustes) cd $HOME
mkdir .mozilla
ln -s ~/snap/firefox/common/.mozilla/firefox .mozilla/firefox |
|
buenas, rogaría que la aplicación se desarrollara de tal modo que Autofirma en firma online en exploradores funcionara para distribuciones tan estándar como lo es Debian. Que este issue lleve abierto más de 2 años y medio a fecha de hoy solo refleja la dejadez al respecto en tratar la característica de firma (obligada en muchas gestiones), para sistemas Linux. Vamos, que tengo una partición windows exclusivamente instalada para poder usar Autofirma, cuando absolutamente todas las demás gestiones, las hago a través de Linux sin problema. No sé si es porque la contrata del ministerio no es capaz o porque el ministerio no quiere pagar por la característica de firma en explorador bien desarrollada para todos los SO... realmente es algo indistinto, es impermisible y bochornoso el estado de esta issue. |
|
En realidad es ilegal que te obliguen a usar windows en españa y en toda europa, esto se puede denunciar https://porunajusticiaindependiente.com/ Esta incluso explicada como la cadena de mando hace que la justicia sea totalmente dependiente del poder politico puede sancionar a jueces que emitan justicia en vez de ideologia (pej denuncias falsas de violencia de genero que nunca se hace justicia y siempre se acaba abusando de los menores que son los primeros perjudicados) Lo dicho podeis hacer una denuncia pre-judicializada en los tribunales de la UE y de una vez por todas conseguir que no os obliguen a comprar windows el opensource debe ser admitido por ley por todas las administraciones publicas |
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
Confirmo que haciendo eso me funciona en Ubuntu 22.04 desde Google Chrome 129.0.6668.100 (Official Build) (64-bit) |
Puedo usar Autofirma en mi sistema Linux para firmar archivos con mi DNIE sin problema.
También puedo usar mi DNIE en mi navegador Firefox para identificarme.
Sin embargo, la integración de Autofirma con el navegador no me funciona ni en Chrome ni en Firefox. Entiendo que Autofirma hace un bind a un puerto aleatorio y escucha peticiones HTTPS, y las webs que integran Autofirma hacen peticiones a este puerto para operar. Sin embargo, observo que estas peticiones fallan, al parecer porque el navegador no confía en el certificado que usa Autofirma para la comunicación HTTPS.
Veo mensajes como:
en mi navegador, existiendo un proceso:
He intentado importar el certificado a mano sin demasiado éxito.
¿Pueden ayudarme a resolver este problema?
The text was updated successfully, but these errors were encountered: