http://bugzilla.novell.com/show_bug.cgi?id=508844 Summary: YaST-generated X.509 certificate for SMTP server only valid for Key Encipherment Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: dkg@fifthhorseman.net QAContact: jsrain@novell.com Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030814 Iceweasel/3.0.9 (Debian-3.0.9-1) A recent report by Roland Winkler on help-gnutls shows what appears to be a YaST-generated self-signed X.509 certificate for an SMTP server with certain X.509v3 options set, in particular, the key usage extension is only set to "key encipherment": http://lists.gnu.org/archive/html/help-gnutls/2009-05/msg00041.html but as the followup on that list states,
This certificate restricts its usage to key encipherment. For TLS this is restricted to only the RSA key exchange. By misconfiguration however the server allows you to connect with a ciphersuite that violates this usage and that's why gnutls-cli fails to connect.
What's more, the Key Usage extension appears to be set not critical, though the RFC suggests that conformant implementations SHOULD set this extension as critical: http://tools.ietf.org/html/rfc5280#section-4.2.1.3 If this is the default certificate generation for YaST, it seems that YaST should set the Key Usage extension to critical if it uses it, and do one of the following: * do not apply a Key Usage extension at all, or * generate a certificate with the expected Key Usage extension set (e.g. include keyAgreement as well as keyEncipherment if the service is expected to negotiate diffie-hellman keys), or * configure the service to avoid TLS negotiations using protocols excluded by the Key Usage extension. (e.g. turn off diffie-hellman key exchange) I'm not an SUSE user, and this is not my system so i don't know for sure that this was directly caused by YaST (the user could have mis-applied a certificate generated for other services, for example). But i'm interested in seeing free crypto tools do the right thing by default, and not require users to become experts in the arcana to get things working smoothly, and this seems like a likely scenario. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3. -- 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.