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

Re: Issue 650, SSL certificate authority validation questions

From: <jerenkrantz_at_apache.org>
Date: 2003-01-25 01:57:53 CET

--On Friday, January 24, 2003 16:58:01 -0700 David Waite mass@akuma.org

 I'm trying to tackle issue 650, starting with SSL server certificate
 validation, moving to client certificate authentication. (CRL support

Cool. (Ditto on CRLs. If someone wants 'em, they can add support.)

 I assume all of these should be in the servers file. Other than names
 above, there are a couple of issues I'm seeking feedback on:

I think the CA options you have listed would be system wide rather than per
server. But, that's me.

 - should ssl-authorities-file have a default if not specified? If so,
 what should this be across platforms?

Yes, I think so. ~/.subversion/certs/ sounds like a reasonable starting
point (I believe OpenSSL supports pointing at a directory and adding all of
the .pem's to its internal list).

Perhaps you could do some registry entries on Win32, but I've seen Brane
starting to mumble that Win32 should have a ~/.subversion/ dir anyway. I'd
defer to whatever the Win32 crowd says...

 - should ignore-ssl-host-mismatch allow you to specify an alternate
 hostname to match against the server certificate CN?

I don't think so. An 'alternate-ssl-host-name' per-server option might be
sufficient rather than wrapping it in the ignore-ssl-host-mismatch option.

 - should there be prompting on the above errors?

My hunch is no, but it should print out a warning at the very least.
Perhaps the host mismatch should at least produce a prompt the first time
(thinking of how OpenSSH does this when there is a mismatch). The rest of
them aren't as 'fatal.' (It's out-of-date or the CA is unknown isn't the
end of the world and probably is worth a warning if that.)

I would also probably suggest that you do this on a branch rather than
doing it in a cave. But, that's me. =) Earlier feedback would be better,
I think. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:16:20 2006

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.