Welcome to WebmasterWorld Guest from 22.214.171.124
Forum Moderators: phranque
The SSL certificate should be for her specific domain name, be installed on her host and it should not be self signed but issued by a CA (certificate authority). You should not get any security warnings on visiting the site.
If she is on shared hosting, without her own IP - chances are she is not secure - because SSL is basically one certificate per IP.
Right click will still show source - being secure doesn't affect that, it encrypts the information coming and going.
Hope that helps!
Her site is definitely secure, and the supposed webmaster owes her a refund.
Is, or is NOT?
Before you go slamming this "webmaster" and demanding a refund, you may want to gather a little more understanding of what secure and non-secure means, and does.
There is not a single bit of difference between a page on a non-secure server and one on a secure server. Not one. So your initial claim that the developer "built a secure website" says you're ready to jump this person wthout any grounds for a complaint.
An example: pick out any page and go to it with and without the https:
Same page. One is "secure" and one is not. So, you're saying, what am I paying for on a secure server?
As said a secure server delivers encrypted pages to the browser, and if the browser understands and recognizes the certificate, using the encryption scheme defined in the certificate, takes any plain html page loaded in the browser and encrypts it before sending it back to the server. THIS is the effect of a secure server, and has nothing to do with the pages created on it. A secure server encrypts the data being sent to and from the browser so if the data is intercepted en route it is extremely difficult to decode into anything that can be abused.
But the page that exists on the server is just plain html.
Now, there ARE a few things the web developer should be responsible for. See my previous example between http and https. If a page is supposed to be on the secure server, a visitor should NOT be able to accidentally or intentionally enter the non-secure url. The web developer should put means in place to prevent this from happening, the most graceful being an invisible rewrite using mod_rewrite, a more simplistic method would be a simple redirect.
Secondly there are many things in any server side programming that should be addressed dealing with security, a developer is responsible for these issues.
But if you have a simple form submitted to a secure gateway, there's not one bit of difference between this form and a non-secure version. The difference is how it is requested.
Be sure you understand these issues, nowadays when I get inquiries like this, I am inclined to bill the customer the time it takes to explain it to them. If a client brought this question to me in the way you have phrased it, I would have to tell them this information comes from an uninformed source and I could fully explain it but the time would be billable.
Some sites that accept credit cards aren't secure until you click submit. The form will be http, but it will submit to an https.
As said this is not only false, it's insecure and dangerous. Any web developer that has a form on a "regular" server in which the user enters sensitive information, such as credit card info, should be banned from computer usage. :-) The form on which you ENTER info needs to be generated from a secure server. Otherwise it's submitted as plain text.
The exception would be a page that accepts **only** non-sensitive information, then passes a total and a few other tokens to a secure server. The PayPal payment forms on sites are a good example. But if you notice, when you submit from the site, the CC info is collected on PayPal, not on the originating server.
That would be insanely insecure.
this is not only false, it's insecure and dangerous.
The form on which you ENTER info needs to be generated from a secure server. Otherwise it's submitted as plain text.