Difference between revisions of "Secure Website"

Jump to navigation Jump to search
121 bytes added ,  10:45, 6 February 2013
m
Minor typo corrections
m (→‎Set-up Secured Website: Updated warning note)
m (Minor typo corrections)
Line 2: Line 2:
In order to run a secure website you need certificates, whist providing a full explanation as to the purpose and usage of certificates is beyond the scope of this page, I'll attempt to summarise...
In order to run a secure website you need certificates, whist providing a full explanation as to the purpose and usage of certificates is beyond the scope of this page, I'll attempt to summarise...


What kind of certificate your require depends on what you are going to use the site for.  Generally speaking a website that's going to be accessed by the general public, or non IT-literate users, will need to be signed by one of the big certificate authorities (i.e. a well-known root CA) which are already trusted by web-browsers.  If its a internal or test site, or its only going to be access by people who know and trust you, a self-signed certificate will be fine.  
What kind of certificate your require depends on what you are going to use the site for.  Generally speaking a website that's going to be accessed by the general public, or non IT-literate users, will need to be signed by one of the big certificate authorities (i.e. a well-known root CA), which are already trusted by web-browsers.  If its a internal or test site, or its only going to be accessed by people who know and trust you, a self-signed certificate will be fine.  


It boils down to how much trust a user needs to have in your website, and what level of monetary insurance there should be, if the security mechanism breaks down.
It boils down to how much trust a user needs to have in your website, and what level of monetary insurance there should be, if the security mechanism breaks down.
Line 16: Line 16:
Cheaper (or sometimes free if you're a person rather than a company) certificates require limited validation to prove that you are who you say you are, and provide minimal insurance (if any) for a loss due to security breach.   
Cheaper (or sometimes free if you're a person rather than a company) certificates require limited validation to prove that you are who you say you are, and provide minimal insurance (if any) for a loss due to security breach.   


More expensive certificates can be more flexible (can cover an entire domain rather than just a single host), provide greater insurance, and should provide greater assurance to your users that you are who you say you are, you own your domain etc etc). They'll also require much more stringent validation to confirm you (and/or your company's) identity.
More expensive certificates can be more flexible (for example, can cover an entire domain via a wildcard certificate, rather than just a single host), provide greater trust and insurance (for example, Extended Validation), and should provide greater assurance to your users that you are who you say you are, you own your domain etc etc). They'll also require much more stringent validation to confirm you (and/or your company's) identity.


If you expect to be handling any money/card transactions or other highly sensitive data, then securing your website can be hard-work and expensive.  Both in terms of the certificate(s) you need to purchase, and other measures you need to take to ensure your site is actually secure.  There is good reason why many online businesses use 3rd party websites to handle their transactions.  Unless you have dedicated staff that can continually apply preventative measures (be it OS patching, reacting to PHP vulnerabilities, or whatever) and that can promptly detect and react to potential security breaches, do not take on the responsibility yourself.   
If you expect to be handling any money/card transactions or other highly sensitive data, then securing your website can be hard-work and expensive.  Both in terms of the certificate(s) you need to purchase, and other measures you need to take to ensure your site is actually secure.  There is good reason why many online businesses use 3rd party websites to handle their transactions.  Unless you have dedicated staff that can continually apply preventative measures (be it OS patching, reacting to PHP vulnerabilities, or whatever), and that can promptly detect and react to potential security breaches, do not take on the responsibility yourself.   


Ensuring that communication between your website and clients is secure is only part of the job.  A secure connection into a compromised server is worse than an insecure connection to a compromised server as users will be under the impression that your site is trustworthy.
Ensuring that communication between your website and clients is secure is the easiest part of the job.  A ''secure'' connection into a compromised server, is worse than an ''insecure'' connection to a compromised server; as users will be under the impression that your site is trustworthy when it is not.


'''If your site gets breeched, and your clients/customers become exposed, its your fault.'''
'''If your site gets breeched, and your clients/customers become exposed, its your fault.'''


== Create Self-Signed Certificate ==
== Create Self-Signed Certificate ==
This is basically an adapted version of what has been documented previously by [http://www.vanemery.com/Linux/Apache/apache-SSL.html Van Emery], if well worth checking out.
This is basically an adapted version of what has been documented previously by [http://www.vanemery.com/Linux/Apache/apache-SSL.html Van Emery], its well worth checking out.


If you already have a Certificate Authority (because you're created self-signed keys before) then don't create another unless you really need to.
If you already have a Certificate Authority (because you're created self-signed keys before) then don't create another unless you really need to.

Navigation menu