línea de comandos SVN en Jenkins falla debido al servidor desajuste certificado

D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up --trust-server-cert --non-interactive 
Updating '.': 
svn: E175002: Unable to connect to a repository at URL 'https://xxx/stable' 
svn: E175002: OPTIONS of 'https://xxx/stable': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://xxx)

Pero cuando corro la misma desde la ventana de CMD línea de comandos que está bien:

D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up 
Updating '.': 
At revision 1797.

D:\Jenkins\jobs\Merge Trunk to Stable\workspace\stable>svn up --trust-server-cert --non-interactive 
Updating '.': 
At revision 1797.

alguna idea de cómo solucionar esto ??

Fuente

2012-08-14 Ran Cohen

¿Necesita agregar en alguna parte las huellas dactilares del servidor para ese servidor? – fduff

No es que yo sepa. Realmente no entiendo la pregunta ... Sé que el nombre del certificado del servidor no coincide. No me causó ningún problema antes. –

Tenía en mente algo así como en el archivo del servidor de Tortoise/Red/Subversion; puede haber una configuración faltante allí, pero eso es solo una suposición. – fduff

Bastante vieja pregunta, pero todavía bastante viva.

Como sabe, el problema es que la caché de certificados aceptados (así como la caché de nombre de usuario/contraseña) es por usuario, y dado que Jenkins se ejecuta como un usuario diferente (probablemente SISTEMA), no tiene idea de su caché de usuario habitual.

No todos los clientes SVN te permiten hacer el "eco p" allí (no funcionó), y el --trust-server-cert aparentemente tampoco funciona en este caso.

Lo que funcionó para mí fue open a console window as SYSTEM, y hacer el baile interactivo acceptcertificate-login-password allí.

Dado que todo esto está almacenado en la memoria caché, solo necesita hacer esto una vez, y desde ese momento, todas las solicitudes svn up y similares funcionarán.

Fuente

2013-11-20 08:19:03

plusone - ¡Tres años después, sigue siendo un problema y tu respuesta me salvó! Gracias. –

¡Finalmente logré resolver el problema! Lo que hice fue simplemente poner en el guión de Jenkins:

echo p | svn up --username <usr> --password <pwrd>

Esto lo resolvió! ya que el eco emuló la entrada manual para aceptar permanentemente el certificado.

causa raíz es el hecho de que los scripts de shell Jenkins se ejecutan bajo el usuario del servicio de Windows - por lo tanto utiliza un lugar diferente para la caché de perfil de usuario (en C:\Windows\System32\config\systemprofile\AppData\Roaming\Subversion en lugar de %USERPROFILE%\AppData\Roaming\Subversion\)

Fuente

2012-08-14 14:55:35

Tal vez, el certificado se emite a una diferente nombre de host (no xxx, pero algo así como xxx.yourcompany.com). Si es así, haga un pago limpio con este nombre de host.

Fuente

2013-01-28 07:37:07 ZhekaKozlov

echo p | svn commands

funcionó muy bien en Jenkins símbolo del sistema de Windows por lotes. Al hacer esto una vez, se aceptará permanentemente el certificado para el usuario de Jenkins en el cuadro Generar.

Fuente

2014-09-04 16:45:12 arunics

Ejecutar comandos Svn a través de Jenkins en esclavo me estaba dando problemas. Hice lo siguiente:

Si está en Unix a continuación, siga este enlace: http://www.microhowto.info/howto/configure_subversion_to_trust_a_given_ssl_certificate.html

Si está en Windows y luego hacer:

cd %APPDATA%\Subversion\

luego editar el archivo server en ese directorio mediante la eliminación de la # firme desde el elemento ssl-authority-files y actualice la ruta hasta donde guardó su archivo de certificado ssl.

También cambie lo siguiente, si desea guardar sus credenciales.

store-passwords = yes 
store-ssl-client-cert-pp = yes

Una vez hecho esto, también se tendría que añadir el certificado a su máquina de Windows siguiendo Add the Cert to the Trusted Root CA Store

Fuente

2015-07-08 20:29:43

Esto puede parecer como una respuesta horrible, pero después de haber agotado los demás, que no funcionaba para mí debido a otros problemas, elijo ir por la ruta de cambiar el servidor SVN para no usar SSL.

Esto fue solo una opción porque acabo de configurar este servidor y está en una red totalmente interna, pero eliminó por completo el problema. Y me quedé sin otras opciones y tiempo.

También sugiero esto en caso de que alguien no se dé cuenta de que es incluso una opción. Usar SSL me haría sentir mucho mejor independientemente de la exposición del servidor.

Fuente

2016-01-29 18:01:08 DarrenMB

Tuve el mismo problema con Jenkins y Windows 7. Lo resolví ingresando a los servicios, seleccionando Jenkins, ingresando a Log-on e ingresando las credenciales administrativas y reiniciando el servicio jenkins.

Espero que esto resuelva su problema.

Fuente

2016-06-22 20:39:20

línea de comandos SVN en Jenkins falla debido al servidor desajuste certificado

Respuesta

Cuestiones relacionadas