Archivo de la etiqueta: verify

Solucionar error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Fork me git - server certificate verification failed
Fork me git – server certificate verification failed

Este error SSL al clonar repositorio GIT suele aparecer en algunos repositorios. En mi caso particular apareció este error (server certificate verification failed) al clonar el repositorio de ffmpeg descrito en su propia página:

$ git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg

Que produce el error:

fatal: unable to access 'https://git.ffmpeg.org/ffmpeg.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Esto se debe a que GIT esta intentando validar el certificado SSL de dicho repositorio y rechaza el certificado puesto que tiene algún problema (por ejemplo puede estar autofirmado o no ser válido).

Error: server certificate verification failed

Si quieres obtener más información sobre el problema, puedes mostrar más información de depuración con:

GIT_CURL_VERBOSE=1

En mi ejemplo sería:

$ GIT_CURL_VERBOSE=1 git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
Clonar en «ffmpeg»...
* Couldn't find host git.ffmpeg.org in the .netrc file; using defaults
* Trying 79.124.17.100...
* TCP_NODELAY set
* Connected to git.ffmpeg.org (79.124.17.100) port 443 (#0)
* found 168 certificates in /etc/ssl/certs/ca-certificates.crt
* found 684 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Curl_http_done: called premature == 1
* Closing connection 0
fatal: unable to access 'https://git.ffmpeg.org/ffmpeg.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Posibles soluciones

Existe una manera rápida y sucia de solucionar el problema que es ignorar el paso de verificar el certificado (ojo, esto implicaría que realmente confías en el sitio que estas ignorando y que si alguien ha reemplazado su certificado de forma maligna, tu asumirías las consecuencias), para ignorar la verificación en GIT:

$git config --global http.sslverify false

O bien puedes usar la variable de entorno:

$ export GIT_SSL_NO_VERIFY=1

 



Otra posible solución, es obtener el certificado autofirmado (archivo .crt) y añadirlo a la lista de los que tiene tu propio ordenador. Para ello, con el anterior comando hemos visto que el host al que debemos solicitarlo (en mi caso) es git.ffmpeg.org, luego sería el siguiente comando:

$ echo -n | openssl s_client -showcerts -connect git.ffmpeg.org:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Esto devuelve un texto, que el el certificado y que debemos añadir a nuestro listado de certificados, normalmente en la ubicación/etc/ssl/certs/ca-certificates.crt:

$ sudo nano /etc/ssl/certs/ca-certificates.crt 

Posteriormente, si es el correcto, actualizariamos con el comando:

$ sudo update-ca-certificates

Y debería mostrar que se ha añadido uno nuevo. Con ello debería permitir clonar el repositorio que produce el fallo de verificación SSL (server certificate verification failed).

Solucionar Warning: session_start() [function.session-start]: open(/tmp/sess_404b65f5a6f22fd57694ce1442af5769, O_RDWR) failed: Permission denied (13)

El error completo sera algo como:

PHP Warning: Unknown(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp/) in Unknown on line 0
PHP Warning: Unknown(): open(/tmp/sess_404b65f5a6f22fd57694ce1442af5769, O_RDWR) failed: No such file or directory (2) in Unknown on line 0
PHP Warning: session_start() [<a href=’function.session-start’>function.session-start</a>]: open(/tmp/sess_404b65f5a6f22fd57694ce1442af5769, O_RDWR) failed: No such file or directory (2)

Las sesiones en php, son simplemente una cookie, pero que se almacena en servidor. Y una cookie es simplemente un fichero de texto con un hash y variables con datos.

Este error puede darse en el session_start() y puede darse que al no asignar un nombre especifico a la sesión, se use un genérico, que tiene la forma sess_(un hash) y se use un fichero de sesión aleatorio que haya dado colisión con otro que haya sido creado por otro usuario que lo este usando también sin establecer nombre.

¿y porque se da el error? Porque estas viendo una página “cacheada” en tu navegador y el servidor tiene asignada esa cookie-sesion a otro usuario, por eso de dice que no tienes permisos. La solución seria borrar la cache, pero aunque es un apaño, la culpa no la tiene el usuario, esta en el servidor por haber asignado esa cookie-session a otro usuario previamente no haber liberado la cookie-session.

Pero tampoco podemos echarle toda la culpa al servidor si nosotros lo programamos de tal modo.

En algún comentario en ingles podéis leer “in the belief that somehow the two people were getting the same ID and hence temp file”.

Yo tengo bastante experiencia en php y nunca se me había dado este error y ya de por sí me resultaba muy raro. Pero esto es un problema que esta generando PHP con phpsuexec.

Buscando en google, aparentemente no hay soluciones, pero si que había reportes de bug en el bugtracker de PHP:
http://bugs.php.net/bug.php?id=19022 (BUG PADRE)
Otros bugs relacionados:
http://bugs.php.net/bug.php?id=43990
http://bugs.php.net/bug.php?id=5370

Si observas las respuestas de google de otros hosting, dan como solución  “contrata a un mejor sysadmin”, “TU estas haciendo algo mal”, “comprueba tu configuración”, “Asked sys admin to fix it” , pero no dicen porque, ni como arreglarlo, ni dan soluciones, eso es para evitar decir que NO tienen solución,  en Quijost no engañamos a nuestros usuarios de tal modo y explicamos lo hechos de forma honesta.

Las únicas soluciones que se dan son:

1 – Reiniciar la máquina (MALA solución: tratándose de servidores en producción no se puede jugar con el uptime y más si se da espontánea y periódicamente)

2 – Eliminar todas las sesiones con: rm -rf /tmp/sess_* (MEDIA solución: no requiere reinicio, pero hace perder el logueo a todos los usuarios que estén en el servidor para arreglar al resto, aparte habría que ejecutarla cada vez que da este error que puede ser en cualquier momento y sin posibilidad de detectar cuando)

3 – Modificar el directorio donde se guardan las sesiones a uno del usuario para así que no den problemas de permisos:
ini_set('session.save_handler', 'files');
O bien un directorio del usuario (creando un directorio tmp en el directorio del usuario):
ini_set('session.save_path', '/home/usuario/tmp');

Documentacion:
session_save_path() www.php.net/session_save_path

Podría valer pero no es la mejor solución.

La solución más correcta y hasta que los señores de PHP se dignen a arreglar este BUG que posiblemente afecte a millones de sitios web de php sería la siguiente:

1 – Establecer la cookie-sesion en un directorio de tu propio usuario, es decir dentro de tu dominio, por ejemplo:

ini_set('session_save_path', '/home/tuusuario/tmp');

2 – Asignar un nombre a la sesión:

session_name('tuusuario');

3 – Poner este trozo de código para evitar que te de error en el session_start():

if(@session_start() == false){session_destroy();session_start();}

Lo que hacemos es borrar la sesión actual si da error y generar otra, sino da error simplemente la iniciamos (esta más cool utilizando un if ternario).

Por lo tanto, resumiendo, en vez de poner sólo session_start(), para solucionar el bug, tendrías que poner lo siguiente (claro esta, poniendo tu usuario):
ini_set('session_save_path', '/home/tuusuario/tmp');
session_name('tuusuario');
if(@session_start() == false){session_destroy();session_start();}