Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

PreviousNextUp[Front page] [Index]

LDAP Publishing Method

For the LDAP publishing method, you need to choose a LDAP Publishing Service instance that is being used to perform the directory publishing. It is selected from the LDAP Server Connection list. Make sure that this Publishing Service instance is correctly configured and it has access to the LDAP directory.

CRL Distribution

In LDAP publishing, the CRL distribution point can be included either as an LDAP URL or as a directory name.

To actually include the CRL distribution point information in the issued certificates, the CA policy has to contain the Set CRL Distribution Point module.

Object Name Format

The object name format is the path name used when adding the object to the directory. The correct format is a string containing literal characters and symbolic fields that are to be replaced with data from their respective objects. The format field names are written as %{name}.

LDAP object name is a distinguished name and therefore must be structured as OID and value pairs. Most commonly used OIDs can be written using their symbolic names but they can also be given as numeric OID values. Very probably the certificates and CRLs should be published to exactly the location implied by the subject name of the certificate (or the issuing CA subject name in the CRL case). If this is not the case, various PKI clients will not be able to automatically perform certificate path construction or fetch peer certificates from the directory.

This recommended setup is accomplished by specifying

%{subject-name}
as the object name format.

For non-trivial PKI or directory setups the object path name can be constructed piece by piece. For example, the following object name format string for certificate publishing would take the organization (O) from the subject name of the certificate issuer, the common name (CN) from the subject name of the certificate, and finally add the serial number of the certificate with a fictional OID 1.2.3.4.5.6.

C=FI, O=%{ca-subject-name:O}, CN=%{subject-name:CN}, 
OID.1.2.3.4.5.6=$${serial-number}

The supported special fields are the following:

  • %{subject-name}

    Replaced with the subject name of the user certificate (if any). Optionally a parameter can be appended to specify a RDN within the subject name. If the subject name is, for example, C=FI,O=SSH,CN=Test Person, the field %{subject-name:CN} will be replaced with the string Test Person.

  • %{ca-subject-name}

    Replaced with the subject name of the CA certificate. Optionally a parameter can be appended to specify a RDN within the subject name. For example, %{ca-subject-name:OU} will be replaced with the value of the OU field from the subject name (without the OU= part).

  • %{entity:attribute}

    Replaced with an attribute from the associated entity, if any. Only one attribute value is used even if the entity contains multiple attributes of the same type. For example, %{entity:email} will be replaced with the Email attribute of the entity. Valid attributes are ip, email, uri, upn, description, address, and phone.

  • %{serial-number}

    Replaced with a serial number from the associated certificate. In CRL publish method this is the same as ca-serial-number.

  • %{ca-serial-number}

    Replaced with a serial number from the associated CA certificate.

  • %{callback:function}

    Replaced with the result of a policy callback function defined in policy.scm with function given as a parameter. This allows an extensible way to define object names. Same functions are also usable in LDAP attribute definitions.

Usually the subject name is a good choice for the certificate's path name and the subject name of the CA certificate for certificate revocation lists. Note that the object path given here is expected to be in the same order as all other distinguished names in SSH Certifier. This order is then reversed before the name is sent to the LDAP client.

LDAP Attributes

LDAP stores data as attribute/value pairs. To maximize flexibility, the attributes can be configured very freely. Attributes can be added by selecting an attribute from the LDAP Attributes list and clicking the Add button. This will add a new row to the LDAP attribute table.

The attribute table contains columns for attribute name, value, and type. Attribute Name is a string that identifies the attribute in the LDAP system. How the Value field is used depends on the type of the attribute.

  • String Literal

    The value field is stored to the attribute as is.

  • User Certificate

    By default, the entire issued certificate associated with the operation (if any) is stored to the attribute as binary data. This can be an end-user certificate or a sub-CA certificate, depending on the type of certificate that was issued. Alternatively, the serial number, validity period start or end, or Netscape comment extension of the certificate can be stored.

  • CA Certificate

    The entire CA certificate (of the issuing CA) associated with the operation is stored to the attribute as binary data. Other values can also be stored as in the User Certificate case.

  • CRL

    The certificate revocation list (CRL) is generated and stored to the attribute as binary data.

  • Email Extension

    The Email subject alternative name extension field of the user certificate is used.

  • DNS Extension

    The DNS subject alternative name extension field of the user certificate is used.

  • IP Address Extension

    The IP subject alternative name extension field of the user certificate is used.

  • Serial Number

    The serial number of the user certificate is used.

  • User Subject Name

    The subject name of the user certificate is copied to the attribute. If Single RDN from user subject name is selected, only the named RDN value from the subject name is copied (without the tag part). For example, if the subject name is C=AS, O=Policy Application Inc., S=Grant + G=Prachi and the value is O, then the attribute will have the value of Policy Application Inc..

  • CA Subject Name

    As User Subject Name above, but the CA subject name (or one of its components) is stored.

  • Entity Data String

    The specified data field is copied the from the associated entity data. For example, selecting Email copies the Email attribute from the entity to the given LDAP attribute. If the entity has several attributes of the same type, only the first attribute or all attributes can be selected.

  • Use Policy Callback

    The value is given as a parameter to the scheme policy callback function and its result is stored to the attribute.

    Example functions provided in policy.scm include

    • make-user-name

      Takes either the CN or the G and S fields from the subject name and makes them a single name string.

    • current-time

      Replaced with current time value in 2001-10-21 20:15:30 format.

    • set-certificate

      The value is replaced with a binary certificate. In addition, the attribute name is replaced with cACertificate if the CA flag of the certificate is set.

When publishing an object, the system first tries to search the object from the LDAP directory. If the object does not exist, the system performs an add operation with the given path name and attribute. If the object already exists, the system performs the publishing action selected for the attribute. The actions can be:

  • Update by replace: The system tries to perform a replace-type modify operation. This means that previous values of the attribute are replaced with the new value(s), creating the attribute if it did not exist. If this fails, the publishing attempt fails and the engine can either mark the publishing attempt as failed or restart the operation after a delay.
  • Update by add: The system tries to perform an add-type modify operation. This means that the new attribute value is added to the list of existing attribute values, creating the attribute if it did not exist. If this fails, the publishing attempt fails.
  • Initial add only: If the attribute already exists, the publishing attempt fails.

Default Publishing Schemas

The LDAP publishing schema can be reset to default values by selecting a schema and clicking the Set button in the Reset to default box.

The available default schemas for certificate publishing are:

  • LDAPv2 pkiUser schema
  • LDAPv3 pkiUser schema
  • LDAPv2 strongAuthenticationUser schema
  • LDAPv3 strongAuthenticationUser schema

The available default schemas for CRL publishing are:

  • LDAPv2 pkiCa shcema
  • LDAPv3 pkiCa shcema
  • LDAPv2 certificationAuthority shcema
  • LDAPv3 certificationAuthority shcema
  • ActiveDirectory schema

RFC 2587, Internet X.509 Public Key Infrastructure LDAPv2 Schema, defines object classes for certain PKI objects. For certificates the standard defines the object classpkiUser, which can be configured in SSH Tectia Certifier by selecting LDAPv2 pkiUser schema under Reset to default and clicking Set.

For CRLs the RFC defines multiple object classes, one of which is pkiCa. It can be configured in SSH Tectia Certifier by selecting LDAPv2 pkiCa schema under Reset to default and clicking Set.

Note that both the pkiUser and the pkiCA are auxiliary object classes which means that you have to use a structural object class with them. There are also common structural object classes containing attributes for certificates and CRLs such as inetOrgPerson and eidCertificationAuthority. Also these can be used when the directory schema supports them.

Other Options

Clicking the Commit Changes button will update the data into the Database and clicking the Cancel button will ignore the changes.


PreviousNextUp[Front page] [Index]

===AUTO_SCHEMA_MARKUP===