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 [1]
Once it's created, use the online CSR checker [2] 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 [3] to install your Digi-SSL™
Then proceed to configure the server to require Digi-Access™ for two factor authentication [2FA] using these instructions [4]
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 [5].

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 [5], those users that wish to use the two factor authentication login will get their Digi-Access™ certificate [6] 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 [7] 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 [8]

IIS [9]

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

1. Download and save this certificate bundle:

CA Bundle for Digi-Acess™ [10]

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 [8] 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 [8] 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 [8] 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 [8] page

6. Save your httpd.conf file

7. Restart Apache

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

1. Download and save these two certificates:

Digi-Sign Root CA [11]

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

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 [13] (for example, "dsacme")
       * OU = organizationalUnitName [13] (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 [6] 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™ [14] 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 [15]'. 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 [16] as many users as required.

Review the other available invitation [16] 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 [17] to match your specific design requirements.

See other sample enrolment [17] 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 [15] each end user application using the Digi-Access™ certificate Authorization Panel.

Depending on the Enrolment Policy [15] 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 [18] the Digi-Access™ certificate and this completes the issuing process.

See other sample certificate activation [18] 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 [15] 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 [15] options or browse the other pages below.

Sample Mobile Application Form

Sample Customised Digi-Access™ Mobile Application Form

The Digi-Access™ [19] 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 [15] 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 [20] 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 [17] 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 [15] 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 [15] 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 [15] options or browse the other pages below.

Digi-Access™ can be used with most modern smart phones and tablets (contact support [21] 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 [22].

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 [23]. 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 [22] 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 [24]		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 [25]		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 [26]		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 [27]		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 [28]		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: