LDAP Linux LDAP TLS: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
Строка 4: | Строка 4: | ||
ТУТ я просто дублирую статью со своими комментариями и изменениями |
ТУТ я просто дублирую статью со своими комментариями и изменениями |
||
− | < |
+ | <BR> |
У меня в отличие от примера - 2 сервера в режиме мастер-мастер репликации, потому мне нужно 3 сертификата (по факту - 1 на оба сервера но на момент написания статьи я этого не понимал) |
У меня в отличие от примера - 2 сервера в режиме мастер-мастер репликации, потому мне нужно 3 сертификата (по факту - 1 на оба сервера но на момент написания статьи я этого не понимал) |
||
Версия 14:05, 30 мая 2016
LDAP Шифрование
ТУТ я просто дублирую статью со своими комментариями и изменениями
У меня в отличие от примера - 2 сервера в режиме мастер-мастер репликации, потому мне нужно 3 сертификата (по факту - 1 на оба сервера но на момент написания статьи я этого не понимал)
- Для сервера ldap1
- Для сервера ldap2
- Для сервера ldap - адрес который будет проксировать запросы на один из 2 серверов.
Подготовка 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