[csw-maintainers] openssl migration: group 1 packages uploaded

[Ben Walton]

Hi Dago,

On Tue, Oct 9, 2012 at 8:55 AM, Dagobert Michelsen <dam at opencsw.org> wrote:

>> Should that directory (and it's content) be split out from
>> CSWlibssl-0-9-8 into a generic package then?
>
> Why not let the directory be provided by both CSWlibssl0-9-8 and CSWlibssl1-0-0 ?
> If the permissions are the same it wouldn't matter.

If it were only the directory I'd agree with you.  It's the files in
the directory that make it worth splitting it out, I think.

>> I also wonder if the */dovecot.pem.CSW should be moved from a
>> delivered file to a generated one?
>>
>> Also, is there any interest in a CAS to handle creating SSL
>> certificates at installation time?  I'd put one together if so.  I
>> have a few packages that could uTSse it
>
> Excellent idea! How would you handle the cn as it should match the DNS?

We should let the admins set that via a config file as we couldn't
reliably determine this.  Maybe they want the SSL cert to be defined
with a a CN that is only CNAME'd to the primary DNS name of the
system?  The approach I took in apache for the dummy certificate was
to feed it some obviously fake info.  Maybe what we should do is setup
basic dummy info and then allow overrides from a system config file:

CN=$(hostname)
COUNTRY=...
STATE=...
...

if [ -f /etc/opt/csw/cas-ssl.conf ]; then
  . /etc/opt/csw/cas-ssl.conf
else
  echo "WARNING!!!"
  ...
  ...
fi

$do_the_cert_gen_stuff

The locations for the private and public halves of the certificate
would either need to be standardized into some directory or be
configurable in the package.  Also, we'd need to handle the package
upgrade case where either the package generated file exists or has
been replaced...neither case should see the files changed.  I'm
thinking that the file tagged with the cswssl CAS could specify the
locations for the public/private locations and the CAS script would
just install this file and take no action if the targets exist.
Removal would never touch the certificates.

The only real benefit to this approach over what we're currently doing
is that it removes the postinstall or other delivery mechanism to a
standardized framework.  Many (most?) sites will likely place their
own certs with proper signature chains so our delivery of the original
file is only a nicety.

Thoughts?

Thanks
-Ben