Suggested solutions to certificate handling/generation for server/clients using SSL/TLS.
Problem: Incomplete or missing SSL support
Webmin, LDAP, CUPS, Apache, IMAP, POP, SMTP (more?) should all have
proper SSL support, with proper (not self-signed) certificates, with
correct names.
Getting a trusted third party to manually sign the server certificates
of all the servers on a Debian-Edu installation will be too cumbersome.
If the servers are only accessed by clients on the internal Debian-Edu
network, creating a local Certification Authority (CA) will be OK.
Suggested solution
During installation, a CA will be created. Maybe before all the SSL-
enabled servers are installed, maybe after; that depends on how we
aim to solve the certificate signing.
If the CA is in place _before_ the SSL-enabled servers, they can
have a pre-install script generate a signing request. If the CA
responds, and signs the request, the server gets a properly signed
certificate. If not, it can fall back to a self-signed certificate.
dpkg-reconfigure ought to repeat this process, in case the CA was
not working at install time.
Design consideration: The servers could "pull" their certificates
by sending a signing request, or the CA could "push" by putting the
certificate and the private key in a predetermined place.
Required integration with Debian
We need a framework for distributing the CA certificate to all the
clients. It should happen without human intervention upon installation.
The name space used is supposed to be the same as in DNS and LDAP.
Integration with debconf to get country code and other settings.
SSL-enabled server packages must send certificate signing requests
to the CA (pull), or have the CA generate signed certificates and
a private key for them (push).
SSL-enabled client packages must append the CA certificate to their
list of trusted signers (pull). Or the CA must have the ability to
do so for them (push). Pull is probably the most "future proof".
Considerations for the long term
Debian-edu may migrate to AFS and Kerberos in the future. The use
of local, non-unique, names and a NAT firewall may be abandoned.
--
Herman Robak
Reply to: