Secure Website

From vwiki
Jump to navigation Jump to search

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.

  1. 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!
    1. Create folder for them, and move into the folder
      • EG mkdir /root/certs
      • EG chmod 0770 /root/certs
      • EG cd /root/certs
    2. Create CA key (you'll need to provide a passphrase/password for your key)
      • EG openssl genrsa -des3 -out self-ca.key 2048
    3. 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
    4. Check certificate
      • EG openssl x509 -in self-ca.crt -text -noout
  2. Create a private key and certificate for your website
    1. 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
    2. 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
    3. 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
    4. Check certificate
      • EG openssl x509 -in web-my-server.crt -text -noout
    5. 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/

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.

  1. Create a backup of the server key
    • EG cp my-server.key my-server.key.pass
  2. Create an unencrypted version (you will be prompted for the passphrase)
    • EG openssl rsa -in server.key.org -out server.key

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)...

  1. 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)
  2. Test by browsing to your web-server's IP address, no webpage should be returned

Now lets create the secure website...

  1. Create sub-folders for your web-sites, eg
    • EG mkdir /var/www/www.domain.com
  2. Create sub-folders for your web-sites' logs, eg
    • EG mkdir /var/log/apache2/www.domain.com
  3. Enable mod_ssl
    • cd /etc/apache2/mods-enabled
    • ln -s ../mods-available/ssl.conf ssl.conf
    • ln -s ../mods-available/ssl.load ssl.load
  4. Create config file for site (see below for content)
    • EG vi /etc/apache2/sites-available/ssl-site
  5. Enable site
    • cd /etc/apache2/sites-enabled
    • ln -s ../sites-available/ssl-site ssl-site
  6. 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 run ln -s ../mods-available/socache_shmcb.load socache_shmcb.load


<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...

  1. Create a named virtual hosts in /etc/apache2/ports.conf
    • EG NameVirtualHost 192.168.1.45:443
  2. Add IP address to Virtual Host config in each site's config
    • EG <VirtualHost 192.168.1.45:443>

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

Retrieved from ‘http://vwiki.co.uk/index.php?title=Secure_Website&oldid=2466’