 |
|
|
UniCERT is Baltimore Technologies� flagship product. Using X.509v3 digital certificates, UniCERT provides key management, authentication and non-repudiation facilities for services such as secure e-mail, Internet commerce, secure Web banking, on-line trading and Virtual Private Networks (VPN). The architecture of UniCERT has been designed to be as flexible as possible in order to help it fit a wide range of business and legislatory requirements. The result is a modular structure that allows new components to be individually added, modified, upgraded or removed as the organisation needs evolve. Separate components can be run on the same machine, or can be placed on separate machines to reduce bottlenecks and allow distribution of workload. All modules communicate either through the underlying Oracle database or via secured (i.e. PKIX CMP) TCP/IP connections. UniCERT Certification Authority The Certification Authority (CA) module generates and signs certificates and Certificate Revocation Lists (CRLs), and is the nucleus of a PKI. All trust within the infrastructure depends upon the CA's signature. The CA operates according to its own flexible operational policy, which is controlled by the Certificate Authority Operator (CAO). Responsibilities include:
UniCERT includes various features to support revocation, including:
UniCERT Certificate Authority Operator The Certificate Authority Operator (CAO) module is the �security officer� of the PKI. The CAO controls all of the administration functions and grants privileges to other UniCERT modules and operators. There can be multiple CAOs, each with diminished rights, if distributed control is required. Responsibilities include:
UniCERT Certificate Status Server The Certificate Status Server (CSS) provides real-time certificate status information to the other UniCERT components. The CSS acts as a server listening for network connections. When a connection is established, the CSS checks for Online Certificate Status Protocol (OCSP) requests. The CSS responds to OCSP request messages by sending OCSP response messages containing the status of each certificate listed in the request. OCSP is a well-defined ASN.1 protocol that provides a message format to request the status of a certificate, and a message format to respond to such a request. The CA certificate typically needs to be made as public as possible � end-users must be able to download the CA certificate and manually trust it, for example, before they can take advantage of the services offered by the PKI. The CA certificate within UniCERT can be exported in a variety of different formats, and is included in PKCS#12 and PKCS#7 responses to end-users. If an X.500 or LDAP directory is being utilised then the certificate can be published to the directory using the Publisher. The use of a directory in conjunction with UniCERT is optional, but adds considerable functionality. In order to encrypt messages it is necessary to have the recipient�s certificate, and in order to verify a signature one must have access to the signer�s certificate. For these two reasons it is common to store certificates and revocation information (CRLs) in a directory. This directory is made accessible to the user group, and all publishing is handled by the UniCERT Publisher. This is standards based and can be configured to use the Lightweight Directory Access Protocol (LDAP V3). The Publisher handles all the publishing requirements of the CA, including the ability to publish to a wide range of different directories (including Microsoft�s Active directory) and OCSP responders, and to be able to publish to multiple directories. It supports flexible publishing schemas, and has the ability to only publish certain types of certificates and CRL/ARLs. UniCERT also allows certificates and CRLs to be published to disk, opening up possibilities for custom publication mechanisms to be implemented outside of the CA if required. Responsibilities include:
UniCERT Registration Authority The Registration Authority (RA) acts as a router between RA Operators (WebRAOs), Protocol handlers and the CA. RAs divide the PKI into operational domains. Each operational domain is a separate structure linked to the CA, yet intra-domain confidentiality is maintained at all times. The RA obeys its own operational policy, which is maintained centrally.
Responsibilities include:
The WebRAO can authorise certification and revocation requests that have been sent by the Protocol Handlers, or via other WebRAOs. It can also handle face to face registrations. The WebRAOs belong to one or a number of Authorisation Groups, and can only process requests associated with specific registration policies that have been assigned to their Authorisation Groups by the CAOs. Responsibilities include:
The RA eXchange functions as a gateway for remote requests from the protocol handlers and the WebRAO. Responsibilities include:
The Protocol Handlers (PH) are an extensible set of request handlers, that handle certification requests using such protocols as Web, e-mail, Cisco SCEP and PKIX CMP. The Protocol Handlers take care of the complexities of each protocol, and pass the registration (or revocation) requests into the RA for onward processing. They also return the resulting certificates. Responsibilities include:
The UniCERT Token Manager can be used to manage multiple PKCS#11 devices and initialise and administer the tokens or smart cards that the hardware device uses. It is possible to change the tokens� PINs, as well as administer the objects stored on tokens or smart cards. The Token Manager is also used to create crypto profiles. UniCERT v5.0 uses crypto profiles to store the configuration information required to start UniCERT services. This configuration information can include details of the location of the PSE file, if the PSE is split, and details of any devices used. Each application has its own crypto profile. Other modules are also available:
The underlying database for UniCERT is Oracle 8.1.7, and UniCERT makes use of Oracle features that allow for multiple million record tables to be created, thus enabling UniCERT to handle millions of certificates. There is no theoretical limit on how big a UniCERT-based PKI may become � the number of certificates that can be managed is purely dependent on the design of the PKI and the choice of hardware. Each of the UniCERT components (e.g. CAO, CA etc) which has an Oracle connection requires an Oracle client licence. Baltimore bundles Oracle with the UniCERT starter kit with enough licences to install a basic PKI, and can resell additional Oracle licences as required. Baltimore also interoperates with a number of third party directory servers, since the UniCERT package does not include one. The directory server is only necessary if it is required to publish certificates and CRL�s for LDAP clients, however � all certificate and CRL data is also stored in the Oracle database. As UniCERT employs secure, encrypted communications between components, it is possible to configure it for intranet or Internet usage. The UniCERT components � such as the CA, RA, and so on � can be run on separate computers or together on a single system. UniCERT V5 is undergoing Common Criteria EAL4 certification (UniCERT V3 was evaluated to ITSEC E3). Note that with the release of Version 5, both Unix and Windows platforms are supported for all modules except the CAO. Installation is a lengthy process, but relatively uncomplicated. Even the required interaction with Oracle (to create user accounts for components such as the CA, RA and Publisher) has been simplified in the latest release thanks to the introduction of the Database Wizard, which provides an easy way to create an Oracle user account and its underlying database structure. Once Oracle has been installed, the installation of the UniCERT components is very straightforward. The only blight on the installation as tested was the requirement for a DOS box running the Java-based Tomcat server, which handles the Web requests for the WebRAO and Web Handler components. Apache, iPlanet or IIS with suitable servlet managers can all be used instead of Tomcat. For any serious PKI implementations, the optional Key Archive Server should be installed too (available separately), and the root CA keys should be protected by Hardware Security Modules (HSM). If a HSM is used, this must be installed prior to UniCERT. Baltimore recommends that the CA be installed on a separate machine and physically secured to prevent access by unauthorised users. All the main components run as native NT services on the Windows platform (or as daemons under Unix), and the administrator can choose between having the services start automatically whenever the machine is booted (not recommended in a production environment) or starting them manually. �Crypto profiles� are used to store configuration information required to start services or log onto UniCERT applications. This configuration information includes details of the location of the PSE file (and whether it is stored in a file on disk, or in a hardware token), if the PSE is split, and details of any cryptographic devices used. A new utility, the UniCERT Service Manager, can be used to install and run multiple UniCERT services on a single computer. The Service Manager provides a useful graphical interface allowing the administrator to add service instances and configure new service types, such as:
When a service is installed, the Service Manager automatically adds it to the registry, and it is also possible to configure certain service properties, such as service name and start-up mode. The ability to clone CAs and RAs enables administrators to continually extend the capacity of a single CA/RA as required. As the name suggests, clones are exact replicas using the same database, same certificate and same key pair (i.e. this is not the same as simply supporting multiple CAs, each of which would require its own root key pair). The resulting implementation provides higher performance (through rudimentary load balancing) and high availability (through automatic fail over of cloned components). Cloning also enables organisations to cost-effectively run two �parallel� systems in separate locations. Because both systems are always running in parallel, should a system fail in one location, the other system automatically picks up the work without the need for manual intervention. In essence, this means that the parallel system can provide both back-up and disaster recovery capabilities. Once installed, it is necessary to initialise the CA configuration, during which a key pair is generated for the CA itself and the CA Officer (CAO), and a CA registration policy is completed. The CA registration policy specifies such things as the Distinguished Name, key pair size and algorithm, key pair usage, certificate, CRL and directory options, and so on. Key pairs can be generated in software or on a token/HSM (Hardware Security Module). Automatic certificate rollover for the CA is not supported in the current version (planned for a future release). The resulting Personal Secure Environment (PSE) file holds the CA�s certificate and key information. The PSE can be stored on disk or on a PKCS#11 smartcard/token. When key pairs are generated in the software, the PSE contains both the key pairs and the certificates. It is possible to have the CA's PSE file split into multiple components and protected by more than one user's pass phrase. In this way, the responsibility for creating or running the CA(s) is shared among two or more trusted security officers. One person cannot load the PSE if he knows only his own pass phrase and the PSE has been saved as individual components, each protected by a different person's pass phrase. Once the initialisation process has been completed (it needs doing only once) the CAO utility can be run. This has been completely revamped for the new release, and offers a clean, intuitive interface that provides the administrator with all the tools he needs to manage the PKI components, policies, certificates, CRLs, and reports. The CAO main screen provides access to the two main editors which will be used by the administrator:
In addition, it is possible to create authorisation groups, administer policies and certificates, and monitor logs using the dockable Policy Authorisation and Explorer windows on the right of the main CAO screen. As with previous releases, the PKI entities are depicted in a graphical manner in the PKI Editor, making it very easy to view and manage the overall infrastructure. Although it is still possible that in very large infrastructures � with large numbers of CA�s and RA�s � the screen could potentially become very cluttered, this has been partially addressed in the latest release by eliminating the need to create individual RAO entries. This has been achieved by providing a new set of extensions to the certificate policies that allow a certificate to be identified as a PKI entity certificate � thus a WebRAO certificate will identify itself as such, and automatically authorise its holder to perform RAO operations without having to be explicitly defined as an operator within the PKI Editor. In addition, should on-screen clutter ever become a real issue, the number of objects on display at any one time can be further reduced by only including sub CAs, Cross CAs, and RAs connected to the specific CA being administered. On bringing up the PKI Editor for the first time after the PKI �bootstrap� process, administrator is presented with icons for the CA and CAO (referred to as the �CAO Superuser�) generated during the initialisation process. Any number of additional CAOs can be created, and these can be assigned a subset of the tasks available to the Superuser � for instance, they may only be able to create and edit policies, and may not be allowed to edit the PKI itself or revoke certificates. These security assignments are applied via a set of check boxes on the CAO Access Rights tab.
Once the CA and CAO have been configured, the remainder of the PKI can be designed by creating and registering other PKI entities, including:
Each of these entities has a number of attributes associated with them, such as CRL generation parameters or certificate publication details for a CA, or access rights for a CAO. The relationships between entities (specifying which RA belongs to which CA, for example) are defined by connecting them together on screen. A set of standard policies are provided with the PKI which apply to the CAs, PKI entities and end users (specifying critical parameters such as key length, algorithm, key usage, and so on). New policies can be created using the RP Editor. It is also possible to delete entities, generate CRLs, and establish cross-certification relationships from the PKI Editor. Entity renewal capabilities will be added in the next patch release. UniCERT allows a hierarchical system of CAs � either on different machines or on the same host � with the certificate of each CA down the hierarchy being generated by its parent CA. Sub-CA and Sub-RA components are used to create the hierarchy in the PKI Editor by creating new CA or RA components and connecting them to the parent CA/RA as required. There is no limit to the number of sub-CAs that can be created.
Peer-to-peer cross certification is accomplished by generating cross certification requests, or processing requests from other CAs, by right clicking on the CA entity in the PKI Editor. Requests can be generated in PKCS#10 or certificate format. The request file is transmitted to the remote CAO out of band and a reply is returned, at which point it can be imported to complete the cross certification processIn addition to support for standard CRL�s and OCSP � it is possible to define CRL Distribution Points (CDPs) in the CAO. Distribution Points allow CRL�s to be broken down into sub CRL�s and have the CA publish them (or make them available to a third-party application that publishes them) to various locations depending on the policy being used for the issued certificates. When the CDP extension is used, the CA can place a CRL in a location where it can be retrieved via an e-mail address, a URL, or by other means. For those who require key backup and recovery, the Key Archive Server (KAS) is an optional UniCERT component which allows storage of end users' private encryption keys securely in encrypted form, and retrieval as needed. The Key Archive Server is connected to the CA in the PKI, and RAOs pass the keys to be archived to the KAS via the CA. Unfortunately we were unable to test key recovery functions in the version of software provided to us. Within a PKI, the policies under which certificates are issued determine the level of confidence other parties will have in the certificates issued by a CA, and are normally published in a Certification Practice Statement (CPS). This states the policies for issuing various levels of certificates and the registration process that people must go though in order to obtain each different type of certificate. The Registration Policy Editor (RP Editor) allows the administrator to define the attributes that end users must specify to have their request accepted. It also provides the ability to specify the operational constraints that either the WebRAO who processes the request, or the end user, must obey to complete the certification process. UniCERT supports a wide variety of registration processes, including direct face-to-face requests, or indirect or remote requests via the UniCERT Protocol Handlers (web browser, e-mail or VPN, for example).
The RP Editor enables the administrator to set up details of:
Personal information � such as date of birth, postal address, driving license number, and so on � which is required as part of the registration process but is not intended to be published in the final certificate, can be collected via the registration policy and stored in the Oracle database separate from the certificate to which it relates. This information can later be used for reporting and auditing purposes.
The RP Editor provides a very easy-to-use graphical interface that provides a drag-and-drop approach to building new policies on-screen. Certificate elements are dragged from an hierarchical menu on the left of the screen to the editing area on the right. Once placed in the editing area, the appearance of the object can be changed (text input fields can be altered, pick lists can be designated as drop-down menus or multiple check boxes, and so on), a range of values specified (allowable encryption algorithms, for example), and default values specified. During policy definition, the administrator must:
In order to be a true security policy, as opposed to a profile editor, it is necessary to be able to provide operational controls, such as mandating key length or encryption algorithm, key archival policy, certificate validity period, method of key generation (hardware or software), and the number of RAOs required for certificate authorisation (or whether no RAO authorisation is required at all, allowing the certificate request to be passed directly to the CA). These controls go beyond the content of a certificate, and allow for certificate issuance to be processed in a more integrated fashion. At the very highest level, there may be differences between the requirements of the registration policies which are to be used in a face-to-face environment and those which are to be applied to requests received remotely (via the Protocol Handlers). New elements can easily be added � registration criteria, key properties, extensions, policy information, and so on � and for each element in the policy, it is possible to choose whether the end user or WebRAO is to enter a value, or whether a value is predefined (and even hidden from the user). For example, a specific registration policy could always set certain certificate extensions and not show this to the WebRAO, or the key length and algorithm used may be fixed for certain types of certificate. Where values are pre-defined by the administrator, those elements do not need to be visible on the registration form. However, since UniCERT can support any number of registration policies, it is possible to create one policy where these values are fixed, and another where the available options are presented in drop-down menus or pick lists if required. Once elements are placed in the editing area, they can be resized and repositioned, and at any point the administrator can call up a WYSIWYG preview of the finished form before saving it. Once saved, the policy is pushed to all the RAs in the PKI automatically, making it easy for a CAO to control enterprise-wide policy from a single, central location. UniCERT offers one of the most flexible, powerful and, above all, easy to use policy definition capabilities that we have seen. Finally, the CAO utility also provides access to the reporting and auditing functions of UniCERT. From here the administrator can manage certificates as required. This includes revoking certificates, suspending or unsuspending certificates (a temporary revocation), viewing certificate details and event log entries, and viewing and troubleshooting incomplete tasks (i.e. certificates that cannot be issued). The Registration Authority (RA) acts as a router between RA Operators (WebRAOs), Protocol handlers and the CA.The RA eXchange functions as a gateway for remote requests from the protocol handlers and the WebRAO. RAs divide the PKI into operational domains. Each operational domain is a separate structure linked to the CA, yet intra-domain confidentiality is maintained at all times. The RA obeys its own operational policy, which is maintained centrally. The actual RA process is something of a �black box� that simply needs to be started each time the RA machine boots. The UniCERT RA Operator (WebRAO), on the other hand, is the Java-based Web interface through which requests for certification are received and processed. These requests may be received via e-mail, WWW (remote Web or VPN requests) or in person (face-to-face requests). In the latest release of the software, the old Windows-based RAO GUI has been replaced completely by the WebRAO utility, providing purely Web-based access to the RAO functions.
Unlimited numbers of WebRAOs can be created, and the operations that can be performed by each of them is controlled by the Registration and Operation Policies, and by the RAs that they have access to. WebRAOs can also be divided into operation domains, dividing the infrastructure into logical sections. Information and certificate requests specific to a domain are not made available to other domains, thus allowing the PKI to be departmentalised. When the RAO user first accesses the WebRAO he will be required to authenticate himself using his private key (smartcard or PKCS#12). He is then presented with a list of available security policies, one of which is selected � this determines the information to be collected and the type (and content) of certificate to be issued. During face-to-face registrations, the person using the WebRAO program enters an end user�s details and accepts or rejects the candidate�s application. It is the RAO�s responsibility to process certificate requests and perform whatever steps are deemed necessary to ensure that the information and credentials provided by the requester are valid as defined in the Certificate Practice Statement (CPS). Keys can either be generated by the WebRAO program and are secured using a pass phrase entered by the applicant, or the applicant can generate their own keys and provide the public key to the WebRAO. Once the certificate is processed, it can be saved on a smartcard or disk and given to the user. In many cases, however, a method of registration other than face-to-face is required. This can occur where the user is remote from the WebRAO and wishes to submit their registration request via browser, e-mail or VPN. In these cases the registration request is sent via the UniCERT Protocol Handlers, and the request is stored at the RA. A WebRAO can then authorise the request in the same way as when doing face-to-face registration. Alternatively, if allowed by the Registration Policy, the RA can send requests received from the UniCERT Protocol Handler directly to the CA without being authorised by a WebRAO. Another of the features that make UniCERT so flexible, is that custom registration processes can be built, typically using the UniCERT ARM or Baltimore KeyTools (e.g. Using the PKIX CMP protocol). This may be done where it is required for the registration process to interact with another application or database, for example a human resources database. End-user certificates must be provided to the requestor by a method and in a format that matches the requestor requirements. UniCERT can issue certificates in a variety of formats and deliver them by suitable mechanisms � this is controlled by the Registration Policy. Typically, certificates dealt with in a face-to-face manner are distributed either in software or on cryptographic hardware (smartcards, for example). Remote requests are generally distributed by the same method in which they were received: email, HTTP or sockets. However using the Registration Policy, alternative distribution mechanisms can be used. On firing up the WebRAO utility, the operator is offered a simple menu containing four options:
When processing face-to-face requests, the WebRAO user first selects the registration policy from a list of those available. He then completes the appropriate fields as specified by the policy selected and generates a key pair (either in software or using a PKCS#11 token or smart card). If either a PKCS#11 Token or PKCS#11 Smartcard was used, then the key pair is generated on the device. If no hardware token was used, then the key pair is stored in a password protected PKCS#12 file on disk. Alternatively, the end user may elect to use a key pair that was generated remotely as the basis of their certificate request, in which case the key pair can be loaded from the appropriate source. Whichever method is used to acquire the key pair, the public key is passed to the CA for signing at this point.
Having been processed by the RA, the RAO user retrieves the certificate and installs it into the key store (PKCS#12 file or PKCS#11 device) that was used during the initial key generation process. The registration process is then complete. The Authorise command is used to process remotely generated certificate requests that require one or more authorisations. This command can be used to authorise both certificate issuance and certificate revocation, suspension and unsuspension requests. If Remote certificate requests require authorisation (as defined by the registration policy) they are automatically routed to the RAO and can be retrieved from a list of pending requests and processed according to the available remote policies. Any additional validation can be performed at this point before the request is passed on the to CA. Certificates issued for remote requests received by e-mail or Web are automatically routed back to the requester (rather than the RAO) via the appropriate protocol handler.To authorise certificate issuance and revocation requests, the WebRAO user must belong to a user group that has an authorisation access path to the policies under which the certificates were processed. Usually, a certificate can be collected almost immediately after submitting the request (unless the policy under which the certificate is issued requires that the CA send the certificate directly to the applicant or place it at a Web address from which the applicant can collect it). The most common reasons for collecting certificates some time after the initial registration process are the following:
All that is required to collect a certificate is to enter the transaction ID provided during the registration process (other search criteria can be entered if this is not known, or if it is necessary to collect multiple certificates) and the certificate is returned to the WebRAO. At this point, it can be saved � along with the previously generated key pair(s) � to either a hardware token or a PKCS#12 file on disk. Once certificates are issued, the WebRAO user can perform additional certificate management tasks as needed, such as revoking, suspending and unsuspending certificates. Certificate revocation refers to the practice of invalidating the public key of a user�s certificate during the life of that certificate. The revocation of any user�s certificate needs to be made public and is hence entered into a directory or an Online Certificate Status Protocol (OCSP) responder.
UniCERT maintains a number of different system logs, which detail every system and operator action at the CA or RA. These logs can be viewed through UniCERT screens and complex reports can be created through the use of SQL. All the database logs are signed by the entity logging the information and are verifiable via the GUI screens. The CAO utility provides access to basic auditing and reporting capabilities, and a number of pre-defined reports are provided, including:
Using the New Query dialogue box, simple queries can be constructed to locate certificates with particular characteristics, for example, certificates issued by a particular CA or which contain a particular domain name in the e-mail address. Output is restricted to a basic spreadsheet format, and once the query has been built, any of the certificates displayed can be managed further (revoke, suspend, unsuspend, view or export) by right clicking on the appropriate entry.
The UniCERT Web Handler provides the Web-based user interface to certificate applicants who originate certificate requests, retrieval requests, and status requests remotely from a Web browser. Typically, the applicant invokes the Web Handler by linking from a Web page. The Certification Authority Operator (CAO) configures the Web Handler by creating policies that determine the information required from, and available to, applicants. The CAO then maps the policies to the Web Handler. From this screen, the applicant selects the following commands:
When the applicant clicks Register, they are presented initially with a list of the available policies, which will determine the certificate types that may be applied for. The operational policy that the CAO has created and mapped to the screen determines the types of policies that appear on this screen. The subsequent Web pages are built dynamically from the registration policies depending on which policy is selected. Once the application form has been completed and the certificate request submitted, the applicant can attempt to collect their certificate by clicking Retrieve Certificate. Often, however, because the CA can not process the request immediately, especially if the request requires one or more authorisations, the certificate is not ready for collection. The applicant then returns to the Web Handler at a later time to retrieve their certificate, using the Retrieve command (or the certificate can be returned by other means � Web page or e-mail, for example � as specified by the registration policy). When the certificate is retrieved, it can be saved in DER format, PEM format, as a certificate chain, or saved directly to the browser. When a CRL is retrieved, it can be saved in X.509 format, PKCS#7 format, or directly to the browser. Note that the Retrieve command can also be used to search for the latest CRL issued by the CA.
Using the CertStatus command, the applicant can check the status of a certificate � either their own or someone else�s � and change the status of their own certificate. To begin either process, the applicant clicks CertStatus and the Certificate Status dialogue appears, displaying the two options available to the applicant: check or change. Check returns the current status of the certificate (from the CSS server, rather than via a CRL), whilst Change allows the user to revoke, suspend or unsuspend their certificate (providing this is allowed by the issuing policy). If the browser model is not acceptable to an organisation � or more functionality is required � there are a number of tool kits available to allow third-party applications to be PKI-enabled. KeyTools Pro is the primary Baltimore tool kit for developing PKI-enabled applications. It is available as C++ or Java classes, and provides a high-level API offering full encryption and digital signature capabilities to the developer.
The built-in policy enforcement system allows an organisation to dictate security policy at application and desktop level. Being completely standards-based, Baltimore KeyTools applications work with any standards-based CA, not just UniCERT. Additional tool kits are available to address specific XML, WAP, S/MIME and SSL applications/requirements. The simplicity of configuration of UniCERT hides the tremendous complexity and power hidden beneath the hood. A powerful database-driven policy engine, coupled with the excellent PKI and RP Editors, makes UniCERT the most flexible CA solution out of the box of all those we have tested. Yet it lacks none of the features we expect to see in a high-end PKI solution. Other products allow similar functionality to be achieved via extensive Java coding or the use of tool kits, but UniCERT provides a superior �out of the box� experience, as well as offering the necessary tool kits for those who want to take things even further via custom development. If we had any criticism of the current release, it would be that automatic key update is not available at the CA. Also, it would be nice to see an enterprise LDAP directory included in the box. The new release provides a number of new features that make it a very attractive proposition, however. Multiple registration methods are on offer backed by strong policy enforcement, and the new Protocol Handlers have streamlined remote registration requests. Extensive customisation is also available via the ARM module. Whilst cost may prohibit the use of UniCERT in smaller (i.e. under 1000 user) PKI implementations, it nevertheless provides and attractive and easy-to-use interface for the PKI �novice� whilst providing the ability to scale to the largest implementations. Hierarchical PKI structures, cross certification, unlimited RAs and WebRAOs, unlimited certification policies, real-time certificate status checking, multiple CAs and RAs on a single platform, PKI entity cloning, and unlimited certificates all help to make UniCERT ideal for the largest and most mission critical deployments. Cross-platform deployment is easier too, with almost all the components running on both Windows and Unix now, and Windows components running as native services. At the client end, strong policy enforcement is a key feature, and the ability to build client-side Web pages dynamically from the stored registration policies makes it one of the simplest systems to deploy and maintain. Overall, we found UniCERT to be hard to beat in terms of features, flexibility and ease of use. Company
name: Baltimore Technologies Click here to
go to the Baltimore Checklist |
Security Testing |
Send mail to webmaster
with questions or
|
