The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: appendix/para
Context English State
<package>sysutils/ldapvi</package> is a great utility for editing LDAP values in an LDIF-like syntax. The directory (or subsection of the directory) is presented in the editor chosen by the <envar>EDITOR</envar> environment variable. This makes it easy to enable large-scale changes in the directory without having to write a custom tool.
<package>security/openssh-portable</package> has the ability to contact an LDAP server to verify <application>SSH</application> keys. This is extremely nice if you have many servers and do not want to copy your public keys across all of them.
<application>OpenSSL</application> Certificates for LDAP
If you are hosting two or more LDAP servers, you will probably not want to use self-signed certificates, since each client will have to be configured to work with each certificate. While this is possible, it is not nearly as simple as creating your own certificate authority, and signing your servers' certificates with that.
The steps here are presented as they are with very little attempt at explaining what is going on—further explanation can be found in <citerefentry><refentrytitle>openssl</refentrytitle><manvolnum>1</manvolnum></citerefentry> and its friends.
To create a certificate authority, we simply need a self-signed certificate and key. The steps for this again are
Creating a Certificate
<prompt>%</prompt> <userinput>openssl genrsa -out root.key 1024</userinput>
<prompt>%</prompt> <userinput>openssl req -new -key root.key -out root.csr</userinput>
<prompt>%</prompt> <userinput>openssl x509 -req -days 1024 -in root.csr -signkey root.key -out root.crt</userinput>
These will be your root CA key and certificate. You will probably want to encrypt the key and store it in a cool, dry place; anyone with access to it can masquerade as one of your LDAP servers.
Next, using the first two steps above create a key <filename>ldap-server-one.key</filename> and certificate signing request <filename>ldap-server-one.csr</filename>. Once you sign the signing request with <filename>root.key</filename>, you will be able to use <filename>ldap-server-one.*</filename> on your LDAP servers.
Do not forget to use the fully qualified domain name for the <quote>common name</quote> attribute when generating the certificate signing request; otherwise clients will reject a connection with you, and it can be very tricky to diagnose.
To sign the key, use <option>-CA</option> and <option>-CAkey</option> instead of <option>-signkey</option>:
Signing as a Certificate Authority
<prompt>%</prompt> <userinput>openssl x509 -req -days 1024 \
-in ldap-server-one.csr -CA root.crt -CAkey root.key \
-out ldap-server-one.crt</userinput>
The resulting file will be the certificate that you can use on your LDAP servers.
Finally, for clients to trust all your servers, distribute <filename>root.crt</filename> (the <emphasis>certificate</emphasis>, not the key!) to each client, and specify it in the <literal>TLSCACertificateFile</literal> directive in <filename>ldap.conf</filename>.

Loading…

No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: appendix/para
Flags
read-only
Source string location
article.translate.xml:961
String age
a year ago
Source string age
a year ago
Translation file
articles/ldap-auth.pot, string 168