Re: cleaning up courier-* packages

Buchan Milne a =E9crit :
>> 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 o=
nly:
>> 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
>=20
> 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 ser=
vices=20
> running on the same host (and maintaining multiple configurations) by=20
> default.
>=20
> 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 -k=
eyout
> /etc/pki/tls/private/${SSLNAME}.pem -out /etc/pki/tls/certs/${SSLNAME}.=
pem
Good point. But I'd prefer have all our SSL package consistent:
1) either they all provide their own configuration file, resulting in
each having its own certificate
2) either none of them, resulting in using a shared certificate, that
need to be provided by something else (openssl, probably)

Let's start with 1 currently.

> The question is also about the contents of the openssl configuration fi=
le. 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:
>=20
>=20
> # This definition stops the following lines choking if HOME isn't
> # defined.
> HOME                    =3D .
> RANDFILE                =3D $ENV::HOME/.rnd
Not mandatory AFAIK.
>=20
> ####################################################################
> [ req ]
> default_bits            =3D 1024
> default_keyfile         =3D privkey.pem
useless, this is commandline-driven
> distinguished_name      =3D req_distinguished_name
> attributes              =3D req_attributes
uneeded, especially as everything is commented in your exemple :)
> prompt =3D no
we're dealing with service certs, so you also need:
encrypt_key             =3D no

> # This sets a mask for permitted string types. There are several option=
s.
> # 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 UTF8Stri=
ngs
> # so use this option with caution!
> string_mask =3D nombstr
>=20
> # req_extensions =3D v3_req # The extensions to add to a certificate re=
quest
>=20
> [ 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
Does this syntax work ? I was thinking about generating the
configuration dynamically.

> emailAddress                    =3D [email protected]
> subjectAltName=3DDNS.0:myhost.mydomain.com,IP.0:xxx.xxx.xxx.169,IP.1:xx=
x.xxx.xxx.42,IP.2:xxx.xxx.xxx.98
I'd only use the ones than can get guessed from environment.

> [ req_attributes ]
> #challengePassword              =3D A challenge password
> #challengePassword_min          =3D 4
> #challengePassword_max          =3D 20
> #unstructuredName               =3D An optional company name
>=20
> [ v3_req ]
> # Extensions to add to a certificate request
> basicConstraints =3D CA:FALSE
> keyUsage =3D nonRepudiation, digitalSignature, keyEncipherment
Useless also in your example, as commented.

I'd rather propose the very minimal following one:
[ req ]
default_bits            =3D 1024
encrypt_key             =3D no
prompt                  =3D no
distinguished_name      =3D req_dn
req_extensions          =3D req_ext

[ req_dn ]
commonName 		=3D $ENV::HOSTNAME
organizationalUnitName	=3D default cert for $ENV::HOSTNAME
emailAddress		=3D root@$ENV::HOSTNAME

[ req_ext ]
basicConstraints        =3D CA:FALSE

Actually, I don't know exactly what the latest does, neither as keyUsage
in your example, nor the nstype=3Dserver sometimes found.


> Either we could assume the user will edit this file by default, or we s=
hould=20
> consider passing more as environment variables (such as with HOSTNAME a=
bove).
>=20
>> Sysadmin could just replace /etc/pki/tls/imap.cnf with its own one, an=
d
>> use it as he want thereafter, without troubles during following upgrad=
es.
>=20
> Sure.
>=20
>> This is achievable right now, and could already benefit from
>> standardising all our ssl-dependant packages.
>=20
> Indeed.
I just tested it with latest courier-imap upload. Comments welcome.