Connessione LDAP non riuscita con "PKIX path building failed" dal rinnovo del certificato del controller AD [chiuso]

1

Abbiamo diversi server Linux e Windows che utilizzano l'autenticazione LDAPS su un controller MS AD per le applicazioni che ospitano, che presenta un certificato firmato dalla nostra CA radice interna.

Recentemente, i controller AD hanno rinnovato automaticamente i loro certificati. Da questo momento in poi, la maggior parte dei server Linux ospitati non è riuscita ad autenticarsi su questo controller AD, mentre il server host di Windows ha continuato a funzionare.

Nulla su questi server è cambiato durante questo periodo, solo il certificato del controller AD, i certificati sub e root sono invariati.

Il nostro primo pensiero era che gli host Linux non avessero il certificato radice interno importato come affidabile, ma perché funzionava prima di allora?

Alcuni scavi hanno rivelato che questo controller AD non presenta l'intera catena di certificati, il che significa che manca il certificato CA radice.

L'importazione del certificato CA radice nella maggior parte dei sistemi lo ha risolto.

Come può aver funzionato prima del rinnovo su queste macchine Linux che NON hanno i certificati root / sub attendibili? Anche con una catena di certificati correttamente presentata, questa connessione non dovrebbe essere attendibile, in quanto la CA radice non è conosciuta dal sistema.

Purtroppo non ho accesso al certificato e alla catena che sono stati utilizzati prima, quindi non posso confrontarli, ma non sono state apportate modifiche alla lunghezza delle chiavi o simili.

    
posta parampam 03.01.2018 - 14:59
fonte

1 risposta

0

A seconda del software effettivo che sta eseguendo la convalida della catena di certificati, ci sono diverse possibilità su come questo potrebbe aver funzionato prima del rinnovo:

  • I vecchi certificati erano direttamente affidabili a livello locale senza basarsi sulla fiducia in un'autorità di certificazione.

    Sebbene ciò non sia strettamente possibile (poiché le catene di certificati valide devono iniziare con un certificato di origine), la maggior parte delle implementazioni consente questa opzione (ad esempio, i certificati autofirmati possono essere considerati attendibili senza aggiungere l'overhead di un'impostazione di CA ).

  • Il software non usa il trust store che stai guardando.

Obiter Dictum:

Even with a correctly presented certificate chain, this connection shouldn´t be trusted, as the root CA is not known by the system.

Questo non è esattamente vero. Anche se la CA radice potrebbe non essere attendibile, una CA intermedia potrebbe essere firmata in modo incrociato da un'altra CA in cui il sistema in questione ha stabilito la fiducia.

    
risposta data 03.01.2018 - 15:40
fonte

Leggi altre domande sui tag