Servidor: Ubuntu 18.04
Cliente: Microsfot Windows 10 versión 1803 (compilación del SO 17134.523)
Servidor: 2.2.0-snapshot-53ebc47a
Cliente: 2.1.0-RELEASE-0b2dfd80
flatpak run com.github.debauchee.barrier
[2019-01-18T11:41:57] INFO: OpenSSL 1.1.1 11 Sep 2018
[2019-01-18T11:41:57] ERROR: ssl certificate doesn't exist: /home/thomas/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
[2019-01-18T11:42:13] INFO: OpenSSL 1.1.1 11 Sep 2018
[2019-01-18T11:42:13] ERROR: ssl certificate doesn't exist: /home/thomas/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
[2019-01-18T11:42:29] INFO: OpenSSL 1.1.1 11 Sep 2018
Puedo confirmar que el archivo no existe:
$ ls ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/
$ locate Barrier.pem
Pensé que esto podría ser similar al # 142, pero permitir barrera.exe y barreras.exe a través del firewall no cambió el mensaje en los registros.
Al menos puedo confirmar que esto está relacionado con tener habilitada la configuración SSL. Con esa discapacidad, puedo hacer que el cliente y el servidor funcionen juntos.
Eso es interesante, soy un usuario diario del flatpak y la barrera logró generar un certificado SSL para mí muy bien.
alc@am1m-s2h ~ % ls -l .var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
-rw-rw-r--. 1 alc alc 1649 May 21 2018 .var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
Como solución alternativa, utilicé las instrucciones de sinergia de esta página: https://wiki.archlinux.org/index.php/synergy#Set_up_encryption_on_server
TL; DR:
mkdir -p ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints
openssl req -x509 -nodes -days 365 -subj /CN=Barrier-newkey rsa:4096-keyout ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem -out ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
openssl x509 -fingerprint -sha2 -noout -in ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem > ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints/Local.txt
Luego, habilite el cifrado desde la configuración tanto en el cliente como en el servidor, reinicie ambos y acepte el nuevo certificado de servidor de su cliente ... debería estar listo desde allí.
Editar:
cambiar la longitud de clave de 1024
a 4096
cambiar -sha1
a -sha2
Dejaré este problema abierto en caso de que otra persona también tenga este problema. También es posible que desee aumentar esa longitud de clave de 1024
a 4096
, y usar sha2
lugar de sha1
.
punto justo. Normalmente uso las teclas 4K ... Esta vez me volví perezoso y copié / pegué. Comentario actualizado con las sugerencias de @AdrianKoshka .
Editar: puntuación.
Cuando ejecuto el comando openssl req
, aparece un mensaje de error:
$ openssl req -x509 -nodes -days 365 -subj /CN=Barrier-newkey rsa:4096-keyout ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem -out ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
req: Use -help for summary.
Parece que ha perdido un par de espacios del comando. Los siguientes trabajos:
$ openssl req -x509 -nodes -days 365 -subj /CN=Barrier -newkey rsa:4096 -keyout ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem -out ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
Generating a 4096 bit RSA private key
......................................................................................................................................................++
.......................................................................................................................................................................++
writing new private key to '/home/thomas/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem'
-----
El comando openssl x509
también falla.
$ openssl x509 -fingerprint -sha2 -noout -in ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem > ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints/Local.txt
x509: Unknown digest sha2
x509: Use -help for summary.
Creo que el consejo de solución alternativa debería actualizarse a:
mkdir -p ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints
openssl req -x509 -nodes -days 365 -subj /CN=Barrier -newkey rsa:4096 -keyout ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem -out ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem
openssl x509 -fingerprint -sha1 -noout -in ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Barrier.pem > ~/.var/app/com.github.debauchee.barrier/data/barrier/SSL/Fingerprints/Local.txt
Al menos en mi caso.
Ahora bien, ¿la ausencia de soporte sha2 explica la causa de mi problema? Si lo que se espera que genere automáticamente las claves es intentar usar sha2 y fallar silenciosamente.
Tengo la versión 1.1.0g de OpenSSL.
$ openssl version
OpenSSL 1.1.0g 2 Nov 2017
¿Qué versión se espera que sea compatible con sha2? Parece que puedo usar -sha256
o -sha512
en la línea de comando sin obtener un error.
Me complace informar que con la solución en su lugar (usando sha512 en este caso) he podido conectar el cliente de Windows a la versión flatpak de la barrera.
Gracias por su ayuda para ponerme en funcionamiento. Hágame saber si hay algo más que pueda hacer para ayudar a encontrar la causa del problema y una posible solución.
La misma configuración y el mismo comportamiento que en la descripción del error aquí.
Tuve el mismo problema. Tanto el cliente como el servidor tenían la versión 2.2.0-snapshot-53ebc47a. Usar los comandos en la publicación de @TafThorne funcionó.
Tuve el mismo problema, ¡también funcionó para mí!
Esto simplemente se me acercó de la nada después de esta actualización pasada. Tuve que seguir las instrucciones anteriores también.
Oye, probé los comandos de @TafThorne y
[2019-06-15T17:20:12] INFO: OpenSSL 1.1.1b 26 Feb 2019
[2019-06-15T17:20:12] ERROR: could not use ssl certificate
[2019-06-15T17:20:12] ERROR: error:0909006C:PEM routines:get_name:no start line
¿Alguien sabe cuál es el problema?
No intento sonar grosero, pero ¿por qué esto no se ha solucionado en la versión oficial de Flatpak, ya que parece afectar a todas las instalaciones nuevas, incluyéndome a mí hoy y es una verdadera barrera de entrada para nuevos usuarios?
Entonces, como probablemente era obvio, las herramientas de línea de comandos openssl
no se envían, lo que evita que se genere el certificado, estoy trabajando para solucionar esto finalmente. Lo siento.
Lo siento mucho, esto fue un problema durante tanto tiempo, realmente no debería haberlo sido. Después del trabajo, puede ser difícil encontrar la energía para trabajar en OSS.
De hecho, gracias por solucionar el problema.
Mi punto fue que el paquete Flatpak es probablemente uno de los canales principales para instalar Barrier y, dado que estaba efectivamente roto para todos los usuarios nuevos, fue un poco frustrante descubrir que el problema había estado abierto durante tanto tiempo.
Arreglado para mí en una máquina personal en el trabajo, antes de que no tuviera certificado.
openssl
se envía con un paquete plano de barreras, y creo que esto se ha solucionado.
Hola gente, ¡acabo de encontrar este problema en una instalación nueva usando snapd
en fedora!
mkdir -p /home/fbidu/snap/barrier-kvm/2/.local/share/barrier/SSL/
cd /home/fbidu/snap/barrier-kvm/2/.local/share/barrier/
openssl req -x509 -nodes -days 365 -subj /CN=Barrier -newkey rsa:4096 -keyout Barrier.pem -out Barrier.pem
¡Trabajó para mi!
Comentario más útil
Cuando ejecuto el comando
openssl req
, aparece un mensaje de error:Parece que ha perdido un par de espacios del comando. Los siguientes trabajos:
El comando
openssl x509
también falla.Creo que el consejo de solución alternativa debería actualizarse a:
Al menos en mi caso.