[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] Problem with unsigned/unknown certs with SSL and ra_serf

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Tue, 4 Nov 2008 15:25:28 -0600

I'm currently running into an issue with the new cert stuff that Ivan
added a while back to trunk for ra_serf.

ra_serf currently constructs the realmstring (ie
https://svn.collab.net/) and then passes that into SVN's credential
system. However, OpenSSL/Serf will ask for validity checks against
every cert that is presented - ie also validating the entire cert
chain against its storage. (I believe ra_neon only presents the
server's cert - not the entire chain.)

Now, what happens is that if you have a self-signed cert, OpenSSL will
ask Serf (and in turn ra_serf) to validate the root CA *then* it will
also ask to validate the server's cert. The core problem is that the
realmstring will stay the same (as it is keyed off the session's repos
url). But, the certs OpenSSL is asking to validate are different.
Hence, the svn.ssl.server cert is presented with *two* different certs
to store. This causes svn.ssl.server auth mechanism to overwrite the
1st cert in its storage with the 2nd one. So, the next time the user
invokes svn and presents the root CA, it won't be there - then, the
user will be prompted to accept the cert.

One option is to use cert_info.hostname (aka CN) as the key (not
realmstring) - but there is no guarantee that the CN is unique.
Hence, I tried to concat the realmstring and .hostname, but this issue
with this patch is that it yields the following:

Error validating server certificate for
'https://svn.apache.orgStarfield Secure Certification Authority':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
 - The certificate hostname does not match.
Certificate information:
 - Hostname: Starfield Secure Certification Authority
 - Valid: from Jan 14 21:05:21 2004 GMT until Jan 9 21:05:21 2024 GMT
 - Issuer: ValiCert Class 2 Policy Validation Authority, ValiCert,
Inc., ValiCert Validation Network, (null), (null) (info_at_valicert.com)
 - Fingerprint: 44:6A:2A:00:C1:BB:A3:6D:59:D1:C1:78:A6:7A:27:C5:0E:6D:03:DF
(R)eject, accept (t)emporarily or accept (p)ermanently? p

That isn't quite what I'd want. So, I'm tempted to go with just
cert_info.hostname rather than realmstring. Or, perhaps, rev the
credential system to split the primary key from the prompt display
info. (ie show realmstring but store based on cert_info.hostname).

Thoughts? -- justin

* subversion/libsvn_ra_serf/util.c
  (ssl_server_cert): Pass in cert_info.hostname into credential system.
Index: subversion/libsvn_ra_serf/util.c
--- subversion/libsvn_ra_serf/util.c	(revision 34034)
+++ subversion/libsvn_ra_serf/util.c	(working copy)
@@ -109,7 +109,7 @@ ssl_server_cert(void *baton, int failures,
   svn_auth_ssl_server_cert_info_t cert_info;
   svn_auth_cred_ssl_server_trust_t *server_creds = NULL;
   svn_auth_iterstate_t *state;
-  const char *realmstring;
+  const char *realmstring, *realm_cert_string;
   apr_uint32_t svn_failures;
   svn_error_t *err;
   apr_hash_t *issuer, *subject, *serf_cert;
@@ -166,9 +166,19 @@ ssl_server_cert(void *baton, int failures,
+  if (cert_info.hostname)
+    {
+      realm_cert_string = apr_pstrcat(subpool, realmstring, cert_info.hostname,
+                                      NULL);
+    }
+  else
+    {
+      realm_cert_string = realmstring;
+    }
   err = svn_auth_first_credentials(&creds, &state,
-                                   realmstring,
+                                   realm_cert_string,
   if (err || ! creds)
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-04 22:25:42 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.