Bug #20411 "GRANT ... REQUIRE ISSUER nnn AND SUBJECT mmm" fails to require both

Description:
Using the GRANT statement, I wish to restrict access to a remote account
by requiring the use of SSL, as well as requiring the use of a particular
certificate, as well as being able to verify that certificate.

OpenSSL is 0.9.8b.

If I present a certificate who's CN is not the same as the CN in the
REQUIRE ISSUER nnn field, then MySQL logs the fact that the issuer
does not match, and refuses the connection.

If I present a certificate that does match the ISSUER but fails to match
the SUBJECT, MySQL allows the connection.

The documentation suggests that where ISSUER and SUBJECT are both
specified, that both must match for the connection to succeed.

Here's my GRANT statement:

mysql> GRANT ALL PRIVILEGES ON *.* TO 'ajs'@'hostname' IDENTIFIED BY PASSWORD '<deleted>' REQUIRE ISSUER '/C=CH/O=Aeschi/OU=Certificate Authority/CN=Aeschi CA' AND SUBJECT '/C=CH/L=Basel/O=Aeschi/OU=DB Comms/CN=whatever' WITH GRANT OPTION;

ssl_type in mysql.user says "SPECIFIED". flush privileges was run.

If this is intended, what should one configure such that matching is done
on all of the values defined for ISSUER/SUBJECT/CIPHER ?

How to repeat:
Create SSL certificates; define that both ISSUER and SUBJECT should
be in mysql.user.

Attempt to connect with ISSUER mismatching: you'll see "X509 issuer mismatch:
should be 'nnn' but is 'mmm'" and the connection is refused.

Attempt to connect with ISSUER matching but SUBJECT mismatching: you'll
see "X509 subject mismatch: 'nnn' vs 'mmm'".

Suggested fix:
Be more strict.

Patch...

diff -ur mysql-5.0.22_o/libmysqld/sql_acl.cc mysql-5.0.22/libmysqld/sql_acl.cc
--- mysql-5.0.22_o/libmysqld/sql_acl.cc 2006-05-25 10:56:46.000000000 +0200
+++ mysql-5.0.22/libmysqld/sql_acl.cc   2006-06-13 06:38:09.000000000 +0200
@@ -867,6 +867,7 @@
             sql_print_information("X509 issuer mismatch: should be '%s' "
                              "but is '%s'", acl_user->x509_issuer, ptr);
           free(ptr);
+          user_access=NO_ACCESS;
           break;
         }
         user_access= acl_user->access;
@@ -882,11 +883,13 @@
         if (strcmp(acl_user->x509_subject,ptr))
         {
           if (global_system_variables.log_warnings)
-            sql_print_information("X509 subject mismatch: '%s' vs '%s'",
-                            acl_user->x509_subject, ptr);
+            sql_print_information("X509 subject mismatch: should be '%s' "
+                             "but is '%s'", acl_user->x509_subject, ptr);
+          free(ptr);
+          user_access=NO_ACCESS;
+          break;
         }
-        else
-          user_access= acl_user->access;
+        user_access= acl_user->access;
         free(ptr);
       }
       break;

Thank you for a problem report and patch. Yes, it is a bug according to the manual (http://dev.mysql.com/doc/refman/5.0/en/grant.html), because:

"REQUIRE SUBJECT 'subject' places the restriction on connection attempts that the client must present a valid X509 certificate containing the subject subject. If the client presents a certificate that is valid but has a different subject, the server rejects the connection."

The patch isn't sufficient - seems that one must apply the same patch to sql_acl.cc, too.

Regards,
Al.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/10725

ChangeSet@1.2250, 2006-08-22 14:29:48+02:00, tnurnberg@salvation.intern.azundris.com +3 -0
  Bug#20411: "GRANT ... REQUIRE ISSUER nnn AND SUBJECT mmm" fails to require both
  
  when X.509 subject was required for a connect, we tested whether it was the right
  one, but did not refuse the connexion if not. fixed.
  
  (corrected CS now --replace_results socket-path)

Available in 5.0.25 .

Available in 5.1.12

Noted in 5.0.25, 5.1.12 changelogs.

For connections that required a SUBJECT value, a check was performed
to verify that the value was correct, but the connection was not
refused if not.