Belinda Johnson wrote: >>From their company: > [...] >Again, I'm not sure what the people below are talking about but, the above >information is how site security works. I would be more than happy to >conduct a class for the "major techies" on how this all works. SMS seems to >think I know what I'm talking about, after all, I teach the e-commerce / >e-business class there. > Blah blah blah, internal server security.... you have just had smoke blown in your face. The person who composed this reply is not being very helpfull, or very professional. He prattles on about ASP and sessions and certificates not proving anything... byt the only thing you care about is the fact that IP is not an encrypted protocol, and that a web browser will transmit credit card name, type, number and expiration date in the clear. The first concern, then is that someone may intercept (or "snoop" or "evesdrop" on) the transmission between browser and server, and collect that data. Until a secure connection is established between a web browser and the web server, there is no justification for anyone to presume that my little brother is not going to go on a shopping spree with their credit card. A certificate means that Verisign thinks you are talking to the correct people. It does nothing more than that, he is correct.* Then you have to address the issue of encryption, now that you have established the identity of the server. That is traditionally done using SSL through HTTPS. I will now paste in the *one* important piece of information in his post now: <snip> You and I had spoken last week about purchasing a site certificate for the Sharp Signs web site to give a sense of confidence to the customer that their data is secure. We are in the process of doing this but, Verisign still needs to contact you regarding the authenticity of the information within your incorporation document that was faxed to us. As soon as they verify this, and generate the corresponding certificate key, we will install it and make the changes to the site to use HTTPS as the protocol. </snip> This tells us something we didn't know before: they do not intend to use their own domain name, and an appropriate certificate, to establish identity of the server. They intend to have the certificate generated in the name of your business. Thus you need to hold some people's hands and coax them into helping with the generation of this certificate done fast. 1) get an email with a tracking number, case number, or SOME specific evidence to his prior communications with Verisign so that you may facilitate the generation of the certificate. 2) contact Verisign by telephone (expect a wait) and speak with someone there about what needs to be done next. They will request that your organization fax business incorporation documentation (or similar proof of your right to 'own' your domain name) to them. 3) knock on some doors there at work to make sure this gets done. NOTES: * the following may help explain the difference between the two requisite tasks involved: authenticating identity and encrypting data. This has been shamelessly stolen from Verisign's Website, so please excuse their corporate branding. [ http://www.verisign.com/products/site/faq/40-bit.html ] What is the relationship between Public Keys and Certificates? In Public Key Cryptography, if Alice wants to send a secret message to Bob, she must obtain a copy of his public key. Before doing so, however, she needs to make sure that the public key really belongs to Bob. Certificates (also called Digital IDs) address this problem. A certificate is an electronic document that binds a public key to a particular individual or organization. Certificates are issued by a trusted third party, called a Certification Authority (CA). Before issuing a certificate, a good CA will go though a series of authentication procedures to make sure that Bob is who he claims to be, and that the public key in the certificate really belongs to Bob. Your Server ID will contain the following information: Your organization's common name (e.g. www.verisign.com) Additional identifying information (e.g. IP and physical address) Your public key Expiration date of the public key Name of the CA that issued the ID (i.e. VeriSign) A unique serial number The certificate is then encrypted (signed) with the CA's private key. Thus, if the end users trust the CA, and have the CAs public key, they can be assured of the certificate's legitimacy.