Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

 


Overview

In securing your web site with a digital certificate, your main aim is to provide proof of your online identity and in so doing establish a relationship of trust with those with whom you wish to interact online, with authentication being the most important element of a digital certificate.

Authentication provides users with proof that:

1. your company is a bona fide real world company.

2. they are connecting to the correct server.

A certificate's level of authentication may be seen as an indication of its quality – the higher the level of authentication provided, the greater the quality of the certificate. It is therefore important to understand that the various digital certificates available each differ in level of authentication depending on the issuing Certificate Authority (CA) or even the specific product. Some CAs perform only very basic authentication prior to issuing a certificate while others conduct extensive checks to ensure the identity of the applying organisation.

The following are the various authentication checks that are performed by CAs:

• Domain lookup to confirm that applying company owns the domain.

• Check existence of company to confirm that it is a legally registered organisation.

• Verification of identity of individual requesting certificate to confirm that they are an authorized representative.

All CAs perform one or more of these authentication checks, the result is certificates with a range of differing levels of quality. It is important to note that the more authentication checks performed the better the quality of the certificate. So make sure you determine exactly what authentication checks are performed before purchasing.


Implementation Process

1) InTime Support creates an openSSL (-sha256)

2) InTime Support sends details to the client with information containing: URL of InTime site, Expiry date of current certificate, CSR attached (information in the CSR to be checked for errors) and finally the format in which the SSL must be created in.

3) The clients IT team or outsourced IT team, raise the CSR with the chosen provider e.g Go-Daddy, choose the length and level of cover they'd like to pay for.

Then return the SSL to Support@In-Time.co.uk for us to apply to the server we will host your InTime subdomain on.

4) We apply the SSL for you, typically out of hours, after this has propagated (updated) worldwide (this can take up to 48hrs) your site will become/remain accessible and secure.


SSL Certificate Purchase Options

Our customers primarily opt for one of two options when securing RSM online applications with a SSL certificate, these are as follows:

• A free CAcert (http://www.cacert.org/) certificate, which although secure is not registered with common internet browsers such as Firefox and Internet Explorer and as such users will be presented with connection security warnings. The users can choose to ignore the warnings and not be prompted again.

•The alternative is to purchase a certificate from a provider such as Thawte http://www.thawte.com/ or VeriSign (http://www.verisign.com/) whose certificates are registered with common internet browsers. Certificates which are registered on internet browsers do not prompt the user with the above warning messages.

SSL Certificate setup process

• Any sub domains required (e.g. timesheets.yourdomain.com) should be created by the client and confirmed to RSM Employer Services Limited in writing.

• RSM will generate a server certificate for each sub domain, which will in-turn be forwarded to the client.

• Upon receipt of the server certificate(s) the client should purchase the SSL certificate for each sub domain from a Certificate Authority. During the purchase process the server certificate(s) provided by RSM need to be uploaded. Please ensure the Web Server Type you choose is "Apache - X.509". 

• The SSL certificate provider will supply a certificate which would need to be forwarded to RSM  support. Please include both the root and intermediate certificates for your chosen provider. The certificate is used to generate a key store which is then uploaded to the server.

• Upon completion of these steps the site will be secure and can be accessed via the https protocol.

 

 

Certificates and Web Site Security

Reference: http://en.wikipedia.org/wiki/Ssl_certificate 14 April 2009

The most common use of certificates is for HTTPS-based web sites. A web browser validates that an SSL (Transport Layer Security) web server is authentic; so that the user can feel secure that their interaction with the web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate provider with a certificate signing request. The certificate request is an electronic document that contains the web site name, contact email address, and company information. The certificate provider signs the request, thus producing a public certificate. This public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believed that the provider issued a certificate to the owner of the web site. Before issuing a certificate, the certificate provider will request the contact email address for the web site from a public domain name registrar, and check that published address against the email address supplied in the certificate request. Therefore, an https web site is only secure to the extent that the end user can be sure that the web site is operated by someone in contact with the person that registered the domain name.

 

 

 

  • No labels