Bug #59376 Specific RDN order required if GRANT ... REQUIRE SUBJECT used
Submitted: 9 Jan 2011 9:36 Modified: 4 Apr 2013 15:02
Reporter: Dave Kelly Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Security: Privileges Severity:S3 (Non-critical)
Version:5.5.8 GA, 5.5.30 OS:Any
Assigned to: Paul DuBois CPU Architecture:Any
Tags: certificate, certificate subject, grant require subject, SSL, subject, X509

[9 Jan 2011 9:36] Dave Kelly
Description:
After issuing the following query command:

grant all privileges on *.* to 'myusername'@'%' identified by 'mypass'
  require subject '/CN=myusername/emailAddress=myemail@mydom.dom'
  with grant option;

Then, trying to connect with mysql, I received the following error:

ERROR 1045 (28000): Access denied for \
  user 'myusername'@'myhost.mydom.dom' (using password: YES)

The server error log had the following entry:

[Note] X509 subject mismatch: \
  should be '/CN=myusername/emailAddress=myemail@mydom.dom' \
  but is '/emailAddress=myemail@mydom.dom/CN=myusername'

This behavior appears to be incorrect (i.e., requiring specific ordering of the RDN components of the certicate subject value).  As the certificate 'subject' value is an X.500 Distinguished Name, per the matching rules defined in the X.50x series specifications, the ordering of the RDN (Relative Distinguished Name) components of the certificate subject should not be significant for purposes of certificate subject value matching.  See the following excerpts from the specs.

From ITU-T Rec. X.509 (08/2005), Annex A, A.1 Authentication framework [ASN.1] module
(http://www.itu.int/rec/T-REC-X.509/en):

-- public-key certificate definition 
Certificate ::= SIGNED {
  SEQUENCE {
      -- ...
      subject  Name,
      -- ...
  }
}

From ITU-T Rec. X.501 (08/2005), Annex B, Information Framework in ASN.1
(http://www.itu.int/rec/T-REC-X.501/en):

-- naming data types 
Name ::= CHOICE {
  rdnSequence  RDNSequence
}

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

DistinguishedName ::= RDNSequence

RelativeDistinguishedName ::=
  SET SIZE (1..MAX) OF AttributeTypeAndDistinguishedValue

AttributeTypeAndDistinguishedValue ::= SEQUENCE {
  type                  ATTRIBUTE.&id({SupportedAttributes}),
  value                 ATTRIBUTE.&Type({SupportedAttributes}{@type}),
-- ... etc. ...
}

From ITU-T Rec. X.501 (08/2005), 13.5.2 Matching rule definition
(http://www.itu.int/rec/T-REC-X.501/en):

"The distinguishedNameMatch is defined as follows:

distinguishedNameMatch MATCHING-RULE ::= {
  SYNTAX DistinguishedName
  ID id-mr-distinguishedNameMatch
}

A presented distinguished name value matches a target distinguished name value if and only if all of the following are
true:
a) the number of RDNs in each is the same;
b) corresponding RDNs have the same number of AttributeTypeAndValue;
c) corresponding AttributeTypeAndValue (i.e., those in corresponding RDNs and with identical attribute
types) have attribute values which match as described in 9.4.

distinguishedNameMatch is an equality matching rule."

Unless I'm missing something somewhere (which is entirely possible, but I don't think so) the certificate subject RDN's should not have to be entered in any specific order.

How to repeat:
Issue the following query command with appropriate values substituted for your username, password and certificate subject:

grant all privileges on *.* to 'myusername'@'%' identified by 'mypass'
  require subject '/CN=myusername/emailAddress=myemail@mydom.dom'
  with grant option;

Then, try to connect with mysql.  If you happen to get lucky and enter the certificate subject RDN's in the order that the server requires, then try issuing the 'grant' command again with the RDN'S in a different order and try connecting again.

Suggested fix:
Update the code to adhere to the distinguishedNameMatch matching rules per the specs.
[20 Dec 2012 20:22] Sveta Smirnova
Thank you for the report.

Verified as described. It also treats addresses such as sveta@mysql.com and SVETA@MYSQL.COM as different.
[4 Apr 2013 15:02] Paul DuBois
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.

Added to REQUIRE SUBJECT description:

MySQL does a simple string comparison of this value to the value in the 
certificate, so lettercase and component ordering must be given exactly as 
present in the certificate.