Secure Website: Difference between revisions
m (→Remove Key PassPhrase: Minor text update) |
(→Set-up Secured Website: Added fix for shmcb error in Ubuntu 12.04) |
||
(8 intermediate revisions by the same user not shown) | |||
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 ( | 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. | |||
A | === 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 | 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 (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. | |||
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.''' | |||
== 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], | 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. | |||
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''' | ||
Line 31: | Line 49: | ||
## Create a Certificate Signing Request (CSR) for the website | ## Create a Certificate Signing Request (CSR) for the website | ||
##* EG <code> openssl req -new -key my-server.key -out web-my-server.csr </code> | ##* 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 | ## 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> | ##* 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 61: | ||
##* EG <code> cp self-ca.crt /etc/apache2/ssl/</code> | ##* EG <code> cp self-ca.crt /etc/apache2/ssl/</code> | ||
==== CSR Fields ==== | |||
The table below offers guidance on how to complete the fields of a CSR. Note that the fields should refer to the legal entity that owns the certificate. So if you or your company is registered and operates from London (UK), but the server(s) happen to be hosted in Amsterdam (Netherlands), you enter location details for London. Remember that the purpose of the certificate is to identify you, the website operator, as who you are. | |||
Unless where specifically stated, you should not use abbreviated or shortened answers, and note that apart from OU, all fields are required. | |||
{|class="vwikitable" | |||
|- | |||
! Field !! DN !! Purpose !! Example | |||
|- | |||
| Country Name || C || [http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 2 letter ISO country code] || <code> GB </code> | |||
|- | |||
| State / Province Name || ST || State/County/Province || <code> Greater London </code> | |||
|- | |||
| Locality Name || L || City or locality || <code> London </code> | |||
|- | |||
| Organization Name || O || Company name (not abbreviated) || <code> SandfordIT Limited </code> | |||
|- | |||
| Organizational Unit || OU || Department name || <code> Engineering </code> | |||
|- | |||
| Common Name || CN || FQDN of server/URL || <code> www.sandfordit.com </code> | |||
|- | |||
| Email Address || || Contact for certificate || <code> info@sandfordit.com </code> | |||
|} | |||
Don't enter anything for the 'extra' attributes, password and company name. | |||
=== Remove Key PassPhrase === | === Remove Key PassPhrase === | ||
Line 55: | Line 98: | ||
== Set-up Secured Website == | == Set-up Secured Website == | ||
'''If you have | {| 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> | ||
Line 77: | 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> | ||
Line 102: | Line 159: | ||
SSLEngine on | SSLEngine on | ||
# Server Certificate: | # Server Certificate: | ||
SSLCertificateFile /etc/apache2/ssl/my-server.crt | |||
# Server Private Key: | |||
SSLCertificateKeyFile /etc/apache2/ssl/my-server.key | |||
# Server Certificate Chain: | # Server Certificate Chain: | ||
Line 115: | Line 172: | ||
</VirtualHost> | </VirtualHost> | ||
</IfModule> | </IfModule> | ||
== Multiple Secure Websites == | |||
In order to run multiple secure websites you need to perform some additional steps... | |||
# Create a named virtual hosts in <code>/etc/apache2/ports.conf </code> | |||
#* EG <code> NameVirtualHost 192.168.1.45:443 </code> | |||
# Add IP address to Virtual Host config in each site's config | |||
#* EG <code> <VirtualHost 192.168.1.45:443> </code> | |||
So your <code>'''ports.conf'''</code> might look a bit like... | |||
<IfModule mod_ssl.c> | |||
NameVirtualHost 192.168.1.45:443 | |||
Listen 443 | |||
</IfModule> | |||
<IfModule mod_gnutls.c> | |||
Listen 443 | |||
</IfModule> | |||
...and a site config might begin like... | |||
<IfModule mod_ssl.c> | |||
<VirtualHost 192.168.1.45:443> | |||
ServerName sec1.domain.com | |||
ServerAdmin info@domain.com | |||
... | |||
See also [[Multiple Websites On The Same Server]] | |||
[[Category:Apache]] | [[Category:Apache]] |
Latest revision as of 23:03, 11 September 2014
Certificates
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 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.
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.
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 (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.
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.
Create Self-Signed Certificate
This is basically an adapted version of what has been documented previously by 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.
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
- These will be used as a basis for any future cert/key's for web-servers you need - keep them safe!
- Create folder for them, and move into the folder
- EG
mkdir /root/certs
- EG
chmod 0770 /root/certs
- EG
cd /root/certs
- EG
- Create CA key (you'll need to provide a passphrase/password for your key)
- EG
openssl genrsa -des3 -out self-ca.key 2048
- EG
- Create CA X.509 certificate (you'll need to provide details about you (if your website is public, these details will viewable))
- EG
openssl req -new -x509 -days 3650 -key self-ca.key -out self-ca.crt
- EG
- Check certificate
- EG
openssl x509 -in self-ca.crt -text -noout
- EG
- Create a private key and certificate for your website
- Generate the private key for the server (you'll need to provide a passphrase/password for your key)
- This is specific to your server (not the website)
- EG
openssl genrsa -des3 -out my-server.key 1024
- Create a Certificate Signing Request (CSR) for the website
- EG
openssl req -new -key my-server.key -out web-my-server.csr
- The Common Name must match the FQDN of your website, see CSR Fields for further info
- EG
- Create certificate for the website
- EG
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
- EG
- Check certificate
- EG
openssl x509 -in web-my-server.crt -text -noout
- EG
- Protect keys and copy to Apache directory
- EG
chmod 0400 *.key
- EG
mkdir /etc/apache/ssl
- EG
cp web-my-server.crt /etc/apache2/ssl/
- EG
cp my-server.key /etc/apache2/ssl/
- EG
cp self-ca.crt /etc/apache2/ssl/
- EG
- Generate the private key for the server (you'll need to provide a passphrase/password for your key)
CSR Fields
The table below offers guidance on how to complete the fields of a CSR. Note that the fields should refer to the legal entity that owns the certificate. So if you or your company is registered and operates from London (UK), but the server(s) happen to be hosted in Amsterdam (Netherlands), you enter location details for London. Remember that the purpose of the certificate is to identify you, the website operator, as who you are.
Unless where specifically stated, you should not use abbreviated or shortened answers, and note that apart from OU, all fields are required.
Field | DN | Purpose | Example |
---|---|---|---|
Country Name | C | 2 letter ISO country code | GB
|
State / Province Name | ST | State/County/Province | Greater London
|
Locality Name | L | City or locality | London
|
Organization Name | O | Company name (not abbreviated) | SandfordIT Limited
|
Organizational Unit | OU | Department name | Engineering
|
Common Name | CN | FQDN of server/URL | www.sandfordit.com
|
Email Address | Contact for certificate | info@sandfordit.com
|
Don't enter anything for the 'extra' attributes, password and company name.
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 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
- EG
cp my-server.key my-server.key.pass
- EG
- Create an unencrypted version (you will be prompted for the passphrase)
- EG
openssl rsa -in server.key.org -out server.key
- EG
For further info, see http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#removepassphrase
Set-up Secured Website
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 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 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
sites-enabled
rm /etc/apache2/sites-enabled/000-default
service apache2 restart
(you may get a warning about no VirtualHosts)
- Test by browsing to your web-server's IP address, no webpage should be returned
Now lets create the secure website...
- Create sub-folders for your web-sites, eg
- EG
mkdir /var/www/www.domain.com
- EG
- Create sub-folders for your web-sites' logs, eg
- EG
mkdir /var/log/apache2/www.domain.com
- EG
- Enable
mod_ssl
cd /etc/apache2/mods-enabled
ln -s ../mods-available/ssl.conf ssl.conf
ln -s ../mods-available/ssl.load ssl.load
- Create config file for site (see below for content)
- EG
vi /etc/apache2/sites-available/ssl-site
- EG
- Enable site
cd /etc/apache2/sites-enabled
ln -s ../sites-available/ssl-site ssl-site
- Restart Apache to apply (you'll get prompted for the server key passphrase - see Remove Key PassPhrase
service apache2 restart
- If you receive the following error
AH00526: Syntax error on line 43 of /etc/apache2/mods-enabled/ssl.conf:
SSLSessionCache: 'shmcb' session cache not supported (known names: ). Maybe you need to load the appropriate socache module (mod_socache_shmcb?).
- Load the
socache_shmcb
module to resolve..- In
/etc/apache2/mods-enabled
runln -s ../mods-available/socache_shmcb.load socache_shmcb.load
- In
<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerName www.domain.com ServerAdmin info@domain.com DocumentRoot /var/www/www.domain.com <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/www.domain.com> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ErrorLog "|/usr/sbin/rotatelogs /var/log/apache2/www.domain.com/error-%Y-%m-%d.log 86400" CustomLog "|/usr/sbin/rotatelogs /var/log/apache2/www.domain.com/access-%Y-%m-%d.log 86400" combined # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on # Server Certificate: SSLCertificateFile /etc/apache2/ssl/my-server.crt # Server Private Key: SSLCertificateKeyFile /etc/apache2/ssl/my-server.key # Server Certificate Chain: SSLCertificateChainFile /etc/apache2/ssl/self-ca.crt # Certificate Authority (CA): SSLCACertificateFile /etc/apache2/ssl/self-ca.crt </VirtualHost> </IfModule>
Multiple Secure Websites
In order to run multiple secure websites you need to perform some additional steps...
- Create a named virtual hosts in
/etc/apache2/ports.conf
- EG
NameVirtualHost 192.168.1.45:443
- EG
- Add IP address to Virtual Host config in each site's config
- EG
<VirtualHost 192.168.1.45:443>
- EG
So your ports.conf
might look a bit like...
<IfModule mod_ssl.c> NameVirtualHost 192.168.1.45:443 Listen 443 </IfModule> <IfModule mod_gnutls.c> Listen 443 </IfModule>
...and a site config might begin like...
<IfModule mod_ssl.c> <VirtualHost 192.168.1.45:443> ServerName sec1.domain.com ServerAdmin info@domain.com ...
See also Multiple Websites On The Same Server