[1] Since the invention of SSL/TLS technology, requesting, installing and managing SSL Certificates [2] on servers has been a manual process. Some parts of these time consuming activities have been automated and some ‘solutions’ have tried to offer complete automation, but in doing so, have undermined the integrity and security of the environment.
[1] Although the AACD™ system automates the life cycle of all the Certificates on a device or server, it does so without having any impact on how the CA [3]/RA Validates your organization. As explained in 2.1.2, reliable Certificate vendors will follow strict Validation procedures to protect the integrity and trust of the Certificates they issue. As the amount of time that the Validation process takes is an ‘unknown variable’, the AACD™ system ensures sufficient notice is given to the CA so that this does not interrupt the timely delivery of the SSL.
AACD™ does not require extensive installation and configuration of a central server in order to function correctly simply because there is none. Nor does it require individual configuration of every server on the network either (a single DSSA™ [4] can be installed on multiple servers). And nor does it require customized formatting and configuration or compiling to create users, user groups, access controls or reporting.
There are three principle components of the AACD™ that form the Trust Triangle [5] and their simplicity is explained in the following sub sections:
Certificate Authority [CA] [6]
Certificate Services Gateway [CSG™] [7]
Daemon or Server Side Software™ [DSSA™] [4]
Then there is the optional network scanning service available on the CSG™ if required:
Certificate Discovery Search Engine™ [CDSE™] [8]
[1] In 2007, after 13 years, the Automated & Authenticated Certificate Delivery™ [AACD™] system solved not only the issue of automation but the all important issue of strong security and simplicity too. The AACD™ system is the unique, patent protected, SSL Management system used to assist any Certificate Administrator in the deployment and management of their Certificates. It can be used to manage the life cycle of a single SSL or many tens of thousands of Certificates, as required.
[1] The design of AACD™ makes it simple to deploy and it can manage any SSL environment. No matter how many SSLs [2] and how many different groups, departments and business units there are in your organisation, AACD™ can be deployed quickly and easily to serve all their needs. There is no complicated implementation, harden [9], report building or sophisticated technical knowledge required to use it and once deployed, day-to-day management is minimal.
AACD™ uses a unique concept known as ‘Trust Triangle [5]’ to securely automate your SSL requirements. The Trust Triangle creates a unique and authenticated link between any device containing a Digital Certificate [10] and the Certificate Authority [CA] [3] that will issue it with those Certificates. This is achieved by joining the Trust Triangle.
To join the Trust Triangle, the SSL Administrator downloads a software Daemon or Server Side Application™ [DSSA™] [4] for the specific device or server and conducts a straightforward install procedure. Once this installation is successfully completed, the Trust Triangle ensures that the entire life cycles of all the Certificates on the server are automated.
The AACD™ system improves the security within the organisation by removing the need for storing ‘Root’ passwords and does this whilst also improving the overall management of the server(s). AACD™ improves security, overall control and does this in a simple way that significantly reduces the manual time lost by current methods of SSL administration.
This online manual is for both technical and non-technical personnel in your organisation and is divided into several distinctly separate sections:
[1] AACD™ is a unique invention that can be compared to the pneumatic drill or the traffic signal because it takes a long established convention of manually doing a task and automates it so that people ask "why wasn’t this automated long before now?"
SSLs are a basic security requirement for any network where web servers are in use. We are all familiar with the ‘little yellow lock’ that appears in our browser when ordering an airline ticket and we understand its necessity for e-commerce. This lock is the SSL Certificate [2] ‘in action’ and is a basic component of most modern networks in operation today.
What most people don’t know is that SSLs expire on an annual basis and must be replaced. Your technical people spend hours and days requesting, ordering, receiving, installing and rebooting servers to make these SSLs work. And they do all of this online manually.
AACD™ automates this entire process and does it simply and securely. It removes not only time lost through all the manual procedures but also solves the issue of oversights where Administrators forget to renew an SSL on time. Failing to renew an SSL on time results in systems failure, ‘chaos’ and revenue loss.
Activating AACD™ is a one-time event. Once completed, everything is automated reliably and securely using advanced cryptographic technology and authentication. The result is a network with ‘one less security issue to be concerned with’. This means the time saved can be better used by dealing with the more important and critical security or network administration tasks of your organization.
With AACD™ the following positive outcome is affected:
See the AACD™ Flash Presentation [17] that explains the issues and benefits of using the system.
[1] AACD™ is supplied in accordance with the standard Digi-Sign Courtesy Refund Policy [18], that states: "[we] warrant that if a customer is not 100% Satisfied with their purchase of any of its products or solutions, it will refund the entire amount paid to Digi-Sign regardless of whether the product or solution has been used or not. This courteous 100% refund policy is offered without exception."
'Fast Track' the AACD™ Implementation
Implementing AACD™ in your environment is simple. If the server(s) in your organisation have an internet connection, then you simply download and install the DSSA™ [4] server software and install it on every machine. Once installed, all the SSLs on all of the DSSA™ Servers will automatically be renewed without any further action by anyone in your organisation.
In larger environments, with multiple servers, a Certificate Services Gateway™ [CSG™] [6] appliance must be placed inside your organisation to act as a gateway between your servers, the internet and ultimately the CA [3]. With the CSG™ installed, the DSSA™ software will communicate through your CSG™ to the internet and again, all of the servers will automatically be renewed without any further action by anyone in your organisation.
For further commercial advice or assistance in this regard, simple contact an AACD™ specialist using any of the following contact details:
Telephone:
US +1 (800) 959-4039
UK +44 (207) 242-1255
EU +353 (1) 410-0663
or e-mail: aacd@digi-sign.com [20]
See the AACD™ Flash Presentation [17] that explains the issues and benefits of using the AACD™ system.
[1] The process of requesting and receiving an SSL Certificate [2] typically involves technical people in your organization completing web forms and/or emails to request and receive them. This largely manual process takes some time and there are also request/response time delays between each of the ‘steps’ of the process. The following diagram illustrates the standard steps in the process of requesting and installing an SSL Certificate on a device or server.
With this number of steps and the need to rely on the CA [3] to act promptly to all requests (assuming that the Validation of these requests by the RA is positive so that the Certificate can be issued), ‘time loss’ is a natural consequence of the process.
[1] In a correctly run and operated CA [3], a team of trained RA Administrators manually check and verify every request for an SSL Certificate [2] following an internationally recognised practice known as validations [21].
For expedience and to save on cost, some CAs [3] have automated the Validation process so that the CA can deliver its Certificates cheaply and without the need for manual Validations. The Certificates are delivered quickly, but an automated Validations process is flawed and can undermine the integrity and values of the SSL it issues.
Regardless of how you request an SSL Certificate [2], the RA should validate the request and then issue the Certificate to you. Automated Certificate issuance from a CA is only one part of the overall Certificate life cycle and what it saves in expedience, it looses in security. Digi-Sign would only recommend using automated SSL Certificates for very specific, closed environments where Certificate integrity is easily controlled. For reputable and reliable providers, you should use vendors like VeriSign® or Digi-Sign to ensure your SSL Certificates are correctly validated and have internationally recognised integrity.
Important Note: Automated SSL Certificate delivery from a CA should not be confused with ‘automated life cycle management’ that occurs inside your organisation once you receive the SSL(s) from the CA.
Two-factor authentication, Machine Readable Travel Documents [MRTD [22] ] systems, national ID card systems, web access control, e Passports [23], device-to-device authentication and two factor authentication [24], all require the use of SSL Certificates. Integral to all of these environments is the requirement for digital authentication, digital identification, digital encryption, digital stamping and/or digital signing and being able to support these transactions with a legally binding infrastructure. The SSL Certificates is a basic component in each of these environments and its presence is central to their correct performance.
[1] This online manual assumes the reader has a basic knowledge of the function and purpose of an SSL or TLS Certificate and also some of the issues surrounding day-to-day management of the Certificates’ life cycle.
To gain a basic understanding of Digital Certificates [10], CA [3] systems, their functions and uses, download and read the Digi-CA™ [25] Manual.
The Basic Issues
Digital Certificates are issued and are valid for a specific period of time or ‘life’. So the life of the Certificate is set for a period of time and after this, it expires. An expired Certificate must be replaced if the security and integrity of the server or device is to be maintained. The life cycle of an SSL Certificate is circular and repetitive in nature.
Certificate Life cycle
How SSL Certificates are Issued
To initiate this process, the Administrator in your organisation must go to the specific server and generate a Certificate Signing Request [CSR [26]] and submit it, along with other legal contact and domain ownership information to the CA. On receiving the CSR & supporting information, a Department within the CA called the Registration Authority [RA] verifies and approves, or rejects, the request accordingly. This process is called validations [21].
If the Validation process is successful and the RA can accurately determine that your organisation does have legal ownership of the domain name used in the SSL Certificate [2] you are requesting, then the Certificate is issued. Your Administrator then installs the Certificate, thereby activating the HTTPS:// connection to the server and the ‘little yellow lock’ that appears in the browser whenever a connection is made to the specific server.
[1] The AACD™ system automates the SSL life cycle(s) in your organization and also adds additional layers of security. Layered security is a common practice in securing any network and the introduction of AACD™ improves the security layering by removing certain risks from the organization.
Layered security can be likened to a sphere with many layers that ultimately protect the core. To the access the critical assets at the core, each layer must be ‘peeled back’ and the more layers that are used to protect the core, the more secure it becomes. AACD™ adds additional layers of security to your environment, thereby protecting core assets without increasing Administrative overhead or time. In fact, time spent on the security of your environment is reduced and, at the same time, the security is increased.
With AACD™ the three additional layers of security are added are explained in the following sub sections:
[1] In the manual method of installing an SSL Certificate [2], the Administrator must have ‘Root’ access on the server. This means that the Administrator has the unique username and password that enables access the core of the machine. As layered security is designed to protect the core of any IT asset, providing core access to multiple Administrators potentially undermines this security principle.
Root access on any server should be a carefully guarded secret within your organisation because if this access is compromised, the entire server is vulnerable to endless security issues. Notwithstanding this fact, many organisations still store these passwords in clear text format on PCs with little, or no, real security in place.
Previous attempts to automate SSL delivery within the organisation have required Root passwords to be stored on a central server or in ‘line commands’ to be executed in the servers on the network. The central server has root access to all the servers it controls and must be able to send executable commands to those servers in order to function correctly. This requirement is a security weakness of these systems and is considered flawed.
Central server SSL management has not been adopted by the more security conscious organisations simply because the requirement of this server to centrally store Root access privileges gives rise to a ‘single point of failure’ and undermines the ‘best practice’ of layered security. Security architects will advise against the practice of single-point-failure wherever possible.
In choosing to adopt the AACD™ system to automate the SSL life cycle(s) in your organisation, you will download DSSA™ [4] software and install it on every server on the network that requires SSL Certificates. This software does not use Root access passwords to function. The fact that the Root access password is not required is an improved layer in the protection of the servers’ integrity and security.
[1] When manually installing an SSL Certificate [2], the Administrator must enter the ‘Root’ password for the server. This means that the Administrator has the unique username and password that enables them to access the core of the machine and although this is not the preferred security, it is acceptable on the assumption that the Administrator is careful where these access details are stored and also controls who has access to them.
The username and password authentication of the Administrator to the system is as strong as the password used and the security of how the password is protected. In the event that a single server’s password is compromised, the rest of the servers on the network remain unaffected. This is a common practice in most organisations and can be considered as an acceptable layer of security, but as AACD™ demonstrates, there is a superior method.
As previously explained, in the central server SSL managed system, passwords are stored at the central location. Access to this central server is most probably protected by another username and password. In this environment, it is therefore easier to gain unauthorized access to the entire network by simply compromising this single, central server. With the central server’s username and password compromised, the entire network is vulnerable. As authentication from the central SSL management server is by username and password, server authentication is undermined in this system’s design.
The DSSA™ [4] software that is installed on each server has a unique and trusted relationship with the CSG™ [6] and the CA [3] that it communicates with. This authentication uses encrypted connections and two factor client Certificate authentication between the DSSA™ and the CSG™ and subsequently the CSG™ and the CA. This military grade security cannot be compromised because each individual server must authenticate to the CSG™.
Before the DSSA™ can function, it must first initiate and successfully complete an authentication process with the CSG™. This authentication uses a Unique ID [UID] Key that is embedded in the accompanying config.txt file for that specific DSSA™. The UID is an encrypted string that cannot be compromised and is issued by the CA for use by the specific DSSA™ in the organization. This UID is in an one-time-only transaction to authenticate the DSSA™ to the CSG™ so that the two devices can exchange the two factor authentication [24] Certificates. This is the third layer of security used to protect the server in the AACD™ system and further improves the overall security of your environment.
[1] Server autonomy is an important issue in the layered security environment. It means that the server is not vulnerable to unnecessary external threats. The server can be protected from such threats by ‘hardening [9]’ the server and preventing unwanted executables from running on it without the permission.
When manually installing an SSL, the server is accessed directly by the Administrator and all executables are only performed after the Root access has been granted directly during a unique session. This is a secure method of installing the SSL Certificate [2], albeit that the process is manual, and the server’s autonomy is maintained.
In the case of SSL Management from a central server, the server is configured to permit external executables to run. This more sinister issue means that the servers on the network must permit executable commands to be sent from one server(s) to another and monitoring or controlling this traffic is very difficult.
This gives rise to the serious security issue that there is the possibility to run unauthorized, external executables. If you can compromise the central server, then all the servers on the network are vulnerable. Combine the ability to run executables with the Root access password and the entire infrastructure is undermined. On the basis of this combination of no autonomy, Root access and the ability to run executables, this method of SSL management should not be considered. ‘Best practice’ should not be allowed to undermine security simply for expedience or convenience.
The DSSA™ [4] software that is installed on any server is specifically designed to harden the server’s autonomy and not to permit any commands or executables to be received or run. All commands and executables come from the DSSA™, so all communication originates from it in an outward direction. No communication can be received by the DSSA™ unless it specifically initiates the communication request/response.
Just as the DSSA™ does not contain the Root password, nor does it have any mechanism to understand any external communication. So the non-existence of Root access adds a layer of security and the inability to receive, process or run executables adds a second layer of security to the server. All communications originate exclusively from the DSSA™ and therefore the server’s autonomy is not only preserved but also improved.
[1] The AACD™ system is the unique SSL Management system used to assist any Certificate Administrator in completely automating the deployment and management of their Certificates. When considering AACD™, it is important to understand that while all of the life cycle issues are automated, security is improved [9] without any disruption or negative impact to your organization.
AACD™ is a simple solution to a simple issue. It treats the issue first as one that must improve security and then improve efficiency by automating processes. Once the security is assured by the AACD™ authentication method (and this is done automatically) then the system begins automating the SSL life cycle of every Certificate in your organization.
To secure the environment and the server(s), the AACD™ system uses a unique concept called ‘The Trust Triangle’. Once established, the Trust Triangle provides the security necessary to automate the Certificate life cycle process within your organization. This patent protected system ensures that only Authorized and Authenticated servers can request and receive Certificates.
For the Trust Triangle to function correctly and securely, the Daemon or Server Side Software™ [DSSA™] [4] must be installed on the SSL Server. This software automatically joins the SSL server to the AACD™ system to form the third component of the Trust Triangle. Once the Trust Triangle is formed, the AACD™ system is activated and automatically renews the SSL Certificates [2] on all of the servers connected to it.
Removing the ‘Human factor’ Factor
Rather than relying on your organization Certificate Administrator(s) to renew Certificates on time, and every the time, AACD™ automates the entire process and removes the human factor too. By automating the process, the human factor that causes SSLs to expire and time lost on manually requesting and installing certificates, or waiting for the CA [3] to deliver the Certificates, are all removed.
As stated, all of this is achieved using highly secure cryptographic technology to ensure that the layered security of your environment is improved and that it remains fully operational without interruption and without undermining its integrity.
[1] The Certificate Authority [CA [3]] is modified to provide the SSL Certificates [2] whenever an authenticated requested is received through the Certificate Services Gateway [CSG™] [6]. The modified CA also provides the Unique Identification [UID] key that is used to authenticate the DSSA™ [4] so that it can join server to the [30]. And the CA is also modified to create a trusted relationship with the CSG™. Otherwise, the CA functions and operates offering all of the services of any typical Trusted CA. The customized Digi-CA™ [31] with AACD™ is an example of a modified Trusted CA.
The Certificate Services Gateway™ [CSG™] acts as the ‘Trusted Third Party’ (a well known concept in the Digital Certificate [10] industry) between your server and the CA Certificate provider. It acts in a unique way to securely authenticate your server to the CA, automatically. Where your Administrator is currently the ‘point of contact’ between the server and the CA, the CSG™ will fill this role once AACD™ is implemented.
The CSG™ uses a Hardware Security Module [HSM] and high grade military encryption and authentication technology are combined within the AACD™ system so that once the DSSA™ software is installed successfully, the Trust Triangle is created automatically and without further intervention of the Administrator.
The default configuration of the CSG™ has an inherent trusted relationship with the CA because it is installed at the CA site. In the larger environment, the CSG™ is installed on your network and a unique connection is made directly with the CA. In either case, the security and integrity of the CA/CSG™ relationship is established before any server is added to the Trust Triangle.
The CSG™ serves two main functions in that it authenticates any device to the CA and can also be used to scan the network for any SSLs installed on it.
[1] Before downloading the DSSA™ software, the web server software (IIS, Apache, etc) is selected and standard contact and organisation details are entered in a web form. The DSSA™ is then downloaded with a Unique ID [UID] Key that is automatically embedded in the accompanying config.txt file (this can be modified, as required, by an experienced Administrator).
This downloaded DSSA™ software complete with its UID/config.txt file is now unique to your organisation and can be installed on the server(s) with the web server software selected during the download process. Once installed, the DSSA™ checks the server, or device, for all the SSLs currently available on the machine and notes the expiration date of each one. If there are no SSLs present, the DSSA™ can receive commands from the server Administrator using the integral interface or command prompt entered directly in the DSSA™ to request whatever new SSL(s) may be required. This completes the installation process for that server.
The active DSSA™ then uses the UID Key and automatically connects to the CSG™ [6] to initiate the two factor authentication [24] Certificate exchange. This causes the UID to be sent to the CSG™ and subsequently to the CA [3] for validation. If the CA recognises the UID, it will have a corresponding legal contact and domain ownership information data set. If the RA Validations Department [21] of the CA has approved the data set, the UID is accepted and the CSG™ is authorised to create the two factor authentication Certificates that will be used to authenticate all communications for the DSSA™ for all future transactions.
Once the two factor authentication Certificates are exchanged, the DSSA™ is securely connected to the Trust Triangle [30] and automation occurs automatically thereafter. With the Trust Triangle established, the DSSA™ automatically manages the complete life cycle of all the Certificates on the server without any further intervention.
Important Note: As stated, the design of the DSSA™ software does not receive commands or prompts from anywhere. In fact, the DSSA™ can only be accessed or communicated with, from within itself using command prompts or the internal interface. This ensures that the security of the server is never compromised and that unauthorised access to a single server has no impact on any other server in the network. Even with multiple installations of the same copy of the DSSA™ software, throughout the same network of servers, there is no logical relationship between these servers and therefore each server remains separate, secure and autonomous. This autonomous design is a central security features of the system and is one of the unique security design principals of the entire AACD™ system.
[1] The AACD™ system is designed to work in any server environment and the DSSA™ [4] software can be used to manage a single server or many hundreds, or even thousands of servers, as required. There are two types of DSSA™ server: one that can connect to the internet, such as a web server for example; or one that cannot, or should not, such as a network server on an intranet.
For the single server with DSSA™ installed, it simply connects to the CSG™ [6] located at the CA [3] Trust Centres [32]" />Trust Centres. This occurs over the internet using an available port on the server that is enabled for DSSA™ communications (part of the configuration and setup [33]). This HTTPS communication is easily established and any intermittent reliability of the connection does not affect the performance of the AACD™ system.
For the multiple server environments, a single DSSA™ download can be configured for all of the machines that use the same web server software. The Administrator simply configures one DSSA™ and installs the same version on every machine. If you have several different types of web server software (IIS, Apache, etc), one DSSA™ is needed for each different web server software in operation.
In the environment where all of the servers have connections to the internet, the DSSA™ will operate exactly the same way as the single server DSSA™ (see sub section 2.6.1). However, most organizations with multiple servers do not have this direct connection for all the server on the network for security reasons. In this type of environment, the AACD™ system solves this issue by moving the CSG™ appliance into your network.
With the CSG™ inside the network, the DSSAs™ is configured to communicate with your network CSG™ and your corporate CSG™ then communicates directly with the CA on the internet. The CSG™ also comes with other powerful features:
DSSA™ Activation Management [34]
SSL Network Scanning [35]
DSSA™ Monitoring [36]
SSL Certificate Statistics [37]
All of these features are components of the CSG™ management interface: the AACD™ Control Centre (see sub section 5.2)
[1] As an additional feature of the CSG™ [6], it has a Certificate Discovery Search Engine™ [CDSE™] that can be enabled or disabled as required. The CDSE™ uses a non-invasive search algorithm that specifically searches on port 80 and port 443 only to determine if any SSL Certificate is present on the server. The heuristic function of the algorithm ranks each step based on the information on these ports in order to make a decision in relation to the presence of the SSL and then displays its details in a .csv list format for further use.
This non-invasive search engine can be ‘invited’ into your network on request and this requires specific security protocols to be followed by the Network Administrator to ensure that permission is granted according to the strictest of security practices.
The most common use of CDSE™ is when the CSG™ is installed inside your network where it poses no threat to the network’s security. The scan is activated internally by your Network Administrator and by virtue of this fact it is conducted in consideration of internal network policies and security. The CDSE™ is supplied as part of the standard installation of the CSG™ and if this capability of the system is not required, it can be disabled easily.
[1] The DSSA™ [4] is autonomous and does not accept any commands or network communications received from outside. Therefore, the only way to configure or modify any DSSA™ is by using the interface or command prompts directly on the software itself.
The DSSA™ must authenticate to the CSG™ [6] every time it wants to communicate with the CA [3] and using the AACD™ Control Centre, the CSG™ can enable/disable this communication and effectively control the behaviour of a specific DSSA™ Server. This simple feature can be valuable when multiple instances of DSSA™ Servers occur on a network.
The intuitive design of the AACD™ Control Centre means that the specific server’s IP Address or Fully Qualified Domain Name [FQDN] appears in a list with a simple radio button that can be checked to enable the DSSA™ communication with the CA or unchecked to disable it.
[1] For the larger organization with hundreds or thousands of servers, the CSG™ [6] can conduct unobtrusive network scanning using the Certificate Discovery Search Engine™ [CDSE™] to determine the location and number of SSLs in the organization. This is an invaluable scanning service that can be used during the initial installation of the CSG™ to get an overall ‘view’ of your organization total SSL requirements and it can also be used to monitor SSL usage on a regular basis.
Depending on your environment, and during the installation of the CSG™ appliance, the CDSE™ service can be configured and enabled to meet the specific security policies of your network. During all scanning sequences, the AACD™ Control Centre will display the status of the specific scans that are running:
If required, the scanning service within the CSG™ can be disabled if it is not required by your organization. Regardless of how you choose to configure the scanning service, the information will be the same for most organizations and will provide results like those in the table below:
DSSA™ Monitoring
The CSG™ [6] also provides statistics using a pie chart to graphically represent the percentage of different SSL Certificates [2] in use in the environment (for this to function correctly, the CDSE™ facility must be enabled). This is valuable, high level, management information that can be used to how many SSL vendors currently supply your organization and the impact if specific vendor relations were to be canceled and replaced with the more dominant vendors.
[1] Another benefit of having the CSG™ [6] inside your network is that you can use the web interface to monitor all of the servers in your environment from the CSG™. The AACD™ Control Centre displays details on the status of each SSL and is colour coded depending on the status of the SSL: Active: CSR Created (and sent to the CA [3]); Awaiting Notification (from the CA to collect the Certificate); or Expired.
[1] Making the decision to implement AACD™ is simply a case of examining the number of servers in your organization and determining whether it makes sense to install the DSSA™ [4] to automate all your SSL life cycles or to continue with the manual installation process that is the current practice.
If automation suits your requirements, then the number of SSLs in your organization and whether all of the server can connect directly to the internet, or not, will decide if the CSG™ [6] must be located inside your organization.
For further commercial advice or assistance in this regard, simple contact an AACD™ specialist using any of the following contact details:
Telephone:
See the AACD™ Flash Presentation [17] that explains the issues and benefits of using the AACD™ system.
[1] The business case for automating the life cycle of the SSLs in your organization should be obvious. And in choosing to implement automation, it must be as secure as your current environment. So expedience must not compromise security.
In order for any product or system to be successfully adopted by any market, it must improve on current practices and must add real benefit. When considering IT security, achieving a balance between: automation; security; and control; is not simple. Yet for the product to succeed, it must do this in a way that is simple to use without undermining (or concealing) security risk.
Before implementing AACD™ in your organization, you should understand the history of the AACD™ Project. This project was commissioned and approved by the Board on the basis that the required Certificate life cycle automation would:
These three principals then became the basis of the Board’s decision to form a ‘Black Project’ Team to work on the development of such a system. As a Black Project, only the Board members and those working directly on the development of the system were permitted to have any knowledge of the project at all. The name assigned to it was ‘The Vesuvius Project’ and, as it happens, it was aptly named after an enormous mountain with a history of volatility. The Vesuvius project was also enormous and volatile too.
The Vesuvius Project began in 2002 with the monumental task of the seemingly simple task of automating SSL and Digital Certificate [10] life cycles. Only if the project could prove it would meet the Board’s original objectives would it be approved for full scale development and publishing.
The seemingly innocuous brief was received with excitement and enthusiasm by the project team that subsequently spent four years before they reached a workable solution. Many ideas were combined, rejected, remodeled, reintroduced, reworked and modified before the result emerged.
[1] The Project Vesuvius approach was to separate the Certificate Discovery component from the rest of the project and create a customized ‘search engine’ capable of spidering any network and returning any, and all, SSL information in list format. The first version of this was available by Q4, 2002.
The second component that would ultimately give the project its name (i.e. Automated & Authenticated Certificate Delivery™) was returned to the Board almost four years later and the project’s Logic was confirmed as follows:
Project Vesuvius for Certificate Life cycle Automation will:
The effect of this is that:
The completed solution also exceeded the initial brief because
Project Vesuvius was renamed AACD™ and was immediately moved into production prior to its release in 2007.
In considering the medium to large IT environment, Administrator and User roles, server grouping, permissions, reporting and report designing, planning, implementation, harden [9] and quality checking are components of the total project. When considering SSL automation, each of these requirements must be examined.
Returning to the AACD™ Logic in sub-section 3.2, the design of the AACD™ system means that, with exception of the Certificate Discovery Search Engine™ [CDSE™] (see sub section 2.5.4), it will have little, or no, impact on your current infrastructure. Also, on the basis that the CDSE™ is an optional addition to the AACD™ system and that it has no impact on your environment, there is no requirement to plan for developing reports, specialist configuration and/or subsequent vulnerability checks on the network either.
[1] There are two categories of server that use SSL Certificates [2] and once your server(s) category is confirmed, then the requirements for implementing AACD™ are minimal. The two categories of server(s) are those that have:
Single-Server with direct/indirect internet connection
Multi-Server with direct/indirect internet connection
And
Single-Server with no direct/indirect internet connection
Multi-Server with no direct/indirect internet connection [38]
Planning for AACD™, where the serve has direct, or indirect internet connection, can be as simple as downloading and installing the DSSA™ [4] software. You should also note that for each version of web server software you use (IIS®, Apache, etc), you need at least one corresponding version of the DSSA™. If this is the extent of your planning, then instead of renewing the server’s existing SSL(s), you simply install the DSSA™ instead.
On the assumption that all the SSL servers on the network can connect to the internet, you may have a Network Operations Centre [NOC] or Security Operations Centre [SOC] in which case they will probably install the DSSA™ software as part of the weekly or monthly maintenance program.
Just like the implementation of AACD™ this planning is simple and the only requirement is to remember that for each version of web server software, a single corresponding version of the DSSA™ is required.
A single DSSA™ can be configured for installation on multiple servers, on multiple networks and in multiple geographic locations within the same organization.
It is rare that a single server will not have direct or indirect internet connection. If however this occurs and you have a single server with no internet connection, the only way that AACD™ can work is if you install the CSG™ [6] appliance. On the basis that this would result in a CSG™ being installed to manage a single server, you should only consider the AACD™ system in very specific and ‘special cases’ because the implementation costs would be prohibitive.
[1] The CSG™ [6] appliance is specifically designed to meet the requirements of the medium to large organization where some, or all, of the SSL servers cannot connect either directly or indirectly to the internet. As explained in sub section 2.5.2, the CSG™ appliance can be installed inside the network and all of the servers can be rerouted through the CSG™ that in turn connects with the CA [3] for issuing and renewing the required SSLs.
Your NOC or SOC will decide on the best location to install the CSG™ appliance(s) and then the config.txt file for the DSSA™ [4] will be configured to direct the DSSA™ to the IP Address where it is located. As part of the weekly or monthly maintenance, servers will have the DSSA™ software installed and will automate the life cycle of all the SSLs on the network without further intervention.
The CSG™ is a 2U, customised Linux® server with an nCipher netHSM 500 PCI card and proprietary Digi-CA™ [6], AACD™ and CSG™ application software installed before hardening [9] the complete appliance. The CSG™ for your environment will be customised by the AACD™ installations team: Digi-CAST2™ and is shipped to you ready for rack mounting.
Once mounted in its rack with the appropriate network number of network cards installed, maintenance and upgrade requirements is minimal.
Important Note: A CSG™ appliance is required for each separate geographic location within the same organisation unless these networks can be connected securely to each other and ultimately to a single CSG™.
[1] On the basis that there are some complicated and less secure systems and other free scripts available in the market you will discover the following combination of requirements:
Moreover, once the above implementations are completed, regular testing should be added to the weekly or monthly internal procedures to ensure the systems reliability and security. As stated throughout this online manual, the AACD™ system was specifically designed to introduce Certificate life cycle automation without introducing new security risks or increasing maintenance demands within the organisation.
AACD™ does not require any of the above procedures or maintenance implementations.
Currently, there are two principal versions of the DSSA™ software:
And on the basis that these two web server software account for 92.6%+ of the worlds web servers (the next highest being Zeus® with a declining 0.4%), either of these versions of the DSSA™ software should enable you to automate almost your entire environment. There is other web server software specific to your environment that you may wish to consider:
As all of these use Apache, depending on the specific software release, version and hardware you are operating, DSSA™ can be modified to meet specific requirements. Another DSSA™ software, pending release is for use with:
Important Note: The DSSA™ modules and libraries are extensive and further development of any requirement for a specific web server software can now be delivered in 8 weeks or less. For further details, contact a DSSA™ specialist for further advice.
True to the original project brief from 2002 (see sub section 3.1), choosing and implementing AACD™ couldn’t be easier. Match the DSSA™ [4] software version with the corresponding web server software and install it on all your servers.
If you have multiple servers with no connection to the internet, then you will also need to purchase the CSG™ [6] appliance. Installing the CSG™ appliance and testing should take the same amount of time as a single server within a typical network.
Server SSL Certificate renewals can be switched on, or off, as required either directly at the DSSA™ or, if you have the CSG™, this can be controlled from the AACD™ Control Centre interface.
[1] Currently, there are two principal versions of the DSSA™ software:
And there are other ‘blends’ of Apache that the DSSA™ will work with, subject to modification by the AACD™ team of engineers: Digi-CAST2™. So the DSSA™ Apache web server software can be modified to meet the specific appliance or server in your environment, for example:
Important Note: The DSSA™ modules and libraries are extensive and further development of any requirement for a specific web server software can now be delivered in 8 weeks or less. For further details, contact a DSSA™ specialist for further advice.
Before installing the DSSA™ it must be downloaded first. The download can be from any official, or unofficial, website. This capability to offer unrestricted download of this highly secure software is integral to its design, because without the correct UID Key, the software is useless. There are two principal ways to get your version of the software:
DSSA™ Validation Download [39]
DSSA™ Open Download [40]
[1] The Validation Download is the simplest method of downloading and activating the DSSA™ software. This is because the Validation Download initiates the Validation of your organization and the software download by completing a single set of three web forms. These forms are explained in the following sub sections:
Validation Request Initiation Form
Software Selection & Configuration [41]
Account Creation & Payment Options [42]
All forms are intuitively designed and every field has a help button opposite so that completing this form should be straightforward. The information entered in this form is used by the Validations Department to Validate & Verify [21] the integrity of your organization in accordance with WebTrust ‘Best Practice’.
The importance of correctly completing this form cannot be over stated, so to enable the smooth implementation of your AACD™ system, take the necessary time to complete this form accurately.
There are three sections to the Step 1 Form when downloading the DSSA™ software:
Each of these sections separates the legal information or ‘Organizational Information’ required to correctly validate your organization; from the technical person in your organization that will provide the ‘Administrative Information’ and act as the point of contact for all IT and technical matters; and separates each of these roles from the ‘Billing Information’ required so that all accounting and financial matters can be directed to the correct person also.
If the IT Administrator and the Billing Contact in your organization are all different roles with different personnel, then you must expand this form and supply the Administrative Information and Billing Information as required.
Important Note: As stated, if the Administrative or Billing contact information are different from the Organizational information provided in the upper section of the AACD™ - Order Form Step 1 of 3, you must click the ‘different ?’ radio button underneath the respective section and complete this section of the form also.
Once all sections of the 'AACD™ - Order Form Step 1 of 3' form are completed you can submit this form and move to the second form: AACD™ - Order Form Step 2 of 3, the Software Selection & Configuration form.
[1] Under the heading ‘Domain names that your SSL Certificates [2] will use’ you simply enter the Fully Qualified Domain Names [FQDN] (e.g. domain.com) or IP Addresses (e.g. (1.0.0.127) that currently have SSLs. Simply, (separated by Enter/Return key on your keyboard) that your SSL certificates will use.
Type all the domain names:
Under the heading ‘Select the server software you use’ the drop down dialog will display the following list of web server software:
MULTIPLE
The first option on this dialog is to select MULTIPLE. By selecting this option, two new drop down dialogs will appear, so that you can request several different versions of the DSSA™ software in a single download.
For example, you may have 100 servers where 70 are using Apache web server software, 20 use IIS and the rest are a mixture of Websphere, Zeus, etc. In this instance, you require four different versions of the DSSA™, one version for each of the web server software in your environment. Therefore, when making the first choice in the drop down dialog, you should select MULTIPLE. The following two drop down dialogs will appear:
The two new fields that appear are Web Server Software 1 and Web Server Software 2. From these two new drop down dialogs you can now enter two server software within your organization. As you have three or more, simply enter MULTIPLE in the Web Server Software 1 drop down dialog and the screen will change again:
Using the CTRL button and your mouse, you can make multiple selections of the web server software in your organization.
If the web server software that you use is not available in the drop down dialog, then simply select ‘Other’ at the end of the list and this will enable a field where you can manually enter the details:
[1] Under the heading ‘Current SSL Vendor’ you can select the current vendor of your SSLs from the list provided:
If your current SSL vendor is not listed, select ‘Other’ and enter the vendors name manually.
Under the heading ‘Number of SSL Certificates [2]’ simply enter the total number of SSL Certificates you use each year (don’t worry about entering the precise figure, an estimate will suffice).
Under the heading ‘Type of Certificates’ enter the most commonly used type of Certificate in your organisation, for example 2-Year EV-SSL or 1-Year SSL (i.e. not EV). Some organizations prefer to use 2-Year Certificates, other organizations have a policy that they use only 1-Year Certificates and it is unlikely that your organization is using EV SSL throughout the IT environment, but if this is the case, then make this selection.
In every organization, there are exceptions where some severs do not follow the organization policy. This is not important when ordering your DSSA™ as the software is completely flexible and can be modified to meet each individual SSL requirement.
In the drop down dialog, select the option that is most common for your SSL Certificate:
If none of the options in the drop down dialog reflect the most commonly used SSL in your organization, then select ‘Other’ and enter the description manually into the field that will appear.
[1] Under the heading ‘Server Category’, there are only two options to choose from:
If your server(s) has a direct/indirect internet connection to the internet, select ‘internet connection’ otherwise select ‘no internet connection’. To understand this selection, re-read sub section 3.4.
Under the heading ‘DSSA™ requirement’, there are only two options to choose from:
This is a simple but important selection because it will determine if the DSSA™ software download will function on only a single server or if it will be required to function on many servers. If you only intend using DSSA™ on a single server, regardless of how many virtual web servers are on that server or how many SSLs it will use, then select ‘Single-Server’.
If however, you may choose to install the DSSA™ on more than one server, you must select the ‘Multi-Server’ option for the software to function correctly.
[1] Depending on the selection made in ‘Current SSL Vendor’ in Form 2 of 3 (see sub section 4.1.2.3), the DSSA™ will either be a chargeable item or if you are purchasing Digi-SSL™ [43] Certificates, the DSSA™ software is supplied ‘free of charge’.
Important Note: In the event that your current vendor does not support DSSA™, with their co-operation, we can implement DSSA™ for you but this may take some time. Alternatively, you can opt to purchase Digi-SSL™.
Unless you already have an account with Digi-Sign or wish to request an account because the value of the order is more than you wish to pay by credit card (see sub section 4.1.3.2), the default option is to pay by credit card.
This is a typical credit card payment form with the usual fields you would expect to see on this type of form. Due to EU Tax Regulations, when selecting your country, if you select a country that is a member of the EU, an additional field will appear where you must enter a valid EU VAT number.
If you already have an account with Digi-Sign or wish to request an account because the value of the order is more than you wish to pay by credit card, then select the ‘Pay by Purchase Order’ option on the default form. This will then cause the form to change as follows:
Simply enter a valid Purchase Order number for your organisation and if your country is in the EU, enter your VAT number to complete the process.
[1] Once the three forms are completed, the DSSA™ software is downloaded to your PC in a .zip archive folder.
Open this .zip file and the following files will be visible:
There are three files contained in the .zip folder and these are explained in the following sub sections:
[1] The AACD™ system is specifically designed so that the DSSA™ software component can be distributed freely and uninhibited on the internet without breach of copyright or legal restrictions. This means that you can distribute your copy of the DSSA™ software without any concerns in relation to security or royalty obligations.
As explained the DSSA™ [4] software cannot function without its UID Key [4]. If a user attempts to use the UID Key from one organisation in another, warning systems at the Modified CA [3] Trust Centres [32] will automatically disconnect the unauthorised and invalidated attempt to use a duplicate UID Key. Therefore, copying the UID Key serves no benefit to unauthorised users and similarly, the distribution of the DSSA™ on its own is secure.
If you receive a copy of DSSA™ or download it from the many open download sites on the internet, three forms for the DSSA™ Open Download is exactly the same as for the DSSA™ Validation Download except that when you complete the final form, you only receive a single config.txt file instead of the .zip file.
These forms are explained in the following sub sections:
[1] Once you have received all three files as a result of completing either the DSSA™ Validation Download [39] or the DSSA™ Open Download [40] you should now have three files. And these are further explained below:
This is the actual software executable that will be installed on the server that will join the AACD™ system.
The most up to date digital version of this AACD™ manual is included in the download file for reference.
This is the Configuration File that enables the server with the DSSA™ to be validated and authenticated into the AACD™ system. Where the DSSA™ software is the same for every user, the config.txt file is unique. Using any text editor, open the config.txt file and you will see information similar to the following (this sample is for windows):
<?xml version="1.0"?>
UID=UmFuZG9tSVYDu%2BN%2ByWoR7elsxiBodOURl9xFVB53c7ICZ0kxNbaWluUa3wE22O5a
The UID Key is highlighted in the above sample config.txt file and is an encrypted key that cannot be tampered with. Any attempts to re-engineer this key by unauthorised users will server no purpose and cannot be used to undermine the integrity of the AACD™ system.
Important Note: Before modifying any information in this config.txt file, contact the AACD™ Team for advice. Incorrect changes to this file will result in the DSSA™ malfunctioning.
[1] The specific installation instructions for each of the different versions of DSSA™ are supplied in the .zip file that is supplied in at the end of the Validations Download process.
Once configured, the DSSA™ installation on Apache uses simple command prompts, for example:
Change working directory:
Using tar, unpack files from the archive:
tar --gunzip -xvf dssa-1.1.tar.gz
Change working directory:
cd /usr/local/src/dssa-1.1
Prepare the installation:
./configure
make
make check
make install
Once the above sequence of commands is successfully completed and the software is installed without error, the command prompts required to activate the software are input to conclude the process (see sub section 4.5).
[1] Installing DSSA™ for IIS uses a familiar seven step Windows® wizard and the config.txt file can be modified directly using the wizard dialog rather than editing it manually using a text editor. The UID Key also appears in the wizard dialog and should not be tampered with.
Important Note: Before modifying any information in this wizard dialog, contact the AACD™ Team for advice. Incorrect changes to this text entry will result in the DSSA™ malfunctioning.
Wizard Step 1
Wizard Step 2
Wizard Step 3
Wizard Step 4
Wizard Step 5
Wizard Step 6
Wizard Step 7
Once the wizard is successfully completed and the software is installed without error, the command prompts required to activate the software are input to conclude the process (see sub section 4.5).
If the following error screen appears, restart the IIS web server and restart the Wizard.
[1] The specific activation instructions for each of the different versions of DSSA™ are supplied in the .zip file that is supplied in at the end of the Validations Download process. This online manual gives you the activation procedures for the two main DSSA™ software and these are explained in the following sub sections:
With the DSSA™ installation on Apache completed, it is initialized and activated using the following command prompts:
cd /usr/local/dssa/bin
./dssa -req -new -config-section [virtual_host_name:port] -cn [www.domain.com]
./dssa ./dssa -req -renew -config-section [virtual_host_name:port]
[1] With the DSSA™ installation on IIS completed, it is initialized and activated using the DSSA™ software interface [48] to read further instructions on IIS configuration settings.
[1] All instructions to the DSSA™ in the Linux® environment use command prompts. Due to the simplistic functions of the DSSA™, once installed and initialised, there are very few commands that can be executed.
Important note: There is no command prompt to renew an existing SSL on the server. DSSA™ automatically detects all existing SSLs on the server and automatically renews these unless instructed to the contrary. Therefore, by installing DSSA™ you must ensure that you want all the SSLs on the system to be renewed automatically. To disable a specific SSL, use the ‘Disable’ command (see sub section 5.1.1.3
This limited set of commands not only makes the DSSA™ simple to use, it also make the application more secure. Any attempt to send unrecognised or incorrectly constructed command prompts are simply rejected by the DSSA™. The following are the correct command prompt instructions for the main DSSA™ functions:
[1] All instructions to the DSSA™ in the Microsoft® environment use a Graphical User Interface [GUI]. Dues to the simplistic functions of the DSSA™, once installed and initialized, there are very few commands that can be executed.
As stated, this limited set of commands not only makes the DSSA™ simple to use, it also make the application more secure. The following sub sections provide the instructions for completing the configuration of the DSSA™ and the other features of the GUI.
Once installed, the DSSA™ GUI is used to configure the server. This is a one-time-only configuration that is activated using the Tools -> Configure option from the menu. The DSSA™ will run a routine and when completed will display all the SSL Certificates [2] present on the server. The configuration is now complete.
To view all of the SSLs installed on the server, simply open the DSSA™. Once open, all of the Certificates on the machine are displayed in the familiar IIS Certificate Store format. The GUI will display a list of all the SSLs on the system, regardless of their life cycle status (i.e. currently valid and in date, expired and out of date, revoked, etc).
Important Note: The DSSA™ will only automatically renew SSLs that are valid at the exact time that the DSSA™ is installed and initialized. To enable the DSSA™ to replace an expired SSL with a new SSL, use the ‘Renew’ command prompt (see sub section 5.1.1.5).
To add a new SSL to the server, select File -> New from the GUI Menu and enter the hostname of the SSL that you want to add to the server.
To disable the renewal of an existing SSL on the server, select File -> Delete from the GUI Menu and enter the hostname of the SSL that you want to add to the server.
To enable the renewal of an existing SSL on the server that was previously disabled or had expired prior to the installation of the DSSA™, select File -> Enable from the GUI Menu and enter the hostname of the SSL that you want to renew immediately.
To enable the renewal of an existing SSL on the server immediately (i.e. force the immediate renewal), select File -> Renew from the GUI Menu and enter the hostname of the SSL that you want to renew immediately
[1] Throughout this online manual, it is explained that layered and improved security [9] are central to the AACD™ design and to ‘harden [9]’ security the DSSA™ does not receive any commands other than direct inputs using the IIS GUI or command prompts, in the case of Apache. This is a security feature of the DSSA™ designed specifically to improve your organizations overall security policies and practices.
As explained in the multi-server environment [49] where many servers cannot have direct/indirect connection to the internet, then the CSG™ [6] appliance must be placed inside your network environment. Once installed, the CSG™ acts as an authentication gateway only. This means that unauthorized access to the CSG™ does not impact on the security of your environment and again this is a security feature of the AACD™ system.
The CSG™ designed specifically to improve your organizations overall security policies and practices. As an authentication gateway, the CSG™ can simply disable the authentication of a specific DSSA™ request and this means that central control of the SSLs on your network is possible without the need to centrally store sensitive server information that would undermine your networks security.
As is the case with the security design of the DSSA™, the AACD™ Control Centre that is accessed on the CSG™ has only a limited set of commands that makes simple to use and also make the your network more secure. The following sub sections provide the instructions for using the AACD™ Control Centre.
[1] As explained the DSSA™ is autonomous [4] and does not accept any commands or network communications received from outside. Therefore, the only way to configure or modify any DSSA™ is by using the interface [48] or command prompts [51] directly on the software itself.
The DSSA™ must authenticate to the CSG™ [6] every time it wants to communicate with the CA [3] and using the AACD™ Control Centre, the CSG™ can enable/disable this communication and effectively control the behaviour of a specific DSSA™ Server. This simple feature can be valuable when multiple instances of DSSA™ Servers occur on a network.
The intuitive design of the AACD™ Control Centre means that the specific server’s IP Address or hostname appears in list format with the option to enable or disable it using the corresponding radio button. There are three functions that can be enabled/disabled using this section of the AACD™ Control Centre interface:
[1] The CSG™ [6] can conduct unobtrusive network scanning to determine the location and number of SSLs in the organisation. This is an invaluable scanning service that can be used during the initial installation of the CSG™ to get an overall ‘view’ of your organisation’s total SSL requirements and it can also be used to monitor SSL usage on a regular basis.
Depending on your environment, and during the installation of the CSG™ appliance, the Certificate Discovery Search Engine™ [CDSE™] service can be configured and enabled to meet the specific security policies of your network. During all scanning sequences, the AACD™ Control Centre will display the status of the specific scans that are running:
If required, the scanning service within the CSG™ can be disabled if it is not required by your organisation. Regardless of how you choose to configure the scanning service, the information will be the same for most organisations and will provide results like those in the table below:
[1] The CSG™ [6] also provides statistics using a pie chart to graphically represent the percentage of different SSL Certificates [2] in use in the environment (for this to function correctly, the SSL Network Scanning facility must be enabled). This is valuable, high level, management information that can be used to how many SSL vendors currently supply your organisation and the impact if specific vendor relations were to be cancelled and replaced with the more dominant vendors.
[1] Another benefit of having the CSG™ [6] inside your network is that you can use the web interface to monitor all of the servers in your environment from the CSG™.
The AACD™ Control Centre displays details on the status of each SSL and is colour coded depending on the status of the SSL.
This status note indicates that the specific hostname has an SSL that is under management and that the DSSA™ [4] has already generated the CSR and send it to the CA requesting a new SSL, in advance of the expiry date of the current active SSL.
This status note indicates CSR has been successfully transmitted to, and accepted by, the CA [3] and that the DSSA™ is periodically checking with the CA so that once the CA issues the SSL, the DSSA™ can collect it.
This indicates that the SSL is not under management by the DSSA™ and has been allowed to expire by the Administrator that was manually managing it.
Important Note: This list does not provide a list of all the SSLs on your network, it is only for notifying you of SSLs that are at critical points in their life cycle. To see all the SSLs on your network, use the SSL Network scanning reports (see sub section Error! Reference source not found.)
[1] This section provides technical data on the DSSA™ [4], CSG™ [6], the modified CA [3]: Digi-CA™ [6] and the HSM, operating system and other technical data used in the creation of the total AACD™ environment and is provided for reference purposes only.
The Digi-CA™ System software suite is a multi application component based PKI [53] system for managing cryptographic keys, Digital [X.509] Certificates and supplemental PKI related services.
Each application component provides a series of defined functionalities to other PKI [53] application components of the system, as well as to administering and operating parties, and to end entities, to whom Certificates are issued. This system is built with the following modules:
All Digi-CA™ [31] components providing core functionalities were developed using C programming language and the software operates under Unix/Linux operating system environment, which has proven to be a solid, reliable – and if not the best - platform family choice for server side applications.
Diagram below illustrates the overall logical and high level hardware architecture design of a complex PKI infrastructure that Digi-CA™ [31] can be deployed in. This includes multi-server based system component distribution, replication and failover of various PKI services and load balancing.
Whilst Digi-CA™ software can meet most complex requirements, in many scenarios it is often required to operate all PKI related services on a single dedicated server hardware. Digi-CA™ can easily meet this requirement and the diagram below illustrates overall logical and high level hardware architecture design of the basic infrastructure utilizing a single server to operate all Digi-CA™ PKI services. This unique feature of Digi-CA™ software suite provides not only a flexible range of possible configuration variations but allows organisations to slowly build their own PKI infrastructure from a very small environment, thus carefully control their expenditure related to purchasing and maintenance of hardware devices.
Digi-CA™ PKI System provides a wide range of PKI related functionalities and introduces a variety of services and features including:
[1] Number of certificates: 200 up to 200,000,000
Production speed: Without HSM up to 5,000 1024-bits Digi-IDs™/hour
With HSM up to 10,000 1024-bits Digi-IDs™/hour
Key length: Root and Sub-CA [3] 9196-1024 bits
Digi-IDs™ 1024-2048 bits
Symmetric Keys 56 to 256 bits
Certificate validity: Root CA 1 to 25 years
Sub-CA 1 to 10 years
End Entity 1 to 10 years (as per Certificate Policy)
Key storage: Root CA Key can be stored off-line, in an encrypted format, within the boundary of an HSM device and protected by several separate Operator Cards that usually are stored securely in multiple offsite safe locations. Other keys, such as Subordinate CA, can also be stored within a boundary of an HSM device and regularly used by the Digi-CA™ [31] PKI [53] System on a day to day basis. Access to these keys can be also protected with multiple Operator cards.
Cryptographic Ciphers: AES, Blowfish, CAST5, DES, 3DES, IDEA, RC2, RC4, RC5 and RSA
Signature Algorithms: MD2, MD4, MD5, MDC2, SHA1 (DSSI) and RIPEMD-160
Entropy: 2127
[1] The CSG™ [6] communicates transparently with the Digi-CA™ [31] Certificate Authority" />Digi-CA™ system using the API provided. Currently, the CSG™ is interacts with the Digi-CA™ PKI [53] System only using this defined API as follows:
[1] The CSG™ [6] is able to allow registration and management of the DSSA™ [4] software clients. The DSSA™ registration process is defined as follows:
[1] The CSG™ acts as a gateway between the DSSA™ [4] client and the Digi-CA™ [6] System, thus on top of the ability to receive requests from DSSA™ clients, it is able to communicate with the Digi-CA™ System during the same connection session.
There are various development approaches to this architecture and the AACD™ developers have various different recommendations. The current approach uses an Apache 2.x web server and builds an Apache C module that handles all requests from the DSSA™ clients.
To act as a client when communicating with the Digi-CA™ System, the CSG™ Apache module utilizes a cURL C API that provides the mechanisms for secure SSL/TLS communications and thus allows the CSG™ module to receive requests from the DSSA™ clients, communicate with the Digi-CA™ System and respond to DSSA™ clients within a single communication session.
The CSG™ has a web based interface on top of the SSH operating system interface to allow the administrator to manage the CSG™ configuration and the permission/denial of DSSA™ clients (remember that every DSSA™ is autonomous, see sub section 2.5.3). The panel provides the following functionalities:
The interface uses the PHP scripting language along with an Apache web server for hosting the DSSA™ web based panel application. In addition the AACD™ has a variety of C extended OpenSSL PKI [53] cryptographic functions for the PHP language that control and manage a typical basic PKI environment, for which CSG™ is a perfect target.
[1] The CSG™ uses the high security, highly scalable, large capacity, resilient nCipher Security World HSM 500 that is FIPS certified and offers the security and flexibility required by the AACD™ system.
The Secure Execution Engine Code within the FIPS hardware offers the highest integrity and protection using nCipher Trusted Computing Environment that protects application software as it is executed. Keys can only be used by signed SEE code that runs within the physical FIPS boundary. SEE secures utilization of keys in a FIPS Approved HSM and removes the risk of attack on the host machine.
The HSM uses the ‘impath’ protocol, a stronger development of existing protocols like SSL that ensure encryption of the host-HSM link and enable strong mutual authentication between systems.
The nCipher have more FIPS certificates than any other HSM vendor and nCipher ensure all versions of the CSG™ HSM receive separate FIPS certification [56], ensuring that each HSM component used is FIPS validated.
[1] Developed using C programming language and operates under Windows®, UNIX and Linux® operating system environments.
Links:
[1] https://www.digi-sign.com/downloads/download.php?id=aacd-digi-ssl-pdf
[2] http://www2.digi-sign.com/ssl+certificate
[3] http://www2.digi-sign.com/certificate+authority
[4] http://www2.digi-sign.com/aacd/daemon+server+side+application
[5] http://www2.digi-sign.com/aacd/explained
[6] http://www2.digi-sign.com/aacd/certificate+service+gateway
[7] http://www2.digi-sign.com/aacd/certificate+services+gateway
[8] http://www2.digi-sign.com/aacd/certificate+discovery+search+engine
[9] http://www2.digi-sign.com/aacd/security
[10] http://www2.digi-sign.com/digital+certificate
[11] http://www2.digi-sign.com/aacd/understanding+ssl
[12] http://www2.digi-sign.com/aacd/choices
[13] http://www2.digi-sign.com/aacd/installation+operation
[14] http://www2.digi-sign.com/aacd/control+centre
[15] http://www2.digi-sign.com/aacd/dssa/technical+data
[16] http://www2.digi-sign.com/digi-ssl/explained
[17] http://www2.digi-sign.com/demos/aacd
[18] http://www2.digi-sign.com/policies/refunds
[19] http://www2.digi-sign.com/en/contact
[20] mailto:aacd@digi-sign.com
[21] http://www2.digi-sign.com/validations
[22] http://www2.digi-sign.com/electronic+identification
[23] http://www2.digi-sign.com/e+passport
[24] http://www2.digi-sign.com/two+factor+authentication
[25] http://www2.digi-sign.com/download/digi-ca-manual
[26] http://www2.digi-sign.com/support/digi-ssl/generate+csr
[27] http://www2.digi-sign.com/aacd/password+protection
[28] http://www2.digi-sign.com/aacd/server+autonomy
[29] http://www2.digi-sign.com/aacd/server+authentication
[30] http://www2.digi-sign.com/aacd/trust+triangle
[31] http://www2.digi-sign.com/digi-ca
[32] http://www2.digi-sign.com/trust+centre
[33] http://www2.digi-sign.com/aacd/configuration
[34] http://www2.digi-sign.com/aacd/dssa/activation+management
[35] http://www2.digi-sign.com/aacd/ssl+network+scanning
[36] http://www2.digi-sign.com/aacd/dssa/monitoring
[37] http://www2.digi-sign.com/aacd/ssl+certificate+statistics
[38] http://www2.digi-sign.com/aacd/advanced+requirementss
[39] http://www2.digi-sign.com/aacd/dssa/download
[40] http://www2.digi-sign.com/aacd/dssa/open+download
[41] http://www2.digi-sign.com/aacd/dssa/download+form2
[42] http://www2.digi-sign.com/aacd/dssa/download+form3
[43] http://www2.digi-sign.com/digi-ssl
[44] http://www2.digi-sign.com/aacd/dssa/software
[45] http://www2.digi-sign.com/aacd/dssa/manual
[46] http://www2.digi-sign.com/aacd/dssa/config+file
[47] http://www2.digi-sign.com/aacd/dssa/download#form1
[48] http://www2.digi-sign.com/aacd/dssa/iis+instructions
[49] http://www2.digi-sign.com/aacd/capabilities
[50] http://www2.digi-sign.com/aacd/ssl+certificate+monitoring
[51] http://www2.digi-sign.com/aacd/dssa/apache+instructions
[52] http://www2.digi-sign.com/aacd/aacd/dssa/apache+instructions#important
[53] http://www2.digi-sign.com/public+key+infrastructure
[54] http://www2.digi-sign.com/digi-ca/administrator/online+certificate+status+protocol
[55] http://www2.digi-sign.com/digi-ca/administrator/time+stamp
[56] http://www2.digi-sign.com/compliance/introduction
[57] http://www2.digi-sign.com/digi-access