Re: ssl certificate management

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

jmdault wrote:
> Le jeu 28/04/2005 à 06:16, Buchan Milne a écrit :
> 
>>>>Then some people proposed a full-blown PKI infrastructure. Oden just 
>>>
>>>That is very interesting, but a bit overkill for the majority of desktop
>>
>>But what about the admin for a majority of desktop users?
> 
> 
> I agree that a PKI infrastructure would be useful (hey, I'd be the first
> one to use it ;-).
> 
> What I meant is that I think there are more immediate issues to
> consider:

I agree ...but I think solving all of the issues below, when we could
solve them *and* provide for us implementing a complete solution is a
waste of time ... lets try and do it once.


> 1) Right now, every server has a different certificate. This is bad,
> because this means that every service has to be configured separately.
> If the certificate and key was the same for all servers, a KDE user
> would simply have to launch Konqueror, accept a master certificate, and
> it would be accepted for smtp, pop and ldap.

Well, if all the certs were signed by one CA cert ... the use would just
have to import one cert ...

> 
> 2) Even worse than a different certificate is the fact that most
> certificates are generated for localhost.

Agreed, and this is one of the primary things that should be solved.

> This means that when you
> accept a certificate for one server, you can't use it for others as they
> conflict. I solved it for Apache, but other services have the same
> problem

Could you elaborate?

> 
> 3) Many servers don't have ssl/tls enabled. For example, mod_ldap and
> proftpd have to be recompiled, otherwise the only connection is LDAPv2
> without ssl.

Well, this should be fixed whether we sort out cert management or not.

> 
> 4) Many servers don't work with LDAP out of the box.

But, this isn't anything to do with SSL ... winbind is also affected ...

> Take ssh for
> example, you have to add UsePAM=yes and
> ChallengeResponseAuthentication=no to sshd_config. It would be great to
> have this by default. And use pam_access instead of having both
> pam_listfile and PermitRootLogins=no.

Or, drakauth should take care of it.

The ssh maintainers are averse to using pam by default.

> Even if we have no PKI infrastructure, if we could have just SSL
> generate a CA by default, generate a single copy of certs that are used
> across all servers, and have a simple way to regenerate them, that would
> be a start.

Agreed. But, some steps will be the same for a PKI infrastructure. So,
we shouldn't make assumptions about where the CA cert is ... the script
run by a service installation should generate a CSR (we should also use
a common openssl.cnf file, and make it easy to edit) ... somehow the CSR
should be signed, and the init script should check for a signed cert (at
which time the pem files should be swapped ...).

The issue is solving the "somehow the CSR should be signed" bit.

Regards,
Buchan

- --
Buchan Milne                      Senior Support Technician
Obsidian Systems                  http://www.obsidian.co.za
B.Eng          RHCE (803004789010797),LPIC-1 (LPI000074592)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCcl83rJK6UGDSBKcRAsHIAKDIchgQLohzPAbMUFVYNzi85wWSxQCbBbn8
ryX9YauULaHBOaoZzjFeO+Y=
=U+Oz
-----END PGP SIGNATURE-----