[Pki-devel] Question on cloning and replication . . .

[Matthew Harmsen]

Everyone,

I received the following from a community member who is using Dogtag and 
389:

    I have 2 questions and 1 note.

    *Note:*
    Here is an interesting thing that I noticed during CA cloning:
    When CA to be cloned has secure connection DS enabled, cloning
    process fails.
    None of docs:

      * https://www.dogtagpki.org/wiki/PKI_10.5_Installing_CA_Clone
      * https://github.com/dogtagpki/pki/blob/DOGTAG_10_6_BRANCH/docs/installation/Installing_CA_Clone.md
      * https://github.com/dogtagpki/pki/blob/master/docs/installation/ca/Installing_CA_Clone.md

    is covering this issue.
    Solution here is to use
    pki_clone_replication_master_port=389
    pki_clone_replication_clone_port=389
    pki_clone_replication_security=None
    https://github.com/dogtagpki/pki/blob/DOGTAG_10_5_BRANCH/base/server/etc/default.cfg#L255


    *Question 1 (sorry, bit long):*
    When CA is cloned both DS servers have *nsslapd-referral *attribute
    set in dn: *cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config* entries
    so DS on vm-users4.hostname.com <http://vm-awnuk4.hostname.com>
    would have
    *dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
    nsslapd-referral:
    ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA
    <http://vm-awnuk3.hostname.com:389/o%3Dpki-tomcat-CA>*
    and DS on vm-users3.hostname.com <http://vm-awnuk3.hostname.com>
    *dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
    nsslapd-referral:
    ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
    <http://vm-awnuk4.hostname.com:389/o%3Dpki-tomcat-CA>*
    *I wonder what is the meaning of nsslapd-referral attribute?*
    **

    The reason I'm asking is that I was thinking that for replication
    over SSL maybe nsslapd-referral should be modified
    from *ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
    <http://vm-awnuk4.hostname.com:389/o%3Dpki-tomcat-CA>*
    to *ldaps://vm-users4.hostname.com:636/o%3Dpki-tomcat-CA
    <http://vm-awnuk4.hostname.com:636/o%3Dpki-tomcat-CA>*
    but when I did this nsslapd-referral attribute was reverted to
    original value by DS automatically,
    *so I'm trying to make sure **if nsslapd-referral attribute should
    be left unchanged during enabling of SSL to DS replication?*

    Just in case here is a sample of all changes on both DS (hopefully,
    I didn't miss anything to have properly configured replication over
    SSL):
    vm-users4.hostname.com <http://vm-awnuk4.hostname.com>:
    ------------------------------------
    dn: cn=config
    nsslapd-security: on

    dn: cn=RSA,cn=encryption,cn=config
    nsSSLPersonalitySSL: slapd-vm-users4
    nsSSLToken: internal (software)
    nsSSLActivation: on

    dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
    nsslapd-referral:
    ldap://vm-users3.hostname.com:389/o%3Dpki-tomcat-CA
    <http://vm-awnuk3.hostname.com:389/o%3Dpki-tomcat-CA>

    dn:
    cn=cloneAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping
    tree,cn=config
    nsDS5ReplicaPort: 636
    nsDS5ReplicaTransportInfo: SSL


    vm-users3.hostname.com <http://vm-awnuk3.hostname.com>:
    ------------------------------------
    dn: cn=config
    nsslapd-security: on

    dn: cn=RSA,cn=encryption,cn=config
    nsSSLPersonalitySSL: slapd-vm-users3
    nsSSLToken: internal (software)
    nsSSLActivation: on

    dn: cn=o\3Dpki-tomcat-CA,cn=mapping tree,cn=config
    nsslapd-referral:
    ldap://vm-users4.hostname.com:389/o%3Dpki-tomcat-CA
    <http://vm-awnuk4.hostname.com:389/o%3Dpki-tomcat-CA>

    dn:
    cn=masterAgreement1-vm-users4.hostname.com-pki-tomcat,cn=replica,cn=o\3Dpki-tomcat-CA,cn=mapping
    tree,cn=config
    nsDS5ReplicaPort: 636
    nsDS5ReplicaTransportInfo: SSL


    *Question 2:*
    DS has so called "SSF Restrictions"
    (https://directory.fedoraproject.org/docs/389ds/howto/howto-use-ssf-restrictions.html}
    which may be configured by setting *nsslapd-minssf* attribute in
    *cn=config* entry.
    Default value of *nsslapd-minssf* attribute is 0. W
    Minimum SSF configuration setting can be used to define the minimum
    level of encryption that is required.

    *Do you know what this means?*
    **
    *Should I be concerned?*

    By the way, when is set *nsslapd-minssf* attribute to *128*, DS
    becomes inaccessible and CA is not working.

Thanks in advance for any answers,
-- Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pki-devel/attachments/20201110/67341d83/attachment.htm>