Digi-Access™ : 2FA : UK VPN : Digi-Sign.com

Product Name:

Digi-Access™

Product Extension:

Strong Authentication

Category:

Two Factor Authentication Systems

Description:

Digi-Access™ offers the <nobr>best <a href="/digi-access" alt="TEXT" title="Learn about Digi-Access™ two factor authentication" />two factor, strong</nobr> authentication</a> required by web-based systems. Password login security is strengthened by adding a second, critical layer of security. No hardware or software required. Configuration is simple. Deployment and management are easy.

Simple & Strong Two Factor Authentication [2FA]

Securing any on line system with usernames and passwords (single factor authentication) may not offer the level of protection and security your organisation needs. Adding a 'second layer' of protection, called 'two factor authentication [1]' [2FA], is the preferred security option that strengthens the existing username and password access.

Digi-Access™ Strong Authentication		Digi-Access™ Two Factor Authentication
[2]		[3]
Watch Video [2]. Duration 5:16 Minutes		Watch Video [3]. Duration 1:35 Minutes

Two factor authentication [2FA] is something that you own/posses (e.g. a Digi-Access™ certificate) combined with something that you know (i.e. the username and password). And this is the preferred security option to strengthen user access.

There are alternative [1] two factor authentication [2FA] solutions but none are as easy to implement, or as compatible [4] as Digi-Access™. It literally 'sits in front' of your current systems and for ARP members [5] is a simple additional revenue 'add-on'.

Two Factor Authentication [2FA] Demos'

Benefits of Digi-Access™

Where Digi-Access™ is Most Effective

Digi-Access™ Web [9]	- enhances password security for web access control
Digi-Access™ Cloud [10]	- for securing cloud computing systems access
Digi-Access™ Mobile [11]	- for securing mobile devices (i.e. smart phone, iPads, etc)
Digi-Access™ SaaS [12]	- security for Software-as-a-Service [SaaS] offerings
Digi-Access™ Extranet [13]	- secures any extranet with strong authentication
Digi-Access™ VPN [14]	- used to secure almost every type of VPN
Digi-Access™ Finance [15]	- specifically for online banking or financial transactions
Digi-Access™ VoIP [16]	- eliminate hacking & phreaking on VoIP systems

Simple Setup & Activation

As there are only three steps, a basic setup of Digi-Access™ should be possible in less than a few hours. The three simple steps are:

1.	If required, change the location of the Login [17] page

2.	Configure [18] the server to use Digi-Access™ for two factor authentication [2FA]
2.5	Customise [19] the IIS error pages (IIS Only)

3.	Invite [20] users to get their Digi-Access™ Certificate and approve [21] successful applicants

Extensive Compatibility

Digi-Access™ is compatible with 27 different servers [4], so adding this second layer of security access does not require any re-programming of your existing environment.

Choose your Digi-Access™ >> [22]

Alternatives

Choosing between One-Time-Passwords & Digi-Access™

You have an existing, well structured and 'secured' online application. This could be an extranet, portal, online banking, insurance service, medical application or any other online system. Currently, access is controlled and 'protected' by usernames and passwords.

[7]Online Banking Example [7]

For many reasons, this security is no longer sufficient and there are only two credible options available:

One-Time-Password [OTP] Tokens

Digi-Access™ Certificates

In Favour of OTP

Against using OTP

In Favour of Digi-Access™

Against using Digi-Access™

You decide which makes more sense

And then let your users decide

Perhaps you don't have any plans to increase the security access to your online application. Budgetary restrictions may be another issue. So why not let your users decide if they want this security 'add-on'.

We have a simple programme for this too:

Avail of this ARP Special Offer >> [5]

Man-in-the-Middle Security Issue

How the Man-in-the-Middle attack occurs

The Man-in-the-Middle [MITM] attack intercepts a communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.

This attack can occur, even when One-Time-Password [OTP] tokens are in use. The MITM system simply takes the password as it is issued and uses it to gain access to the online system.

How Digi-Access™ protects against the Man-in-the-Middle attack

Using Digi-Access™ the Man-in-the-Middle attack is not possible because it uses completely different 'key-pair' technology. The server must receive the public key from the Digi-Access™ certificate and the MITM server cannot have the correct configuration to request this (because it is not part of the 'trust-link' that is an integral part of the Digi-Access™ 'key-pair' technology). Therefore the MITM attack will fail to work when the user has a Digi-Access™ certificate.

Concerns about the MS CryptoAPI

Some systems Administrators will refer to the security bug within Microsoft© CryptoAPI [31]. This security bug means that for users that have Internet Explorer© browsers, it is possible for hackers to break into the Microsoft© Certificate store and misappropriate the Digi-Access™ certificate (this does not apply to Mozilla browser users).

However, this security concern is irrelevant if the user has a properly configured PC with regular Microsoft© updates enabled. As most responsible users do have Microsoft© updates enabled (and you can provide help pages to highlight the issue), then this is as much a risk to end users as protecting their computers from viruses.

Quick-Start Guide

Getting Digi-Access™ Operational Quickly

The following QuickStart guide to implementing Digi-Access™ is for experienced server administrators. There is a complete implementation guide for beginners, if you need more detailed instructions.

Allow 30 Minutes

Generate a Certificate Signing Request [CSR] from the server using these instructions [32]
Once it's created, use the online CSR checker [33] to make sure it's correctly configured
If the CSR checker passes the CSR as beign correctly generated, then go to the Digi-SSL section of your Digi-CA™ Service account and request your Digi-SSL™ certificate
Wait for the Digi-SSL to be be returned to your email address
Use these instructions [34] to install your Digi-SSL™
Then proceed to configure the server to require Digi-Access™ for two factor authentication [2FA] using these instructions [35]
And finally, use the Digi-Access™ section of your Digi-CA™ Service account to issue test Digi-Access certificates

New Login Page

Step 1 - Changing the Login Page to require Digi-Access™

Depending on how you decide to implement Digi-Access™ will dictate whether you need a new login page or not.

Allow 30 Minutes

If you want all users to use Digi-Access™ client certificates for two factor authentication, then you do not make any changes to the login page. You can skip this step and move to Step 2 [18].

Alternatively, if some users will continue using usernames & passwords and other users will use Digi-Access™, then the following are the suggested guidelines to follow:

Instructions for changing the Login Page

1. Create a completely new domain directory. For example the new login URL could be:

https://login.organisation.com

2. Make a copy of the existing login page and place it in the root, default folder for this new site.

3. There are many ways to implement and manage the database of users and this is one, simple suggestion: copy the user database from the existing website and enable it for the new login page you have created for Digi-Access™

Those users that login with usernames and passwords will continue to do so, as they do currently. Once the server(s) is configured [18], those users that wish to use the two factor authentication login will get their Digi-Access™ certificate [20] and use this, together with their existing username and password for login at the new URL.

Note:- As each new Digi-Access™ certificate is issued, the username and password access to the original login page must be disabled.

Follow the right side link below to learn how easy it is to configure the server to use Digi-Access™ certificates.

Server Configuration

Step 2 - Configuring Digi-Access™ on the Server

The instructions below are for the two most popular servers (i.e. IIS and Apache). If you are using different web server software, use the online contact form for Support [36] and they will supply the instructions for your server.

Allow 30 Minutes

Enabling Digi-Access™ client certificates for two factor authentication will take you 30 minutes (or less). Configure your server by following these simple steps:

Apache [37]

IIS [38]

For full detailed instructions and explanations, read the Apache Support [37] pages.

1. Download and save this certificate bundle:

CA Bundle for Digi-Acess™ [39]

2. Open the httpd.conf file for editing and locate the Virtual Host section for your SSL secured site

3. Add the following directive line into your site/directory configuration section:

SSLOptions +StdEnvVars +ExportCertData

Once the StdEnvVars is enabled, the standard set of SSL related CGI/SSI environment variables are created. CGI and SSI requests are disabled by default. This is for performance reasons and we do not recommend changing this unless you are an experienced Apache Administrator. For further details and instructions, refer to the Apache Support [37] page

4.Add the following directive line into your site/directory configuration section:

SSLVerifyClient require

This directive sets the certificate verification level for the Client Certificate Authentication. This directive can be used both on a per-server and a per-directory context. In the per-server context, the client authentication process is applied during the standard SSL handshake when a connection is established. In per-directory context, it forces the SSL re-negotiation with the reconfigured client verification level after the HTTP request was read but before the HTTP response is sent. We recommend that you use the 'require' variable unless you are an experienced Apache Administrator. For further details and instructions, refer to the Apache Support [37] page

5.Add the following directive line into your site/directory configuration section:

SSLVerifyDepth 10

This directive sets the depth of 10. This means that the client certificate has to be signed by a CA that is directly known to the server (i.e.: the CA's certificate is under SSLCACertificatePath). We recommend that you use the '10' variable unless you are an experienced Apache Administrator.

You can also add the following directive(s) to enable a customised authentication rule, if you choose the Apache web server to be the authentication level:

SSL Require

This directive specifies a general access requirement which has to be fulfilled in order to allow access. It's a very powerful directive because the requirement specification is an arbitrarily complex Boolean expression containing any number of access checks. We recommend do not recommend using this unless you are an experienced Apache Administrator. For further details and instructions, refer to the Apache Support [37] page

Note:- If you are implementing a CGI application with Digi-Access™ some Apache versions may require the following directive to be present:

   SetEnvIf User-Agent ".*MSIE.*" \
   nokeepalive ssl-unclean-shutdown \
   downgrade-1.0 force-response-1.0

For further details and instructions, refer to the Apache Support [37] page

6. Save your httpd.conf file

7. Restart Apache

For full detailed instructions and screenshots, read the IIS Support [38] pages.

1. Download and save these two certificates:

Digi-Sign Root CA [40]

Digi-Sign CA Digi-Access™ Xs [41]

2. On the server, click the Start button, select Run and type MMC, before clicking the 'OK' button

3. You should now be in the Microsoft Management Console and should follow these steps:

4. Now all you need to do is import the Digi-Access™ Root certificate, following these steps:

5. Then import the Digi-Access™ intermediate certificate, as follows:

6. Go to Windows Administrative Tools and open the properties window for the website that you have enabled SSL on. Open the Directory Security by right clicking on the Directory Security tab and then follow these steps:

Click Edit in the Anonymous access and authentication control section. The Authentication Methods window will appear
Make sure that all options (check boxes) in this section are disabled, including the Anonymous Access, Basic Authentication, Digest Authentication and Integrated Windows Authentication
Click OK to apply changes
Click Edit in Secure communications section and the Secure Communications window will appear
Ensure that both the 'Require secure channel (SSL)' option and the 'Require 128-bit encryption' option are enabled
Ensure that Require client certificates radio button is enabled
Then ensure that the 'Enable client certificate mapping' option is enabled and that the 'Ensure that Enable certificate trust list' option is enabled
Move to the 'Under Current CTL' and click New, followed by Next > and a Certificate Trust List Wizard window will appear
Browse for the Digi-Sign_Root_CA.cer Certificate file and click Open, followed by Next>
In the Friendly Name field enter: Digi-Access
In the Description field enter: Digi-Access Two Factor Client Authentication
Click Next > and then Finish
You should now see your Certificate Trust List [CTL] List on the Secure Communications window
Click OK and then OK again

7. Start Internet Services Manager, or open the MMC that contains the IIS snap-in.

Right-click the Web site for which you want to configure authentication (for example, Default Web Site), and then click Properties
Click the Directory Security tab, and then under Secure communications, click Edit
Click to select the Enable client certificate mapping check box, and then click Edit
Click the Many-to-1 tab, and then click Add
In the General dialog box, type 'Digi-Access' as the name for the rule, and then Next
In the Rules dialog box, click New
In the Edit Rule Element dialog box that appears, configure the settings that you want for the rule

There are two fields from client certificates that can be used as criteria for many-to-one rules:

* Issuer - This field specifies information about the Certification Authority [CA] that issued the Digi-Access™ certificate

* Subject - This field specifies information about the entity to whom the Digi-Access™ certificate was issued

Each of these fields can contain common LDAP sub fields for example:

       * CN = commonName (for example, "Bob Smith")
       * OU = organizationalUnitName (for example, "Sales")
       * OU = organizationalUnitName [42] (for example, "dsacme")
       * OU = organizationalUnitName [42] (for example, "ds10003")
       * O = organizationName (for example, "Acme, Inc.")
       * L = localityName (for example, "Dublin")
       * S = stateOrProvinceName (for example, "Dublin")
       * C = countryName (for example, "IE")

To create a mapping, you create a rule based on a field/subfield pair for a specific value. For example, you could create a rule that matched the Subject's O subfield with 'Acme' to allow access to all clients with certificates that were issued for the Acme organization. This effectively eliminates client connections from any clients that are not part of the Acme organization.

When finished creating the rule settings, click OK, and then click Next

IMPORTANT NOTE:- In addition to the above parameters you enter, two additional rule sets will be generated by the Registration Authority [RA] that will be used to distribute [20] the the end users' Digi-Access™ certificates. These two rule sets are based on Organizational Unit Name [OU] fields and will be 'silently' pre-appended to each Digi-Access™ Certificate issued by the Digi-Access™ CA.

These OU field values distinguish end users as belonging to your specific user domain. You must obtain these values from Digi-Access™ RA Certificate Management Console where these two rule sets can be found in the Certificate Manager's 'Distinguished Name' policy configuration.
In the Mapping dialog box, click Accept this certificate for Logon Authentication, and then in the Account box, type, or click Browse to browse to the Windows user account that you want to map. Type the password of the user account in the Password box.
Click OK three times, and then quit Internet Services Manager, or close the IIS snap-in

Your web server is now ready to start using Digi-Access™ client certificates for two factor authentication.

Follow the right side link below to learn how easily each user can get their Digi-Access™ certificate.

Issuing Certificates

Step 3 - Issuing Digi-Access™ Certificates to the End Users

The Digi-CA™ [43] Certificate Authority [CA] system (that issues the Digi-Access™ end user certificates) can issue thousands of certificates every hour. This 'endless' capacity means that getting Digi-Access™ certificates to the end users can occur as quickly as your environment demands.

Allow 30+ Minutes

How the Digi-Access™ certificates are issued is set by the 'Enrolment Policy [44]'. The options within the Enrolment Policy are designed to be very flexible. They can be customised to meet almost any requirement with many different settings and combinations. The three basic options are:

Overview of the Issuing Process

Issuing the Digi-Access™ certificates is either a one or two stage process. Either the user receives an email inviting them to apply for their certificate, or they are referred from an existing online site/system to the Certificate Application form.

However the user is prompted to get their certificate, in the first stage, the Digi-CA™ Inviting 'action' requires the end user 'reaction' (completing an application form). In the second stage, the Digi-CA™ Approving 'action' requires the end user 'reaction' (activating the certificate) and this completes the process. It is best understood as follows:

Sample Issuing Process

As stated, because the Enrolment Policy is very flexible, there are many different ways to invite and approve end users certificates. The following is a sample issuing process only. You may wish to include other options, as required.

Stage One 'Digi-CA™ Action' - Inviting Digi-Access™ Certificate Applications

Using the Digi-CA™ RA Management Console interface, the Administrator uploads a .CSV batch file inviting [45] as many users as required.

Review the other available invitation [45] options.

Stage One 'User Reaction' - Completing Enrolment Form

The Digi-CA™ system sends an email to each end user with a unique link to the Digi-Access™ certificate enrolment form. Using the link provided in the email, the end user then completes the Digi-Access™ certificate enrolment form.

Note:- this is the default Digi-Access™ End Entity Digital Certificate Enrolment Form. This form uses basic HTML programming that can be altered [46] to match your specific design requirements.

See other sample enrolment [46] forms.
Stage Two 'Digi-CA™ Action' - Approving Enrolment Applications

Once the end user completes all the fields and submits the enrolment form to the Digi-CA™ system, the Administrator is notified. The Administrator then approves [44] each end user application using the Digi-Access™ certificate Authorization Panel.

Depending on the Enrolment Policy [44] this stage may be automated.

Stage Two 'User Reaction' - Activating the Digi-Access™ Certificate

Assuming the Administrator approves the application, the Digi-CA™ system sends a new email to the end user advising them that their application has been approved. Using the link provided in the email, the end user then activates [47] the Digi-Access™ certificate and this completes the issuing process.

See other sample certificate activation [47] forms.

Thumbnail:

Sample Application Forms

Examples of How the Digi-Access™ Application Forms can be Customised: The Digi-Access™ End Entity Digital Certificate Enrolment Form uses basic HTML programming that can be altered to match your specific design requirements. Below are some samples of customised enrolment pages:

Note:- In addition to changing the 'look and feel' of the enrolment page you will notice that the fields required on the form can be altered according to the specific Enrolment Policy [44] set by the organisation.

Once the enrolment form is completed and submitted by the end user, the Enrolment Policy enforces how the application is handled by the Digi-CA™ system. Learn more about the Enrolment Policy [44] options or browse the other pages below.

Sample Mobile Application Form

Sample Customised Digi-Access™ Mobile Application Form

The Digi-Access™ [11] Mobile End Entity Digital Certificate Enrolment Form for mobile users is basic HTML programming that can be altered to match your specific design requirements. Below is a sample of a customised enrolment page:

Note:- In addition to changing the 'look and feel' of the enrolment page you will notice that the fields required on the form can be altered according to the specific Enrolment Policy [44] set by the organisation.

Once the enrolment form is completed and approved, the user is notified by email and uses the link in that email to download [48] and install their Digi-Access™ certificate to their mobile device.

Certificate Invitation Options

Descriptions of the Digi-Access™ invitations options

Digi-Access™ certificates are issued according to the Enrolment Policy. The first stage is the Inviting stage that is controlled by the End Entity Account Manager interface in Digi-CA™. There are three options:

Once the invitation is issued, the end user must complete the enrolment form. View customised enrolment [46] forms or browse the other pages below.

Enrolment Policy

Descriptions of the Digi-Access™ invitations options

The Enrolment Policy for Digi-Access™ controls the entire certificate issuing process. Enrolment Policy is set by the Certificate Policy [CP] for the Digi-CA™. This is a specialist subject and requires experienced knowledge of Certificate Authority [CA] systems and Public Key Infrastructure [PKI]. Keeping this complex topic simple, there are three basic options for Enrolment Policy:

Sample Activation Forms

Examples of How the Digi-Access™ Application Forms can be Customised: The Digi-Access™ End Entity Digital Certificate Enrolment Form uses basic HTML programming that can be altered to match your specific design requirements. Below are some samples of customised enrolment pages:

Note:- In addition to changing the 'look and feel' of the enrolment page you will notice that the fields required on the form can be altered according to the specific Enrolment Policy [44] set by the organisation.

Once the enrolment form is completed and submitted by the end user, the Enrolment Policy enforces how the application is handled by the Digi-CA™ system. Learn more about the Enrolment Policy [44] options or browse the other pages below.

Sample Mobile Activation Form

Examples of How the Digi-Access™ Application Forms can be Customised

The Digi-Access™ End Entity Digital Certificate Enrolment Form uses basic HTML programming that can be altered to match your specific design requirements. Below are some samples of customised enrolment pages:

Once the enrolment form is completed and submitted by the end user, the Enrolment Policy enforces how the application is handled by the Digi-CA™ system. Learn more about the Enrolment Policy [44] options or browse the other pages below.

Digi-Access™ can be used with most modern smart phones and tablets (contact support [49] to check your specific device).

Error Customisation

Step 4 - Creating Custom Error Pages (IIS Only)

Microsoft® IIS servers are unique because they have specific default error pages designed to work with Digi-Access™ certificates. To enhance the user experience you should use the customised Digi-Access™ error 403 pages [50].

Allow 10 Minutes

The error handlers within IIS display default error pages depending on the specific issue that occurs on the server. The error message on each of these pages and their purpose are explained below.

Most error pages on IIS can be customised [51]. The default 403 error pages that relate to the use of Digi-Access™ are stored in the C:\WINDOWS\help\iisHelp\common\ folder. The 2X Application Server Administrator should download the Digi-Access™ error 403 pages [50] and place them in a new folder: (e.g. C:\WINDOWS\help\iisHelp\digi-access\ ). The server should be configured to display these new error pages before being restarted to complete the setup procedure.

	Error		Description

	403.7 [52]		Access denied. SSL Client Certificate is Required

			The system is using Digi-Access™ two factor authentication and users must have a Digi-Access™ certificate to gain access

	403.12 [53]		Access denied due to certificate mapping configuration

			Digi-Access™ only uses mapping in highly integrated situations. In most instances, this error page will not display

	403.13 [54]		Access denied. The SSL Client Certificate was revoked or revocation status can not be established

			The specific Digi-Access™ certificate being used is invalid/out-of-date. The user must get a new Digi-Access™ certificate is required

	403.16 [55]		Access denied. The SSL Client Certificate is incorrect or is not trusted by the server

			The user has incorrectly selected a different type of digital certificate (i.e. not the required Digi-Access™ certificate)

	403.17 [56]		Access denied. The SSL Client Certificate has expired or is not yet valid

			The user's Digi-Access™ certificate has expired and they must request a new one from the Digi-Access™ system

Thumbnail:

Viewing Your Certificate

How to view your Digi-Access™ Certificate

Depending on your operating system and browser version, you can view your Digi-Access™ two factor authentication certificate using the instructions below:

Microsoft® Internet Explorer®

Mozilla/Firefox/Safari

1. To view your Digi-Access™ certificate in Microsoft® Internet Explorer®, use the Tools menu (you may have to press the 'Alt' button on your keyboard to view this menu) and then select Internet Options

2. In the Internet Options dialog box, select the Content tab and then click the Certificates button

3. In the Certificates dialog box, select the certificate you wish to examine and then click the View button

4. The chosen certificate will be displayed where you will be able to see:

Here is an en example of such a Digi-Access™ certificate:

1. To view your Digi-Access™ certificate in Mozilla, Firefox or Safari, use the Tools menu and then select Options

2. In the Options dialog box, select the Encryption tab and then click the View Certificates button

3. In the Certificate Manager dialog box, select the certificate you wish to examine and then click the View button

4. The chosen certificate will be displayed where you will be able to see:

Here is an en example of such a Digi-Access™ certificate:

Thumbnail:

Deleting Your Certificate

Instructions on How to Delete an Unwanted/Expired Digi-Access™certificates

Depending on your operating system and browser version, you can delete your Digi-Access™ two factor authentication certificate using the instructions below:

Microsoft® Internet Explorer®

Mozilla Firefox

2. In the Internet Options dialog box, select the Content tab and then click the Certificates button

3. In the Certificates dialog box, select the certificate you wish to examine and then click the View button

4. The chosen certificate will be displayed where you will be able to see:

Here is an example of a Digi-Access™ certificate as seen in the Microsoft® Internet Explorer® dialog:

5. Once you have viewed and confirmed this is the Digi-Access™ certificate you wish to remove, return to the Certificates dialog box, select the certificate and click the Remove button

1. To view your Digi-Access™ certificate in Mozilla Firefox, use the Tools menu and then select Options

2. In the Options dialog box, select the Encryption tab and then click the View Certificates button

3. In the Certificate Manager dialog box, select the certificate you wish to examine and then click the View button

4. The chosen certificate will be displayed where you will be able to see:

Here is an example of such a Digi-Access™ certificate as seen in the Mozilla Firefox dialog:

5. Once you have viewed and confirmed this is the Digi-Access™ certificate you wish to delete, return to the Certificate Manager dialog box, select the certificate and click the Delete button

Digi-Access™ Compatibility

Compatible with 27 Web Servers

Digi-Access™ is compatible with all of the following servers listed below. If your webserver software does not appear on the list, please contact support [36] with full details of your webserver software and we will contact you with further instructions.

Apache Mod_SSL

OpenSSL

Java Based Web Servers

Cobalt RaQ4/XTR

Apache via Ensim Webppliance 3.1.x

Stronghold Server

Hsphere

IBM HTTP Server

Java Based Web Servers

Lotus Domino Server versions 4.6x and 5.0x

Microsoft IIS 4.x

Microsoft IIS 5.x / 6.x

Microsoft ISA 2000 Server

Microsoft SMTP Server

I-Planet Web Server

I-Planet Web Server 6.x

Sun ONE 6.x

Oracle Web Server

Plesk Server Administrator 2.5

Plesk 5.0

Plesk 6.0

Plesk 7.0

Plesk 7.5

BEA Systems Weblogic

Website Pro 3.x

WS FTP Server

Zeus