openLDAP ssl/tls Centos 6.3

[Pavel Kankovsky]

On Wed, 12 Mar 2014, Katerina Bubenickova wrote:

>> Samozřejmě, že to zůstane "viset". Je to server, který čeká, až se s 
>> ním někdo na jmenovaném portu spojí. Proto můj dotaz pokračoval:
>>>> ... a pak se s ním spojíte pomocí openssl s_client na ten port?
>
> Jsem to na poprvé nepochopila, děkuju za trpělivost:
>
>> [root na test-LDAP log]# openssl s_client -connect localhost:12345
>> CONNECTED(00000003)
>> depth=1 DC = cz, DC = plbohnice, CN = PNB CA cert
>> verify error:num=19:self signed certificate in certificate chain
>> verify return:0
>> ---
>> Certificate chain
>>  0 s:/CN=test-LDAP.bohnice.cz
>>    i:/DC=cz/DC=plbohnice/CN=PNB CA cert
>>  1 s:/DC=cz/DC=plbohnice/CN=PNB CA cert
>>    i:/DC=cz/DC=plbohnice/CN=PNB CA cert
>> [...]

Takže klíče a certifikáty v databázi jsou asi použitelné a chyba bude 
spíš v samotném LDAPovém serveru.


On Wed, 12 Mar 2014, Katerina Bubenickova wrote:

> při dotazu je množství logování dáno parametrem -d - to je ve výpisech
> v minulých mejlech ldapsearch -x -d 1 [...]
> myslela jsem, že je to u serveru, ale možná ne.

To rozhodně není. Parametr -d u ldapsearch nastavuje ukecanost klienta.

> Teď se mi podařilo zvýšit loglevel na serveru na 1
> po příkazu [...]
> Mar 12 13:19:49 test-LDAP slapd[7481]: slap_listener_activate(8):
> Mar 12 13:19:49 test-LDAP slapd[7481]: >>> slap_listener(ldaps:///)
> Mar 12 13:19:49 test-LDAP slapd[7481]: connection_get(14): got connid=1002
> Mar 12 13:19:49 test-LDAP slapd[7481]: connection_read(14): checking for input on id=1002
> Mar 12 13:19:49 test-LDAP slapd[7481]: connection_read(14): TLS accept failure error=-1 id=1002, closing
> Mar 12 13:19:49 test-LDAP slapd[7481]: connection_close: conn=1002 sd=14

Podle toho id=1002 soudím, že to možná nebyl úplně "čerstvý" server.
Neobjevily se nějaké další hlášky dřív, zejména při prvním pokusu po 
restartu?

> a při loglevel -1

Připadá mi, že dále je v tom citovaném výpisu jen konec zpracování jednoho 
spojení a pak začátek zpracování druhého spojení. Je to nějaké ukecanější, 
ale nikde tam není nic o TLS.

>> - Jake je CN u SSL/TLS certifikatu?
> Jak to cn poznám? Všechno, co o certifikátu umím zjistit, jsem napsala
> v minulém mejlu. Možná je cn ten nickname, pak je to v pořádku.

Certifikát má jméno toho, pro koho je vystaven (subject). To jméno má 
formu tzv. distinguished name (DN) a skládá se z tzv. atributů, 
které mají vždy typ a hodnotu (může to být i složitější, ale to raději 
neřešme). Ovšem ke jménům používaným v Internetu to pasuje jako hranatý 
kolík do kulaté díry, a tak někdo (Netscape?) vymyslel, že v případě 
použití X.509 pro SSL bude klientská strana kontrolovat, zda se v DN 
vyskytuje položka typu common name (CN) mající hodnotu odpovídající plně 
kvalifikovanému DNS jménu, se kterým se chce klient spojit. Později se 
vymyslel poněkud lepší mechanismus (alternative names), ale tohle už tak 
nějak zůstalo.

Hádám, že tazatel chtěl vedět, že je v CN správně jméno serveru. V daném 
případě je certifikát vystaven pro DN "CN=test-LDAP.bohnice.cz" (jak bylo 
vidět např. z detailního výpisu certutil, který byl kuriozně obsažen v 
dopise, který současně s tím dotazem citoval) a stejným jménem je na něj i 
odkazováno, a tudíž je to asi dobře. Ale vzhledem k tomu, že se klient ani 
nedostane k tomu, aby se mohl a certifikát serveru podívat, tak na tom až 
tolik nezáleží.

-- 
Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /