bypass ssl certificado de validación en subversión

Question

Estoy administrando un sistema de compilación basado en subversión y usamos un ssl autofirmado para el servidor. Entonces, de vez en cuando, obtenemos errores de compilación porque se ha agregado una nueva máquina y no se puede extraer, ya que es la primera vez que esa máquina se pone en contacto con el servidor svn.

El mensaje de error es como:

icasimpan ~$ svn ls https://scm.myserver.com/trunk 
Error validating server certificate for 'https://scm.myserver.com:443': 
- The certificate is not issued by a trusted authority. Use the 
    fingerprint to validate the certificate manually! 
Certificate information: 
- Hostname: scm.myserver.com 
- Valid: from Mon, 05 Dec 2011 00:00:00 GMT until Tue, 11 Dec 2012 23:59:59 GMT 
- Issuer: Terms of use at https://www.verisign.com/rpa (c)10, VeriSign Trust Network, VeriSign, Inc., US 
- Fingerprint: c0:69:f6:67:8d:1f:d2:85:c1:94:9f:59:8e:81:cc:81:3d:1e:44:28 
(R)eject, accept (t)emporarily or accept (p)ermanently? 

Lo que normalmente necesito es algo así como el parámetro --insecure para rizar. En este momento, nuestra solución es simplemente hacer un comando svn simple para que podamos responder "permanentemente" y el problema sería resuelto ... al menos hasta que el certificado ssl se cambie/renueve nuevamente o la compilación se realice en otro nuevo máquina.

¿Alguien ha solucionado este problema?

Gracias de antemano :)

Answer 1

Supongo que tiene dos opciones; tirar por la borda toda la precaución y el establecimiento de la confianza de servidor cert y no interactiva desde la línea de comandos:

svn help co 
.... snip.... 
--non-interactive  : do no interactive prompting 
--trust-server-cert  : accept unknown SSL server certificates without 
         prompting (but only with '--non-interactive') 

y la otra opción es usar algo como s_client openssl con -showcerts para comprobar y validar si el certificado ha cambiado antes a la llamada svn, y luego abortar muy limpiamente y dejar que un ser humano haga la llamada de juicio, o algo sucio, como usar el -showcert para actualizar el certificado conocido en ~/.subversión.

En cualquiera de los casos - el bit de la magia no intuitivo está en los archivos de ~/.subversion/auth/svn.ssl.server/<serverrecord> - para extraer la información que necesita cert:

cat <serverrecord> | grep ^MII | base64decode | openssl x509 -text -inform DER 

o algo así como

cat <serverrecord> | grep ^MII | base64decode | openssl x509 -text -inform DER -noout - out current-cert.pem 

y luego se puede utilizar con OpenSSL s_client -CApath o verificar con ese certificado para ver si ha cambiado y/o utilizar -showcert cruzar cheque. (Nota: sustituya perl -e 'use MIME :: Base64; imprima decode_base64 (join ("",));' para base64decode si es necesario).

Answer 2

Otra opción es usar esperar. Con el uso, puede simular que un usuario acepte el certificado. Funcionará cuando otras opciones no lo harán. Creé esto para poder descargar el código de svn en un Dockerfile.

#!/usr/bin/expect -f 

set svn_username [lindex $argv 0] 
set svn_password [lindex $argv 1] 
set svn_url [lindex $argv 2] 

spawn svn --username=${svn_username} --password=${svn_password} list ${svn_url} 
expect "(R)eject, accept (t)emporarily or accept (p)ermanently? " 
send -- "p\r" 
expect "Store password unencrypted (yes/no)? " 
send "no\r" 
expect -re "root@.*:\/#" 

Answer 3

Hay dos escenarios posibles: el certificado no es de confianza, pero válida (es decir, un certificado válido autofirmado por ejemplo), o el certificado no es válido (por ejemplo, cuando se está accediendo a una máquina en la red LAN IP o desde fuera de su LAN por FQDN y esa máquina tiene un certificado emitido a su nombre simbólico). El cliente svn no confiará en el segundo tipo de certificado, incluso si usa la opción --trust-server-certificate. En el segundo escenario, su única opción que puedo pensar es usar una entrada de archivo de hosts para alias de la IP de esa máquina a su nombre interno.

Ilustración del escenario 2 que una vez que se presentan cuando VisualSVN fue instalado con todas las opciones por defecto y ha generado un certificado a nombre simbólico de la máquina que se descubrió:

LAN nombre de la máquina MACHINE1 ejecuta el servidor SVN y tiene un certificado instalado que se emitió a MACHINE1. Está intentando acceder a SVN a través de su dirección IP y obtener un error de certificado no válido.

También obtendría ese error si se puede acceder a esa MACHINE1 desde fuera de su LAN por FQDN, por ejemplo, svn.domain.com y se está conectando al FQDN.

En ambos casos, svn arrojaría el error de certificado no válido.

Se puede añadir una entrada al archivo hosts para asignar direcciones de la máquina IP (LAN o externa dependiendo de dónde se está accediendo desde) el certificado de nombre se emitió a:

123.45.67.89 MACHINE1 

y acceso a SVN a través de https://machine1/svn/ para evitar esta situación.