Openssl self-signed certificate verificatiion
Hi, Does anyone know where in the certificate verification routine that it checks the Common Name field against the device's interface IP address? Because the interface ip address may change at run time, it's preferred to have the routine check the CN field against some constant value instead of the ip. If you could point out where the verification code is, I could make a change. Thanks very much, -Grace __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Openssl self-signed certificate verificatiion
On Tue, Aug 15, 2006, Xie Grace Jingru-LJX001 wrote: Hi, Does anyone know where in the certificate verification routine that it checks the Common Name field against the device's interface IP address? Because the interface ip address may change at run time, it's preferred to have the routine check the CN field against some constant value instead of the ip. If you could point out where the verification code is, I could make a change. OpenSSL doesn't do this check automatically. It is left to an application to check. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Openssl self-signed certificate verificatiion
Hi, Does anyone know where in the certificate verification routine that it checks the Common Name field against the device's interface IP address? You want to check the CN against what the higher-level code intended to connect to. The SSL library has no idea what the higher-level code intended to connect to, so it cannot do this check. For example, if you try to connect to 'www.amazon.com' and the resolver resolvers this to '72.21.206.5', you want to get a certificate for 'www.amazon.com'. A certificate for '72.21.206.5' would not prove to the user that he reached 'www.amazon.com' because an attacker could redirect the DNS. Verifying that you got the right certificate as opposed to a valid certificate is outside the scope of what the SSL layer can do. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Openssl self-signed certificate verificatiion
David Schwartz wrote: For example, if you try to connect to 'www.amazon.com' and the resolver resolvers this to '72.21.206.5', you want to get a certificate for 'www.amazon.com'. A certificate for '72.21.206.5' would not prove to the user that he reached 'www.amazon.com' because an attacker could redirect the DNS. Verifying that you got the right certificate as opposed to a valid certificate is outside the scope of what the SSL layer can do. The key issue (pun intended) is possession of the associated private key for the identity bound to the public key in the cert. If the party possesses it, they may be presumed (modulo key revocation, etc.) to be the party indicated in the certificate -- no one else can perform a successful SSL handshake. Whether you like IP addresses or FQDNs is irrelevant. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Openssl self-signed certificate verificatiion
Verifying that you got the right certificate as opposed to a valid certificate is outside the scope of what the SSL layer can do. The key issue (pun intended) is possession of the associated private key for the identity bound to the public key in the cert. If the party possesses it, they may be presumed (modulo key revocation, etc.) to be the party indicated in the certificate -- no one else can perform a successful SSL handshake. Whether you like IP addresses or FQDNs is irrelevant. OpenSSL can check whether the other end has the private key corresponding to the certificate presented. This proves it owns the certificate. OpenSSL can check that the certificate presented is properly signed by a trusted authority. This ensures that the other end owns the CN in that certificate. However, OpenSSL cannot make sure the certificate presented is for the entity you wanted to connect to. Because it does not know that you really wanted to connect to 'www.amazon.com', it has no way to complain that the valid certificate presented was actually for 'www.evilsite.com'. Obviously, resolving 'www.evilsite.com' to an IP address and getting the one you connected to doesn't help. You must come back and make sure the certificate is owned by the thing you wanted to connect to in the first place. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
