Automatically generated configuration files

Florian Weimer fweimer at redhat.com
Thu Apr 24 14:57:12 UTC 2014


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


More information about the devel mailing list