ECS: Come configurare e accettare certificati su LDAPS su ECS

Summary: Come configurare e accettare certificati su LDAPS (Lightweight Directory Access Protocol Secure) su ECS.

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

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

Instructions

LDAPS, noto anche come LDAP (Lightweight Directory Access Protocol) su SSL (Secure Socket Layer) o TLS (Transport Layer Security), è una forma di traffico crittografato di utilizzo di LDAP per un server Active Directory (AD) o LDAP.

LDAPS dipende da una connessione LDAP funzionante. Consultare la Guida all'amministrazione di ECS e questo articolo della knowledgebase ECS: Come configurare una connessione al server AD o LDAP nell'interfaccia utente

diUn componente critico della comunicazione SSL o TLS sono i certificati. Accertarsi che i certificati utilizzati non siano scaduti e non validi. Questa operazione è importante affinché tutti i certificati nell'intera catena di certificati siano corretti.
Verificare con il team di rete a questo proposito.

Per caricare la catena di certificati LDAPS e abilitare LDAPS, prendere nota dei seguenti passaggi.
1. Un indirizzo IP di gestione dei nodi è indispensabile per caricare la catena di certificati LDAPS.
2. L'utente root dell'interfaccia utente deve caricare la catena di certificati LDAPS nell'interfaccia CLI di gestione dei nodi.
3A. La catena di certificati LDAPS in un payload XML all'indirizzo
IP di gestione del nodo 3B. L'impostazione dei parametri di abilitazione LDAPS in un payload XML per l'indirizzo
IP di gestione del nodo 4. Utilizzare LDAPS nella pagina del provider di autenticazione ECS con un nome di dominio completo (FQDN) anziché un indirizzo IP.
5. Testare l'accesso utente al dominio.

Per il passaggio 3,
è necessario un FQDN invece di un indirizzo IP come:
"Con i certificati SSL, il certificato deve avere un nome SAN (Subject Alternate Name) nel certificato per corrispondere alla connessione a cui ci si connette, alla SAN viene presentato solo un nome DNS per corrispondere alla configurazione su ECS".

Pertanto, verificare che la pagina del provider di autenticazione ECS, finestra di dialogo dell'URL del server, utilizzi un FQDN anziché un indirizzo IP.
Esempio: ldaps://ad-or-ldap-fqdn-domain.com

I passaggi precedenti:

Un indirizzo IP di gestione dei nodi è indispensabile per caricare la catena di certificati LDAPS.

Per esaminare le impostazioni ECS relative alle impostazioni del certificato LDAPS, ottenere innanzitutto un IP di gestione dei nodi da utilizzare.
Se è presente la separazione di rete per la gestione dell'interfaccia utente, "getrackinfo -n" visualizza i valori "MGMT".

Utilizzare l'indirizzo IP MGMT dei nodi. La replica e la separazione della rete di dati non sono correlate a questi passaggi:

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 non vi è alcuna separazione di gestione della rete sul VDC, utilizzare invece l'indirizzo IP pubblico del nodo.

NOTA: La separazione della rete ha la precedenza se esiste una rete di gestione.

Nell'esempio seguente non esiste alcun MGMT in "getrackinfo -n"; pertanto, utilizzare l'indirizzo IP pubblico in getrackinfo come indirizzo IP di gestione per i passaggi successivi.

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. L'utente root dell'interfaccia utente deve caricare la catena di certificati LDAPS nell'interfaccia CLI di gestione dei nodi.

Utilizzare l'indirizzo IP di gestione acquisito per ottenere il token dell'utente root. È richiesta la password dell'utente root (o un utente dell'interfaccia utente con privilegi di amministratore dell'interfaccia utente):

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

Esempio:

# 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 l'output non è "HTTP/1.1 200 OK", controllare la password e l'indirizzo IP, cioè se esiste una separazione della rete di gestione dell'interfaccia utente dal comando "getrackinfo -n.".

Con il token utente root, creare una variabile di token.

NOTA: Un token valido potrebbe richiedere l'aggiornamento se in una nuova sessione CLI:

# export TOKEN='X-SDS-AUTH-TOKEN: BAAcdWhGbnVRVjd1WlpmR0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxAgAC0A8='
Per testare il valore del token, eseguire un comando curl Comando per controllare la capacità:

# 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>

3A. La catena di certificati LDAPS in un payload XML all'indirizzo

IP di gestione del nodo 3B. LDAPS abilita l'impostazione dei parametri. Accettare il parametro LDAPS in un payload XML all'indirizzo IP di gestione del nodo.

Quanto sopra utilizza il token utente root per ottenere l'accesso curl al truststore dell'interfaccia utente di ECS in cui è possibile caricare il certificato LDAPS.
Consultare la Guida dell'amministratore ECS per ulteriori informazioni sull'aggiunta di un certificato LDAP personalizzato.

Ottenere le impostazioni del truststore con un curl GET :

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

Esempio:

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>

Nell'esempio precedente, il truststore "accept_all_certificates" è impostato su false. Ciò significa che nessun certificato LDAPS è attendibile.

Le "accept_all_certificates" Il termine può essere ambiguo, ma è un flag che continua a essere utilizzato per ECS per determinare se devono essere utilizzati i certificati LDAPS.
Un utente potrebbe desiderare che questo set sia true o false, a seconda delle proprie esigenze. Per testare la connessione LDAPS, impostandola su true e testando l'accesso dell'utente è possibile convalidare la connessione LDAPS.

NOTA: Ogni volta che un certificato LDAPS viene caricato o rimosso dal truststore, il "accept_all_certificates" si trasforma di nuovo in falso. Pertanto, se si modifica il truststore, è necessario impostare "accept_all_certificates" torna al vero in seguito.

Creare un file xml per modificare le impostazioni del truststore utilizzando un comando curl con un 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>

Per impostare accept_all_certificates su false, modificare il file di payload su false anziché su true ed eseguire il comando PUT utilizzando il file di payload.

Eseguire un comando curl con un file xml come payload con un 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

Per verificare che "accept_all_certificates" sia aggiornato, eseguire il 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>

Per esaminare il truststore, non solo l'impostazione del truststore:

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

Esempio di truststore di un certificato LDAP vuoto:

# 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/>

Potrebbero essere necessari più certificati, in quanto ECS richiede l'intera catena di certificati, il certificato root, il certificato CA, il certificato host e così via.
Per aggiungere un certificato al truststore, creare un file XML del certificato di cui dispone l'utente. Un certificato può essere costituito da tipi di file con estensione pem, .crt, .cer e così via.

Per caricare i certificati in ECS, devono essere in formato xml per fungere da payload xml.

File di formato non xml del certificato:

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

Il formato xml per un 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>

Caricare il formato xml del payload del certificato:

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

Per verificare che il certificato sia stato caricato, eseguire il comando GET; il carattere della riga finale nel truststore 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>

Per verificare che le impostazioni LDAPS non siano state ripristinate, eseguire il 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 è stato ripristinato su false, reimpostarlo su true,
poiché quando si verifica una modifica al truststore, l'impostazione potrebbe essere impostata su "false".

Eseguire un comando curl con un file xml come payload con un 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

Per controllare le impostazioni 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: Potrebbero essere presenti più certificati nel truststore. Tenere presente che potrebbe essere necessaria l'intera catena di certificati.

4. Utilizzare LDAPS nella pagina del provider di autenticazione ECS, con FQDN anziché indirizzo IP.

Con la catena di certificati LDAPS caricata nel truststore ECS e il accept_all_certificates impostare il flag su true, passare alla pagina del provider di autenticazione dell'interfaccia utente ECS e modificare l'URL del server da.
< ldap://IP o FQDN>
del controller di dominio A
ldaps://< FQDN>

del controller di dominio Ovvero:

FQDN con protocollo LDAPS

Deve essere un FQDN per l'utilizzo LDAPS.

È necessario un FQDN anziché un indirizzo IP in quanto:
"Con i certificati SSL, il certificato deve avere un Subject Alternate Name (SAN) nel certificato per la corrispondenza della connessione a cui si sta connette, alla SAN viene presentato solo un nome DNS per corrispondere alla configurazione su ECS".

Pertanto, verificare che la pagina del provider di autenticazione ECS, finestra di dialogo URL server, utilizzi un FQDN anziché un indirizzo IP.
Ovvero:
ldaps://fqdn-domain-of-the-ad-or-ldap-server.com

NOTA: La porta può essere omessa se si utilizza la porta predefinita.

Porte:
La porta predefinita per LDAP è 389.
La porta predefinita per LDAPS è 636.

Formato URL se la porta non è predefinita:
< ldap://IP o FQDN> del controller di dominio:<porta> o ldaps://< FQDN> del controller di dominio:<porta>

5. Testare l'accesso utente al dominio.

Testare quindi l'accesso utente di dominio mentre il protocollo LDAPS verifica che gli utenti di dominio possano accedere correttamente tramite LDAPS.

Pertanto, la connessione del protocollo ECS-LDAPS funziona.

Informazioni supplementari:

Se necessario:
Per rimuovere un certificato dal truststore, creare un file XML che corrisponda al certificato da rimuovere, ma invece di "add" come payload, utilizzare "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>

Per utilizzare il file payload, ovvero aggiungere o rimuovere, utilizzare questo 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

Per verificare se il payload ha avuto esito positivo, eseguire il 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 non si è certi che il server LDAPS non corrisponda al certificato fornito, eseguire il comando seguente per verificare la risposta prevista dalla richiesta del server LDAPS di un certificato corrispondente.

NOTA: Chiede l'intera catena "verify error:num=21:unable to verify the first certificate".

In questo esempio, il server LDAPS è un certificato autofirmato anziché un certificato di terze parti, pertanto potrebbe generare un avviso aggiuntivo che indica che è autofirmato:

# 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

Controllare il file di certificato che si connette al server LDAPS e, se è presente un certificato corrispondente da utilizzare, si tratta di Verify return code: 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: I certificati possono scadere e influire sulla connessione se non aggiornati.

A tale scopo, utilizzare il comando seguente:

# 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

Versione JSON dell'esempio di comandi.
Se non si utilizzano i comandi XML riportati sopra (nota, XML è preferibile):

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

Esempio:

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}

Per creare un file JSON per modificare le impostazioni del truststore utilizzando un comando curl con un payload JSON:

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

Il modulo json.tool su python può convalidare un formato di file JSON. Se si verifica un errore, il file potrebbe non essere un file JSON. In questo esempio, non sono presenti errori e il file restituisce un output che indica che si tratta di un file JSON formattato:

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

Eseguire un comando curl con un file JSON come payload con un 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:
Il payload XML PUT utilizza --data-binary nel comando curl, mentre il payload JSON PUT utilizza -d Nel comando curl:
--data-binary

(HTTP) In questo modo i dati vengono inseriti esattamente come specificato senza alcuna elaborazione aggiuntiva:
--data-ascii aka -d
(HTTP) Questo è un alias per -d, --data.

Per verificare che sia aggiornato, eseguire il 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}

Testare l'accesso dell'utente di dominio sull'interfaccia utente di ECS con i certificati LDAPS ora consentiti.

Per esaminare il truststore:

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

Esempio di truststore di un certificato LDAP vuoto:

# 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":[]}

Il formato JSON per un comando curl add, un file a riga singola con caratteri di nuova riga sostituiti con \n e \r\n:

Esempio: {"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-----"]}

Consultare la Guida all'amministrazione di ECS "Aggiunta di un certificato LDAP personalizzato". Utilizzare questo comando per aggiungere o rimuovere:

# 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

Per verificare il caricamento:

# 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-----"]}

Per verificare che le impostazioni LDAPS non siano state ripristinate, eseguire il 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 il valore è false, reimpostarlo sul valore true. Quando si apporta una modifica al truststore, l'impostazione può essere impostata su "false".

Eseguire un comando curl con un file JSON come payload con un 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

Per controllare le impostazioni 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: Potrebbero essere presenti più certificati nel truststore. Tenere presente che potrebbe essere necessaria l'intera catena di certificati.

Per rimuovere un certificato dal truststore, creare un file JSON che corrisponda al certificato da rimuovere, ma anziché utilizzare "add" come payload. "remove":

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

Per aggiungere o rimuovere, utilizzare questo 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

Per verificare il caricamento:

# 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: Come configurare e accettare certificati su LDAPS su ECS

Summary: Come configurare e accettare certificati su LDAPS (Lightweight Directory Access Protocol Secure) su ECS.

Instructions

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

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

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

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

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

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

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

ECS: Come configurare e accettare certificati su LDAPS su ECS

Summary: Come configurare e accettare certificati su LDAPS (Lightweight Directory Access Protocol Secure) su ECS.

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

Instructions

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

Instructions

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

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

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

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

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

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

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