On 04/24/2014 04:20 PM, Paul Wouters wrote:
On Thu, 24 Apr 2014, Florian Weimer wrote:
I'm working on advice on automated X.509 certificate generation during
package installation.
I would strongly recommend doing it on first service start. I've lived
through the FreeS/WAN times and my experience with it for 15+ years
caused us (in libreswan) to completely refrain from geenrating raw RSA
keys or certificates. (But we don't need to do OE/anon TLS)
I don't think "openssl genrsa 2048" has this issue on today's machines.
(I know I saw it with GNUTLS.)
One aspect is that these files obviously have to be generated on the
system during installation (or first service start) and cannot be
shipped in the package. Some existing RPMs just drop files into
/etc/pki/certs and /etc/pki/tls/private, without marking them as ghost
files or configuration files. (I'm not even sure if you can mark
something for which no content is provided in the RPM as a
configuration file.)
Those are global locations, right? While certs could go there, CAcerts
should not just be dropped in there - especially not self-signed ones.
It would be a self-signed non-CA certificate. A package-specific
directory would work as well.
I wonder what an ideal RPM package would do in this case?
How many packages would actually perform any kind of "opportunistic
encryption"? I know the mail servers prefer a selfsigned cert over no
cert whatsoever, but what other applications have this issue of "better
unknown certificate than plaintext" ?
It came up in the context of clustering software where the single
certificate/key pair (shared across the cluster) would be used to secure
cluster membership. The cluster nodes trust each other as a result of
the protocol features, so they could access their private keys anyway,
even if they were separate.
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
