Secure Website - Revision history

Sstrutt: /* Set-up Secured Website */ Added fix for shmcb error in Ubuntu 12.04

2014-09-11T23:03:00Z

Set-up Secured Website: Added fix for shmcb error in Ubuntu 12.04

← Older revision		Revision as of 23:03, 11 September 2014
Line 128:		Line 128:
	# Restart Apache to apply (you'll get prompted for the server key passphrase - see [[#Remove_Key_PassPhrase\|Remove Key PassPhrase]]		# Restart Apache to apply (you'll get prompted for the server key passphrase - see [[#Remove_Key_PassPhrase\|Remove Key PassPhrase]]
	#* <code> service apache2 restart </code>		#* <code> service apache2 restart </code>
			#* If you receive the following error
			#** <code> AH00526: Syntax error on line 43 of /etc/apache2/mods-enabled/ssl.conf:</code>
			#** <code> SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).</code>
			#* Load the <code>socache_shmcb</code> module to resolve..
			#** In <code>/etc/apache2/mods-enabled</code> run <code> ln -s ../mods-available/socache_shmcb.load socache_shmcb.load</code>


	<IfModule mod_ssl.c>		<IfModule mod_ssl.c>

Sstrutt: Minor typo corrections

2013-02-06T10:45:42Z

Minor typo corrections

← Older revision		Revision as of 10:45, 6 February 2013
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.

Sstrutt: /* Set-up Secured Website */ Updated warning note

2012-08-30T06:42:44Z

Set-up Secured Website: Updated warning note

← Older revision		Revision as of 06:42, 30 August 2012
Line 98:		Line 98:

	== Set-up Secured Website ==		== Set-up Secured Website ==
	'''If you have an existing site that's served from the root of your webserver, this needs to be removed 1st.''' So to remove the default site that's installed with Apache...		{\| class="vwiki-note"
			\|-
			\| '''If you have a single existing site that's served from the root of your webserver, this needs to be removed 1st.'''
			\|-
			\| Website(s) served through [http://httpd.apache.org/docs/2.2/vhosts/ Virtual Hosts] aren't a problem - see [[Multiple Websites On The Same Server]]. Your websites need to be configured as Virtual Hosts if running more than one from a webserver.
			See [[#Multiple_Secure_Websites\|Multiple Secure Websites]] if you need to host more than one secure site from the same webserver
			\|}

			To remove the default site that's installed with Apache (if required - see note above)...
	# Disable the web-site by removing the link to its config from <code>sites-enabled</code>		# Disable the web-site by removing the link to its config from <code>sites-enabled</code>
	#* <code> rm /etc/apache2/sites-enabled/000-default</code>		#* <code> rm /etc/apache2/sites-enabled/000-default</code>

Sstrutt: Minor rewording

2012-08-20T09:11:53Z

Minor rewording

← Older revision		Revision as of 09:11, 20 August 2012
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 (~~aka~~ well-known root CA) which are already trusted by web-browsers~~; but 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~~. 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~~.		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.

	~~A '''self-signed certificate''' will present an alert~~ to ~~the~~ user~~, asking them if they really trust the~~ website ~~they're accessing. They can either decide that they do trust you or close the page. If they do trust you~~, and ~~trust that they're hit your genuine website~~, ~~they can permanently accept your self-signed certificate as valid and trustworthy. Note that~~ if ~~they (for some reason) go to an invalid website masquerading as you on, before they've accepted your certificate as valid, they can be tricked into trusting somebody else instead~~.		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.

	A ~~'''commercially~~ signed certificate~~'''~~ will ~~normally automatically provide validation that~~ the ~~website is valid and trustworthy~~, ~~but will also normally cost money. Cheaper (or sometimes free~~ if ~~you~~'re ~~a person rather than a company) require limited validation~~ that you ~~are who you say you are, and minimal insurance for an 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 (~~they'~~ll also require much more stringent validation to confirm you (or~~ your ~~company) actually exists~~, ~~you own~~ your ~~domain etc etc)~~.		=== Self-Signed ===
			A self-signed certificate will cause the web browser to present an alert to the user, asking them if they really trust the website that they're accessing. They can either decide that they do trust you or close the page. If they do trust you, and trust that they've hit your genuine website, they can permanently accept your self-signed certificate as valid and trustworthy by adding an exception for the certificate.

	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 ~~for~~ 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 your site gets breeched, and your clients/customers become exposed, its your fault.		Note that if (for some reason) they go to an invalid website masquerading as you, before they've accepted your certificate as valid, they can be tricked into trusting somebody else instead.

			=== Commercially Signed ===
			A commercially signed certificate will normally automatically provide validation that the website is valid and trustworthy, but will also normally cost money.

			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.

			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.

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

	== Create Self-Signed Certificate ==		== Create Self-Signed Certificate ==

Sstrutt: Added "Multiple Secure Websites"

2012-08-07T07:08:03Z

Added "Multiple Secure Websites"

@@ Line 144: / Line 144: @@
   </VirtualHost>
   </IfModule>
 [[Category:Apache]]

Sstrutt: /* Create Self-Signed Certificate */ Added some extra notes

2012-04-30T16:20:58Z

Create Self-Signed Certificate: Added some extra notes

← Older revision		Revision as of 16:20, 30 April 2012
Line 11:		Line 11:

	== 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], if 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.

			Similarly, if you have already created a server key for your server, and you just need another certificate for a another site being hosted on the server, start from the ''Create a Certificate Signing Request (CSR) for the website'' part of the procedure''.

	# '''Create private (self generated) Certificate Authority (CA) key and certificate for you/your organisation'''		# '''Create private (self generated) Certificate Authority (CA) key and certificate for you/your organisation'''

Sstrutt: /* Set-up Secured Website */ Typo fix

2012-04-30T15:53:49Z

Set-up Secured Website: Typo fix

← Older revision		Revision as of 15:53, 30 April 2012
Line 128:		Line 128:
	# Server Certificate:		# Server Certificate:
	SSLCertificateFile /etc/apache2/ssl/my-server.crt		SSLCertificateFile /etc/apache2/ssl/my-server.crt

	# Server Private Key:		# Server Private Key:
	SSLCertificateKeyFile /etc/apache2/ssl/my-server.key		SSLCertificateKeyFile /etc/apache2/ssl/my-server.key

Sstrutt: /* Create Self-Signed Certificate */ Updated CSR info

2012-04-30T15:53:12Z

Create Self-Signed Certificate: Updated CSR info

@@ Line 31: / Line 31: @@
 ## Create a Certificate Signing Request (CSR) for the website
 ##* EG <code> openssl req -new -key my-server.key -out web-my-server.csr </code>
-##* The Common Name ''must'' match the FQDN of your website
+##* The Common Name ''must'' match the FQDN of your website, see [[#CSR Fields|CSR Fields]] for further info
 ## Create certificate for the website
 ##* EG <code> openssl x509 -req -in web-my-server.csr -out web-my-server.crt -sha1 -CA self-ca.crt -CAkey self-ca.key -CAcreateserial -days 3650 </code>
@@ Line 43: / Line 43: @@
 ##* EG <code> cp self-ca.crt /etc/apache2/ssl/</code>
 === Remove Key PassPhrase ===

Sstrutt: /* Set-up Secured Website */ Corrected inconsistent filenames

2012-04-20T22:53:06Z

Set-up Secured Website: Corrected inconsistent filenames

← Older revision		Revision as of 22:53, 20 April 2012
Line 102:		Line 102:
	SSLEngine on		SSLEngine on
	# Server Certificate:		# Server Certificate:
	SSLCertificateFile /etc/apache2/ssl/~~mail~~-~~sync2~~.crt		SSLCertificateFile /etc/apache2/ssl/my-server.crt

	# Server Private Key:		# Server Private Key:
	SSLCertificateKeyFile /etc/apache2/ssl/~~web2~~-server.key		SSLCertificateKeyFile /etc/apache2/ssl/my-server.key

	# Server Certificate Chain:		# Server Certificate Chain:

Sstrutt: /* Remove Key PassPhrase */ Minor text update

2012-03-13T07:58:03Z

Remove Key PassPhrase: Minor text update

← Older revision		Revision as of 07:58, 13 March 2012
Line 45:		Line 45:

	=== Remove Key PassPhrase ===		=== Remove Key PassPhrase ===
	The following removes a layer of security protection should your webserver be attacked. You should balance the increased risk of this against the improved usability (a common trade-off in the world of security). The server key will no longer be encrypted, which means it can be stolen and re-used to impersonate your server, opening you up to a [http://www.wikipedia.org/wiki/Man-in-the-middle_attack man in the middle attack].		The following removes a layer of security protection should your webserver be attacked. You should balance the increased risk of this against the improved usability (a common trade-off in the world of security). The server key will no longer be encrypted, which means it can be stolen and re-used to impersonate your server, opening you up to a [http://www.wikipedia.org/wiki/Man-in-the-middle_attack man in the middle attack], but it does mean that your webserver will start with the OS, or can be restarted without manual interaction being required.

	# Create a backup of the server key		# Create a backup of the server key