General Information

This chapter provides general information about DirX Directory for Certificate Service Providers (CSPs) and the scenario in which it operates.

About DirX Directory for CSP

A CSP that operates according to the German “Signaturgesetz” law can use DirX Directory as a Certificate and Certificate Revocation List (CRL) repository.The DirX Directory server ensures:

  • Public read access to the certificates that are publicly available for reading via Lightweight Data Access Protocol (LDAP) (“abrufbar”, according to Signatur Gesetz (SigG).

  • Protection against unauthorized reading of certificates that are stored only for evaluation purposes (“nachprüfbar”, according to Signatur Verordnung (SigV).

  • Protection against unauthorized modifications of stored certificates.

The DirX Directory product’s X.500 access control features are used to distinguish between certificates and CRLs that are “abrufbar” or “nachprüfbar”.

The special aspects of installing, configuring, administering and using DirX Directory for CSP deal mostly with security and availability of the service.

About the DirX Directory for CSP Scenario

This section describes an example scenario for using DirX Directory in a CSP environment, including:

  • Network hosts and applications

  • Users and data

Network Hosts and Applications

The following figure shows the general architecture of a distributed DirX Directory service within a CSP boundary.

Network Hosts and Applications
Figure 1. Network Hosts and Applications

As shown in the figure, the distributed DirX Directory service runs on a several hosts within the CSP boundary. Outside access to this system occurs only via a well-defined communication port to a CSP frontend/portal application; for example, via HTTP. Direct access to the DirX Directory service occurs via LDAP. Public users can read certificates or CRLs from the DirX Directory service if and only if they are allowed to read them. With respect to DirX Directory access control, it doesn’t matter whether the user accesses the system directly using an LDAP client application or via the CSP frontend/portal application.

The internal network connections of the systems hosting the DirX Directory service should not be visible to the outside world. A firewall product and a virtual private network (VPN) can be used to achieve this state. The provider may also choose to use the SSL/TLS-protected variant of the X.500 protocols (called secure IDM, or IDMS in DirX Directory) for communication inside the CSP boundary.

CSP administrators perform all administrative accesses to the system from inside the CSP boundary. They use DirX Directory DAP or RPC client applications to manage meta-data like the schema, database configuration or access control, and use Ldapv3 over SSL (LDAPS) to manage user data: adding, deleting or changing the status of certificates. We recommend using SSL/TLS client authentication as the only accepted authentication method for these operations.

The hosts on which the DirX Directory servers are running are dedicated to DirX Directory to minimize risk.

For availability and performance reasons, the DirX Directory service consists of master servers and multiple shadow consumer servers. Read access is distributed onto the consumer servers using an LDAP load balancer.

The DirX Directory service can be configured to send out Simple Network Management Protocol (SNMP) traps (also called alarms) on conditions that require CSP administrator attention, such as security-relevant events and critical operational status.

Users and Data

In the context of this guide, the following directory tree is assumed:

Users and Data
Figure 2. Users and Data

The certificates hosted by the CSP are stored as attributes of user entries in the directory server below the subtree OU=Users. On the basis of access control and configuration, the administrator CN=admin has the privileges required to administer the entire service, including access control. The CSP frontend/portal application uses the administrator CN=certAdmin account to add the certificate attributes and modify the certificate access status (expressed by the objectClass values OCL=PUBLIC versus. OCL=RESTRICTED). A set of X.500 access control subentries (ACS) is located directly under the root of the tree O=My-Company. These subentries ensure that certificates are only readable for anonymous or authenticated users without special privileges if the certificates belong to user entries with the PUBLIC objectClass value.