Bz1212001: cherry-pick

xml/security_ldap_ca.xml

@@ -5,15 +5,15 @@
     %entities;
 ]>
 
-<sect1 xmlns="http://docbook.org/ns/docbook" 
-       xmlns:xi="http://www.w3.org/2001/XInclude" 
-       xmlns:xlink="http://www.w3.org/1999/xlink" 
-       version="5.0" 
+<sect1 xmlns="http://docbook.org/ns/docbook"
+       xmlns:xi="http://www.w3.org/2001/XInclude"
+       xmlns:xlink="http://www.w3.org/1999/xlink"
+       version="5.0"
        xml:id="sec-security-ldap-server-ca">
  <title>Importing TLS server certificates and keys</title>
  <para>
-  You can manage your CA certificates and keys for &ds389; with the following 
-  command line tools: <command>certutil</command>, <command>openssl</command>, and 
+  You can manage your CA certificates and keys for &ds389; with the following
+  command line tools: <command>certutil</command>, <command>openssl</command>, and
   <command>pk12util</command>.
  </para>
  <para>
@@ -23,62 +23,63 @@
   <filename>/etc/dirsrv/slapd-<replaceable>INSTANCE-NAME</replaceable>/ca.crt</filename>.
   </para>
   <para>
-    For production environments, it is a best practice to use a third-party 
-    certificate authority, such as Let's Encrypt, CAcert.org, SSL.com, or 
-    whatever CA you choose. Request a server certificate, a client 
+    For production environments, it is a best practice to use a third-party
+    certificate authority, such as Let's Encrypt, CAcert.org, SSL.com, or
+    whatever CA you choose. Request a server certificate, a client
     certificate, and a root certificate.
   </para>
  <procedure>
-  <para>
-  Before you can import an existing private key and certificate into the NSS
-  database, you need to create a bundle of the private key and the server 
-  certificate. This results in a <filename>*.p12</filename>
-  file.
-  </para>
   <important>
-  <title><filename>*.p12</filename> file and friendly name</title>
-  <para>
-   When creating the PKCS12 bundle, you must encode <literal>Server-Cert</literal>
-   as the friendly name in the <filename>*.p12</filename> file.
-   Otherwise the TLS connection will fail, because the &ds389; searches for 
-   this exact string.
-  </para>
   <para>
-    The friendly name cannot be changed after you
-    import the <filename>*.p12</filename> file into the NSS
-    database.
+  The Mozilla NSS (Network Security Services ) toolkit uses nicknames for certificates in the certificate store.
+  The server certificate uses the nickname <emphasis>Server-Cert</emphasis>.
   </para>
- </important>
+  </important>
  <step>
   <para>
-   Use the following command to create the PKCS12 bundle with the required friendly name:
+   Use the following commands to remove the Self-Signed-CA and Server-Cert from the instance:
   </para>
-<screen>&prompt.sudo;<command>openssl pkcs12 -export -in <replaceable>SERVER.crt</replaceable></command> \ 
-<command>-inkey <replaceable>SERVER.key</replaceable></command> \
-<command>-out <replaceable>SERVER.p12</replaceable> -name Server-Cert</command></screen>
+<screen>&prompt.sudo;<command>dsctl <replaceable>INSTANCE_NAME</replaceable> tls remove-cert Self-Signed-CA</command>
+&prompt.sudo;<command>dsctl <replaceable>INSTANCE_NAME</replaceable> tls remove-cert Server-Cert
+</command>
+</screen>
+
   <para>
-   Replace <replaceable>SERVER.crt</replaceable> with the server certificate
-   and <replaceable>SERVER.key</replaceable> with the private key to be bundled.
-   Use <option>-out</option> to specify the name of the <filename>*.p12</filename>
-   file. Use <option>-name</option> to set the friendly name, which must be
-   <literal>Server-Cert</literal>.
+   Replace <replaceable>INSTANCE_NAME</replaceable> with the instance name of the directory server.
+   This is LDAP1 in the previous sections.
   </para>
  </step>
  <step>
    <para>
-     Before you can import the file into the NSS database, you need to
-     obtain its password. The password is stored in the
-     <filename>pwdfile.txt</filename> file in the 
-     <filename>/etc/dirsrv/slapd-<replaceable>INSTANCE-NAME/</replaceable></filename> directory.
+    Import the CA that has signed your certificate.
    </para>
+   <screen>&prompt.sudo;<command>sudo dsctl <replaceable>INSTANCE_NAME</replaceable> tls import-ca
+   /path/to/CA/in/PEM/format/CA.pem  <replaceable>NICKNAME_FOR_CA</replaceable>
+</command>
+</screen>
+<para>Replace <literal>INSTANCE_NAME</literal> with the instance name of the directory server.
+Replace <literal>/path/to/CA/in/PEM/format/CA.pem</literal> with the full path to the CA certificate file in the PEM format.
+Replace <literal>NICKNAME_FOR_CA </literal> with a nickname for the CA. </para>
  </step>
  <step>
   <para>
-   Now import the <replaceable>SERVER.p12</replaceable> file
-   into your &ds389a; NSS database:
+   Import the server certificate and the key for the certificate.
   </para>
-  <screen>&prompt.sudo;<command>dsctl <replaceable>INSTANCE_NAME</replaceable> tls remove-cert Self-Signed-CA</command>
-&prompt.sudo;<command>pk12util -i <replaceable>SERVER.p12</replaceable> -d /etc/dirsrv/slapd-<replaceable>INSTANCE-NAME</replaceable>/cert9.db</command></screen>
- </step>
+  <screen>&prompt.sudo;<command>dsctl <replaceable>INSTANCE_NAME</replaceable> tls import-server-key-cert
+  <replaceable>/path/to/SERVER.pem</replaceable> <replaceable>/path/to/SERVER.key</replaceable></command>
+  </screen>
+  <para> Replace <literal>INSTANCE_NAME</literal> with the instance name of the directory server.
+Replace <literal>/path/to/SERVER.pem</literal> with the full path to the server certificate in PEM format.
+Replace <literal>/path/to/SERVER.key</literal> with the full path to the server certificate key file in the PEM format.
+</para>
+</step>
+<step>
+  <para>
+   Restart the instance so that the new certificates are used.
+  </para>
+  <screen>&prompt.sudo;<command>systemctl restart dirsrv@<replaceable>INSTANCE-NAME.</replaceable>.service
+</command> </screen>
+<para>Replace  <literal>INSTANCE_NAME</literal> with the instance name of the directory server.</para>
+</step>
  </procedure>
- </sect1> 
+ </sect1>