Differences between revisions 1 and 9 (spanning 8 versions)
Revision 1 as of 2011-01-03 17:18:54
Size: 2979
Editor: KevinBullock
Comment: Clean up per WikiStyleGuide, copy-edit
Revision 9 as of 2011-01-04 04:11:42
Size: 3900
Comment: add link to Japanese translation
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Line 4: Line 3:

About Mercurial's handling of SSL certificates for https urls.
About Mercurial's handling of SSL certificates for `https` urls.
Line 10: Line 8:
Mercurial has improved its https support in the 1.7.x series. When connecting to an https server, it will now verify the server's certificate. Connections to a server with the wrong identity will be rejected. As of 1.7.3, Mercurial will warn if it doesn't know how to verify it because no Certification Authorities (CAs) have been configured. Mercurial has improved its HTTPS support in the 1.7.x series. When connecting to an HTTPS server, it will now verify the server's certificate. Connections to a server with the wrong identity will be rejected. As of 1.7.3, Mercurial will warn if it doesn't know how to verify it because no Certification Authorities (CAs) have been configured.
Line 12: Line 10:
{i}  The "certificate not verified" warning does not mean that you are less secure than before. It just informs you how insecure you always has been. {i} The "certificate not verified" warning does not mean that you are less secure than before. It just informs you of how insecure you have always been.
Line 14: Line 12:
You should fix your setup so you get the security you might expect from SSL and don't get any warnings; otherwise you might just as well stop using https. You should fix your setup so you get the security you might expect from SSL and don't get any warnings; otherwise you might just as well stop using HTTPS.
Line 16: Line 14:
== Configuration of Certificate Authorities ==
Most operating systems maintain a set of root certificates that you might decide to trust. Note that any of these authorities can approve a server identity, and any of them will thus be able to spoof any server identity.
== Configuration of HTTPS certificate authorities ==
Most operating systems maintain a set of root certificates that you might decide to trust. Note that any of these authorities can approve any server identity, and any of them will thus be able to spoof any server identity.
Line 31: Line 29:
If your platform doesn't provide a usable CA list, you can download a cacert file from http://curl.haxx.se/docs/caextract.html .
Line 32: Line 31:
On other platforms you can download a cacert file from http://curl.haxx.se/docs/caextract.html . The Mercurial-1.7.3 installers for Windows already contains a `misc\cacert.pem`. {i} The Windows installers for Mercurial 1.7.3 (and corresponding TortoiseHg installers) contain a `cacert.pem` and will by default configure `web.cacerts` in `hgrc.d\paths.rc` and will thus prevent connecting to repositories with self-signed certificates.
Line 34: Line 33:
You might want to modify the cacert file, for examply by removing CAs you don't trust or by adding your own internal or self-signed CAs. You might want to tweak your cacert file, for examply by removing CAs you don't trust or by adding your own internal or self-signed CAs. Only one cacerts file can be specified at any time, so you might want to override `web.cacerts` in your user or repository configuration.
Line 37: Line 36:
If you want to control explicitly which servers you will authenticate to and pull from you can explicitly configure the trusted servers identity for each local clone. If you want to control more explicitly who can impersonate which servers you will authenticate to and pull from you can explicitly configure the trusted CAs for each local clone.
Line 39: Line 38:
The server's public identity can for example be retrieved with Firefox. Browse to `https://server/repo`, click the lock symbol in the lower right corner, View Certificate, Details, Export, "X.509 Certificate (PEM)" and save somewhere as server.pem. The root CA certificate for a server can for example be retrieved with Firefox. Browse to `https://server/repo` and verify that this is the repository you trust, click the lock symbol in the lower right corner, View Certificate, Details, select the certificate at the top of the Certificate Hierarchy, Export, "X.509 Certificate (PEM)" and save somewhere for example as `server.pem`. With other browsers on Windows (XP) you have to view the certificate at the top of the Certification Path and "Copy to File" as "Base-64 encoded X.509 (.CER)".
Line 41: Line 40:
In your local repo edit .hg/hgrc and add In your local repository edit `.hg/hgrc` and add
Line 47: Line 46:
Line 51: Line 49:
Packagers are encouraged to integrate as good as possible with the platforms existing PKI, for example by distributing a `hgrc.d/cacert.rc` with configuration of `web.cacerts`. If the platform don't have a suitable CA list you might want to distribute your own - for example the one from cURL/Mozilla. Packagers are encouraged to integrate as good as possible with the platforms existing PKI, for example by distributing a `hgrc.d/cacert.rc` with configuration of `web.cacerts`. If the platform doesn't have a suitable CA list you might want to distribute your own - for example the one from cURL/Mozilla.
Line 53: Line 51:
Note however that that will cause a regression for those who connect to servers with self-signed certificates. It should thus not be introduced in a bugfix release but wait for a major update, depending on how your update strategy is. Note however that that using a pre-configured cacert list by default will cause a regression for those who connect to servers with self-signed certificates. It should thus not be introduced in a bugfix release but wait for a major update, depending on how your update strategy is.

== SMTP TLS certificates ==
Mercurial does not currently verify TLS certificates for SMTP.
Line 56: Line 57:
 * http://docs.python.org/library/ssl.html#ssl-certificates
Line 59: Line 61:

----

[[JapaneseCACertificates|日本語]]

CA Certificates

About Mercurial's handling of SSL certificates for https urls.

1. Changes in Mercurial 1.7.x

Mercurial has improved its HTTPS support in the 1.7.x series. When connecting to an HTTPS server, it will now verify the server's certificate. Connections to a server with the wrong identity will be rejected. As of 1.7.3, Mercurial will warn if it doesn't know how to verify it because no Certification Authorities (CAs) have been configured.

{i} The "certificate not verified" warning does not mean that you are less secure than before. It just informs you of how insecure you have always been.

You should fix your setup so you get the security you might expect from SSL and don't get any warnings; otherwise you might just as well stop using HTTPS.

2. Configuration of HTTPS certificate authorities

Most operating systems maintain a set of root certificates that you might decide to trust. Note that any of these authorities can approve any server identity, and any of them will thus be able to spoof any server identity.

On Debian and Ubuntu you can use this global configuration:

[web]
cacerts = /etc/ssl/certs/ca-certificates.crt

On Fedora and RHEL you can use this global configuration:

[web]
cacerts = /etc/pki/tls/certs/ca-bundle.crt

If your platform doesn't provide a usable CA list, you can download a cacert file from http://curl.haxx.se/docs/caextract.html .

{i} The Windows installers for Mercurial 1.7.3 (and corresponding TortoiseHg installers) contain a cacert.pem and will by default configure web.cacerts in hgrc.d\paths.rc and will thus prevent connecting to repositories with self-signed certificates.

You might want to tweak your cacert file, for examply by removing CAs you don't trust or by adding your own internal or self-signed CAs. Only one cacerts file can be specified at any time, so you might want to override web.cacerts in your user or repository configuration.

3. Per-repository configuration

If you want to control more explicitly who can impersonate which servers you will authenticate to and pull from you can explicitly configure the trusted CAs for each local clone.

The root CA certificate for a server can for example be retrieved with Firefox. Browse to https://server/repo and verify that this is the repository you trust, click the lock symbol in the lower right corner, View Certificate, Details, select the certificate at the top of the Certificate Hierarchy, Export, "X.509 Certificate (PEM)" and save somewhere for example as server.pem. With other browsers on Windows (XP) you have to view the certificate at the top of the Certification Path and "Copy to File" as "Base-64 encoded X.509 (.CER)".

In your local repository edit .hg/hgrc and add

[web]
cacerts = /path/to/server.pem

Note: This requires Mercurial 1.7.3 or later.

4. Packaging

Packagers are encouraged to integrate as good as possible with the platforms existing PKI, for example by distributing a hgrc.d/cacert.rc with configuration of web.cacerts. If the platform doesn't have a suitable CA list you might want to distribute your own - for example the one from cURL/Mozilla.

Note however that that using a pre-configured cacert list by default will cause a regression for those who connect to servers with self-signed certificates. It should thus not be introduced in a bugfix release but wait for a major update, depending on how your update strategy is.

5. SMTP TLS certificates

Mercurial does not currently verify TLS certificates for SMTP.

6. See also


日本語

CACertificates (last edited 2015-04-19 13:20:25 by YuyaNishihara)