Depending on how you decide to implement Digi-Access™ will dictate whether you need a new login page or not.
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:
1. Create a completely new domain directory. For example the new login URL could be:
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.
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.
Enabling Digi-Access™ client certificates for two factor authentication will take you 30 minutes (or less). Configure your server by following these simple steps:
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.*" \ 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: 7. Start Internet Services Manager, or open the MMC that contains the IIS snap-in. |
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.
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:
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:
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.
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.
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.
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.
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.
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.
Once the invitation is issued, the end user must complete the enrolment form. View customised enrolment [17] forms or browse the other pages below.
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.
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.
Digi-Access™ can be used with most modern smart phones and tablets (contact support [21] to check your specific device).
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.
Links:
[1] https://www.digi-sign.com/support/digi-ssl/generate+csr
[2] https://www.digi-sign.com/order/digi-ssl/internal/csr-check.php
[3] https://www.digi-sign.com/support/digi-ssl/install+certificate/index
[4] https://www.digi-sign.com/support/digi-access/administrator
[5] https://www.digi-sign.com/digi-access/configure
[6] https://www.digi-sign.com/digi-access/distribute
[7] https://www.digi-sign.com/contact
[8] https://www.digi-sign.com/support/digi-access/apache
[9] https://www.digi-sign.com/support/digi-access/iis
[10] http://www.digi-sign.com/downloads/certificates/digi-access/BundledCAXp.pem
[11] http://www.digi-sign.com/downloads/certificates/dsroot/Digi-Sign_Root_CA.cer
[12] http://www.digi-sign.com/downloads/certificates/digi-access/Digi-Sign_CA_Digi-Access_Xs.cer
[13] https://www.digi-sign.com/digi-access/configure/ou
[14] https://www.digi-sign.com/digi-ca
[15] https://www.digi-sign.com/digi-access/distribute/policy
[16] https://www.digi-sign.com/digi-access/distribute/invite
[17] https://www.digi-sign.com/digi-access/distribute/enrol
[18] https://www.digi-sign.com/digi-access/distribute/activate
[19] https://www.digi-sign.com/digi-access/mobile
[20] https://www.digi-sign.com/digi-access/mobile/download
[21] https://www.digi-sign.com/mailto
[22] https://www.digi-sign.com/downloads/download.php?id=digi-access-403
[23] http://technet.microsoft.com/nl-nl/library/cc753103(WS.10).aspx
[24] https://www.digi-sign.com/403-7.htm
[25] https://www.digi-sign.com/403-12.htm
[26] https://www.digi-sign.com/403-13.htm
[27] https://www.digi-sign.com/403-16.htm
[28] https://www.digi-sign.com/403-17.htm