Short version: --trust-server-cert bypasses ONLY the "CA is unknown" check; it doesn't bypass hostname and expiry checks.
Arpad Ilia wrote on Wed, 9 Jun 2010 at 15:38 -0000: > Hi! > > Is my observation correct that this command line switch > (--trust-server-cert) will not accept certificates where the > certificate hostname does not match? > To my surprise, yes. (I tested with <https://svn2.sjc.collab.net/repos/svn-org>.) Looking at the source code (from subversion/libsvn_subr/cmdline.c), we see this documentary comment: [[[ Don't actually prompt. Instead, set *CRED_P to valid credentials iff FAILURES is empty or is exactly SVN_AUTH_SSL_UNKNOWNCA. If there are any other failure bits, then set *CRED_P to null (that is, reject the cert). ]]] Where the possible bits are (from svn_auth.h): [[[ /** Certificate is not yet valid. */ #define SVN_AUTH_SSL_NOTYETVALID 0x00000001 /** Certificate has expired. */ #define SVN_AUTH_SSL_EXPIRED 0x00000002 /** Certificate's CN (hostname) does not match the remote hostname. */ #define SVN_AUTH_SSL_CNMISMATCH 0x00000004 /** @brief Certificate authority is unknown (i.e. not trusted) */ #define SVN_AUTH_SSL_UNKNOWNCA 0x00000008 /** @brief Other failure. This can happen if neon has introduced a new * failure bit that we do not handle yet. */ #define SVN_AUTH_SSL_OTHER 0x40000000 ]]] So, yes, current --trust-server-cert doesn't bypass the hostname and expiry checks. I can see an argument for allowing a --I-know-what-I'm-doing-just-accept-that-cert-whatever-it-is mode, though. (In case of an attack, the hostname and expiry are the easiest things to get right --- the CA is the hard part --- so if we allow bypassing *that*...) > Thanks, > Arpad Ilia >
