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