[Freeswitch-users] TLS key management (was FreeSWITCH Weekly News and Notes)
daniel at pocock.com.au
Wed Aug 29 02:24:22 MSD 2012
On 28/08/12 23:07, Michael Collins wrote:
> Tomorrow we hope to have a discussion about
> We have several community members who are experienced with key and
> certificate management and we will be calling upon them to share their
> experience with the rest of us. After that we will have an open discussion.
FYI, this came up at DebConf, some of us are thinking about similar
issues at a platform level:
and notes from the session can be accessed with the gobby tool (sorry I
can't find this online somewhere, I've cut and pasted below for
look under debconf12/bof/X.509
As was emphasized at DebConf, it is a particular issue for VoIP
services, because different applications (e.g. a Jabber server and a SIP
server) can share the same key material (no need to waste money buying a
cert for each protocol), but sharing private keys between different
applications requires a more rigorous platform-wide effort to protect
X.509 Certificate, Root CA, and Key best practices
Confusing for packagers, admins, and users. Let's fix!
* where to store secret key material? (/etc/ssl/private)
* sharing key material across services?
* locations for server certificates?
* auto-creation of key/cert/certreq?
* intermediate CA certificate storage
* list of trusted root authorities for client certs -- shared?
* list of trusted root authorities -- system store? end-user override?
-> Make all clients use the same store?
* managing per-user certificates and secret keys -- p11-kit
* how do we deal with root authorities for different contexts (web,
e-mail, code-signing, etc)
* CRL/OCSP check?
IIRC Microsoft now distributes blacklists via their update service
(chrome iirc too)
* What can the cert be used for (email, website, software)
-> mozilla has that information in it's store
-> openssl can store it, but then uses a different header that others
might not be able to read
(clients and servers) -- how can we make this less painful?
* iceweasel/icedove (via nss and libckbi.so)
* ca-certificates (potential split into ca-certificates,
* kdelibs5-data: /usr/share/kde4/apps/kssl/ca-bundle.crt
* nmap: /usr/share/ncat/ca-bundle.crt
* ruby: /usr/lib/ruby/XXX/rubygems/ssl_certs/ca-bundle.pem
* sympa: /usr/share/sympa/default/ca-bundle.crt
* nutsurf-common: /usr/share/netsurf/ca-bundle.txt
* abiword: /usr/share/abiword-2.9/certs/cacert.pem
* acgvision-agent: /etc/acgvision/acgTrustStore.certs
* apparmor: /etc/apparmor.d/abstractions/ssl_certs
* gnupg2: /usr/share/gnupg2/com-certs.pem
* libpurple0: /usr/share/purple/ca-certs/
* linphone-common: /usr/share/linphone/rootca.pem
* ntop-data: /usr/share/ntop/ntop-cert.pem
* openssl (embeds /etc/ssl/certs)
* gnutls (no default authorities -- is this a good thing)
* dovecot (and other IMAPs, POP3s servers)
* exim4 and other MTAs (SMTPS, SMTP AUTH)
* XMPP servers
normalizing and de-confusing names of directories:
* /etc/ssl → /etc/x509 ?
* .../certs → .../cas ?
* /etc/ssl/public for non-ca certificates?
* monitoring/review of sensitive directories (e.g. cronjob to review
these directories and report on changes,
like many people do already with nagios/icinga)
* tool to inspect/interrogate all open sockets that appear to support
TLS/SSL and report problems
* something like db-config-common for X.509
* ssl-cert and ca-certificates ca-certificates-java
* per-machine root-authority that could be enabled by default?
* best practices documentation: http://wiki.debian.org/X.509
* what of this can or should be policy?
* how can we get project-wide rough consensus
* come up with a plan for how to file bugs; i.e. in the bug report,
we need a suggested plan for what to do differently
* make it easy for an administrator to configure his or her system for
X.509 certificates with a single easily auditable point of control
* make it easy for a packager to rely on certificate creation,
management, expiry, etc. so that each package doesn't need to
reimplement these functions
* make it easy for a user to use client-side certificates across tools
* make it easy for a user to connect to public services predictably
with different tools
Other Distros Approaches
* Fedora's attempt to replace NSS
Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users