 |
|
|
SSH Communications Security provides a whole family of products for implementing a PKI system: SSH Certifier for PKI management, SSH Token Master for personalising smart cards, and SSH Accession for enabling other applications to use smart cards. SSH Certifier is a complete platform for operating a PKIX-based public-key infrastructure. It can be used for issuing certificates and certificate revocation lists, publishing them in public directories, providing OCSP services, authorising end entities for certificate enrolment, and managing a fully functional PKI system. SSH Certifier provides intuitive Web-based graphical user interfaces both for PKI management and end-entity certificate enrolment. SSH Certifier is available for Linux (SuSE and Red Hat), Sun Solaris, and Microsoft Windows NT 4.0, Windows 2000, and Windows XP. The architecture of SSH Certifier - which has changed considerably for this latest release - is highly modular. There are two main components: Certifier Engine and Certifier Server.
The Certifier Engine and the Certifier Server may be run on different machines, and there may be several Servers connected to one Engine. The Engine connects to the embedded Certifier Database (Adaptive Server Anywhere from Sybase) and performs all CA/RA private-key operations. The Engine also implements the certificate policy, and serves the Certifier Servers. The Certifier Servers can have one or more front-end services running:
The different services can be divided between multiple Certifier Servers running on different machines, or all the services can be run on the same Certifier Server. The distributed service concept of SSH Certifier brings added system scalability in addition to providing flexibility to the PKI deployment. For example, if the OCSP Responder and CMP Services are not supported by the end-entity applications, they do not need to be used in the Certifier Server. The distributed model also facilitates the need for different services to be provided with different levels of accessibility and security. Enrolment Services typically need to be available for a wider part of the network than, for example, the Administration Service. By running these services on a separate Certifier Server instance they can be situated on separate host computers (for example, Enrolment Services outside the corporate firewall and the Administration Service on a tightly secured network). Using multiple Certifier Server instances to distribute the PKI services provides a high degree of flexibility in the PKI deployment. Another benefit of the customisable service set is the possibility to add system redundancy. In a worst-case scenario, the unavailability of a single service may prevent the use of the whole PKI. By duplicating critical services to multiple Certifier Server instances a degree of redundancy can be achieved in the system. The Certifier Servers communicate with the Certifier Engine using a TCP-based communication protocol. Transport Layer Security (TLS) with certificate-based authentication is used to protect the internal communications of the components in SSH Certifier. First TLS certificates are created for the Engine and Server during the system installation, and keys are automatically updated and new certificates enrolled before the expiration of the old certificates. Directory administrator passwords are used by the Publishing Service as a basis for directory access control. The Administration Service provides CA and RA operators with a graphical user interface for performing the PKI management operations (including request processing, certificate revocation, and entity management). For system administrators, the Administration Service provides access to reviewing, testing, and modifying the configuration of the Certifier system.
The Administration Service is accessed over an HTTP connection, and all management and configuration actions can be performed using the graphical user interface running on a standard Web browser, and protected with Transport Layer Security (TLS). The Administration Service can be configured to require client authentication for additional security, requiring that the administrators possess an authorised certificate for authentication when logging in. The CMP Service provides the PKI certificate life-cycle management capabilities, acting as a server for handling incoming CMP messages (including certification requests and revocation requests). SSH Certifier uses the CMP Service for communications between RAs and CAs, and the service can be configured to provide either TCP or HTTP-based transport for the Certificate Management Protocol (CMP). A Registration Authority (RA) signs all messages with its private key, and the CA then verifies the origin of the requests (since it has issued the RA certificate that is used). The initial enrolment of the RA is also performed by using CMP. When the initial certification request is made, a pre-shared key is used for authentication. The SSH Certifier system that houses the RA must run the External Enrolment Client Service to perform the client side of CMP, and the system that houses the CA must run the CMP Service to perform the server side. The CMP Service also provides tools for CA-to-CA interaction (including cross-certification between separate PKI domains and issuance of sub-CA certificates). As with the RA-CA case, the enrolling CA must run the External Enrolment Client Service and the issuing CA must run the CMP Service to process the CA certification request. External Enrolment Client Service In certain cases, SSH Certifier needs to act as an enrolment client initiating enrolment with an external CA. This is necessary when an RA requests a certificate from a CA and when a CA requests a cross-certificate or a sub-CA certificate from an external CA. The External Enrolment Client Service is needed to run these client-side operations using CMP. Every SSH Certifier system that has at least one RA has to have an External Enrolment Client Service running on a Certifier Server instance. When the external CA is not online, certification requests can be stored in a file by the External Enrolment Client Service. Also, if a third-party CA does not support online CMP enrolment, the possible cross-certification request can be stored in a file and transported to the CA by other mechanisms. The OCSP Responder Service (new for release 2.0) provides client applications a point of control for retrieving real-time information on the validity status of certificates using the Online Certificate Status Protocol (OCSP). The OCSP Responder Service has a certificate that has been issued by one of the Certifier CAs. The end entity applications that use OCSP need to trust the issuing CA, so that they can validate the signed responses. It is possible to configure the system so that the OCSP Responder Service gives out information only on certificates issued by selected CAs. The Publishing Service provides the means to publish the issued certificates and certificate revocation lists for public use. The most common publishing method is to use a directory server that the certification service subscribers can use to retrieve the latest certificates or CRLs. The most common directory access protocol used for this purpose is the Lightweight Directory Access Protocol (LDAP), and the SSH Publishing Service supports both LDAPv2 and LDAPv3. The SSH Certifier CD-ROM includes the OpenLDAP directory server as an optional component for Unix platforms. Publishing Service configurations include the LDAP connection-related parameters such as directory server address, directory administration login and password (and optionally Socks server and publishing retry parameters). If there are multiple directories for publishing within a single Certifier installation, one Publishing Service has to be created for each directory access. Use of an LDAP directory is not mandatory - certificate revocation lists can be published on a Web server with HTTP instead. The Publishing Service can also be used to store certificates and certificate revocation lists in a file and to run external scripts that perform the publishing. Using external publishing mechanisms provides easy means to use publishing methods such as e-mail or FTP. The SCEP Service provides Simple Certificate Enrolment Protocol (SCEP) services for clients that support this protocol. SCEP is a protocol that defines the procedure for a client to request certification from a CA, and is widely used in IPSec gateways and IPSec host applications. There are two parts to a SCEP operation. First the CA certificate is retrieved from the SCEP Service by using an HTTP GET operation and identifying the CA whose certificate is returned. Once the CA certificate has been received, the certificate for the end entity�s own private key can be enrolled. Pre-shared keys can be used to authenticate the end entity and to automate the process. A client can send a certification request directly to the CA or the certification can be performed via an RA. When an end entity requests the RA certificate using the RA name to identify it, both the CA and RA certificates are given out by the SCEP Service. The end entity needs both certificates as the CA certificate is needed after the enrolment when validating the signature of the end entity�s own certificate. The Web Enrolment Service provides a point of connection for the Web-based enrolment clients that use the certificates issued by SSH Certifier. This service naturally requires a network connection to the same network used by the clients of the CA.
The main function of the Web Enrolment Service is to offer Web pages customised to include scripts that initiate private key and certification request generation in a Web browser. In addition, PKCS #10 certification requests generated by other applications can be given in the enrolment form of the Web Enrolment Service to support applications that do not provide other online enrolment mechanisms. Other functions of the Web Enrolment Service are CA certificate and CRL downloading. The Web Enrolment Service can be run both in TLS-protected and non-TLS mode depending on the requirements. As of release 2.0 of the software, SSH Certifier includes the Adaptive Server Anywhere database from Sybase Inc. The database is installed during the SSH Certifier installation. Open Database Connectivity (ODBC) provides both an API and a database-independent driver layer between the Certifier Engine and the actual database back-end. The Certifier Engine is linked with a generic ODBC driver manager which loads a database specific driver according to its configuration at runtime. Another external service typically required by SSH Certifier deployment is a directory server supporting LDAP. End entities need LDAP services typically when they are fetching the latest CRL or searching for encryption or sub-CA certificates, as well as searching for end-entity certificates. If directory redundancy is required, SSH Certifier provides a mechanism to distribute certificates and CRLs in multiple directories. Multiple Publishing Services can be associated to a single CA to publish, for example, CRLs in multiple directories. The directory server provides a powerful system for organising user data and providing the PKI objects available for each end entity. However, a directory server is an optional component and may not be needed in each PKI. For example in several applications there is no need to search certificates from external databases since they are sent between peers in the security protocol. CRLs can also be published by using a Web server (HTTP). Hardware Security Modules (HSM) From release 2.0 of the software, SSH Certifier provides support for HSM modules by nCipher Corporation Ltd. - the supported devices are nShield and nForce. The native application programming interface of these devices is used by SSH Certifier to format the authentication tokens of the HSM, to create CA private keys, and to perform all CA private-key operations. HSM is an optional external component, and it is not required if software CA keys are used exclusively. SSH Token Master is an application for initialising and managing cryptographic tokens in a PKI. SSH Token Master offers functions for personalising, operating, and managing end-entity cryptographic tokens such as smart cards. It also provides tools for viewing token contents and certificates, enrolling token keys, and batch personalising smart cards. Using SSH Token Master, a PKI administrator can easily personalise blank smart cards and register users in the PKI by performing online enrolment with a CA run by SSH Certifier. The administrator can also act as a Registration Authority by signing the certification requests for user token keys with his own private key on a smart card. SSH Token Master can create an electronic PKCS#15 profile into selected smart card operating systems, thus streamline smart card deployment. Optional generic PKCS#11 personalisation is also provided for smart cards and tokens that are not natively supported. SSH Token Master also supports private key backup and recovery for encryption keys, and is available for Microsoft Windows NT 4.0, Windows 2000, and Windows XP. SSH Accession is a desktop application for enabling other applications, such as Netscape Navigator, Microsoft Outlook, or SSH Secure Shell, to access keys and certificates stored on cryptographic tokens. SSH Accession can also be used as an authentication agent for SSH Secure Shell. SSH Accession provides a �single point of contact� for applications that require private-key operations. It can integrate smart cards, USB tokens, private keys stored on the hard disk, Secure Shell keys, and many other formats of private key storage with applications that support PKCS #11 or MSCAPI. SSH Accession brings public-key authentication to the desktop and enables the user to sign e-mails, open encrypted e-mails, or use strong user authentication during Web sessions or remote connections. SSH Accession works transparently - once it is installed and configured it operates seamlessly in the background. SSH Accession also provides authentication forwarding for SSH Secure Shell. Private keys are safely stored in one place and SSH Accession forwards the authentication over several Secure Shell connections. SSH Accession is available for Linux (Red Hat), Microsoft Windows 98, Windows Me, Windows NT 4.0, Windows 2000, and Windows XP. Naturally, Accession is not a mandatory client-side requirement for SSH Certifier. Third party cryptographic providers can be used with Certifier without additional client software since Web-based enrolment methods are fully supported. Microsoft�s own built-in smart card cryptographic service providers and reader drivers can also be used instead of Accession. Certification Request Processing In SSH Certifier, all end-entity actions are performed via Enrolment Services running on Certifier Server instances. These services perform the message transport-related server-side functionality of certificate enrolment or certificate life-cycle management. There is a dedicated Certifier Service for each protocol:
Each of these Certifier Services check all the incoming messages from end entities. If the message can be parsed (and understood), the Service forwards this request to the Certifier Engine to be resolved and processed according to the defined policies. Malformed requests are dropped immediately by the Service. Since the Enrolment Services do not possess the CA or RA private keys, they cannot decrypt any encrypted messages arriving to the CA or RA. A certification request is processed through the following steps:
The request arrives to the Certifier Engine and is pre-processed. Protocol dispatching: further processing depends on the enrolment protocol used . Verification: the integrity of the request is checked. If the request fails this check, it is dropped. Assigning to CA: The request is assigned to a CA (or an RA). Decryption (SCEP only): The request is decrypted. Mapping: The request is mapped to an entity, providing an entity has been created beforehand and the request contains a valid shared secret. The mapping can also be done via an RA, either based on an already existing RA signature, or based on an existing valid key. POP: Proof-of-possession check is made to the request. If the check fails, the request is dropped. A certificate template is created based on the request and the template is processed in the Certifier Engine according to the CA policy. The policy processing consists of four policy chains - after each chain, the certificate template can be either accepted or rejected. The Receive request policy chain is applied. Based on policy and end entity mapping, further processing can be either automatic or manual. If automatic processing is applied, the template is passed directly to the Accept request policy chain. The View request policy chain is applied when the CA operator views the request. The Update request policy chain is applied when the CA operator updates the request. Finally the Accept request policy chain is applied. If the policy chains end in acceptance, the certificate template is signed with the CA private key. In case of an RA, the request is signed with the RA private key and forwarded to the CA. The certificate is published in the Directory according to the publishing rules. If the client has the enrolment session still open, the certificate is sent to the client via the enrolment service. SSH Certifier can be installed on a wide range of operating system platforms, including Linux SuSE 6.2, Linux Red Hat 6.2/7.x/8.x, Sun Solaris 7/8, Windows NT 4.0 (SP5), Windows 2000 (SP1) or Windows XP. We tested on Red Hat Linux 8.0. There are two basic installation options: full installation and server installation. Full installation installs all SSH Certifier components on the same machine (including the Database). Server installation installs only the Certifier Server component. Installation under Linux was as simple as issuing the RPM command to create the directory structure and place the software in the correct locations, followed by a text-based set-up routine. The SSH Certifier set-up initialises the Database structure and creates the TLS CA for Certifier operational use. The TLS CA issues the TLS certificates required for secure communication between Certifier Engine and Certifier Server. These certificates are created during the set-up, along with the two Certifier Services, an Administration Service and a Web Enrolment Service in the Certifier Server. That is all there is to it, since the CAs that will be used to sign the end-entity certificates in the PKI are actually generated later via the GUI. The SSH Certifier CD-ROM also includes the OpenLDAP directory server as an optional component - this can be installed separately following SSH Certifier if required, though configuration of the LDAP Publishing Service is not as straightforward as it could be. Documentation is excellent, and the following manuals are provided as PDF files on the SSH Certifier CD:
During the set-up process, only the TLS CA is created. This CA is used for issuing certificates to SSH Certifier Servers and (optionally) also to Certifier Services. It is necessary to create one or more new CAs for issuing the end-entity certificates. Even though one CA (the root CA) could be used to sign all the end-entity certificates in the PKI, SSH recommends separate CAs for these functions.
One of the most useful new features of the 2.0 software release is the ability to manage multiple CAs with complex hierarchies on a single host. It is actually possible to create and manage an unlimited number of CAs (each with its own policies) with one Certifier installation making this an excellent product for use in a service provider environment. New certification authorities can be created by the CA operator via the administration GUI. For every CA, the root operator must configure the following:
These can be edited by choosing the CA/RA Hierarchy option in the GUI and clicking the name of the CA. A newly created CA has a very minimal configuration, and the first task after creating a new CA is to configure its policy and publication attributes. This can be accomplished through the CA/RA Hierarchy display by clicking the appropriate View CA button. This brings up the Certification Authority page - the CA Name, Description, and Status fields were already set during CA creation, but can be further modified in this view, and the certificate publication method (LDAP, HTTP, OCSP) and CRL distribution points can also be specified here. SSH Certifier does not impose hard-wired policies and certificate profiles onto the user, and when it comes to creating and modifying policies, there is a graphical Web-based Policy Editor available. The policy is divided into separate policy chains and these chains are always CA specific. Each chain has a separate function and is applied in certain situations - when receiving, accepting or viewing requests, for example. The basic idea is that the chain either accepts the operation or denies it, but it can also change the request contents along the way.
Four policy chains are implemented:
Each chain consists of one or more policy modules added by the administrator. Each module is a function that receives the certification request (perhaps with some additional data), can make changes to the request, and can either accept it, deny it or pass it to the next module in the chain. If the request �drops off� at the end of the chain (the last module passes it on), the request is assumed to be denied. A request is only accepted if one of the modules in the chain explicitly accepts it. Those administrators familiar with defining firewall rule sets will feel right at home with SSH Certifier rule chains - their operation, whilst potentially complex, is very intuitive. A new module is added by selecting it from the chain�s pop up menu and each new module is added to the end of its chain. As the modules are run in order, the module�s position in the chain is important, and modules can be moved within each chain by clicking the Up and Down arrows. A module can also be removed by clicking the Remove button. Other items displayed in the module boxes are the module�s position in the chain, the module�s name, and either a short description or the module specific parameter configuration. The following modules are available:
The policy configuration features are what makes SSH Certifier one of the most flexible and powerful PKI products we have seen - unfortunately they can also make it one of the most difficult to configure from scratch. Basic default policies are included, but these are unlikely to be sufficient for most commercial deployments. Once you start creating custom policies, it is not difficult to define invalid certificates or include incompatible operations in policies that effectively render them inoperative - in other words, you need a good idea of what you are doing before being let loose with the SSH policy editor. In addition, after defining an invalid policy, only the most basic error messages are returned when attempting to issue certificates against it making it very difficult to troubleshoot problems. Of course, the only way to eliminate such problems is for the PKI vendor to �hard code� the policies - there is always a fine line to be walked between flexibility and ease of use, and the SSH product assumes a reasonable level of administrative competence in order to provide an extremely powerful and flexible solution. Whilst on the subject of flexibility, it should be noted that a number of command-line tools are offered allowing non-browser based administration and automation via scripting. The modular architecture of SSH Certifier provides a flexible way to distribute various PKI core tasks to different hosts. The Certifier Engine and other back-end services can be installed on a secure internal network, for example, whilst the front-end services can be installed on a DMZ - or multiple versions of a single service can be installed on separate hosts to provide load balancing in larger organisations. This allows scalability for large deployments, but on the other hand, more limited PKI deployments can still be implemented easily since only the required mandatory services need to be configured.
The default installation will create the Certifier Engine, the Certifier Database, and a Certifier Server on the same machine. In smaller deployments, one Certifier Server can run all desired Services, but in most cases several Certifier Servers are useful to maximise the security of the system. After the initial installation, additional Certifier Servers can be installed on other machines (two Certifier Servers cannot be installed on the same machine). One Certifier Server can contain practically an unlimited number of Certifier Services (these are described in more detail in the Architecture section of this report) All communication between Engine and Server instances is secured with TLS to provide authentication, integrity, and confidentiality for the communications. All administrators who are allowed to operate SSH Certifier must have an operator account created for them. Operators are identified with a login name and a password (if TLS client authentication is not used). However, in most situations the most crucial identification method is the operator�s TLS certificate. This certificate can be stored on the operator�s personal workstation within a Web browser, or on a cryptographic token such as a smart card. An SSH Certifier operator has a set of access control rights (read, entity write, write, and super-user) defining what kind of activities the operator is allowed to perform. It is also possible to restrict operations to certain CAs and RAs in the system, allowing for fine-grained delegation of administrative function. SSH Certifier supports the following access control levels:
As you would expect, SSH Certifier supports cross-certification, where one CA issues a CA certificate for another entity - this can be a sub-CA certificate within a single PKI domain, or a certificate connecting two independent PKI domains. The certification can be either unilateral or bilateral, fully automated or manual. After the certification authorities have been created, and the directory services and certification policies have been configured, the PKI is fully functional, and certificates for the end entities can be created and published. All the administrative functions are available via an intuitive Web-interface which provides access to the Administration Service. Different �themes� can be applied to different operators and CAs, providing a different look and feel to the administrative interface where required. In cases where the certificate policy declares that certification requests with a valid pre-shared key can be approved automatically, the administrator can enable automatic certificate issuance by generating shared keys for authorised end entities. Where automatic issue of certificates is not employed, the most common day-to-day task facing the administrator will be to process certificate requests from end-users and RAOs. Where certificates require manual approval prior to issue, the Process Requests option brings up a list of certificates awaiting approval. Each request can be viewed in detail, and the administrator can add new fields to the certificate or edit existing ones (perhaps overriding a parameter such as key usage). Once the request has been verified, clicking Accept will issue and publish the certificate. If there were several pending requests matching the search criteria, the next request is automatically opened for processing.
After the certificate has been issued, it can be found in the Certifier Database using the Find Certificates option and entering the required search criteria. Once a certificate has been retrieved for viewing, the administrator can view the certificate log (a list of all the operations pertaining to that certificate and its original request), Revoke the certificate or Suspend it. If a key that still has validity time left is compromised, or the right to use it has to be removed for some other reason, the operator can revoke the certificate. It is also possible to revoke multiple certificates in a single operation by specifying a general search criteria and them marking the required certificates on the search screen before revoking. One omission here is that there is no provision to enter a reason for revocation when revoking a certificate - all revocation requests are allocated an identical reason automatically by the system. After the revocation the serial number of the certificate will be included in the next issued CRL (it is immediately available for OCSP). The latest CRL can also be viewed immediately via the administrative interface. While revocation is a final operation and cannot be reversed, suspended certificates can be reactivated. The serial number of the suspended certificate is included in the CRL, but it is removed after reactivation. A suspended certificate can be reactivated by finding the certificate and clicking Reactivate in the certificate view screen. In addition to CAs, it is possible to create and manage RAs within the SSH Certifier installation. An RA entity is very similar to a CA entity in Certifier.- the RA requires a policy, it can receive end entity requests, and it may publish certificates in the directory. The major difference is that the RA does not issue certificates or CRLs directly - instead it signs certification requests with its own private key, and sends them to the CA. Most of the everyday CA administration functions are similar to RA functions. However, the RA creation is a bit different, since RA always enrols its certificate from the CA, which is not running on the same installation. It would not make sense in SSH Certifier to have both RA and CA running on the same host since an RA is merely a �specialised� CA - everything that an RA can do can be accomplished in an identical fashion within the CA in SSH Certifier - strictly speaking RAs are not required at all. This means that Certifier is ideal for deployment in very small PKI implementations since it does not force a rigid, cumbersome hierarchy on the administrator.
From the CA operator�s point of view, the RA is a delegated RA entity in the administration user interface. The delegated RA entity requires a certificate, which is used to verify the incoming RA certification requests, and a CA certificate, which defines the local CA that issues certificates based on the RA requests. The RA creation itself consists of two parts - first the local RA is created, and then the RA certificate is obtained from the CA. Once the RA has a private key with a certificate, and the connection to the CA is correctly configured, it becomes operational and appears in the CA/RA Hierarchy view. At this point it can have policies and operators assigned to it. As with the CA, every RA requires a policy in SSH Certifier. The RA policy definition is almost identical to the CA policy, the only difference being that instead of certificate issuance, a successful policy ends in the signing of a certification request with the RA private key and sending the newly signed request to the CA. Because in typical use the CA issues certificates automatically to RA-signed requests, the RA and CA policies are very similar from the administrator�s point of view. Typically, successful execution of either policy means certificate issuance. SSH Certifier is very limited in its built-in reporting and auditing capabilities. A log is maintained of all CA operations and this can be accessed via the GUI.
A log is also maintained of operations performed against each certificate, though this can only be viewed on-screen. There are no other reports available. However, an extensive set of system messages and logs - including regular heartbeat messages for both Certifier Engine and Server - can be logged to external syslog servers to enable integration to third party network management and monitoring systems. In SSH Certifier, Web-based enrolment services for Internet browsers are provided by the Web Enrolment Service. The default HTML template files that are shipped with SSH Certifier provide Web forms for posting certificate requests, scripts that enable browsers to perform the key generation, and a Web page that can be used to download CA certificates and CRLs. TLS is also supported to provide additional confidentiality and, optionally, client authentication in the Web enrolment. SSH provides a number of customisable HTML pages for browser-based enrolment services - the documentation explains in detail how these can be customised to provide the correct corporate look as well as to request only those fields which are relevant to the particular corporate policy in force. SSH Certifier allows client-side enrolment to be performed using both Internet Explorer and Netscape Navigator. The Web-based forms are very straightforward for the end-user to complete, requesting the information required by the CA/RA policy - such as common name, organisation, country, e-mail, and so on - before packaging the request to be forwarded to the CA or RA.
Netscape Navigator supports the HTML tag keygen, which is used for generating key and certificate requests (using Netscape�s proprietary format). When a form containing the keygen tag is posted, the browser will generate a key pair, wrap the public key inside a request, and post the result. The key pair is stored in the encrypted key storage (PKCS #12 format). The request is then submitted to the Web Enrolment Service, which parses it and forwards it to the Certifier Engine. If the certificate approval is configured to be automatic, the Web Enrolment Service pushes the issued certificate to the browser to be installed immediately. If the request has to be manually approved, it will be queued, and the end user is redirected to a page where the status of the certificate request can be polled. Once approved, the certificate can be downloaded and installed in the local Web browser.
When using Internet Explorer, a Microsoft ActiveX control can be used to perform the client-side enrolment, including the key generation - the control provides a scriptable interface for this. The control creates a private key in the Windows registry along with a base64-encoded PKCS #10 request, which can then be posted to the Enrolment Service. When the Engine has issued the certificate, it can be installed on the end-entity�s machine via the same ActiveX control. When enrolling for a certificate with a browser, the Key size and the Certification Authority from whom the certificate is requested needs to be selected in the Web form. Only those CAs, whose status is public and are included in the Accessible CAs list, can be chosen (naturally the choice can be removed completely if required, allowing the end user to enrol with only a single CA via a particular enrolment form). The enrolment form will request the user attributes Common Name, Organization Unit, Organization, and country. Optionally the user may enter an E-mail address, a domain name (DNS), or an IP address, if the certificate is to be used in an environment where these are required. In addition to names, the user may request the key-usage attributes for the certificates. These include the Email Protection, IKE Intermediate, Client Authentication, Server Authentication, Code Signing, and Time Stamping attributes. The necessary attributes depend on the intended use of the certificate. For example, when requesting a certificate for S/MIME use, the E-mail Protection check box must be selected in the request form. If the Web Enrolment Service connection is TLS protected, a pre-shared key can also be provided via the enrolment form to enable automatic certificate issuing. By clicking Advanced Options on the enrolment form, extension fields and validity period can be further edited in the certification request. Note, however, that the processing of these fields is totally up to CA policy. Both CA and RA certificates, and the CRLs can be downloaded from the Certification Authorities page by clicking CA List in the main menu of the Web Enrolment Services. All the CAs and RAs - at least those whose statuses are not Private and are included in the Accessible CAs list in the Web Enrolment Service configuration - can be viewed in this page. The following buttons can be found under each CA/RA entry:
The Web Enrolment Service can be configured to allow account management capabilities for end users including revocation and suspension of the user certificates. These services require TLS protected Web enrolment connections with client authentication, and the account management has to be specifically enabled in the Web Enrolment Service configuration page. SSH has been around for a while now �behind the scenes� in the PKI world, producing software for managed service providers and large enterprises, and this shows in the robust, well-designed product that is SSH Certifier. This product is extremely straightforward to install, with all necessary components - LDAP directory, relational database, OCSP responder, and so on - included in the box rather than offered as optional extras. Once installed, configuration can pose some challenges - particularly in the areas of LDAP directory integration and policy definition - but the documentation is generally excellent and any administrator with a good working knowledge of PKI systems should have few problems. The latest release of the software has introduced significant new functionality, including support for RA operations, inclusion of a relational database, limited HSM module support, OCSP responder, increased modularity in the architecture, LDAP V3 support, cross certification and token management capabilities. These new features - when coupled with the existing ability to support multiple virtual CAs on a single host - have really helped to position SSH Certifier as a true enterprise PKI solution. The support for multiple CA/RAs and increased modularity in particular make SSH Certifier very attractive in a service provider environment. Each CA can have unique CA policies, publishing rules, and delegated administrators, and policy definition is one of the most flexible we have seen. The separation of Certifier Engine and front-end services (such as administration and enrolment) to separate machines enables a secure deployment, where both administration and certificate enrolment can be done in a secure way over the Internet without need for additional client-side software installation. That same modularity together with the ability to implement a PKI using only a single CA (rather than rely on a complex CA/RA hierarchy which so many other PKI products enforce) also makes SSH Certifier a good choice for the smaller implementation. Company name:
SSH Communications Security, Inc. Click here to
go to the SSH Checklist |
Security Testing |
Send mail to webmaster
with questions or
|