ECS: Como configurar e aceitar certificados por LDAPS no ECS

Summary: Como configurar e aceitar certificados pelo protocolo LDAPS (Lightweight Directory Access Protocol) no ECS.

Αυτό το άρθρο ισχύει για Αυτό το άρθρο δεν ισχύει για Αυτό το άρθρο δεν συνδέεται με κάποιο συγκεκριμένο προϊόν. Δεν προσδιορίζονται όλες οι εκδόσεις προϊόντων σε αυτό το άρθρο.

Δείτε άλλους πόρους

Instructions

LDAPS, também conhecido como LDAP (Lightweight Directory Access Protocol) sobre SSL (Secure Socket Layer) ou TLS (Transport Layer Security), é uma forma de tráfego criptografada de uso do LDAP para um Active Directory (AD) ou servidor LDAP.

LDAPS depende de uma conexão LDAP em funcionamento. Analise o Guia de administração do ECS e este artigo da base de conhecimento ECS: Como configurar uma conexão de servidor AD ou LDAP na interface do usuário

doUm componente essencial com comunicação SSL ou TLS são os certificados. Certifique-se de que os certificados usados não estejam expirados e inválidos. Isso é importante para que todos os certificados em toda a cadeia de certificados estejam corretos.
Verifique com sua equipe de rede a esse respeito.

Para fazer upload da cadeia de certificados LDAPS e habilitar LDAPS, observe as etapas a seguir.
1. Um endereço IP de gerenciamento de nós é obrigatório para carregar a cadeia de certificados LDAPS.
2. O usuário root da interface do usuário do deve carregar a cadeia de certificados LDAPS na interface da CLI de gerenciamento de nós.
3º. O certificado LDAPS é encadeado em um payload XML ao endereço
IP de gerenciamento de nós 3B. Os LDAPS habilitam a configuração de parâmetros em um payload XML para o endereço
IP de gerenciamento de nós 4. Use LDAPS na página do provedor de autenticação ECS, com um nome de domínio totalmente qualificado (FQDN) em vez de um endereço IP.
5. Teste o login do usuário do domínio.

Para a etapa 3,
um FQDN é necessário em vez de um endereço IP como:
"Com certificados SSL, o certificado deve ter um nome alternativo da entidade (SAN) no certificado para corresponder à conexão que está sendo conectada, a SAN é apresentada com apenas um nome DNS para corresponder à configuração no ECS."

Portanto, confirme se a página do provedor de autenticação ECS, caixa de diálogo URL do servidor, está usando um FQDN em vez de um endereço IP.
Exemplo: ldaps://ad-or-ldap-fqdn-domain.com

As etapas acima:

Um endereço IP de gerenciamento de nós é obrigatório para carregar a cadeia de certificados LDAPS.

Para examinar as configurações do ECS em relação às configurações do certificado LDAPS, primeiro obtenha um IP de gerenciamento de nós para usar.
Se houver separação de rede para o gerenciamento da interface do usuário, o "getrackinfo -n" exibirá os valores "MGMT".

Use o endereço IP de gerenciamento de nós. A replicação e a separação da rede de dados não estão relacionadas a estas etapas:

admin@node1:~> getrackinfo -n
Named networks
==============
Node ID       Network          Ip Address        Netmask            Gateway            VLAN               Interface
1            repl              10.xxx.xxx.11     255.255.254.0      xxx.xxx.xxx.xxx    14                 public
1            mgmt              10.xxx.xxx.21     255.255.254.0      xxx.xxx.xxx.xxx    13                 public
1            data              10.xxx.xxx.31     255.255.254.0      xxx.xxx.xxx.xxx    15                 public
2            repl              10.xxx.xxx.12     255.255.254.0      xxx.xxx.xxx.xxx    14                 public
2            mgmt              10.xxx.xxx.22     255.255.254.0      xxx.xxx.xxx.xxx    13                 public
2            data              10.xxx.xxx.32     255.255.254.0      xxx.xxx.xxx.xxx    15                 public
3            repl              10.xxx.xxx.13     255.255.254.0      xxx.xxx.xxx.xxx    14                 public
3            mgmt              10.xxx.xxx.23     255.255.254.0      xxx.xxx.xxx.xxx    13                 public
3            data              10.xxx.xxx.33     255.255.254.0      xxx.xxx.xxx.xxx    15                 public
4            repl              10.xxx.xxx.14     255.255.254.0      xxx.xxx.xxx.xxx    14                 public
4            mgmt              10.xxx.xxx.24     255.255.254.0      xxx.xxx.xxx.xxx    13                 public
4            data              10.xxx.xxx.34     255.255.254.0      xxx.xxx.xxx.xxx    15                 public

Se não houver separação de gerenciamento de rede no VDC, use o endereço IP público do nó.

Nota: A separação de rede tem precedência se a rede de gerenciamento existir.

No exemplo a seguir, não existe MGMT em "getrackinfo -n"; portanto, use o endereço IP público em getrackinfo como o endereço IP de gerenciamento para as próximas etapas.

admin@node1:~> getrackinfo -n 
Named networks 
============== 
Node ID       Network          Ip Address        Netmask            Gateway            VLAN               Interface admin@node1:~>


admin@node1:~> getrackinfo
Node private      Node              Public                                  BMC
Ip Address        Id       Status   Mac                 Ip Address          Mac                 Ip Address          Node Name
===============   ======   ======   =================   =================   =================   =================   =========
192.1XX.2XX.1     1        MA       a4:bf:xx:xx:xx:74   10.xx.xx.1          a4:bf:xx:xx:xx      192.1XX.2XX.101     provo-red
192.1XX.2XX.2     2        SA       a4:bf:xx:xx:xx:c8   10.xx.xx.2          a4:bf:xx:xx:xx      192.1XX.2XX.102     sandy-red
192.1XX.2XX.3     3        SA       a4:bf:xx:xx:xx:e0   10.xx.xx.3          a4:bf:xx:xx:xx      192.1XX.2XX.103     orem-red
192.1XX.2XX.4     4        SA       a4:bf:xx:xx:xx:56   10.xx.xx.4          a4:bf:xx:xx:xx      192.168.219.104     ogden-red

2. O usuário root da interface do usuário é necessário para carregar a cadeia de certificados LDAPS na interface da CLI de gerenciamento de nós.

Use o endereço IP de gerenciamento adquirido para obter o token de usuário root. A senha do usuário root é obrigatória (ou um usuário da interface do usuário com privilégios de administrador da interface do usuário):

curl -s -k -v -u <user> https://<NodeManagementIP>:4443/login 2>&1

Exemplo:

# curl -s -k -v -u root https://10.xxx.xxx.21:4443/login 2>&1
Enter host password for user 'root':
......

< HTTP/1.1 200 OK
< Date: Thu, 14 Jan 2021 13:51:24 GMT
< Content-Type: application/xml
< Content-Length: 93
< Connection: keep-alive
< X-SDS-AUTH-TOKEN: BAAcdWhGbnVRVjd1WlpmR0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxAgAC0A8=
< X-SDS-AUTH-USERNAME: root
< X-SDS-AUTH-MAX-AGE: 28800
<
* Connection #0 to host 10.xxx.xxx.21 left intact
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn><user>root</user></loggedIn>

Se o resultado não for "HTTP/1.1 200 OK", verifique a senha e o endereço IP caso exista separação da rede de gerenciamento da interface do usuário a partir do comando

"getrackinfo -n.".Com o token de usuário root, crie uma variável de token.

Nota: Um token válido pode exigir atualização se estiver em uma nova sessão da CLI:

# export TOKEN='X-SDS-AUTH-TOKEN: BAAcdWhGbnVRVjd1WlpmR0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxAgAC0A8='
Para testar o valor do token, execute um curl Comando para verificar a capacidade:

# curl -k -X GET -H "$TOKEN" https://10.xxx.xxx.21:4443/object/capacity | xmllint --format -        
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed
100   176  100   176    0     0    249      0 --:--:-- --:--:-- --:--:--   250

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cluster_capacity>
  <totalFree_gb>100657</totalFree_gb>
  <totalProvisioned_gb>447005</totalProvisioned_gb>
</cluster_capacity>

3º. O certificado LDAPS é encadeado em um payload XML ao endereço

IP de gerenciamento de nós 3B. Os LDAPS ativam a configuração de parâmetros. Aceite o parâmetro LDAPS em um payload XML para o endereço IP de gerenciamento de nós.

O acima usa o token de usuário root para obter acesso curl ao truststore da interface do usuário do ECS, onde o certificado LDAPS pode ser carregado.
Consulte o Guia do administrador do ECS para obter mais informações sobre "Adicionar certificado LDAP personalizado".

Obtenha as configurações do truststore com um curl GET comando:

curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore/settings | xmllint --format -

Exemplo:

curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore/settings | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<truststore_settings>
  <accept_all_certificates>false</accept_all_certificates>
</truststore_settings>

No exemplo acima, o truststore "accept_all_certificates" está definido como false. Isso significa que nenhum certificado LDAPS é confiável.

O "accept_all_certificates" O termo pode ser ambíguo, mas é um indicador que continua a ser usado para que o ECS determine se os certificados LDAPS devem ser usados.
Um usuário pode querer definir esse conjunto como verdadeiro ou falso, dependendo de suas necessidades. Para testar a conexão LDAPS, defini-la como true e testar o login do usuário pode validar a conexão LDAPS.

Nota: Sempre que um certificado LDAPS é carregado ou removido do truststore, o: "accept_all_certificates" volta ao falso. Portanto, se você editar o truststore, deverá definir o "accept_all_certificates" volta à verdade depois.

Crie um arquivo xml para alterar as configurações do truststore usando um comando curl com um payload xml:

# sudo vi truststoresettings.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<truststore_settings_changes>
<accept_all_certificates>true</accept_all_certificates>
</truststore_settings_changes>


# cat truststoresettings.xml | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<truststore_settings_changes>
  <accept_all_certificates>true</accept_all_certificates>
</truststore_settings_changes>

Para definir accept_all_certificates como false, edite o arquivo de payload como false em vez de true e execute o comando PUT usando o arquivo de payload.

Execute um comando curl com um arquivo xml como payload com um comando curl PUT:

# curl -s -k -X PUT -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore/settings --data-binary @truststoresettings.xml

Para verificar se "accept_all_certificates" está atualizado, execute o comando curl GET:

# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore/settings  | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<truststore_settings_changes>
  <accept_all_certificates>true</accept_all_certificates>
</truststore_settings_changes>

Para examinar o truststore, não apenas a configuração do truststore:

# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore | xmllint --format -

Um exemplo de um truststore vazio do certificado LDAP:

# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<trusted_certificates/>

Vários certificados podem ser necessários, pois o ECS requer toda a cadeia de certificados, o certificado raiz, o certificado de CA, o certificado de host e assim por diante.
Para adicionar um certificado ao truststore, crie um arquivo xml do certificado que o usuário tem. Um certificado pode ter os tipos de arquivo .pem, .crt, .cer e assim por diante.

Para carregar os certificados no ECS, eles devem estar em um formato xml para atuar como um payload xml.

Arquivo de formato não xml do certificado:

# cat cert.crt
-----BEGIN CERTIFICATE-----
MIIF1DCCA7ygAwIBAgIUdK2Ao2/45jYdQP0q6Dr1/ULmnc8wDQYJKoZIhvcNAQEL
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
HhrV5ezjYHY=
-----END CERTIFICATE-----

O formato xml de um comando curl add:

# cat cert.xml | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<trusted_certificate_changes>
  <add>
    <certificate>-----BEGIN CERTIFICATE-----
MIIG2TCCBMGgAwIBAgITMQAAAATxxxxxxxxxxxxxxxxxxxxxxxxxhkiG9w0BAQsF
ADBbMRIwEAYKCZImiZPyLGQBGRYxxxxxxxxxxxxxxxxxxxxxxxxxFgR2aXRjMRMw
.......................
pkHgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzxhlGh2TaTC
xqz4T/sO4ggWs0Yz5nBmCZMDn6nxxxxxxrjX+ahXI=
-----END CERTIFICATE-----</certificate>
  <certificate>-----BEGIN CERTIFICATE-----
MIIG2TCCBMGgAwIBAgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxqhkiG9w0BAQsF
ADBbMRIwEAYKCZImiZxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxZFgR2aXRjMRMw
EQYKCZImiZPyLGQBGRxxxxxxxxxxxxxxxxxxxxxxxxxxRW50ZXJwcmlzZS1DQTAe
Fw0yMDA2MDgwNzQwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxIiMA0GCSqGSIb3DQEB
..........................
8wYIKWr2AqSKKxcBHxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3ykeRMZJk7VpQDQDLN
feFI4rHZ4JOqDWttiHxxxxxxxxxxxxxxxxxxxxxxxxxxxhpXsxyjQIRvrtaCZVXz
GR7Na7Ah1o+9MWenMExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGQlsQ47nZE2YgV
-----END CERTIFICATE-----</certificate>
  </add>
</trusted_certificate_changes>

Faça upload do formato xml do payload do certificado:

curl -i -s -k -X PUT -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore --data-binary @cert.xml

Para verificar se o certificado foi carregado, execute o comando GET, o caractere de linha final no truststore do ECS é " ."

# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<trusted_certificates>
  <certificate>-----BEGIN CERTIFICATE-----
MIIG2TCCBMGgAwIBAgITMQAAAATxxxxxxxxxxxxxxxxxxxxxxxxxhkiG9w0BAQsF
ADBbMRIwEAYKCZImiZPyLGQBGRYxxxxxxxxxxxxxxxxxxxxxxxxxFgR2aXRjMRMw
.......................
pkHgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzxhlGh2TaTC
xqz4T/sO4ggWs0Yz5nBmCZMDn6nxxxxxxrjX+ahXI=
-----END CERTIFICATE-----</certificate>
  <certificate>-----BEGIN CERTIFICATE-----
MIIG2TCCBMGgAwIBAgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxqhkiG9w0BAQsF
ADBbMRIwEAYKCZImiZxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxZFgR2aXRjMRMw
EQYKCZImiZPyLGQBGRxxxxxxxxxxxxxxxxxxxxxxxxxxRW50ZXJwcmlzZS1DQTAe
Fw0yMDA2MDgwNzQwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxIiMA0GCSqGSIb3DQEB
..........................
8wYIKWr2AqSKKxcBHxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3ykeRMZJk7VpQDQDLN
feFI4rHZ4JOqDWttiHxxxxxxxxxxxxxxxxxxxxxxxxxxxhpXsxyjQIRvrtaCZVXz
GR7Na7Ah1o+9MWenMExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGQlsQ47nZE2YgV
-----END CERTIFICATE-----</certificate>
</trusted_certificates>

Para verificar se as configurações do LDAPS não foram revertidas, execute o comando curl GET:

# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore/settings | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<truststore_settings>
  <accept_all_certificates>false</accept_all_certificates>
</truststore_settings>

Se ele for revertido para false, defina-o de volta para true,Como
quando há uma alteração no armazenamento confiável, a configuração pode ser definida como "false".

Execute um comando curl com um arquivo xml como payload com um comando curl PUT:

# curl -s -k -X PUT -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://<NodeManagementIP>:4443/vdc/truststore/settings --data-binary @truststoresettings.xml

Para verificar as configurações do LDAPS:

# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore/settings | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<truststore_settings>
  <accept_all_certificates>true</accept_all_certificates>
</truststore_settings>

Nota: Pode haver vários certificados no truststore. Lembre-se de que toda a cadeia de certificados pode ser necessária.

4. Use LDAPS na página do provedor de autenticação ECS, com FQDN em vez de um endereço IP.

Com a cadeia de certificados LDAPS carregada no truststore do ECS e o accept_all_certificates indicador definido como true, vá para a página do provedor de autenticação da interface do usuário do ECS e altere a URL do servidor de.
< ldap://IP ou FQDN>
do controlador de domínio Para
ldaps://< FQDN>

do controlador de domínio Ou seja:

FQDN com o protocolo

LDAPS Ele deve ser um FQDN para uso do LDAPS.

Um FQDN é necessário em vez de um endereço IP como:
"Com certificados SSL, o certificado deve ter um nome alternativo da entidade (SAN) no certificado para corresponder à conexão que está sendo conectada, a SAN é apresentada com apenas um nome DNS para corresponder à configuração no ECS."

Portanto, confirme se a página do provedor de autenticação ECS, caixa de diálogo URL do servidor, está usando um FQDN em vez de um endereço IP.
Ou seja:
ldaps://fqdn-domain-of-the-ad-or-ldap-server.com

Nota: A porta poderá ser omitida se a porta padrão for usada.

Portas:
A porta padrão para LDAP é 389.
A porta padrão para LDAPS é 636.

Formato de URL se porta não padrão:
< ldap://IP ou FQDN do controlador de> domínio:<porta> ou ldaps://< FQDN do controlador de> domínio:<porta>

5. Teste o login do usuário do domínio.

Em seguida, teste o log-in do usuário do domínio com o protocolo LDAPS se os usuários do domínio podem fazer log-in com sucesso usando o LDAPS.

Portanto, a conexão de protocolo ECS-LDAPS está funcionando.

Outras informações:

Se necessário:
Para remover um certificado do truststore, crie um arquivo xml que corresponda ao certificado a ser removido, mas em vez de "add" como payload, use "remove":

# cat cert_remove.xml | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<trusted_certificate_changes>
  <remove>
    <certificate>-----BEGIN CERTIFICATE-----
MIIG2TCCBMGgAwIBAgITMQAAAATxxxxxxxxxxxxxxxxxxxxxxxxxhkiG9w0BAQsF
ADBbMRIwEAYKCZImiZPyLGQBGRYxxxxxxxxxxxxxxxxxxxxxxxxxFgR2aXRjMRMw
.......................
pkHgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzxhlGh2TaTC
xqz4T/sO4ggWs0Yz5nBmCZMDn6nxxxxxxrjX+ahXI=
-----END CERTIFICATE-----</certificate>
  <certificate>-----BEGIN CERTIFICATE-----
MIIG2TCCBMGgAwIBAgxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxqhkiG9w0BAQsF
ADBbMRIwEAYKCZImiZxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxZFgR2aXRjMRMw
EQYKCZImiZPyLGQBGRxxxxxxxxxxxxxxxxxxxxxxxxxxRW50ZXJwcmlzZS1DQTAe
Fw0yMDA2MDgwNzQwxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxIiMA0GCSqGSIb3DQEB
..........................
8wYIKWr2AqSKKxcBHxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3ykeRMZJk7VpQDQDLN
feFI4rHZ4JOqDWttiHxxxxxxxxxxxxxxxxxxxxxxxxxxxhpXsxyjQIRvrtaCZVXz
GR7Na7Ah1o+9MWenMExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxGQlsQ47nZE2YgV
-----END CERTIFICATE-----</certificate>
  </remove>
</trusted_certificate_changes>

Para usar o arquivo de payload, ou seja, add ou remove, use este comando:

# curl -s -k -X PUT -H Content-Type:application/xml-H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore --data-binary @cert_remove.xml

Para verificar se a carga foi bem-sucedida, execute o comando GET:

# curl -s -k -X GET -H Content-Type:application/xml -H "$TOKEN" -H ACCEPT:application/xml https://10.xxx.xxx.21:4443/vdc/truststore | xmllint --format -
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<trusted_certificates/>

Se você não tiver certeza de que o servidor LDAPS não corresponde ao certificado fornecido, execute o comando abaixo para verificar a resposta esperada da solicitação do servidor LDAPS para obter um certificado correspondente.

Nota: Pede toda a cadeia "verify error:num=21:unable to verify the first certificate".

Neste exemplo, o servidor LDAPS é um certificado autoassinado, em vez de um certificado de terceiros, portanto, ele pode gerar um aviso adicional de que é autoassinado:

# sudo openssl s_client -connect LDAPS_server_IP:636 < /dev/null
CONNECTED(00000003)
depth=0 CN = 
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = 
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
........
---
Server certificate
-----BEGIN CERTIFICATE-----
.......
A cert that it expects.
.......
-----END CERTIFICATE-----
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2223 bytes and written 487 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
.......................
    SRP username: None
    Start Time: 1610452553
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
DONE

Verifique o arquivo de certificado que se conecta ao servidor LDAPS e, se há um certificado correspondente a ser usado, verifique o código de retorno: 0 (ok):

# openssl s_client -connect LDAPS_server_IP:636 -CAfile /home/admin/cert_file_to_be_used.crt
CONNECTED(00000003)
.......
---
Server certificate
-----BEGIN CERTIFICATE-----
.....
.....
-----END CERTIFICATE-----
.......
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:ECDSA+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1
Peer signing digest: SHA1
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2223 bytes and written 487 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
 .........
    Verify return code: 0 (ok)
---

Nota: Os certificados podem expirar e afetar a conexão se não forem atualizados.

Para verificar isso, use este comando:

# cat /home/admin/cert.crt | openssl x509 -dates -noout
notBefore=Jan 12 13:43:52 2021 GMT
notAfter=Jan 12 13:43:52 2022 GMT

Versão JSON do exemplo de comandos.
Se não estiver usando os comandos XML acima (observe que o XML é preferível):

curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore/settings

Exemplo:

curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":false}

Para criar um arquivo JSON para alterar as configurações do truststore usando um comando curl com um payload JSON:

# sudo vi truststoresettings.json
# sudo cat truststoresettings.json
{"accept_all_certificates": "true"}

O módulo json.tool no python pode validar um formato de arquivo JSON. Se houver um erro, o arquivo pode não ser um arquivo JSON. Neste exemplo, não há erros e gera a saída do arquivo, portanto, ele é um arquivo JSON formatado:

# python -m json.tool truststoresettings.json
{
    "accept_all_certificates": "true"
}

Execute um comando curl com um arquivo JSON como payload com um comando curl PUT:

# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore/settings -d @truststoresettings.json

NOTA:
O payload XML PUT usa --data-binary no comando curl, enquanto o payload JSON PUT usa -d No comando curl:
--data-binary

(HTTP) Isso publica os dados exatamente como especificado, sem processamento extra:
--data-ascii aka -d
(HTTP) Este é um alias para -d, --data.

Para verificar se ele está atualizado, execute o comando curl GET:

# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":true}

Teste o log-in do usuário do domínio na interface do usuário do ECS com os certificados LDAPS agora permitidos.

Para examinar o truststore:

# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore

Exemplo de um truststore de certificado LDAP vazio:

# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.xxx.21:4443/vdc/truststore
{"certificate":[]}

O formato JSON para um comando curl add, um arquivo de linha única com caracteres de nova linha substituídos por \n e \r\n:

Exemplo: {"add":["-----BEGIN CERTIFICATE-----\nxxxxx\r\n---END CERTIFICATE-----"]}

# cat cert.json
{"add":["-----BEGIN CERTIFICATE-----\nMIIF1DCCA7ygAwIBAgIUdK2Ao2/45jYdQP0q6Dr1/ULmnc8wDQYJKoZIhvcNAQEL\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nHhrV5ezjYHY=\r\n---END CERTIFICATE-----"]}

Consulte o Guia de Administração do ECS "Adicionar certificado LDAP personalizado". Use esse comando para adicionar ou remover:

# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore -d @cert.json

Para verificar o carregamento:

# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.xxx.21:4443/vdc/truststore
{"certificate":["-----BEGIN CERTIFICATE-----\nMIIF1DCCA7ygAwIBAgIUdK2Ao2/45jYdQP0q6Dr1/ULmnc8wDQYJKoZIhvcNAQEL\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nHhrV5ezjYHY=\r\n---END CERTIFICATE-----"]}

Para verificar se as configurações do LDAPS não foram revertidas, execute o comando curl GET:

# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":false}

Se ele for revertido para false, defina-o de volta para true. Quando há uma alteração no truststore, a configuração pode ser definida como "false".

Execute um comando curl com um arquivo JSON como payload com um comando curl PUT:

# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://<NodeManagementIP>:4443/vdc/truststore/settings -d @truststoresettings.json

Para verificar as configurações do LDAPS:

# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore/settings
{"accept_all_certificates":true}

Nota: Pode haver vários certificados no truststore. Lembre-se de que toda a cadeia de certificados pode ser necessária.

Para remover um certificado do truststore, crie um arquivo JSON que corresponda ao certificado a ser removido, mas em vez de "add" como o payload, use "remove":

# cat cert.json
{"remove":["-----BEGIN CERTIFICATE-----\nMIIF1DCCA7ygAwIBAgIUdK2Ao2/45jYdQP0q6Dr1/ULmnc8wDQYJKoZIhvcNAQEL\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\r\nHhrV5ezjYHY=\r\n---END CERTIFICATE-----"]}

Para adicionar ou remover, use este comando:

# curl -s -k -X PUT -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.21:4443/vdc/truststore -d @cert.json

Para verificar o carregamento:

# curl -s -k -X GET -H Content-Type:application/json -H "$TOKEN" -H ACCEPT:application/json https://10.xxx.xxx.xxx.21:4443/vdc/truststore
{"certificate":[]}

Επηρεαζόμενα προϊόντα

ECS Appliance

Article Number: 000183654

Article Type: How To

Τελευταία τροποποίηση: 04 Νοε 2025

Version: 11

Ελέγξτε αν η συσκευή σας καλύπτεται από τις Υπηρεσίες υποστήριξης.

ECS: Como configurar e aceitar certificados por LDAPS no ECS

Summary: Como configurar e aceitar certificados pelo protocolo LDAPS (Lightweight Directory Access Protocol) no ECS.

Instructions

Επηρεαζόμενα προϊόντα

Ιδιότητες άρθρου

Βρείτε απαντήσεις στις ερωτήσεις σας από άλλους χρήστες της Dell

Υπηρεσίες υποστήριξης

Ιδιότητες άρθρου

Βρείτε απαντήσεις στις ερωτήσεις σας από άλλους χρήστες της Dell

Υπηρεσίες υποστήριξης

ECS: Como configurar e aceitar certificados por LDAPS no ECS

Summary: Como configurar e aceitar certificados pelo protocolo LDAPS (Lightweight Directory Access Protocol) no ECS.

Λεπτομερές άρθρο

Instructions

Επηρεαζόμενα προϊόντα

Instructions

Επηρεαζόμενα προϊόντα

Ιδιότητες άρθρου

Βρείτε απαντήσεις στις ερωτήσεις σας από άλλους χρήστες της Dell

Υπηρεσίες υποστήριξης

Ιδιότητες άρθρου

Βρείτε απαντήσεις στις ερωτήσεις σας από άλλους χρήστες της Dell

Υπηρεσίες υποστήριξης