LDAP Linux LDAP TLS: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
 
(не показаны 3 промежуточные версии этого же участника)
Строка 1: Строка 1:
  +
[[Категория:LDAP]]
  +
[[Категория:Linux]]
  +
[[Категория:SSL]]
 
=LDAP Шифрование=
  
=LDAP Шифрование=
 
* http://pro-ldap.ru/books/openldap-ubuntu-in-practice/tls.html
  
* http://pro-ldap.ru/books/openldap-ubuntu-in-practice/tls.html
Строка 4: Строка 7:
 
ТУТ я просто дублирую статью со своими комментариями и изменениями
  
ТУТ я просто дублирую статью со своими комментариями и изменениями
   
−
<B>
 +
<BR>
 
У меня в отличие от примера - 2 сервера в режиме мастер-мастер репликации, потому мне нужно 3 сертификата (по факту - 1 на оба сервера но на момент написания статьи я этого не понимал)
  
У меня в отличие от примера - 2 сервера в режиме мастер-мастер репликации, потому мне нужно 3 сертификата (по факту - 1 на оба сервера но на момент написания статьи я этого не понимал)
   
Строка 11: Строка 14:
 
* Для сервера ldap - адрес который будет проксировать запросы на один из 2 серверов.
  
* Для сервера ldap - адрес который будет проксировать запросы на один из 2 серверов.
   
  +
Так как в конечной конфигурации все запросы приходят на ldap (HAProxy) то фактически нужно установить этот сертификат на обоих серверах.
  +
Потому часть с генерацией отдельных сертификатов для каждого из серверов можно пропустить.
   
 
==Подготовка CA, выпуск корневого сертефиката==
  
==Подготовка CA, выпуск корневого сертефиката==
Строка 145: Строка 150:
   
   
−
mkdir certs crl newcerts private.
 +
mkdir certs crl newcerts private
 
chmod 700 private
  
chmod 700 private
 
touch index.txt
  
touch index.txt

Текущая версия на 09:06, 30 октября 2023

LDAP Шифрование

ТУТ я просто дублирую статью со своими комментариями и изменениями


У меня в отличие от примера - 2 сервера в режиме мастер-мастер репликации, потому мне нужно 3 сертификата (по факту - 1 на оба сервера но на момент написания статьи я этого не понимал)

  • Для сервера ldap1
  • Для сервера ldap2
  • Для сервера ldap - адрес который будет проксировать запросы на один из 2 серверов.

Так как в конечной конфигурации все запросы приходят на ldap (HAProxy) то фактически нужно установить этот сертификат на обоих серверах. Потому часть с генерацией отдельных сертификатов для каждого из серверов можно пропустить.

Подготовка CA, выпуск корневого сертефиката

Предварительная настройка - создание инфраструктуры CA

Итак, мы создаём централизованную инфраструктуру открытых ключей (PKI) в миниатюре.

Для этого сформируем пару закрытый ключ/корневой сертификат удостоверяющего центра.

Причём сертификат будет подписан этим же закрытым ключом (т. е. станет «самоподписанным»).

Затем сгенерируем новые закрытые ключи для нашей службы каталогов и создадим для неё сертификаты, подписанный закрытым ключом нашего удостоверяющего центра. При этом клиенские рабочие станции должны знать только корневой сертификат.


Используя его они могут установить безопасное соединение с любым сервером, который имеет закрытый ключ и соответствующий ему сертификат, подписанный нашим CA.


Удостоверяющий центр (CA) желательно разворачивать на отдельной машине, не имеющей подключения к сети, но для простоты примера мы проделаем всю работу на ldap1 (node-3)


В конфигурационном файле /etc/ssl/openssl.cnf в секции [ CA_default ] для удобства поменяем значение директивы dir = ./demoCA на dir = ./. В этом же разделе директивой default_days задаётся срок действия выпускаемых сертификатов. 


# cat /etc/ssl/openssl.cnf | grep -v '#' | grep -v ^$

HOME			= .
RANDFILE		= $ENV::HOME/.rnd
oid_section		= new_oids
[ new_oids ]
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
[ ca ]
[ CA_default ]
dir = ./.
default_days	= 3650
policy		= policy_match
[ policy_match ]
countryName		= match
stateOrProvinceName	= match
organizationName	= match
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional
[ policy_anything ]
countryName		= optional
stateOrProvinceName	= optional
localityName		= optional
organizationName	= optional
organizationalUnitName	= optional
commonName		= supplied
emailAddress		= optional
[ req ]
default_bits		= 2048
default_keyfile 	= privkey.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
string_mask = utf8only
[ req_distinguished_name ]
countryName			= Country Name (2 letter code)
countryName_default		= AU
countryName_min			= 2
countryName_max			= 2
stateOrProvinceName		= State or Province Name (full name)
stateOrProvinceName_default	= Some-State
localityName			= Locality Name (eg, city)
0.organizationName		= Organization Name (eg, company)
0.organizationName_default	= Internet Widgits Pty Ltd
organizationalUnitName		= Organizational Unit Name (eg, section)
commonName			= Common Name (e.g. server FQDN or YOUR name)
commonName_max			= 64
emailAddress			= Email Address
emailAddress_max		= 64
[ req_attributes ]
challengePassword		= A challenge password
challengePassword_min		= 4
challengePassword_max		= 20
unstructuredName		= An optional company name
[ usr_cert ]
basicConstraints=CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
nsComment = "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
basicConstraints = CA:true
keyUsage = cRLSign, keyCertSign
[ crl_ext ]
authorityKeyIdentifier=keyid:always
[ proxy_cert_ext ]
basicConstraints=CA:FALSE
nsComment			= "OpenSSL Generated Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo
[ tsa ]
[ tsa_config1 ]

Файлы index.txt и serial будут играть роль своеобразной базы данных, чтобы отслеживать статус выпущенных закрытых ключей и сертификатов.


Создадим каталог для нашего удостоверяющего центра (CA) и установим безопасные права доступа. Затем зададим значение umask таким, чтобы вновь создаваемые файлы имели права доступа чтения и записи только для создавшего их пользователя, затем создадим структуру каталогов и файлов для своего удостоверяющего центра и Сгенерируем закрытый ключ удостоверяющего центра (длиной 4096 бит).

Он должен хранится особенно бережно. Поэтому мы защитим его при помощи шифра AES. Вам будет предложено ввести пароль для доступа к новому закрытому ключу.

Запомните его и не потеряйте. Это последний рубеж защиты от злоумышленника. Без пароля выпустить новые сертификаты не получится. (в моем пример ключ - r00tme) 


0010_prepere_CA.sh

mkdir /root/CA

chmod u=rwx,g=,o= /root/CA
pushd /root/CA
umask 066


mkdir certs crl newcerts private
chmod 700 private
touch index.txt
echo 1000 > serial


# Create key pass = r00tme
openssl genrsa -aes256 -out private/rootca.key 4096
chmod 400 private/rootca.key
chattr +i private/rootca.key

popd

Выпуск корневого сертификата CA

Сейчас мы можем выпустить корневой сертификат удостоверяющего центра, подписав его закрытым ключом rootca.key. Так как это сертификат УЦ, используем расширение v3_ca 

0011_rootCa_crt.sh

openssl req \
-sha256 \
-new \
-x509 \
-days 3650 \
-extensions v3_ca \
-key private/rootca.key \
-out certs/rootca.crt \
-subj /C=UA/ST=Kharkov/L=Kharkov/O=MirantisInc/OU=ServicesDepartment/CN=ca-server/emailAddress=mmaxur@mirantis.com

chmod 444 certs/rootca.crt
chattr +i certs/rootca.crt

openssl x509 -in certs/rootca.crt -noout -text

popd



С помощью модификатора subj заносим в сертификат информацию:

C - Country Name (страна) ST - State or Province Name (штат или провинция) L - Locality Name (город) O - Organization Name (наименование организации) OU - Organizational Unit Name (наименование подразделения) CN - Common Name (имя субъекта или FQDN сервера) emailAddress - Email Address (адрес электронной почты)


Можем посмотреть содержимое сертификата следующей командой: 

openssl x509 -in certs/rootca.crt -noout -text

Удостоверяющий центр готов к выпуску сертификатов.

Создание сертификатов для серверов

Сертификат для сервеа LDAP1

Закрытый Ключ

Создадим закрытый ключ для сервера службы каталогов ldap1 

0012_private_key_for_ldap1.sh

pushd /root/CA
openssl genrsa \
-out private/ldap1.key 4096

chmod 400 private/ldap1.key

popd

Запрос на сертификат

Сгенерируем запрос на подпись сертификата. Наименование организации должно совпадать с наименованием в корневом сертификате УЦ. В качестве Common Name укажем FQDN нашего сервера (в моем случае это ldap1) 

0013_create_cert_request_for_ldap1.sh

pushd /root/CA

openssl req \
-sha256 -new \
-key private/ldap1.key \
-out certs/ldap1.csr \
-subj /C=UA/ST=Kharkov/L=Kharkov/O=MirantisInc/OU=ServicesDepartment/CN=ldap1/emailAddress=mmaxur@mirantis.com

popd

Генерируем сертификат подписанный своим СА

Подпишем его с помощью своего собственного CA: 

0014_create_and_sign_cert_for_ldap1.sh

pushd /root/CA

openssl ca \
-extensions usr_cert \
-notext \
-md sha256 \
-keyfile private/rootca.key \
-cert certs/rootca.crt \
-in certs/ldap1.csr \
-out certs/ldap1.crt

chmod 444 certs/ldap1.crt

popd

Копирование файлов

Так как у нас сертификат генерировался на том же сервере где и используется (node-3 он же ldap1) - то можно просто скопировать его в правильное место и установить права. 

0015_move_certs_to_ldap_config_dir.sh

pushd /root/CA

mkdir /etc/ldap/ssl
chown openldap:openldap /etc/ldap/ssl
chmod 0500 /etc/ldap/ssl
cp certs/ldap1.crt private/ldap1.key /etc/ldap/ssl


chown openldap:openldap /etc/ldap/ssl/{ldap1.crt,ldap1.key}
chmod 0400 /etc/ldap/ssl/{ldap1.crt,ldap1.key}

cp certs/rootca.crt /etc/ssl/certs/

chmod 0644 /etc/ssl/certs/rootca.crt

popd

Проверка сертификата

0016_check_cert.sh

openssl verify -verbose -CAfile /etc/ssl/certs/rootca.crt  /etc/ldap/ssl/ldap1.crt

Конфигурация LDAP сервера

Внести исправления в конфигурацию

0201_install_tls_certs.ldif

dn: cn=config
add: olcTLSVerifyClient
olcTLSVerifyClient: never
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ldap1.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap1.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt



0202_configure_ldap_to_use_tls.sh

ldapmodify -Y EXTERNAL -H ldapi:/// <0201_install_tls_certs.ldif

Запретить нешифрованные подключения

Для того тто бы использовать ldaps:// в настройках /etc/default/slapd 

SLAPD_SERVICES="ldaps://ldap1  ldapi:///"

После рестарта - проверить: 

netstat  -ntpl | grep slap
tcp        0      0 10.20.0.3:636           0.0.0.0:*               LISTEN      17649/slapd

Настроить /etc/ldap/ldap.conf

Настроить файл конфигурации /etc/ldap/ldap.conf который используют клиенты: 

BASE            dc=fuel_domain
URI             ldaps://ldap1
TLS_CACERT      /etc/ssl/certs/rootca.crt
TLS_REQCERT     demand
TIMELIMIT       15
TIMEOUT         20


Проверка конфигурации

Проверить конфигурацию: 

0203_check_config.sh

ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls



olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt
olcTLSCertificateFile: /etc/ldap/ssl/ldap1.crt
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap1.key
olcTLSVerifyClient: never

Проверить подключение на уровне tls/ssl (так же можно провериять и другие подключения - не только LDAP): 

0204_check_tls_connection.sh

gnutls-cli \
-p 636 ldap1 \
-d 1 \
--print-cert \
--x509cafile  /etc/ssl/certs/rootca.crt


Processed 1 CA certificate(s).
Resolving 'ldap1'...
Connecting to '10.20.0.6:636'...
- Certificate type: X.509
 - Got a certificate list of 2 certificates.
 - Certificate[0] info:
  - subject `C=UA,ST=Kharkov,O=MirantisInc,OU=ServicesDepartment,CN=ldap1,EMAIL=mmaxur@mirantis.com', issuer `C=UA,ST=Kharkov,L=Kharkov,O=MirantisInc,OU=ServicesDepartment,CN=ca-server,EMAIL=mmaxur@mirantis.com', RSA key 4096 bits, signed using RSA-SHA256, activated `2016-05-26 17:23:29 UTC', expires `2026-05-24 17:23:29 UTC', SHA-1 fingerprint `a8d1ac296e514badd9aed44fbc405a76e7e63d1b'

-----BEGIN CERTIFICATE-----
MIIGKTCCBBGgAwIBAgICEAIwDQYJKoZIhvcNAQELBQAwgZwxCzAJBgNVBAYTAlVB
MRAwDgYDVQQIDAdLaGFya292MRAwDgYDVQQHDAdLaGFya292MRQwEgYDVQQKDAtN
aXJhbnRpc0luYzEbMBkGA1UECwwSU2VydmljZXNEZXBhcnRtZW50MRIwEAYDVQQD
DAljYS1zZXJ2ZXIxIjAgBgkqhkiG9w0BCQEWE21tYXh1ckBtaXJhbnRpcy5jb20w
HhcNMTYwNTI2MTcyMzI5WhcNMjYwNTI0MTcyMzI5WjCBhTELMAkGA1UEBhMCVUEx
EDAOBgNVBAgMB0toYXJrb3YxFDASBgNVBAoMC01pcmFudGlzSW5jMRswGQYDVQQL
DBJTZXJ2aWNlc0RlcGFydG1lbnQxDTALBgNVBAMMBGxkYXAxIjAgBgkqhkiG9w0B
CQEWE21tYXh1ckBtaXJhbnRpcy5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQC1a5nMVGd00XODBLZmPJIME89ybRrxzJIhlPk33p6g/8Hh9sTj3U9m
JQ/QLWORyDGXVJM5UEdInYD5xSU9l/CZY81Z6Uwk4X6GtRng8Au/8mT0hidSPy0F
BtJmgzgafMjUHbQWJbgXzbXz6Gu4Pu+NKh2gkaCrFN59wOJOGOhnf4TMVLoVw+f9
rn7hA0NcWWhs0sQ6ZPvhsic0A6qh1LgYEzTSSFReywbKH2xg+v4qGoHnnkw2U4r0
pBUYF22WGMrD1khh9QKbsWtQrH5YNcrTJ8c3gIYioTtAH/BwvAvVZp3G2i3R5cD4
gDY56OUIuFfTuuYJvpSWC8dInGRxwoZ3RnFvKFn5N1RwKULe9LlR2+ATi4PwIn7q
rJaa4ukhhr6SRNBSRQsQH1b7kXCIpwSbCNxzTBL/HdvzYHd0CmFhiu3BgiyvjY0u
WvnKk8q/u3j0SkjoG7rebrMhZcXz7Leza2F3O8tSZ7bXeBty1HVnFc8a4SQ52N/f
IIAwBgZQoIGgfkNKzriUZnRn6+tABj6JE5dEv9/BQ77FceoB/cLaK7BnEXRxbTYQ
qyqjLXIwaRM14hDUSuVmRxHA6eGiTZ1YktYQwwZM9/erSw/EpD8Eweg2G8Bf1I1C
JoJkP3Bj5RojE6OM5xcn4G3EsPylunoBcZLwVVqEiyBCpgoIU84uYwIDAQABo4GJ
MIGGMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQfFh1PcGVu
U1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUgtaUYQW3gDDQnTcP
b0KA4WeeWAEwHwYDVR0jBBgwFoAU/msFAiI92/9ld4t5M9XYonUlHyIwDQYJKoZI
hvcNAQELBQADggIBAINHcZZCARgRLZYKGjNkste5L14z+YMA51aBrS6RcwllTM8b
1UAWAwtcVD/GsU21nNYKlRu0cH2Iv8CbZiT1zhrZDCfbcr2l+P5LAtxhObvdr+pk
+tHijGbRgAXGYGlDXUT7sECf8Hw588IVMJw5DPUo0Fl4yppsE6/YBodbCl4dD+/R
uqBrJVT6HwA/Hx1Cgz5+wjTNSztsljQE7U9eJNVoH1hk/W1iHjweAPkgmjdnpfA9
zYxWxAIW4wMY2RAnIaQuyYt4a8L0097VEOUlM9N+dHMtImS0Z+Qgyr7tCViYwHZV
MehpzxsaGbDU0fe8qF474LyA9D62u+BqpHA1FVjQXPtY39zFnWBc83ZQgj2y6gfV
XuYtAcnK7j/QZqE+KfemlNc5G45rvWstkNkbnNgl78R3h3Jx0Dsu0JrBsqU0qjmp
CPyZfbUi6F21B3hf+BzKhTiE4g8MRvddLVRiXGTsyorzbsFnj5R5LyVTDFobvS4W
9KEjd7jaHxrlTLo/e3G1PRymF63wIa90mgcQgjTuKsO4R7BU7KRSPJr/oBUhYS0/
p2QHDxEWmH/uy+Qc3X7tNUqpnqbd3tx3WnXFNClqbp3RVymwrolZV/8dgrE1sy1/
+DwfXsmeK06+Bykppun6glQGL1GX+E9kMZsiWXIrfOocvRqLtbAmX1qt1/jk
-----END CERTIFICATE-----

 - Certificate[1] info:
  - subject `C=UA,ST=Kharkov,L=Kharkov,O=MirantisInc,OU=ServicesDepartment,CN=ca-server,EMAIL=mmaxur@mirantis.com', issuer `C=UA,ST=Kharkov,L=Kharkov,O=MirantisInc,OU=ServicesDepartment,CN=ca-server,EMAIL=mmaxur@mirantis.com', RSA key 4096 bits, signed using RSA-SHA256, activated `2016-05-26 10:16:07 UTC', expires `2026-05-24 10:16:07 UTC', SHA-1 fingerprint `0f74fdaf2195ae2b1f599e3963e3b18970cb81a3'

-----BEGIN CERTIFICATE-----
MIIGGjCCBAKgAwIBAgIJAN1rpxx3AA9AMA0GCSqGSIb3DQEBCwUAMIGcMQswCQYD
VQQGEwJVQTEQMA4GA1UECAwHS2hhcmtvdjEQMA4GA1UEBwwHS2hhcmtvdjEUMBIG
A1UECgwLTWlyYW50aXNJbmMxGzAZBgNVBAsMElNlcnZpY2VzRGVwYXJ0bWVudDES
MBAGA1UEAwwJY2Etc2VydmVyMSIwIAYJKoZIhvcNAQkBFhNtbWF4dXJAbWlyYW50
aXMuY29tMB4XDTE2MDUyNjEwMTYwN1oXDTI2MDUyNDEwMTYwN1owgZwxCzAJBgNV
BAYTAlVBMRAwDgYDVQQIDAdLaGFya292MRAwDgYDVQQHDAdLaGFya292MRQwEgYD
VQQKDAtNaXJhbnRpc0luYzEbMBkGA1UECwwSU2VydmljZXNEZXBhcnRtZW50MRIw
EAYDVQQDDAljYS1zZXJ2ZXIxIjAgBgkqhkiG9w0BCQEWE21tYXh1ckBtaXJhbnRp
cy5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCuZEMVa87WGQJl
1foQGNt4Qh/CWcggjjIqn8IYSPPtqn3YAxvUnubA+DQxkH7PNYR6G9PdNgQon2mV
xvwVFL6YouDkPtEO101B3vM28U3vEEOSLUcign+2XqzKf7lqyXzMK7/wk+iubAfH
hVhXosC+TSwH+eywO1lo2vbOZkf93ZiURDEZfixcMLuYMM8xdOeWeWtnQIA7D8QF
E5wADWXaYpMlmZzHmmtx76l5BGZL75pG0YkAexllu5idlqADhN77xGM69ZSV/pYJ
apMRhy4z0e17UzEbGWgv6OnUNhwGhOCgyIRk7PTKyjU+mxh3qdoNaqNt7Jj60EB7
dvzHeosrizcYaFwaqbBxVRMKJOcNYh7ZYlyrdexa9Wau3xf0NFvyBZ8rvsBv9Ax+
xuRCq2uVGc3rQHZzkwocquAgACY+1GpxFtpNUBhvmi25TUbm8OkAq7lYpf2sptJH
ReZf4EdHhWuHLI93X5Pm6cb0uE+85kuJPNGMprcwvWM5QiT1N56LAVKiApZTSqo8
bcuJZs+nXI4IrYRXjCn75E0LLRpVLXc7+vfKHgHClL9/bhOxcOdwyXejnDQVzWe4
5JvwzLtL3/4KDiTLjG4foJztosxn92cAJAp30cdUalf7QkEFqp5RCvRY2vFVosM5
0Vu3bicGcyucHyxigxWP44qpaJe9WwIDAQABo10wWzAdBgNVHQ4EFgQU/msFAiI9
2/9ld4t5M9XYonUlHyIwHwYDVR0jBBgwFoAU/msFAiI92/9ld4t5M9XYonUlHyIw
DAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBAHMZ
609hm52CYxouUnvH+timAgiqbVv8QCb6IzgM5uRNejlxTzj63RBFvxC6n2UPqBpj
yGtYuwpO249e+sD01ZS0r4B69a3yBePH6Ay4leqfStuqc9dcyamK7lQk8PAsF4wv
yrywNpgGbecDReHJPrOmc5nQw3AlhwcwceHHS7mqaS+SWj1md97saD8uqHK0O5vu
PFlJUKiztQqR2PMPWiKw+Pjri+RAXHj4TCxjPt5Z0wSR+xP/YE1MymvegPUrZ7/7
rFWuqfHDVLh7IA16q+h1xU+FMnVdiPigEJ+Omn6dDfqHD9BBcKOUFYOJiXtG4TDc
tX401kpG1Qm00kS3XtveQgGPF1OWNLyyDr1dDy8/B+77W1yli/VbzK6H4jwrVGy7
EAEzpfbwRJnSIIUczG8//1G6a5yrpcjohKhWY1uBrv56LJdq16OVN3aK5nacMKmQ
p+YpPu/ZT5LVUOzt8I32Q8i1Tn9YZma7vEftvGCZKVcgqlVIpb3P7/7dyRXoMuFD
bErDIDxScMvg82Vg2JF4NzaOp+CXRAYuXbel5anoFOt7FFfnO2w0/aLQpAT+jpze
qcL37IGyCGxOloej7NkdQsX9eJJNIdy5oLjniJ8/d402A0zziPdfrqa0c3FpGukZ
syWlWH0RCerDgVmq+i6l5zGbtx/tKPpLYcJkAetJ
-----END CERTIFICATE-----

- The hostname in the certificate matches 'ldap1'.
- Peer's certificate is trusted
- Version: TLS1.2
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

Создание сертификата для сервера LDAP2

Все действия - аналогичны LDAP1

Ключ

1012_private_key_for_ldap2.sh

pushd /root/CA
openssl genrsa \
-out private/ldap2.key 4096


chmod 400 private/ldap2.key


popd

Запрос на сертефикат

1013_create_cert_request_for_ldap2.sh

pushd /root/CA


openssl req \
-sha256 -new \
-key private/ldap2.key \
-out certs/ldap2.csr \
-subj /C=UA/ST=Kharkov/L=Kharkov/O=MirantisInc/OU=ServicesDepartment/CN=ldap2/emailAddress=mmaxur@mirantis.com

popd

Создание и подписывание сертификата

1014_create_and_sign_cert_for_ldap2.sh

pushd /root/CA

openssl ca \
-extensions usr_cert \
-notext \
-md sha256 \
-keyfile private/rootca.key \
-cert certs/rootca.crt \
-in certs/ldap2.csr \
-out certs/ldap2.crt

chmod 444 certs/ldap2.crt

popd

HA Mode

Так как в дальнейшем нам понадобиться Единый сертификат - то генерируем его полностью аналогичным образом.
Причины, почему нужно использовать один сертификат на всех серверах реплики

  • Запрос приходит на hostname = LDAP а не на hostname = LDAP1/LDAP2 соответственно в сертефикате должно быть указано "имя" кластера. Запросы к нодам кластера напрямую по их именам в этом случае требуют игнорирования ошибок TLS
  • Так как репликация касается в том числе и имен файлов сертификатов лучше что бы они были одинаковы для всех серверов.


2012_private_key_for_ldap.sh

pushd /root/CA
openssl genrsa \
-out private/ldap.key 4096

chmod 400 private/ldap.key

popd



2013_create_cert_request_for_ldap.sh

pushd /root/CA


openssl req \
-sha256 -new \
-key private/ldap.key \
-out certs/ldap.csr \
-subj /C=UA/ST=Kharkov/L=Kharkov/O=MirantisInc/OU=ServicesDepartment/CN=ldap/emailAddress=mmaxur@mirantis.com


popd

2014_create_and_sign_cert_for_ldap.sh

pushd /root/CA

openssl ca \
-extensions usr_cert \
-notext \
-md sha256 \
-keyfile private/rootca.key \
-cert certs/rootca.crt \
-in certs/ldap.csr \
-out certs/ldap.crt

chmod 444 certs/ldap.crt

popd

3201_install_tls_certs.ldif

dn: cn=config
replace: olcTLSVerifyClient
olcTLSVerifyClient: never
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ldap.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap.key
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt

3202_configure_ldap_to_u~s_one_name_on_cluster.sh

ldapmodify -Y EXTERNAL -H ldapi:/// <3201_install_tls_certs.ldif
Источник — https://noname.com.ua/mediawiki/index.php?title=LDAP_Linux_LDAP_TLS&oldid=12180