convalida del certificato SSL ssl in subversion

Question

Sto gestendo un sistema di generazione basato su subversione e usiamo un ssl autofirmato per il server. Di tanto in tanto, si verificano errori di compilazione perché è stata aggiunta una nuova macchina e non è possibile eseguire il checkout poiché è la prima volta che la macchina contatta il server svn.

Il messaggio di errore è simile:

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? 

Quello che in genere bisogno è qualcosa come parametro --insecure ad arricciarsi. In questo momento, la nostra soluzione è semplicemente fare un semplice comando svn in modo che possiamo rispondere "permanentemente" e il problema sarebbe risolto ... almeno finché il certificato ssl non viene cambiato/rinnovato di nuovo o la compilazione viene eseguita su un altro nuovo macchina.

Qualcuno ha risolto questo problema?

Grazie in anticipo :)

Answer 1

Credo che si hanno due opzioni; gettando ogni cautela a mare e la creazione di fiducia-server-cert e non interattivo dalla riga di comando:

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') 

e l'altra opzione è quella di usare qualcosa come OpenSSL s_client con -showcerts per controllare e convalidare se il CERT è cambiato prima alla chiamata svn -e poi annulla in modo molto pulito e lascia che un umano faccia la chiamata di giudizio, o qualcosa di sporco - come usare il -showcert per aggiornare il cert conosciuto in ~/.subversion.

In entrambi i casi - il po 'di magia non intuitivo è sui file in ~/.subversion/auth/svn.ssl.server/<serverrecord> - per estrarre le informazioni cert è necessario:

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

o qualcosa come

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

e può quindi usare OpenSSL s_client con -CApath o verificare con quella cert per vedere se è cambiato e/o utilizzare -showcert per un controllo incrociato. (Nota: sostituire perl -e 'usare MIME :: Base64; stampare decode_base64 (join ("",)); "per base64decode se necessario).

Answer 2

Un'altra opzione è l'uso previsto. L'uso prevede di poter simulare un utente che accetta il certificato. Funzionerà quando altre opzioni non lo faranno. Ho creato questo in modo da poter scaricare il codice da svn in 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

Ci sono due possibili scenari: il certificato non è attendibile, ma valido (cioè un cert valida auto-firmato, per esempio), o certificato è valido (ad esempio, quando si accede a una macchina sulla LAN IP o dall'esterno della LAN per FQDN e quella macchina ha un certificato emesso per il suo nome simbolico). Il client svn non si fiderà del secondo tipo di certificato, anche se si utilizza l'opzione --trust-server-certificate. Nel secondo scenario l'unica opzione a cui posso pensare è quella di utilizzare una voce di file host per l'alias di quell'IP della macchina al suo nome interno.

Illustrazione dello scenario 2 che una volta ho affrontato quando VisualSVN è stato installato con tutte le opzione di default e ha generato un CERT al nome simbolico della macchina che ha scoperto:

LAN nome della macchina MACHINE1 corre server SVN e ha un certificato installato che è stato rilasciato a MACCHINA1. Stai tentando di accedere a SVN tramite il suo indirizzo IP e ottenere un errore di certificato non valido.

Si otterrebbe anche quell'errore se tale MACCHINA1 è accessibile dall'esterno della LAN tramite FQDN ad esempio svn.domain.com e ci si sta connettendo a FQDN.

In entrambi i casi svn genererebbe l'errore di certificato non valido.

È possibile aggiungere una voce al file hosts per mappare l'indirizzo della macchina IP (LAN o esterno a seconda di dove si accede da) per il certificato di nome è stato emesso per:

123.45.67.89 MACHINE1 

e l'accesso SVN via https://machine1/svn/ per aggirare questa situazione.