Differences between revisions 12 and 13
Revision 12 as of 2013-01-31 23:10:15
Size: 3580
Comment: make default key mode 0640 to be consistent
Revision 13 as of 2013-02-01 20:51:28
Size: 3581
Editor: GeoffSimmons
Comment: Spelling.
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
NOTE2: The group name 'ssl-cert' is subobtimal because (a) this doesn't necessarily have anything to do with SSL, and (b) it doesn't have to do with certs, that group is created by the ssl-certs package. In terms of a better implementation approach, there could be a different package that provides similar functionality. NOTE2: The group name 'ssl-cert' is suboptimal because (a) this doesn't necessarily have anything to do with SSL, and (b) it doesn't have to do with certs, that group is created by the ssl-certs package. In terms of a better implementation approach, there could be a different package that provides similar functionality.
Line 49: Line 49:
 * Should we auto create key/cert/certreq on installtion?  * Should we auto create key/cert/certreq on installation?

X.509 Packaging Best Practices

Many Debian packages create, use, manage, and depend on X.509 certificates for TLS, SSL, S/MIME e-mail, VPN connections, and other cryptographic authentication.

This document attempts to collect best practices for debian packagers whose packages deal with X.509 certificates.

Objectives

  • Make it easy for an administrator to configure and manage his or her system's 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 network services predictably with different tools.
  • Make it easy for an application to check the status of the certificate of it's peer

For general end-entity local certificate and key material, the following layout is recommended:

  • /etc/x509: mode => 0755, owner => root, group => root

    • /etc/x509/keys: mode => 0750, owner => root, group => ssl-cert

      • /etc/x509/keys/${fqdn}_${service}.key: mode => 0640, owner => root, group => root

      • /etc/x509/keys/${fqdn}_imapd.key: mode => 0640, owner => root, group => imapd-group

    • /etc/x509/certs: mode => 0755, owner => root, group => root

      • /etc/x509/certs/${fqdn}_${service}.crt: mode => 0644, owner => root, group => root

In the above layout there is one certificate that is installed for the imapd certificate. If the imapd service is run by the 'imapd-user', that service should be in two groups: 'imapd-group' and 'ssl-cert'. This way the xmppd-user, who is also in the 'ssl-cert' group, can see that ${fqdn}_imapd.key exists, but it cannot read it because it is not in the imapd-group.

NOTE: It is not recommended to put local certificate and key material in /etc/ssl because /etc/ssl/certs is only for X.509 certs of system-trusted CAs

NOTE2: The group name 'ssl-cert' is suboptimal because (a) this doesn't necessarily have anything to do with SSL, and (b) it doesn't have to do with certs, that group is created by the ssl-certs package. In terms of a better implementation approach, there could be a different package that provides similar functionality.

NOTE3: The name /etc/x509 is suboptimal as well because the secret key is not x.509 at all, it's PEM-encoded key material

NOTE4: The above proposed layout could be better handled with filesystem acls:

# apt-get install acl
# mount -oremount,acl /
# fiddle with /etc/fstab to make it permanent
# setfacl -m u:imapd-user:r /etc/x509/keys/${fqdn}_imapd.key

Questions

  • Where to store secret key material? (/etc/ssl/private?)
  • Sharing key material across services? -> Question for the administrator?

  • Who owns they secret key material and how do we manage access to it?
  • Locations for the service certificates?
  • Should we auto create key/cert/certreq on installation?

Implementation ideas

  • Use something like db-config-common for creating X.509 service certificates
  • Have only 1 store with public CA certificates and have all libraries add support for reading that store. Make applications use that store by default.
  • Have a library to do CRL/OCSP/blacklist checking and make applications use it.
  • Store trust settings in the CA store.
  • Make applications use the trust settings, adding support to applications and libraries that can't read the trust settings.