unify ca-certificates installations

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

unify ca-certificates installations

Rüdiger Meier
Hi,

today I wanted to install globally a custom ca-certificate (actually
just the ca-certificates-cacert rpm package). I found that it's a bit
annoying that this is not easily possible since different programs are
using different paths to look for ca certificates and we have a lot
duplicated certs installed

For example we have some packages giving us some certificates
 ca-certificates-mozilla: /usr/share/ca-certificates/mozilla/
 kdelibs3: /opt/kde3/share/apps/kssl/ca-bundle.crt
 kdelibs4: /usr/share/kde4/apps/kssl/ca-bundle.crt
(They all have more less the same content.)

Then we have autogenerated bundle file and directory
 /etc/ssl/ca-bundle.pem
 /etc/ssl/certs/
which are generated from everything below /usr/share/ca-certificates/
and possibly some other paths.

Many programs (like curl or wget) are using /etc/ssl/ to search for
certificates. But to get firefox, kde4 and kde3 in sync I need to
 ln -sf /etc/ssl/ca-bundle.pem /opt/kde3/share/apps/kssl/ca-bundle.crt
 ln -sf /etc/ssl/ca-bundle.pem /usr/share/kde4/apps/kssl/ca-bundle.crt
and somehow to teach firefox to use /etc/ssl/certs/ instead
of /usr/share/ca-certificates/mozilla/.

My question is, couldn't we do that per default? So that installing
custom ca-certificates globally would affect hopefully all possible
programs.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Ludwig Nussel
Ruediger Meier wrote:

> today I wanted to install globally a custom ca-certificate (actually
> just the ca-certificates-cacert rpm package). I found that it's a bit
> annoying that this is not easily possible since different programs are
> using different paths to look for ca certificates and we have a lot
> duplicated certs installed
>
> For example we have some packages giving us some certificates
>   ca-certificates-mozilla: /usr/share/ca-certificates/mozilla/
>   kdelibs3: /opt/kde3/share/apps/kssl/ca-bundle.crt
>   kdelibs4: /usr/share/kde4/apps/kssl/ca-bundle.crt
> (They all have more less the same content.)

Those KDE bundles shouldn't exist. They are from 2009 so horribly out of
date. If you find such cases feel free to file bug reports.

> My question is, couldn't we do that per default? So that installing
> custom ca-certificates globally would affect hopefully all possible
> programs.

I'm currently working on that for 13.1¹. Applications are expected to
call SSL_CTX_set_default_verify_paths() resp
gnutls_x509_trust_list_add_system_trust() to make them use the system
certificate store. No package should hardcode /etc/ssl/certs or any
bundle file anymore. NSS applications like Firefox need no change. Just
install p11-kit-nss-trust instead of mozilla-nss-certs.

cu
Ludwig

[1] https://features.opensuse.org/314991

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Rüdiger Meier
On Friday 26 July 2013, Ludwig Nussel wrote:

> Ruediger Meier wrote:
> > today I wanted to install globally a custom ca-certificate
> > (actually just the ca-certificates-cacert rpm package). I found
> > that it's a bit annoying that this is not easily possible since
> > different programs are using different paths to look for ca
> > certificates and we have a lot duplicated certs installed
> >
> > For example we have some packages giving us some certificates
> >   ca-certificates-mozilla: /usr/share/ca-certificates/mozilla/
> >   kdelibs3: /opt/kde3/share/apps/kssl/ca-bundle.crt
> >   kdelibs4: /usr/share/kde4/apps/kssl/ca-bundle.crt
> > (They all have more less the same content.)
>
> Those KDE bundles shouldn't exist. They are from 2009 so horribly out
> of date. If you find such cases feel free to file bug reports.

Ok, I will will do it.

> > My question is, couldn't we do that per default? So that installing
> > custom ca-certificates globally would affect hopefully all possible
> > programs.
>
> I'm currently working on that for 13.1¹. Applications are expected to
> call SSL_CTX_set_default_verify_paths() resp
> gnutls_x509_trust_list_add_system_trust() to make them use the system
> certificate store. No package should hardcode /etc/ssl/certs or any
> bundle file anymore. NSS applications like Firefox need no change.
> Just install p11-kit-nss-trust instead of mozilla-nss-certs.

Thx, good to know. I will try to build p11-kit-nss-trust also for my old
suse version.
But how could I change the search path Firefox if p11-kit-nss-trust is
not available. I can't find where the current
used /usr/share/ca-certificates/mozilla/ comes from.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Freek de Kruijf-2
In reply to this post by Ludwig Nussel
Op vrijdag 26 juli 2013 09:09:02 schreef Ludwig Nussel:
> I'm currently working on that for 13.1¹. Applications are expected to
> call SSL_CTX_set_default_verify_paths() resp
> gnutls_x509_trust_list_add_system_trust() to make them use the system
> certificate store. No package should hardcode /etc/ssl/certs or any
> bundle file anymore. NSS applications like Firefox need no change. Just
> install p11-kit-nss-trust instead of mozilla-nss-certs.
>

Postfix used to have in main.cf two parameters with CApath in it to point to
these certs. Now these parameters do not have a value. Should these parameters
be replaced by new parameters to indicate the use of the above routine in
Postfix?

--
fr.gr.

Freek de Kruijf

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations (postfix)

Rüdiger Meier
On Saturday 27 July 2013, Freek de Kruijf wrote:

> Op vrijdag 26 juli 2013 09:09:02 schreef Ludwig Nussel:
> > I'm currently working on that for 13.1¹. Applications are expected
> > to call SSL_CTX_set_default_verify_paths() resp
> > gnutls_x509_trust_list_add_system_trust() to make them use the
> > system certificate store. No package should hardcode /etc/ssl/certs
> > or any bundle file anymore. NSS applications like Firefox need no
> > change. Just install p11-kit-nss-trust instead of
> > mozilla-nss-certs.
>
> Postfix used to have in main.cf two parameters with CApath in it to
> point to these certs. Now these parameters do not have a value.
> Should these parameters be replaced by new parameters to indicate the
> use of the above routine in Postfix?

I've also thought about it already. Actually there are 3 *CApath vars:
lmtp_tls_CApath
smtp_tls_CApath
smtpd_tls_CApath

Setting them per default might be a good idead but I see a few possible
problems, specially for the update case.
Could it break advanced existing setups? How it conflicts with existing
*_CAfile settings?

For example in past I had set custom *_CAFile vars which only contained
my own CA certificate. I only wanted to trust my own postfix servers
and I wouldn't have liked it if upgrading suse adds all common CAs without
asking me.

BTW TLS is disabled in postfix by default anyway. So it's not worth to
risk these update problems.


On the other hand I would support to enable TLS by default. If we would
do this, then we have to set *_CApath of course.

My preferred default config would be like this:

diff --git a/postfix/main.cf b/postfix/main.cf
index a11775e..2a25522 100644
--- a/postfix/main.cf
+++ b/postfix/main.cf
@@ -726,9 +726,13 @@ strict_rfc821_envelopes = no
 smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination
 smtp_sasl_auth_enable = no
 smtpd_sasl_auth_enable = no
-smtpd_use_tls = no
-smtp_use_tls = no
-smtp_enforce_tls = no
+smtp_tls_note_starttls_offer = yes
+smtp_tls_security_level = may
+smtp_tls_CApath = /etc/ssl/certs
+smtp_tls_loglevel = 1
+smtp_tls_security_level = none
+smtpd_tls_CApath = /etc/ssl/certs
+smtpd_tls_loglevel = 1
 alias_maps = hash:/etc/aliases
 mailbox_size_limit = 0
 message_size_limit = 0
diff --git a/postfix/master.cf b/postfix/master.cf
index 2eadaf5..2939b04 100644
--- a/postfix/master.cf
+++ b/postfix/master.cf
@@ -25,7 +25,7 @@ pickup    fifo  n       -       n       60      1       pickup
 cleanup   unix  n       -       n       -       0       cleanup
 qmgr      fifo  n       -       n       300     1       qmgr
 #qmgr     fifo  n       -       n       300     1       oqmgr
-#tlsmgr    unix  -       -       n       1000?   1       tlsmgr
+tlsmgr    unix  -       -       n       1000?   1       tlsmgr
 rewrite   unix  -       -       n       -       -       trivial-rewrite
 bounce    unix  -       -       n       -       0       bounce
 defer     unix  -       -       n       -       0       bounce


Notes
1. The 3 removed vars are deprecated and should be replaced
by *_tls_security_level in any case.
2. If we could generate default keys somehow then we could also
enable TLS for incomming smtp:
+smtpd_tls_security_level = may
+smtpd_tls_key_file = /etc/postfix/ssl/smtpd.key
+smtpd_tls_cert_file = /etc/postfix/ssl/smtpd.crt
3. lmtp could be handled similar allthough AFAIK it's usually only used
in LAN because of performance reasons so maybe TLS is usually not wanted.
4. Instead of changing the default main.cf we should consider to change
the default compile time settings. Could be more easy handle the update
case this way.


cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations (postfix)

Rüdiger Meier
On Saturday 27 July 2013, Ruediger Meier wrote:

> On Saturday 27 July 2013, Freek de Kruijf wrote:
> > Op vrijdag 26 juli 2013 09:09:02 schreef Ludwig Nussel:
> > > I'm currently working on that for 13.1¹. Applications are
> > > expected to call SSL_CTX_set_default_verify_paths() resp
> > > gnutls_x509_trust_list_add_system_trust() to make them use the
> > > system certificate store. No package should hardcode
> > > /etc/ssl/certs or any bundle file anymore. NSS applications like
> > > Firefox need no change. Just install p11-kit-nss-trust instead of
> > > mozilla-nss-certs.
> >
> > Postfix used to have in main.cf two parameters with CApath in it to
> > point to these certs. Now these parameters do not have a value.
> > Should these parameters be replaced by new parameters to indicate
> > the use of the above routine in Postfix?
>
> I've also thought about it already. Actually there are 3 *CApath
> vars:
> lmtp_tls_CApath
> smtp_tls_CApath
> smtpd_tls_CApath

Just noticed that maybe this might be enough:
  tls_append_default_CA = yes

man 5 postconf

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations (postfix)

Freek de Kruijf-2
Op zaterdag 27 juli 2013 02:40:58 schreef Ruediger Meier:

> > I've also thought about it already. Actually there are 3 *CApath
> > vars:
> > lmtp_tls_CApath
> > smtp_tls_CApath
> > smtpd_tls_CApath
>
> Just noticed that maybe this might be enough:
>   tls_append_default_CA = yes
>
> man 5 postconf

As per http://tech.groups.yahoo.com/group/postfix-users/message/283845 it is
necessary to specify at least xxx_CApath or xxx_CAfile for
"tls_append_default_CA = yes" to be effective. So at least some more or less
dummy xxx_CAfile is needed.

--
fr.gr.

Freek de Kruijf

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations (postfix)

Rüdiger Meier
On Saturday 27 July 2013, Freek de Kruijf wrote:

> Op zaterdag 27 juli 2013 02:40:58 schreef Ruediger Meier:
> > > I've also thought about it already. Actually there are 3 *CApath
> > > vars:
> > > lmtp_tls_CApath
> > > smtp_tls_CApath
> > > smtpd_tls_CApath
> >
> > Just noticed that maybe this might be enough:
> >   tls_append_default_CA = yes
> >
> > man 5 postconf
>
> As per
> http://tech.groups.yahoo.com/group/postfix-users/message/283845 it is
> necessary to specify at least xxx_CApath or xxx_CAfile for
> "tls_append_default_CA = yes" to be effective. So at least some more
> or less dummy xxx_CAfile is needed.

Hehe, I've read the same thread yesterday after posting. It's a pity
that he don't want to let us use SSL_CTX_set_default_verify_paths()
without specifying fixed CApaths already.

But I've tested that it works if you specify "non-existing paths" like
this:
  tls_append_default_CA = yes
  smtp_tls_CApath = default-only
  smtpd_tls_CApath = default-only

.. and postfix doesn't even warns about non existing
path "default-only".

However we could try to convince him to introduce a new config value
like
  tls_append_default_CA = always
to achieve the same more nice and without changing current behavior.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations (postfix)

Marcus Meissner
On Sat, Jul 27, 2013 at 11:13:38AM +0200, Ruediger Meier wrote:

> On Saturday 27 July 2013, Freek de Kruijf wrote:
> > Op zaterdag 27 juli 2013 02:40:58 schreef Ruediger Meier:
> > > > I've also thought about it already. Actually there are 3 *CApath
> > > > vars:
> > > > lmtp_tls_CApath
> > > > smtp_tls_CApath
> > > > smtpd_tls_CApath
> > >
> > > Just noticed that maybe this might be enough:
> > >   tls_append_default_CA = yes
> > >
> > > man 5 postconf
> >
> > As per
> > http://tech.groups.yahoo.com/group/postfix-users/message/283845 it is
> > necessary to specify at least xxx_CApath or xxx_CAfile for
> > "tls_append_default_CA = yes" to be effective. So at least some more
> > or less dummy xxx_CAfile is needed.
>
> Hehe, I've read the same thread yesterday after posting. It's a pity
> that he don't want to let us use SSL_CTX_set_default_verify_paths()
> without specifying fixed CApaths already.
>
> But I've tested that it works if you specify "non-existing paths" like
> this:
>   tls_append_default_CA = yes
>   smtp_tls_CApath = default-only
>   smtpd_tls_CApath = default-only
>
> .. and postfix doesn't even warns about non existing
> path "default-only".
>
> However we could try to convince him to introduce a new config value
> like
>   tls_append_default_CA = always
> to achieve the same more nice and without changing current behavior.

We can of course patch postfix...

Ciao, Marcus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Ludwig Nussel
In reply to this post by Rüdiger Meier
Ruediger Meier wrote:
> But how could I change the search path Firefox if p11-kit-nss-trust is
> not available. I can't find where the current
> used /usr/share/ca-certificates/mozilla/ comes from.

Those certificates are extracted from mozilla-nss actually. It's only a
subset of what mozilla-nss embeds though. So for up to 12.3 it's better
to stay with the built-in certificates. Only the p11-kit way is a
drop-in replacement for mozilla-nss-certs as p11-kit can handle the
blacklists while update-ca-certificates can not.

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Ludwig Nussel
In reply to this post by Freek de Kruijf-2
Freek de Kruijf wrote:

> Op vrijdag 26 juli 2013 09:09:02 schreef Ludwig Nussel:
>> I'm currently working on that for 13.1¹. Applications are expected to
>> call SSL_CTX_set_default_verify_paths() resp
>> gnutls_x509_trust_list_add_system_trust() to make them use the system
>> certificate store. No package should hardcode /etc/ssl/certs or any
>> bundle file anymore. NSS applications like Firefox need no change. Just
>> install p11-kit-nss-trust instead of mozilla-nss-certs.
>
> Postfix used to have in main.cf two parameters with CApath in it to point to
> these certs. Now these parameters do not have a value. Should these parameters
> be replaced by new parameters to indicate the use of the above routine in
> Postfix?

I'm not into Postfix so no idea how to configure it. I suppose
Postfix has a dual role though. When sending mail it acts as client
and when receiving mail it acts as server. In the client role it
makes sense to have it call SSL_CTX_set_default_verify_paths() so it
can authenticate smpts servers in the internet.
As server however the CA path usually has a different meaning. It's
likely used to restrict what CAs are allowed to authenticate client
certificates iow who is allowed to send mail via your server. In that
case you may want to only allow e.g. one single custom CA. So unless the
server allows you to specify the DNs of permitted CAs you better not use
SSL_CTX_set_default_verify_paths() resp /etc/ssl/certs ie provide no
default for a CA path in the package.

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Rüdiger Meier
On Monday 29 July 2013, Ludwig Nussel wrote:

> Freek de Kruijf wrote:
> > Op vrijdag 26 juli 2013 09:09:02 schreef Ludwig Nussel:
> >> I'm currently working on that for 13.1¹. Applications are expected
> >> to call SSL_CTX_set_default_verify_paths() resp
> >> gnutls_x509_trust_list_add_system_trust() to make them use the
> >> system certificate store. No package should hardcode
> >> /etc/ssl/certs or any bundle file anymore. NSS applications like
> >> Firefox need no change. Just install p11-kit-nss-trust instead of
> >> mozilla-nss-certs.
> >
> > Postfix used to have in main.cf two parameters with CApath in it to
> > point to these certs. Now these parameters do not have a value.
> > Should these parameters be replaced by new parameters to indicate
> > the use of the above routine in Postfix?
>
> I'm not into Postfix so no idea how to configure it. I suppose
> Postfix has a dual role though. When sending mail it acts as client
> and when receiving mail it acts as server. In the client role it
> makes sense to have it call SSL_CTX_set_default_verify_paths() so it
> can authenticate smpts servers in the internet.
> As server however the CA path usually has a different meaning. It's
> likely used to restrict what CAs are allowed to authenticate client
> certificates iow who is allowed to send mail via your server. In that
> case you may want to only allow e.g. one single custom CA. So unless
> the server allows you to specify the DNs of permitted CAs you better
> not use SSL_CTX_set_default_verify_paths() resp /etc/ssl/certs ie
> provide no default for a CA path in the package.

Good point, there are use cases where you want to use default CAs even
for the server but probably we shouldn't set this per default.
Allthough it wouldn't be a real problem
because "permit_tls_all_clientcerts" is nowhere used by default.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Rüdiger Meier
In reply to this post by Ludwig Nussel
On Friday 26 July 2013, Ludwig Nussel wrote:

> Ruediger Meier wrote:
> > today I wanted to install globally a custom ca-certificate
> > (actually just the ca-certificates-cacert rpm package). I found
> > that it's a bit annoying that this is not easily possible since
> > different programs are using different paths to look for ca
> > certificates and we have a lot duplicated certs installed
> >
> > For example we have some packages giving us some certificates
> >   ca-certificates-mozilla: /usr/share/ca-certificates/mozilla/
> >   kdelibs3: /opt/kde3/share/apps/kssl/ca-bundle.crt
> >   kdelibs4: /usr/share/kde4/apps/kssl/ca-bundle.crt
> > (They all have more less the same content.)
>
> Those KDE bundles shouldn't exist. They are from 2009 so horribly out
> of date. If you find such cases feel free to file bug reports.
>
> > My question is, couldn't we do that per default? So that installing
> > custom ca-certificates globally would affect hopefully all possible
> > programs.
>
> I'm currently working on that for 13.1¹. Applications are expected to
> call SSL_CTX_set_default_verify_paths() resp
> gnutls_x509_trust_list_add_system_trust() to make them use the system
> certificate store. No package should hardcode /etc/ssl/certs or any
> bundle file anymore. NSS applications like Firefox need no change.
> Just install p11-kit-nss-trust instead of mozilla-nss-certs.

Ok, now I've tried out the new p11-kit* and ca-certificates* packages.
It works pretty well but I have a few issues:

1. It's not nice that /etc/ssl/openssl.cnf is disabled right now. I
understand that you want to reduce the Factory packages which are using
it. But it's unusable for users who need it. Actually this is
completely against the idea to unify the certs stuff and to make it
easier to use.

2. Shouldn't /usr/share/ca-certificates still be parsed for
compatibility. What if users have installed custom certs there?

3. Is it correct that ca-certificates-cacerts are installed in
  /usr/share/pki/trust/anchors/
but ca-certificates-mozilla above in
  /usr/share/pki/trust/
 

BTW if somebody is interested, I've build these packages for old suse
versions >= 11.4 in
home:rudi_m
  ca-certificates
  ca-certificates-cacert
  ca-certificates-mozilla
  p11-kit

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Ludwig Nussel
Ruediger Meier wrote:

> On Friday 26 July 2013, Ludwig Nussel wrote:
>> Ruediger Meier wrote:
>>> today I wanted to install globally a custom ca-certificate
>>> (actually just the ca-certificates-cacert rpm package). I found
>>> that it's a bit annoying that this is not easily possible since
>>> different programs are using different paths to look for ca
>>> certificates and we have a lot duplicated certs installed
>>>
>>> For example we have some packages giving us some certificates
>>>    ca-certificates-mozilla: /usr/share/ca-certificates/mozilla/
>>>    kdelibs3: /opt/kde3/share/apps/kssl/ca-bundle.crt
>>>    kdelibs4: /usr/share/kde4/apps/kssl/ca-bundle.crt
>>> (They all have more less the same content.)
>>
>> Those KDE bundles shouldn't exist. They are from 2009 so horribly out
>> of date. If you find such cases feel free to file bug reports.
>>
>>> My question is, couldn't we do that per default? So that installing
>>> custom ca-certificates globally would affect hopefully all possible
>>> programs.
>>
>> I'm currently working on that for 13.1¹. Applications are expected to
>> call SSL_CTX_set_default_verify_paths() resp
>> gnutls_x509_trust_list_add_system_trust() to make them use the system
>> certificate store. No package should hardcode /etc/ssl/certs or any
>> bundle file anymore. NSS applications like Firefox need no change.
>> Just install p11-kit-nss-trust instead of mozilla-nss-certs.
>
> Ok, now I've tried out the new p11-kit* and ca-certificates* packages.
> It works pretty well but I have a few issues:

Thanks for testing, much appreciated!

> 1. It's not nice that /etc/ssl/openssl.cnf is disabled right now. I
> understand that you want to reduce the Factory packages which are using
> it. But it's unusable for users who need it. Actually this is
> completely against the idea to unify the certs stuff and to make it
> easier to use.

I guess you meant /etc/ssl/ca-bundle.pem? I removed it after I found
several packages in Factory that use it despite the clear instructions
not to do that inside the file.

> 2. Shouldn't /usr/share/ca-certificates still be parsed for
> compatibility. What if users have installed custom certs there?

Since packaging extra certs was of limited use before I ignored that
case so far. I'm actually more worried about /etc/ssl/certs. Ideally it
should be replaced by a read only bind mount to
/var/lib/ca-certificates/pem but I fear that admins put certs there
(that are now completely ignored).

> 3. Is it correct that ca-certificates-cacerts are installed in
>    /usr/share/pki/trust/anchors/
> but ca-certificates-mozilla above in
>    /usr/share/pki/trust/

Yes. Certificates in the "anchors" subdirectory are automatically
trusted whereas one level above the certificates need to have trust
flags attached to them to be considered (dis)trusted. The Mozilla certs all
have (dis)trust bits set.

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Rüdiger Meier
On Thursday 01 August 2013, Ludwig Nussel wrote:
> Ruediger Meier wrote:

> > Ok, now I've tried out the new p11-kit* and ca-certificates*
> > packages. It works pretty well but I have a few issues:
>
> Thanks for testing, much appreciated!

If you want you could pull the three ca-certificates* packages from
home:rudi_m into your branch. I've made some more less important build
fixes and cleanups.

> > 1. It's not nice that /etc/ssl/openssl.cnf is disabled right now. I
> > understand that you want to reduce the Factory packages which are
> > using it. But it's unusable for users who need it. Actually this is
> > completely against the idea to unify the certs stuff and to make it
> > easier to use.
>
> I guess you meant /etc/ssl/ca-bundle.pem? I removed it after I found
> several packages in Factory that use it despite the clear
> instructions not to do that inside the file.

Yes ca-bundle.pem, of course.

> > 2. Shouldn't /usr/share/ca-certificates still be parsed for
> > compatibility. What if users have installed custom certs there?
>
> Since packaging extra certs was of limited use before I ignored that
> case so far.

My case was that I simply wanted to use p11-kit-nss-trust on suse 11.4.
and I had to build/update all cert packages just because of
incompatible paths.

> I'm actually more worried about /etc/ssl/certs. Ideally
> it should be replaced by a read only bind mount to
> /var/lib/ca-certificates/pem but I fear that admins put certs there
> (that are now completely ignored).

Please not another bind mount. If I as an admin want to try something
out quick and dirty I really hate such artificial restrictions to
protect me against my own stupidity.
Couldn't we avoid that update-ca-certificates wipes out /etc/ssl/certs
completely. Would it work to use a subdir and to not touch admin's
files?
Adding /etc/ssl/REAME at least!?

> > 3. Is it correct that ca-certificates-cacerts are installed in
> >    /usr/share/pki/trust/anchors/
> > but ca-certificates-mozilla above in
> >    /usr/share/pki/trust/
>
> Yes. Certificates in the "anchors" subdirectory are automatically
> trusted whereas one level above the certificates need to have trust
> flags attached to them to be considered (dis)trusted. The Mozilla
> certs all have (dis)trust bits set.

Ah, ok.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Ludwig Nussel
Ruediger Meier wrote:
> On Thursday 01 August 2013, Ludwig Nussel wrote:
>> I'm actually more worried about /etc/ssl/certs. Ideally
>> it should be replaced by a read only bind mount to
>> /var/lib/ca-certificates/pem but I fear that admins put certs there
>> (that are now completely ignored).
>
> Please not another bind mount. If I as an admin want to try something
> out quick and dirty I really hate such artificial restrictions to
> protect me against my own stupidity.

quick and dirty would still work if you put the files into
/var/lib/ca-certificates/pem instead of /etc/ssl/certs.

> Couldn't we avoid that update-ca-certificates wipes out /etc/ssl/certs
> completely. Would it work to use a subdir and to not touch admin's
> files?

I think /etc/ssl/certs has to be kept filled with certificates for
compatibility for a while. So we have to fill it somehow. Right now that
happens by putting hundreds of symlinks to individual certs into
/etc/ssl/certs. IMO it would be better to not mess with /etc all the
time, so making either /etc/ssl/certs itself a symlink or making it a
bind mount would be options. Replacing directories with symlinks is
not exactly something rpm likes though ...

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Rüdiger Meier
On Friday 02 August 2013, Ludwig Nussel wrote:

> Ruediger Meier wrote:
> > On Thursday 01 August 2013, Ludwig Nussel wrote:
> >> I'm actually more worried about /etc/ssl/certs. Ideally
> >> it should be replaced by a read only bind mount to
> >> /var/lib/ca-certificates/pem but I fear that admins put certs
> >> there (that are now completely ignored).
> >
> > Please not another bind mount. If I as an admin want to try
> > something out quick and dirty I really hate such artificial
> > restrictions to protect me against my own stupidity.
>
> quick and dirty would still work if you put the files into
> /var/lib/ca-certificates/pem instead of /etc/ssl/certs.

That's not so quick and IMO not even dirty.
Knowing about /var/lib/ca-certificates/pem and calling
update-ca-certificates implies that I know already about the suse 13.1
way how and where to install certs. On earlier suse and other distros
it would be another way.
On current suse distros I would have used /usr/share/ca-certificates/.
So I guess we should still use this path for compatibility.

> > Couldn't we avoid that update-ca-certificates wipes out
> > /etc/ssl/certs completely. Would it work to use a subdir and to not
> > touch admin's files?
>
> I think /etc/ssl/certs has to be kept filled with certificates for
> compatibility for a while. So we have to fill it somehow. Right now
> that happens by putting hundreds of symlinks to individual certs into
> /etc/ssl/certs. IMO it would be better to not mess with /etc all the
> time, so making either /etc/ssl/certs itself a symlink or making it a
> bind mount would be options. Replacing directories with symlinks is
> not exactly something rpm likes though ...

Just checked again, On opensuse 11.4 (and probably still on 12.3) custom
files in /etc/ssl/certs/ were not removed by update-ca-certificates.
IMO we should keep that behavior if possible.
update-ca-certificates only creates symlinks to it's well known paths,
Why not only removing exactly such symlinks.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Ludwig Nussel
Ruediger Meier wrote:

> On Friday 02 August 2013, Ludwig Nussel wrote:
>> Ruediger Meier wrote:
>>> On Thursday 01 August 2013, Ludwig Nussel wrote:
>>> Couldn't we avoid that update-ca-certificates wipes out
>>> /etc/ssl/certs completely. Would it work to use a subdir and to not
>>> touch admin's files?
>>
>> I think /etc/ssl/certs has to be kept filled with certificates for
>> compatibility for a while. So we have to fill it somehow. Right now
>> that happens by putting hundreds of symlinks to individual certs into
>> /etc/ssl/certs. IMO it would be better to not mess with /etc all the
>> time, so making either /etc/ssl/certs itself a symlink or making it a
>> bind mount would be options. Replacing directories with symlinks is
>> not exactly something rpm likes though ...
>
> Just checked again, On opensuse 11.4 (and probably still on 12.3) custom
> files in /etc/ssl/certs/ were not removed by update-ca-certificates.
> IMO we should keep that behavior if possible.
> update-ca-certificates only creates symlinks to it's well known paths,
> Why not only removing exactly such symlinks.

It does exactly that atm. What I am saying is that a) creating and
removing hundreds of symlinks in /etc sucks and b) custom certificates in
/etc/ssl/certs no longer work as neither openssl nor gnutls use
/etc/ssl/certs anymore.

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Rüdiger Meier
On Friday 02 August 2013, Ludwig Nussel wrote:
> Ruediger Meier wrote:
> > Just checked again, On opensuse 11.4 (and probably still on 12.3)
> > custom files in /etc/ssl/certs/ were not removed by
> > update-ca-certificates. IMO we should keep that behavior if
> > possible.
> > update-ca-certificates only creates symlinks to it's well known
> > paths, Why not only removing exactly such symlinks.
>
> It does exactly that atm.
 
No it seems to remove ALL symlinks:

$ ln -s /usr/share/ca-certificates/my/bla.pem  /etc/ssl/certs/bla.pem
$ ll /etc/ssl/certs/bla.pem
  /etc/ssl/certs/bla.pem -> /usr/share/ca-certificates/my/bla.pem
$ update-ca-certificates
$ ll ssl/certs/bla.pem
ls: cannot access ssl/certs/bla.pem: No such file or directory

(It also removes symlinks to other paths)

> What I am saying is that a) creating and
> removing hundreds of symlinks in /etc sucks and b) custom
> certificates in /etc/ssl/certs no longer work as neither openssl nor
> gnutls use /etc/ssl/certs anymore.

Ah ok, I have not updated openssl yet.
Why we don't want to use /etc/ssl/ anymore although we always keep it
up-to-date?
If we really want to break all openssl users on all systems with custom
certs in /etc/ssl then I don't understand why we still want to keep and
update /etc/ssl/certs at all.

cu,
Rudi
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: unify ca-certificates installations

Ludwig Nussel
Ruediger Meier wrote:

> On Friday 02 August 2013, Ludwig Nussel wrote:
>> Ruediger Meier wrote:
>>> Just checked again, On opensuse 11.4 (and probably still on 12.3)
>>> custom files in /etc/ssl/certs/ were not removed by
>>> update-ca-certificates. IMO we should keep that behavior if
>>> possible.
>>> update-ca-certificates only creates symlinks to it's well known
>>> paths, Why not only removing exactly such symlinks.
>>
>> It does exactly that atm.
>
> No it seems to remove ALL symlinks:
>
> $ ln -s /usr/share/ca-certificates/my/bla.pem  /etc/ssl/certs/bla.pem
> $ ll /etc/ssl/certs/bla.pem
>    /etc/ssl/certs/bla.pem -> /usr/share/ca-certificates/my/bla.pem
> $ update-ca-certificates
> $ ll ssl/certs/bla.pem
> ls: cannot access ssl/certs/bla.pem: No such file or directory
>
> (It also removes symlinks to other paths)

Yes, it outputs a warning telling you the correct location for wrong
symlinks though. The above case is a symlink to a well known
location previously managed by update-ca-certificates so it's
removed without warning. I'll remove the unlink in the other case,
otherwise the warning would be hidden in the update logs I guess.

>> What I am saying is that a) creating and
>> removing hundreds of symlinks in /etc sucks and b) custom
>> certificates in /etc/ssl/certs no longer work as neither openssl nor
>> gnutls use /etc/ssl/certs anymore.
>
> Ah ok, I have not updated openssl yet.
> Why we don't want to use /etc/ssl/ anymore although we always keep it
> up-to-date?
> If we really want to break all openssl users on all systems with custom
> certs in /etc/ssl then I don't understand why we still want to keep and
> update /etc/ssl/certs at all.

For compatibility with programs that still hardcode /etc/ssl/certs
instead of calling SSL_CTX_set_default_verify_paths(). Openssl
itself doesn't use that path anymore to be able to use "trusted
certs". Ie ones that are also valid for email or code signing.
/etc/ssl/certs may only hold certs valid for server auth to stay
compatible.

cu
Ludwig

--
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]