Bug 508844

Summary:	YaST-generated X.509 certificate for SMTP server only valid for Key Encipherment
Product:	[openSUSE] openSUSE 11.2	Reporter:	Daniel Gillmor <dkg>
Component:	YaST2	Assignee:	Michael Calmer <mc>
Status:	RESOLVED FIXED	QA Contact:	Jiri Srain <jsrain>
Severity:	Normal
Priority:	P3 - Medium
Version:	Factory
Target Milestone:	Milestone 4
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Daniel Gillmor 2009-06-01 20:33:58 UTC

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.

Comment 1 Daniel Gillmor 2009-06-05 06:28:49 UTC

The original reporter (Roland Winkler) writes the following:

> It's a bit difficult to reconstruct the details.
> 
> The certificate was created via YaST on an Open Enterprise Server
> (OES) SP2. The sysadmin told me that these certificates are mainly
> intended for https connections and secure communication of Novell's
> eDirectory service. They are not specifically designed for secure
> SMTP connections that triggered the "key usage violation" problem.

i think that for standard https connections (e.g. apache with mod_ssl), the concerns above are still relevant.  I don't know what kind of connections are made for eDirectory, so i don't know how relevant these concerns would be for using this kind of cert with eDirectory.

Comment 2 Martin Vidner 2009-07-03 06:04:24 UTC

Anything that looks like YaST can be screened by the YaST team.

Comment 4 Michael Calmer 2009-07-03 08:29:58 UTC

Thanks for the informations. 

With the critical flag I deal with great care, because this might cause applications to reject everything. But for the keyUsage extension it might make sense. Adding keyAgreement is no problem. I think I will try this out for 11.2.

Comment 5 Michael Calmer 2009-07-10 12:28:38 UTC

Submitted to Factory.