Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

9.9. Using Certificate-based Client Authentication

Directory Server supports certificate-based authentication of LDAP clients and for server-to-server connection, such as replication.
Depending on the configuration, the client can or must authenticate using a certificate, if you enabled certificate-based authentication. After verifying the certificate, the server searches for the user in the directory, based on the attributes in the subject field of the certificate. If the search return exactly one user entry, Directory Server uses this user for all further operations. Optionally, you can configure that the certificate used for authentication must match the Distinguished Encoding Rules (DER)-formatted certificate stored in the userCertificate attribute of the user.
Benefits of using certificate-based authentication:
  • Improved efficiency. When using applications that prompt once for the certificate database password and then use that certificate for all subsequent bind or authentication operations, it is more efficient than continuously providing a bind DN and password.
  • Improved security. The use of certificate-based authentication is more secure than non-certificate bind operations because certificate-based authentication uses public-key cryptography. Bind credentials cannot be intercepted across the network. If the certificate or device is lost, it is useless without the PIN, so it is immune from third-party interference like phishing attacks.

9.9.1. Setting up Certificate-based Authentication
링크 복사

To enable certificate-based authentication:
  1. Enable encrypted connections. For details, see Section 9.4, “Enabling TLS”.
  2. Install the CA certificate and set the trust options for client and server connections. See Section 9.3.2, “Installing a CA Certificate”.
  3. Optionally, verify that the CT,, trust options for client and server are set for the CA certificate: 
    # dsconf -D "cn=Directory Manager" ldap://server.example.com security ca-certificate get "Example-CA"
Certificate Name: Example-CA
Subject DN: CN=server.example.com,ST=Queensland,C=AU
Issuer DN: CN=server.example.com,,ST=Queensland,C=AU
Expires: 2021-05-09 10:57:54
Trust Flags: CT,,
    Copy to Clipboard Toggle word wrap
  4. Create the /etc/dirsrv/slapd-instance_name/certmap.conf file to map information from the certificate to Directory Server users. For example: 
    certmap default         default
default:DNComps         dc
default:FilterComps     mail,cn
default:VerifyCert      on

certmap example         o=Example Inc.,c=US
example:DNComps
    Copy to Clipboard Toggle word wrap
    This configures that for authenticating users who use a certificate that has the o=Example Inc.,c=US issuer Distinguished Name (DN) set, Directory Server does not generate a base DN from the subject of the certificate, because the DNComps parameter is set empty for this issuer. Additionally, the settings for the FilterComps and VerifyCert are inherited from the default entry.
    Certificates that have a different issuer DN than the specified one will use the settings from the default entry and generate the base DN based on the cn attributes in the subject of the certificate. This enables Directory Server to start the search under a specific DN, without searching the whole directory.
    For all certificates, Directory Server generates the search filter using the mail and the cn attribute from the certificate's subject. However, if the mail does not exist in the subject, Directory Server will automatically use the value of the certificate's e attribute in the subject.
    For further details and descriptions of the available parameters, see the description of the certmap.conf file in the Red Hat Directory Server Configuration, Command, and File Reference.
  5. Enable client authentication. For example, to configure that client authentication is optional: 
    # dsconf -D "cn=Directory Manager" ldap://server.example.com security set --tls-client-auth="allowed"
    Copy to Clipboard Toggle word wrap
    Alternatively, set the --tls-client-auth parameter to required to configure that clients must use a certificate to authenticate.
  6. If you enabled that the authenticating certificate must match the one stored in the userCertificate attribute of the user by setting alias_name:VerifyCert on in the /etc/dirsrv/slapd-instance_name/certmap.conf file, add the certificates to the user entries. See Section 9.9.2, “Adding a Certificate to a User”.

9.9.2. Adding a Certificate to a User
링크 복사

When you set up certificate-based authentication, you can set that the certificate used to authenticate must match the one stored in the userCertificate binary attribute of the user. If you enabled this feature by setting alias_name:VerifyCert on in the /etc/dirsrv/slapd-instance_name/certmap.conf file, you must add the certificate of the affected users to their directory entry.

Important

You must store the certificate in the Distinguished Encoding Rules (DER) format in the userCertificate attribute.
To store a certificate in the userCertificate attribute of a user:
  1. If the certificate is not DER-formatted, convert it. For example: 
    # openssl x509 -in /root/certificate.pem -out /root/certificate.der -outform DER
    Copy to Clipboard Toggle word wrap
  2. Add the certificate to the user's userCertificate attribute. For example: 
    # ldapmodify -D "cn=Directory Manager" -W -p 389 -h server.example.com -x

dn: uid=user_name,ou=People,dc=example,dc=com
changetype: modify
add: userCertificate
userCertificate:< file:///root/example.der
    Copy to Clipboard Toggle word wrap
For further details about using binary attributes, see Section 3.1.8, “Using Binary Attributes”.

9.9.3. Forcing the EXTERNAL SASL Mechanism for Bind Requests
링크 복사

At the beginning of a TLS session, the client sends its certificate to the server. Then, it sends its bind request. Most clients issue the bind request using the EXTERNAL SASL mechanism, which signals Directory Server that it needs to use the identity in the certificate for the bind, instead of the credentials in the bind request.
However, if a client uses simple authentication or anonymous credentials, this information is missing. In this case, the TLS session fails with invalid credentials, even if the certificate and the client identity in the certificate was valid.
To configure that Directory Server forces clients to use the EXTERNAL SASL mechanism and to ignore any other bind method in the request: 
# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-force-sasl-external=on
Successfully replaced "nsslapd-force-sasl-external"
Copy to Clipboard Toggle word wrap

9.9.4. Authenticating Using a Certificate
링크 복사

To use the OpenLDAP client tools, to authenticate to a Directory Server instance that supports authentication using a certificate:
  1. Set the following environment variables to the corresponding paths for the CA certificate, the user key, and the user certificate. For example: 
    LDAPTLS_CACERT=/home/user_name/CA.crt
LDAPTLS_KEY=/home/user_name/user.key
LDAPTLS_CERT=/home/user_name/user.crt
    Copy to Clipboard Toggle word wrap
    Alternatively, set the TLS_CACERT, TLS_KEY, and TLS_CERT parameters in the ~/.ldaprc file. For details, see the TLS OPTIONS section in the ldap.conf(5) man page.
  2. Connect to the server. For example: 
    # ldapwhoami -H ldaps://server.example.com:636
    Copy to Clipboard Toggle word wrap
If you use a different client, see the client application's documentation for how to connect using certificate-based authentication.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat