I am afraid I still do not quite understand, perhaps because we are talking about different scenarios. In my case I am also the CA. I therefor have absolute trust in the privatekey/certificate issued to both A and B - I do not need to proove to e.g. verisign that I control a given URL.
Note that I am not just nit-picking - I am dealing with clients who (physically) cannot reveal a unique IP or DNS name, as they may be hidden behind NAT firewalls at arbitrary IP's, so please bear with me =o) Now, following your example, assume that A connects to C on www.someothersite.com, which identifies itself using B's certificate. It is certainly true that I can avoid the connection simply by looking at the CN of the certificate versus the DNS, BUT as I understand it, no damage can occur if accept the connection as C does not have the private key of B, and so cannot sign data, and thus THEN refuse the connection. In this case, does the assumption of absolute trust in the CA change the need for the DNS name in the CN? /Jan On Thu, 2002-01-10 at 15:34, Neff Robert A wrote: > > The client needs to verify who it is connected to. > Anyone in the world can present a certificate to > establish an ssl connection. In a nutshell, the > checks that need to be made on the client end are: > a. Do you trust the signer of the certificate received > b. Is the CN contained within the cert what you expect > > For example, I can easily create a certificate that > contains the CN www.vittrup-hansen.dk. However, I cannot > get Verisign to sign that certificate. That is the base > of trust. > > If OpenSSL is configured to verify the certificate chain > using the cert store during a connection attempt, and that > connection completes successfully, you are assured of the > receipt of a trusted cert. At this point you only know that > you are connected to a site that sent a certificate signed > by a trusted CA. Your next task is to ensure that the > trusted cert truly came from the site you expected and > not www.someothersite.com. The browser does this step by > comparing the CN contained in the cert to the URL address > typed into your browser. Your own app must do so as well... > > > -----Original Message----- > From: Jan Vittrup Hansen [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 10, 2002 9:13 AM > To: Neff Robert A > Cc: '[EMAIL PROTECTED]' > Subject: RE: Why DNS/IP in certificate? > > > Yes, but that also means that there is no security benefit in storing a > DNS name/IP address within the certificate. It is simply redundant, no? > > /Jan > > On Thu, 2002-01-10 at 15:09, Neff Robert A wrote: > > No, you misunderstand the handshake. B cannot be impersonated by C > > because C does not have the private key associated with the public > > key contained within B's certificate and thus cannot present that > > cert to successfully establish an SSL connection... > > > > -----Original Message----- > > From: Jan Vittrup Hansen [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, January 09, 2002 8:41 AM > > To: [EMAIL PROTECTED] > > Subject: Why DNS/IP in certificate? > > > > > > Why should one include the DNS/IP of oneself in a certificate? > > > > Consider A connecting to B. > > > > B exposes a certificate from a trusted CA to A. > > > > Now C tries to impersonate B. It easily finds B's certificate, > > and somehow manages to redirect or intercept the connection request from > > A. > > > > It responds with B's certificate, and so connection is established. > > HOWEVER: Since C does not have B's private key, it is unable to sign > > data, or decrypt data. Thus it cannot inflict damage? What am I missing? > > > > Also, do OpenSSL automatically renegotiate symmetric keys every X > > minutes (or Y bytes)? > > > > Regards, Jan > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List [EMAIL PROTECTED] > > Automated List Manager [EMAIL PROTECTED] > > ***************************************************************** > > DISCLAIMER: The information contained in this e-mail may be confidential > > and is intended solely for the use of the named addressee. Access, > copying > > or re-use of the e-mail or any information contained therein by any other > > person is not authorized. If you are not the intended recipient please > > notify us immediately by returning the e-mail to the originator. > > > > ***************************************************************** > DISCLAIMER: The information contained in this e-mail may be confidential > and is intended solely for the use of the named addressee. Access, copying > or re-use of the e-mail or any information contained therein by any other > person is not authorized. If you are not the intended recipient please > notify us immediately by returning the e-mail to the originator. > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
