PKI/SSL Client/Server Certificate Authentication

The current PKI implementation seems to support the encryption aspects of
SSL/TLS, but what about using Authorization/Authentication?

I.e., when you configure SSL on the server, you're not specifying a
trusted CA cert (or directory of trusted CA Certs).

The client can specify REQUIRE_SSL environmental variable, but client
can't present an X.509 certificate. There are no options on either the
client or the server to verify the authenticity of the peers certificates.

I ask because I generally discourage the practice of embedding database
passwords into source code. That reminds me of Oracle, Solaris, and a lot
of other dirty, decrepit, security-hole-prone configurations.

However, "Another popular open source RDBMS" (whose name we wont mention
here) has a nifty feature that permits the mapping of certain Attribute
pairs in the DN= (sometimes called the "Subject) of a client X.509
certificate into the Username credential field.

Thereby:

- The database and the client submit CSRs to an mutually exclusive CA in
the organization

- The CA signs and returns X.509 certs to both.

- The server and client libraries configure to trust local copies of the
CA Cert

- The server requires client cert verification against the CA on the
server config

- The client requires server cert verification against the CA on the
client config

- The server configures a username/access grant like such:

GRANT ALL PRIVILEGES ON dbname.* TO
-> 'web-app-meta-user'@'web-server-inside-dmz'
-> IDENTIFIED BY 'goodsecret' (Optional)
-> REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/
O=MySQL demo client certificate/
CN=Tonu Samuel/Email=tonu(at)example(dot)com'
-> AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/
O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu(at)example(dot)com'
-> AND CIPHER 'EDH-RSA-DES-CBC3-SHA';

- Thus enforcing two-stage authentication, a very healthy practice. This
adds a level of redundancy to security (In conjuntion with the use of
Views, ACLs, Firewall rules, Password Rotation, Auditing, Secure coding
practices, etc.)

If a "bad person" were to somehow obtain a copy of the source code with a
password embedded in the connect string (Steal it from a developer who
uses Windows, or maybe convince Apache to not interpret PHP before sending
to the client, something stupid like that), they would still be unable to
connect without a client certificate.

This two-stage authentication model is in use in Apache, OpenSSH sshd(8),
OpenLDAP, and FreeRADIUS (with EAP-TLS + PAP/CHAP). It's even used on the
Cisco 3000 series VPN Concentrator by default (in all it's glory).

It's definately a very useful feature tha we should aspire to offer.

Thoughts?

TIA,
~BAS