certificate-based authentication for https hgwebdir clients
dimitris at census-labs.com
Tue Jan 6 08:31:35 CST 2009
I'm attaching a patch that enables hgwebdir to do basic certicate-based
authentication for clients, in https mode. By 'basic' I mean that the
client's certificate is checked against a list of registered certificates
and if it is not found in the list (or is invalid), the SSL session is
A few words about the patch:
* A new option, '--require-client-cert', has been added to 'hg serve'.
This turns on the client-authenticated handshake mode of SSL.
* A new section, 'https_clients', has been added to the hgwebdir config
file, describing the client certificates that will be allowed to
participate in SSL sessions. Each certificate is described by a
- The key is a 'nickname' given by the hgwebdir admin to this
- The value is the SHA1 digest of the certificate
(i.e. openssl x509 -fingerprint -in cert.pem -sha1 -noout)
An example follows:
joe = 0F:12:42:32:42:24:12:12:12:12:45:23:24:23:24:25:23:23:23:11
amy = 11:23:23:11:42:42:16:11:AE:15:A8:11:23:82:00:02:08:15:23:43
* A new section, 'https', has been introduced to the client's config file
(.hgrc). This describes the certificates the client will be using during
https sessions. Here's an example of this section:
cert_file = /home/joe/pubkey.pem
key_file = /home/joe/privkey.pem
* Self-signed client certificates are considered OK (as far as certificate
validity is concerned).
* I've added a short script that tests the client/server behaviour
when the client provides:
- a registered certificate
- an unregistered certificate
- no certificate at all
What's the reasoning behind this?
There are times when you don't want to setup a full-blown webserver
with its own acl/authentication scheme, because you will be working
in an ad-hoc manner with others (i.e. no single repository will be
online at all times). Even more so, you might not want to provide
ssh accounts to third parties on the host serving the repository.
'hg serve' is perfect for these types of situations, but it is
really missing an authentication method to control access to
the repositories. This patch is a first step in this direction.
It provides a certificate-based authentication mechanism for https
and could be coupled with the existing framework for acl's, so that
certificate holders (see 'nicknames' above) are treated as regular
...hoping this functionality makes it through to hg :-)
(On a more personal note) Best Wishes for a Happy New Year and a big
THANK YOU for all your great work on Mercurial!
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 15406 bytes
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090106/24e3605f/attachment.patch
More information about the Mercurial-devel