If a client application is behind NAT, it does not have a real IP address. Certificate field 'common name' is supposed to contain a fully qualified domain name or a real IP address. Could the value of this field be ignored on SSL verification?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[email protected] wrote:
If a client application is behind NAT, it does not have a real IP address. Certificate field 'common name' is supposed to contain a fully qualified domain name or a real IP address.
Indeed, but only for server certificates.
Could the value of this field be ignored on SSL verification?
Common names of client certificates are not validated on SSL servers.
stunnel does not validate common names at all, as, unlike web browsers, it does not allow for dynamic selection of servers.
Mike
On 13/Jun/2014 at 07:56:38 +0200, Michal Trojnara wrote:
Common names of client certificates are not validated on SSL servers.
stunnel does not validate common names at all, as, unlike web browsers, it does not allow for dynamic selection of servers.
If I understand the man page properly, in transparent mode stunnel should connect to any server that a non-SSL aware client is going to.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[email protected] wrote:
stunnel does not validate common names at all, as, unlike web browsers, it does not allow for dynamic selection of servers.
If I understand the man page properly, in transparent mode stunnel should connect to any server that a non-SSL aware client is going to.
You understand the man page properly, although in transparent destination mode it would not be possible for stunnel to verify the common name against DNS name of the server. Why? Because stunnel does not know the target server's DNS name, only its IP address. Only the original client knows the server name that resolved to this IP address.
Mike
-
Michal Trojnara -
reg14＠rambler.ru