|
Size: 6083
Comment: letsencrypt-domains planet.debian.org hook uses it for sending certs to maxcdn
|
Size: 4066
Comment: /etc/ssl/ca-debian is not necessary any more
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Machines administered by [[Teams/DSA|DSA]] have a custom setup for SSL verification that was [[https://lists.debian.org/debian-services-admin/2015/01/msg00002.html|announced]] in 2015. | Machines administered by [[Teams/DSA|DSA]] have a custom setup for SSL verification. |
| Line 3: | Line 3: |
| By default, DSA-administered machines do not trust any CA certs and only contain SSL certs for debian.org services. Some software is unable to verify debian.org service certs without the CA cert being present and trusted. For such software, DSA has provided /etc/ssl/ca-debian as a workaround. Please file bugs on any software that needs the workaround, using these usertags: {{{ User: debian-admin@lists.debian.org Usertags: needed-by-DSA-Team ssl }}} |
By default, DSA-administered machines only trust CA certs that issue SSL certs for debian.org services. |
| Line 16: | Line 9: |
| == /etc/ssl/certs == | == /etc/ssl/ca-global == |
| Line 18: | Line 11: |
| wget in wheezy (but not jessie and later) is known to work with the debian.org service certs present in /etc/ssl/certs on debian.org machines. == /etc/ssl/ca-debian == The following software is unable to verify service certs without the CA cert being present and trusted. Known workarounds for these issues are available below, please add any more that are needed. If your service needs to add one of these workarounds, please mention it in the users section below. |
If your service needs this directory, you can use one of the below snippets for this purpose and please mention your service in the users section below. |
| Line 26: | Line 15: |
| apt from Debian jessie requires the bundle rather than the directory: |
|
| Line 29: | Line 16: |
| Acquire::https::buildd.debian.org::CaInfo "/etc/ssl/ca-debian/ca-certificates.crt"; }}} apt from Debian wheezy should be able to use the service cert directly: {{{ Acquire::https::buildd.debian.org::CaInfo "/etc/ssl/servicecerts/buildd.debian.org.crt"; |
Acquire::https::buildd.debian.org::CaInfo "/etc/ssl/ca-global/ca-certificates.crt"; |
| Line 41: | Line 22: |
| dir=/etc/ssl/ca-debian | dir=/etc/ssl/ca-global |
| Line 49: | Line 30: |
| dir=/etc/ssl/ca-debian | dir=/etc/ssl/ca-global |
| Line 57: | Line 38: |
| dir=/etc/ssl/ca-debian | dir=/etc/ssl/ca-global |
| Line 65: | Line 46: |
| dir=/etc/ssl/ca-debian | dir=/etc/ssl/ca-global |
| Line 72: | Line 53: |
| git from Debian jessie onwards requires the bundle rather than the dir: |
|
| Line 75: | Line 54: |
| # Or /etc/ssl/ca-global for external repositories dir=/etc/ssl/ca-debian |
dir=/etc/ssl/ca-global |
| Line 83: | Line 61: |
| dir=/etc/ssl/ca-debian | dir=/etc/ssl/ca-global |
| Line 89: | Line 67: |
| git from Debian wheezy (and older) should be able to use the service cert directly. |
|
| Line 94: | Line 70: |
| my $ca_dir = '/etc/ssl/ca-debian'; | my $ca_dir = '/etc/ssl/ca-global'; |
| Line 102: | Line 78: |
| $capath = '/etc/ssl/ca-debian'; | $capath = '/etc/ssl/ca-global'; |
| Line 113: | Line 89: |
| bundle='/etc/ssl/ca-debian/ca-certificates.crt' | bundle='/etc/ssl/ca-global/ca-certificates.crt' |
| Line 115: | Line 91: |
| requests.get('https://www.debian.org/', verify=bundle) | requests.get('https://www.python.org/', verify=bundle) |
| Line 117: | Line 93: |
| requests.get('https://www.debian.org/') | requests.get('https://www.python.org/') |
| Line 123: | Line 99: |
| dir=/etc/ssl/ca-debian | dir=/etc/ssl/ca-global |
| Line 132: | Line 108: |
| ca_path = '/etc/ssl/ca-debian' | ca_path = '/etc/ssl/ca-global' |
| Line 135: | Line 111: |
| data_file = urllib.urlopen("https://www.debian.org/", context=context) | data_file = urllib.urlopen("https://www.python.org/", context=context) |
| Line 137: | Line 113: |
| data_file = urllib.urlopen("https://www.debian.org/") | data_file = urllib.urlopen("https://www.python.org/") |
| Line 146: | Line 122: |
| bundle = '/etc/ssl/ca-debian/ca-certificates.crt' | bundle = '/etc/ssl/ca-global/ca-certificates.crt' |
| Line 154: | Line 130: |
| bundle = '/etc/ssl/ca-debian/ca-certificates.crt' | bundle = '/etc/ssl/ca-global/ca-certificates.crt' |
| Line 164: | Line 140: |
| dir=/etc/ssl/ca-debian | dir=/etc/ssl/ca-global |
| Line 171: | Line 147: |
| Using service certificates no longer works in jessie. The workaround is to use the CA certificate bundle: |
|
| Line 175: | Line 148: |
| ca_cert_file = "/etc/ssl/ca-debian/ca-certificates.crt" | ca_cert_file = "/etc/ssl/ca-global/ca-certificates.crt" |
| Line 180: | Line 153: |
=== users === * buildd apt * rt-mailgate * nagios dsa-check-mirrorsync * PTS (update_incoming.sh, BTS SOAP calls) * the l10n stuff * vote stuff * webwml (english/mirror/arch_size.pl, english/devel/wnpp/wnpp.pl) * debwww cron (parts/1listscfg parts/1pseudo-packages) * contributors.d.o submitters: wiki, ftp-master, nm, spamreview * [[Services/DerivativesCensus|derivs census]] * [[Services/Debian Archive|dak]] * qa.d.o (lots) * dose (cronjob on qa.d.o) == /etc/ssl/ca-global == If your service needs this directory, you can adapt the ca-debian workarounds for this purpose and please mention your service in the users section below. |
Machines administered by DSA have a custom setup for SSL verification.
By default, DSA-administered machines only trust CA certs that issue SSL certs for debian.org services.
Some services need to verify the SSL certs of arbitrary services on the Internet that could change their SSL provider at any point in time. For such software, DSA has provided /etc/ssl/ca-global, which contains all the certs trusted by ca-certificates.
Contents
/etc/ssl/ca-global
If your service needs this directory, you can use one of the below snippets for this purpose and please mention your service in the users section below.
apt
Acquire::https::buildd.debian.org::CaInfo "/etc/ssl/ca-global/ca-certificates.crt";
curl
dir=/etc/ssl/ca-global test -d $dir && capath="--capath $dir" curl $capath
or
dir=/etc/ssl/ca-global test -d $dir && export CURL_CA_BUNDLE="$dir" curl
wget
dir=/etc/ssl/ca-global test -d $dir && capath="--ca-directory=$dir" wget $capath
lynx
dir=/etc/ssl/ca-global test -d $dir && export SSL_CERT_DIR="$dir" lynx
git
dir=/etc/ssl/ca-global test -d $dir && git config --local --add http.sslCAInfo $dir/ca-certificates.crt
For an initial clone:
dir=/etc/ssl/ca-global test -d $dir && git -c http.sslCAInfo=$dir/ca-certificates.crt clone <URL>
and then also set the config persistently like above.
LWP
my $ca_dir = '/etc/ssl/ca-global';
$ENV{PERL_LWP_SSL_CA_PATH} = $ca_dir if -d $ca_dir;
php
A stream context needs to be created defining the additional cert information. Various APIs can then consume that context. For example:
$capath = '/etc/ssl/ca-global';
if (is_dir($capath)) {
$context = stream_context_create(array('ssl' => array('capath' => $capath)));
libxml_set_streams_context($context);
}
$xml = simplexml_load_file(…);
python-requests
bundle='/etc/ssl/ca-global/ca-certificates.crt'
if os.path.exists(bundle):
requests.get('https://www.python.org/', verify=bundle)
else:
requests.get('https://www.python.org/')Or in the shell wrapper for the Python script:
dir=/etc/ssl/ca-global test -d $dir && REQUESTS_CA_BUNDLE=$dir/ca-certificates.crt
python-urllib
urllib in jessie and later verifies SSL certificates.
ca_path = '/etc/ssl/ca-global'
if os.path.isdir(ca_path):
context = ssl.create_default_context(capath=ca_path)
data_file = urllib.urlopen("https://www.python.org/", context=context)
else:
data_file = urllib.urlopen("https://www.python.org/")
data = data_file.read()
python-httlib2
This enables a per-connection workaround:
bundle = '/etc/ssl/ca-global/ca-certificates.crt' ca_certs = bundle if os.path.exists(bundle) else None h = Http(ca_certs=ca_certs)
This enables a global workaround for the issue and thus will only be suitable in some circumstances and might not always be supported:
bundle = '/etc/ssl/ca-global/ca-certificates.crt' if os.path.exists(bundle): httplib2.CA_CERTS = bundle
rt-mailgate
rt-mailgate requires the bundle rather than the dir:
dir=/etc/ssl/ca-global test -d $dir && cafile="--ca-file $dir/ca-certificates.crt " /usr/bin/rt-mailgate ... $cafile
python-ldap / libldap
ca_cert_file = "/etc/ssl/ca-global/ca-certificates.crt" ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, ca_cert_file) (global) or connection.set_option(ldap.OPT_X_TLS_CACERTFILE, ca_cert_file) (per connection)
users
- PTS update_incoming.sh downloader
- qa.d.o (vcswatch, data/cronjobs/ddpo.ci, data/cronjobs/ddpo.reproducible)
- webwml
- ieee-data
- rtc stuff
- secteam nvd download
dep11-generator (AppStream data extractor)
- tracker.debian.org
- letsencrypt-domains (planet.debian.org hook)
