[Bug 550395] New: Establish trust chain for client certificate
http://bugzilla.novell.com/show_bug.cgi?id=550395 Summary: Establish trust chain for client certificate Classification: openSUSE Product: openSUSE 11.2 Version: RC 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: WebYaST AssignedTo: jdsn@novell.com ReportedBy: kkaempf@novell.com QAContact: qa@suse.de CC: mc@novell.com Found By: Development The current yast2-webclient ssl certificate is self-generated. It should be replaced by something more trustworthy, e.g. within the trust chain of the SLMS server. Jens Daniel, I assign this to you to check with the SLMS team and registration certificates. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=550395
User jdsn@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c1
--- Comment #1 from J. Daniel Schmidt
http://bugzilla.novell.com/show_bug.cgi?id=550395
J. Daniel Schmidt
http://bugzilla.novell.com/show_bug.cgi?id=550395
User jdsn@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c2
J. Daniel Schmidt
The current yast2-webclient ssl certificate is self-generated. It should be replaced by something more trustworthy ...
Please define "something more trustworthy". And btw.: we are not talking about "client certifcates" here - this is an authentication technology based on SSL certificates. We could create a general server certifcate or an entire CA and ship it, but this does not change the trustworthiness. To the contrary: if the certificate key file is published, everybody could decrypt the SSL traffic. So the current situation is the best I can imagine for now. If it comes to deployment every customer has to create his own certificate(s) for his system(s) anyway, as he can only trust a certificate he created and implemented himself and it has to match his domainname(s). We can not do this for him. We can only help by pointing him to the yast2-ca-management module. For his appliances he thus has to use a certificate whose CA is already part of the openssl-certs package and make sure it gets into the appliance _or_ he has to make sure that his own CA certificate file gets into the appliance. I discussed the latter with Michael Calmer and we agreed that SLMS should not import any CA certifcate automatically. As this is a step that touches the trust relationship between two systems, parties or even companies this has to be a deliberate action. So I recommend to close this bug as WORKSFORME or WONTFIX. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=550395
User kkaempf@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c3
Klaus Kämpf
(In reply to comment #0)
The current yast2-webclient ssl certificate is self-generated. It should be replaced by something more trustworthy ...
Please define "something more trustworthy".
As the appliance gets updates from an SLMS server, the slms<->appliance and the appliance<->browser communication could be based on the same CA. Thats the basic assumption.
And btw.: we are not talking about "client certifcates" here - this is an authentication technology based on SSL certificates.
We could create a general server certifcate or an entire CA and ship it, but this does not change the trustworthiness. To the contrary: if the certificate key file is published, everybody could decrypt the SSL traffic. So the current situation is the best I can imagine for now.
So its up to the vendor to create (and install) a certificate ?!
If it comes to deployment every customer has to create his own certificate(s)
customer ? I guess you mean 'vendor', the one creating the appliance.
for his system(s) anyway, as he can only trust a certificate he created and implemented himself and it has to match his domainname(s). We can not do this for him. We can only help by pointing him to the yast2-ca-management module.
For his appliances he thus has to use a certificate whose CA is already part of the openssl-certs package and make sure it gets into the appliance _or_ he has to make sure that his own CA certificate file gets into the appliance.
I discussed the latter with Michael Calmer and we agreed that SLMS should not import any CA certifcate automatically. As this is a step that touches the trust relationship between two systems, parties or even companies this has to be a deliberate action.
Agreed. Question is, whats the default certificate delivered with yast2-webclient ? The current one is self-generated ('webyast team') and serves the needs to run over https. Since its packaged inside a(n autobuild) signed package, it has an established chain of trust. Can we package a 'Novell Inc' or 'SUSE Linux Products GmbH' certificate instead ? Which advice can we give appliance vendors ? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=550395
User jdsn@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c4
J. Daniel Schmidt
So its up to the vendor to create (and install) a certificate ?!
Yes, exaclty.
If it comes to deployment every customer has to create his own certificate(s)
customer ? I guess you mean 'vendor', the one creating the appliance.
Sure, I meant 'vendor'. No customer (in terms of end-user) needs to bother with CA certificates.
Question is, whats the default certificate delivered with yast2-webclient ?
It might sound crazy - but what about "none"? This is the best way to force the vendor to create its own certificates. A server certificate needs to match the hostname or in special cases the IP address of the server. We do not know either of these. For our beta releases or demo images we could ship our self signed certificate - but these images should never be deployed to a production system.
The current one is self-generated ('webyast team') and serves the needs to run over https. Since its packaged inside a(n autobuild) signed package, it has an established chain of trust.
This only deals with encryption of the traffic but not with trust so far. Only we know (or believe the ones who know) how the certificates are created. And I doubt that our security team will allow to ship our CA certificate as a trusted CA.
Can we package a 'Novell Inc' or 'SUSE Linux Products GmbH' certificate instead ?
You mean, we should act as a CA and ship signed certificates and include our CA certificate into the appliance? I would not do this. This is a very big administrative effort. If we act as a CA handing out singed certificates they could be (mis)used for anything else and thus lowering our own trustworthiness. For any abuse of a service with such a certificate we will be contacted.
Which advice can we give appliance vendors ?
I would definitely advise them to create their own certificates and either let them be signed by their own CA or by a known CA whose certificate is alreday shipped with the openssl-certs package. Therefore I'd recommend that we ship no certificate at all with the Add-On product in order to force the vendor to create one. Feel free to comment to this bug but I will close this as WONTFIX now. For any other solution we should setup a meeting together with Michael Calmer (for SLMS and SSL) and the security team and discuss all issues. (Note: I fixed the summary.) -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=550395
User kkaempf@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c5
Klaus Kämpf
http://bugzilla.novell.com/show_bug.cgi?id=550395
Klaus Kämpf
http://bugzilla.novell.com/show_bug.cgi?id=550395
User jdsn@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c6
--- Comment #6 from J. Daniel Schmidt
1. ship with https enabled but with a self-created certificate
Then it needs to be (automatically) created during the first boot sequence (at a point where the hostname is known), as the certificate needs to contain the "full qualified domain name" of the machine it is used on. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=550395
User flucifredi@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c7
Federico Lucifredi
http://bugzilla.novell.com/show_bug.cgi?id=550395
User jdsn@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c8
J. Daniel Schmidt
1. ship with https enabled but with a self-created certificate would be best option as I understand it.
Then we should not stay with the status quo. AFAIK currently we create the certificate when building the add-on product. So every instance uses the same certificate. This serves no purpose at all - the traffic is encrypted, sure, but nobody will notice an attack as it is easily possible now, because the certificate is the same for all instances. We need to add the creation of the CA and the server certificate to the first boot sequence of a system where WebYaST got installed. (Maybe it is a good idea to add this to the rc-scripts yastw[sc]). It must run in the real system as we need to find out the fully qualified domain name of the machine (this is a customer decision and it might change via DHCP) and create a certificate for it. Michael, any further comments from your perspective? What do you think about the idea of adding the certificate creation (resp. the call to a check-certificate-script) to the rc-scripts? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=550395
User mc@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c9
Michael Calmer
http://bugzilla.novell.com/show_bug.cgi?id=550395
User kkaempf@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c10
--- Comment #10 from Klaus Kämpf
http://bugzilla.novell.com/show_bug.cgi?id=550395
User kkaempf@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=550395#c11
--- Comment #11 from Klaus Kämpf
http://bugzilla.novell.com/show_bug.cgi?id=550395
http://bugzilla.novell.com/show_bug.cgi?id=550395#c12
J. Daniel Schmidt
http://bugzilla.novell.com/show_bug.cgi?id=550395
http://bugzilla.novell.com/show_bug.cgi?id=550395#c13
J. Daniel Schmidt
participants (1)
-
bugzilla_noreply@novell.com