[opensuse-factory] unify ca-certificates installations
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Freek de Kruijf -
Ludwig Nussel -
Marcus Meissner -
Ruediger Meier