Alcuni sistemi non possono connettersi a LDAP tramite LDAP, ma altri possono, è il jolly jert?

Quando provo a stabilire connessioni ldaps al mio server Novel eDirectory 8.8, a volte devo inserire TLS_REQCERT neveril file ldap.conf dei server client. Ovviamente, questa è una cattiva idea.

Il comando che eseguo è qualcosa del genere con credenziali che funzionano davvero ...

ldapsearch -x -H ldaps://ldapserver -b 'ou=active,ou=people,dc=example,dc=org' -D 'cn=admin,dc=example,dc=org' -W "cn=username"

Su Ubuntu 13.10, funziona benissimo.

Su SLES funziona benissimo.

Su CentOS 6.5 restituisce:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Ora, il certificato che ho importato è un certificato jolly acquistato da DigiCert. Il mio collega ha trovato alcuni rapporti che indicano che alcuni sistemi hanno problemi con i caratteri jolly.

Quindi, è la colpa del carattere jolly cert? In tal caso, come posso ripararlo?

Se non è il cert jolly, che cos'è?

Seguendo il suggerimento di Andrew Schulman, ho aggiunto -d1al mio comando ldapsearch. Ecco cosa ho finito con:

ldap_url_parse_ext(ldaps://ldap.example.org)
ldap_create
ldap_url_parse_ext(ldaps://ldap.example.org:636/??base)
Enter LDAP Password: 
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.example.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.225.0.24:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: certdb config: configDir='/etc/openldap' tokenDescription='ldap(0)' certPrefix='cacerts' keyPrefix='cacerts' flags=readOnly
TLS: cannot open certdb '/etc/openldap', error -8018:Unknown PKCS #11 error.
TLS: could not get info about the CA certificate directory /etc/openldap/cacerts - error -5950:File not found.
TLS: certificate [CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 2 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Da quanto detto, CentOS non si fida di DigiCert? Oppure CentOS non ha un elenco di emittenti fidati?

ssl-certificate ldap edirectory

— David R.
fonte

"Impossibile contattare il server LDAP" sembra più che il server non sia semplicemente raggiungibile da quella macchina client. Hai verificato prima di poter effettivamente collegarti ad esso? Ad esempio telnet ldapserver ldapso openssl s_client -connect ldapserver:636.

— Richard E. Silverman,

Sì, ho confermato che può connettersi al server. Dopotutto, non funzionerebbe mai se non riuscisse a connettersi affatto.

— David R.

Hai menzionato tre host client diversi. Quello che non funziona potrebbe non essere stato in grado di connettersi a causa di un problema di rete mentre gli altri potevano farlo.

— Richard E. Silverman,

Ho pensato che il mio post fosse abbastanza chiaro che stavo modificando il file ldap.conf su tutti gli host. Come quando ho aggiunto la linea al file, ha funzionato, ma senza la linea non ha funzionato. Pertanto, non è un problema di connessione.

— David R.

Non mi è stato chiaro quando ho letto il tuo post inizialmente, anche se vedo cosa intendi ora. Comunque, le informazioni di debug TLS che hai aggiunto mostrano il problema; Ho aggiunto una risposta per il follow-up.

— Richard E. Silverman,

Risposte:

ldapsearch sta cercando in / etc / openldap / cacerts il suo archivio di certificati CA attendibili, che apparentemente non è impostato, quindi rifiuta il certificato poiché non può costruire una catena di fiducia per esso. Se ldapsearch utilizzava OpenSSL, avrebbe bisogno di una raccolta di formati "hashdir" prodotta ad esempio dal programma "authconfig" di Red Hat o di un singolo file con un elenco semplice di certificati attendibili. Il riferimento qui a "moznss" suggerisce che questo ldapsearch è costruito su Mozilla NSS, nel qual caso è necessario utilizzare "certutil" per creare il certificato db (o meglio, puntarlo nell'archivio certificati NSS di sistema, se presente) .

Sui sistemi in cui funziona ldapsearch deve avere un archivio certificati funzionante, forse perché quei pacchetti OpenLDAP sono invece creati con OpenSSL (o forse c'è un negozio funzionante in stile NSS disponibile lì).

— Richard E. Silverman
fonte

Ah. /etc/openldap/certsè dove si trova il negozio di certificati. Non dolci. In /etc/openldap/ldap.conf sono passato TLS_CACERTDIR /etc/openldap/cacertsa TLS_CACERTDIR /etc/openldap/certse il mio comando ldapsearch ha iniziato a funzionare. Grazie!

— David R.

Ho installato ldapsearch su Ubuntu 16.04 e non esiste una directory / etc / openldap.

— vcardillo,

ldapsearch dirà "Impossibile contattare il server LDAP" se non è in grado di verificare il certificato TLS. Aggiungi -d1al tuo comando ldapsearch e controlla le righe di output che iniziano con "TLS:" per ottenere ulteriori informazioni sul mancato funzionamento della connessione TLS e sul perché.

— Andrew Schulman
fonte

Ho modificato la mia domanda in risposta al tuo suggerimento. Grazie!

— David R.

La soluzione dipende dalla tua installazione:

Se si utilizza un certificato non valido , è possibile forzare l'accettazione /etc/openldap/ldap.confcon la configurazione
```
TLS_REQCERT allow
```
o
```
TLS_REQCERT never
```
Se si utilizza un certificato valido, probabilmente l'installazione di ldap non sa dove si trova l'archivio di certificati CA attendibili (probabilmente a seconda dell'installazione OpenSSL). Quindi puoi provare a impostare la posizione e forzare il controllo /etc/openldap/ldap.confcon la configurazione
```
TLS_CACERT /etc/openldap/cacert
TLS_REQCERT demand
```
/etc/openldap/cacertpuò essere questo o trovarsi in qualsiasi percorso. Deve contenere la catena di certificati della tua CA. Può essere un singolo file con un elenco semplice di certificati attendibili.

I percorsi delle note dipendono dal provider ldap. Potrebbe essere /etc/ldapo /etc/openldapo giù di lì.

— Juan Garcia
fonte