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

Dagobert Michelsen dam at opencsw.org
Tue Oct 9 10:56:42 CEST 2012

Hi Ben,

Am 09.10.2012 um 10:39 schrieb Ben Walton <bwalton at opencsw.org>:
> 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.

Like ssl_hostname in /etc/opt/csw/csw.conf defaulting to `hostname`.`domainname` ?

> 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)
> STATE=...
> ...
> if [ -f /etc/opt/csw/cas-ssl.conf ]; then
>  . /etc/opt/csw/cas-ssl.conf

Ah, ok, a specific ssl config file. Would also be ok.

> 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.

I would put the certificate in the same directory as the CAS
containing the cert descriptions

> 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.

Yes. And: Yes.

> 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?

ATM lots of packages don't go the extra mile of generating a cert. I would
think having secure-by-default would be good.

Best regards

  -- Dago

"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

More information about the maintainers mailing list