Re: cleaning up courier-* packages

--nextPart1206697.ZK9q7SyzgX
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Since I need to look at some of these issues again now, I have returned to=
=20
this thread.


On Friday 02 June 2006 11:07, Guillaume Rousse wrote:
> Buchan Milne wrote:
> >> For achieability, the scenario seems a bit complex, and I'd prefer to
> >> start with simpler issues, such as:
> >> - standard locations for SSL configuration files used to create
> >> certificates - standard contents for those files
>
> If there is no standard directories for them, I think they could be kept
> either in /etc/pki/tls directly (as openssl.cnf), or in
> /etc/pki/tls/conf eventually. And flagged as config files, of course.
>
> >> - standard handling of those files
> >> - standard locations for SSL certs themselves
> >
> > The directory to contain them seems to be fixed (and standardised betwe=
en
> > us, RH/Fedora and SUSE IIRC) as /etc/pki/tls/certs, with keys
> > in /etc/pki/tls/private
>
> I'd prefered /etc/pki/tls/keys :(

It would have been more consistent ...

>
> I guess combined certs+keys files should go in keys directory also.

"private" ? Yes.

> > - standard locations for CRLs (without which, PKI can be entirely
> > compromised).
>
> /etc/pki/tls/crls ?

If there is a CRL for a CA, can we recommend that the CRL name match the CA=
=20
certificate name?

>
> > - standard locations for CA certs (taking into account different
> > assumptions/uses for CA certs, eg you wouldn't want to
> > use 'tls_cacertdir /etc/pki/tls/rootcerts' in /etc/ldap.conf).
>
> From my current /etc/pki content, I guess it should be
> /etc/pki/CA/certs, but I don't understand the need to keep them
> separated from others.

I think the location /etc/pki/tls/rootcerts should be used for commercial C=
A=20
root certificates, but there is a difference between:

=2Dtrusting a CA to sign certificates that you will trust to provide you wi=
th an=20
SSL cert, or validate the certificate of another entity you will do a=20
transaction with
vs
=2Dtrusting a CA to sign certificates that you will trust to allow access t=
o=20
your VPN, your LDAP server, your web server using certificate-based=20
authentication, trust for signing audited shell sessions with easd, or to=20
whom you are prepared to give your password, trust for authenticating your=
=20
root user on your laptop etc etc.

=46or the latter case, I have been using /etc/pki/tls/cacert.pem myself, bu=
t=20
should /etc/ldap.conf, /etc/openldap/ldap.conf etc. etc. use these by=20
default?

> >> For desirability, your prefered scenario (the most complex) seems to
> >> involve too much assumptions about user specific needs. As packagers,
> >> we're supposed to polish softwares issued from different developement
> >> teams, and provide the minimal stuff needed to run them, not replace
> >> sysadmins.
> >
> > Indeed, but no point doing an implementation which precludes re-use by
> > sysadmins to implement the preferred scenario.
> >
> >> My point is that over-configuration hurts, and we should rather focus =
on
> >> minimal harmonisation between packages, letting sysadmins finish
> >> configuration, rather than arguing about the ultimate default
> >> configuration everyone will have to change anyway. And the more advanc=
ed
> >> use-case you try to automatically enforce, the higher the chance they
> >> will differ from user own needs.
> >
> > Well, no, as long as the tool called (and it's arguments) to actually
> > generate (and possibly sign) the cert isn't hardcoded into a macro, but
> > rather a configureable script, it should not be that different.
> >
> >> For all of those reasons, I'd prefer to try to achieve the intermediate
> >> scenario only (local trivial CA), and see thereafter if further
> >> enhancement is really needed.
> >
> > Let's just not make short-sighted assumptions that would make it all
> > useless for someone who has more stringent requirements (eg
> > Sarbannes-Oxley-type stuff).
> >
> > And, let's be careful in noting different uses for SSL certs (eg trusti=
ng
> > a cert signed by a CA to provide access to a host vs trusting a cert to
> > provide some kind of verification for an online transaction are two very
> > different things).
>
> We need a starting point anyway, so let's try different scenarios,
> hardcoding command in spec file first. We can use courier-imap as a test
> package, ssl certs handling have been removed from initscripts anyway :)
>
> Here is a simple auto-signed certs generation scenario:
> 1) ship ssl upstream cert configuration file as /etc/pki/tls/imap.cnf,
> tagged as configuration files
> 2) generate self-signed certificate in %post in initial installation only:
> openssl req -new -x509 -days 365 -config /etc/pki/tls/imap.cnf -keyout
> /etc/pki/tls/private/imap.pem -out /etc/pki/tls/certs/imap.pem

I was wondering if a per-service configuration file should only be used if=
=20
present, since I see no reason to have multiple certs for different service=
s=20
running on the same host (and maintaining multiple configurations) by=20
default.

SERVICE=3D$1
if [ -e /etc/pki/tls/$1.cnf ]
then SSLNAME=3D$SERVICE
else SSLNAME=3Dhost
fi
openssl req -new -x509 -days 365 -config /etc/pki/tls/${SSLNAME}.cnf -keyout
/etc/pki/tls/private/${SSLNAME}.pem -out /etc/pki/tls/certs/${SSLNAME}.pem

The question is also about the contents of the openssl configuration file. =
In=20
trying to understand some of openssl some more, I reduced a default=20
openssl.cnf to just what I needed for a certificate request, and use=20
something like this:


# This definition stops the following lines choking if HOME isn't
# defined.
HOME                    =3D .
RANDFILE                =3D $ENV::HOME/.rnd

####################################################################
[ req ]
default_bits            =3D 1024
default_keyfile         =3D privkey.pem
distinguished_name      =3D req_distinguished_name
attributes              =3D req_attributes
prompt =3D no

# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix   : PrintableString, BMPString.
# utf8only: only UTF8Strings.
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings
# so use this option with caution!
string_mask =3D nombstr

# req_extensions =3D v3_req # The extensions to add to a certificate request

[ req_distinguished_name ]
countryName                     =3D ZA
stateOrProvinceName             =3D Myprovince
localityName                    =3D Mytown
0.organizationName              =3D My Organisation
organizationalUnitName          =3D My Unit
commonName                      =3D $ENV::HOSTNAME
emailAddress                    =3D [email protected]
subjectAltName=3DDNS.0:myhost.mydomain.com,IP.0:xxx.xxx.xxx.169,IP.1:xxx.xx=
x.xxx.42,IP.2:xxx.xxx.xxx.98

[ req_attributes ]
#challengePassword              =3D A challenge password
#challengePassword_min          =3D 4
#challengePassword_max          =3D 20
#unstructuredName               =3D An optional company name

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints =3D CA:FALSE
keyUsage =3D nonRepudiation, digitalSignature, keyEncipherment


Either we could assume the user will edit this file by default, or we shoul=
d=20
consider passing more as environment variables (such as with HOSTNAME above=
).

> Sysadmin could just replace /etc/pki/tls/imap.cnf with its own one, and
> use it as he want thereafter, without troubles during following upgrades.

Sure.

> This is achievable right now, and could already benefit from
> standardising all our ssl-dependant packages.

Indeed.

> A more complexe would be:
> 1) ship ssl upstream cert configuration file as /etc/pki/tls/imap.cnf
1a)Generate self-signed cert for initial use

> 2) generate certificate request in %post:
> openssl req -new -config /etc/pki/tls/imap.cnf -keyout
> /etc/pki/tls/private/imap.pem -out /etc/pki/tls/req/imap.pem

openssl req -new -config /etc/pki/tls/imap.cnf -keyout
/etc/pki/tls/private/imap.new.pem -out /etc/pki/tls/req/imap.new.pem

> 3) generate crl in %post:
> ?
> 4) sign them using local CA:
> openssl ca -in /etc/pki/tls/req/imap.pem -out /etc/pki/tls/certs/imap.pem

4)Wait for CA to sign cert, providing a script to do it if the CA is local,=
 or=20
let the user do it manually for the initial cert.

5)Have something like certnanny check all certs matching a certain glob, in=
=20
which case it should create a new request a configurable time before the ce=
rt=20
expires, signing it with the previous cert, which can (depending on CA=20
software and configuration) result in an automatically renewed cert on next=
=20
run of certnanny.

BTW, the Makefile in /etc/pki/tls/certs may be useful (and reminds me that =
we=20
may need to discuss whether we should set the Serial or not).

Regards,
Buchan

=2D-=20
Buchan Milne
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)

--nextPart1206697.ZK9q7SyzgX
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBE0KQLrJK6UGDSBKcRAjs0AJ95YyDL3ATpcaNrGqbjzzkHOSf4hACfcYhH
J8hvg1+004trzJ38+YlYM6M=
=++k2
-----END PGP SIGNATURE-----

--nextPart1206697.ZK9q7SyzgX--