server verification of client FQDNs

This is a multi-part message in MIME format.

------=_NextPart_000_0024_01C4860A.C1BAB450
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi All,



I want to configure Apache to verify client certificates. What I am not sure
about is whether Apache verifies the fully qualified domain name (FQDN) of
each client as well. If it does, where is this behavior explained? For
example, does it use the client IP address to look up the corresponding
domain names in the DNS and then compare all matching domain names to the
one in the client certificate? Also, which field is used in the client
certificate, subjectName.commonName or subjectAltName.dNSName? What happens
if the names don't match? What if the DNS lookup fails because there is no
DNS entry for the given IP?



Thanks,

Alex


------=_NextPart_000_0024_01C4860A.C1BAB450
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">


charset=3Dus-ascii">

Re: server verification of client FQDNs

Alex Milanovic wrote:
> Hi All,
>
>
>
> I want to configure Apache to verify client certificates. What I am not sure
> about is whether Apache verifies the fully qualified domain name (FQDN) of
> each client as well. If it does, where is this behavior explained? For
> example, does it use the client IP address to look up the corresponding
> domain names in the DNS and then compare all matching domain names to the
> one in the client certificate? Also, which field is used in the client
> certificate, subjectName.commonName or subjectAltName.dNSName? What happens
> if the names don't match? What if the DNS lookup fails because there is no
> DNS entry for the given IP?
>
>
>
> Thanks,
>
> Alex
>
>

I see no-one else has answered this so ... in short, Alex, https/TLS
servers aren't supposed to validate client IP addresses or domain names.

A server certificate for https/TLS binds a domain name to a key pair,
and client software is required to verify the correspondence of the
requested domain name in the URL and in the server certificate. In a
server certificate the subjectAltName.dNSName - or traditionally the CN
component of the distinguished name - is the server's FQDN.

General X.509 certificates, however, bind *arbitrary* information and
identities - not usually domain names - to the keypair; any valid
certificate can be used as a client certificate and usually there will
be no domain-related information in the certificate at all.

So, for example, my company-issued certificate binds my corporate
identity ...

DN=(CN="Jmaes Colier",O="Vogon Enterprises Inc.",OU="Janitors", ...)

.... to a private key that is accessible to my laptop's browser. This
means I can authenticate myself to my company's intranet no matter
where/how my laptop is connected to the Internet (home, airport, hotel,
random hotspot ...).

The verification of TLS certificates under https is governed by RFC 2818
- worth reading for clarification - and as far as I can see there is no
expectation that a server should ever attempt to verify a
subjectAltName.dNSName in a client certificate against a DNS reverse lookup.

That said, there is nothing to stop you from doing this kind of
verification in a closed community where you issue all certificates (you
could probably hack it with mod_rewrite), but you would need to consider
carefully whether or not it is a sensible or useful thing to do.

Regards -- James.

____________________________________________________________ __________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majordomo@modssl.org