openLDAP ssl/tls Centos 6.3

[Pavel Kankovsky]

On Mon, 17 Mar 2014, Katerina Bubenickova wrote:

> Aktualizovala jsem, než jsem začala úpravy - hned po naklonování
> serveru. [...]

Aha... vskutku máte aktuální verzi. Přehlédnul jsem, že citovaný kus kódu 
je z úplně jiného místa, než jsem očekával. Omlouvám se.

>> -12285 je SSL_ERROR_NO_CERTIFICATE
> Ne, že bych to byla někdy schopna zopakovat sama, ale čistě ze
> zvědavosti - kde se tenhle popis chyb najde?

V dokumentaci k NSS je k nalezení taková pěkná tabulka:
<https://developer.mozilla.org/en-US/docs/NSS/SSL_functions/sslerr.html>

Ovšem pro obecné kódy z NSPR jsem našel jen seznam bez kódů:
<https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR/API_Reference/NSPR_Error_Handling>
a musel jsem si to najít ve zdrojácích (prerror.h).

> spustila jsem
> /usr/lib64/nss/unsupported-tools/selfserv -d /etc/openldap/certs -n
> Server-Cert -p 12345 -f /etc/openldap/certs/tmp/pwdfile
> [...]
> Je zajímavé, že stejný výstup měl příkaz openssl s_client ... i bez
> parametru -f, i když jsem tam napsala špatnou cestu k pwdfile, i když už
> to bylo správně...

To je skutečně zajímavé. To podle mne znamená, že v databázi máte privátní 
klíč v nešifrované podobě (což není úplně dobré).

> kromě problému,
> Missing separate debuginfos, use: debuginfo-install
> sqlite-3.6.20-1.el6.x86_64
> vidím také
> /usr/include/bits/string3.h: No such file or directory - to tam opravdu
> není. Je to potřeba?

Myslím, že není.

> Krokování tlsm_deferred_ctx_ini:
> [...]
>> (gdb)
>> SECMOD_RestartModules (force=0) at pk11util.c:1520
>> 1520		return SECFailure;

Toto vypadá spíš jako tlsm_deferred_init bez "ctx". Ale to nevadí, to se 
také musí provést. (Vypadá to, že funkce bez ctx se volá jen z funkce
s ctx, tak jí asi kompilátor inlajnoval.)

>> tlsm_deferred_init (arg=0x7fbc48002600) at tls_m.c:1804
>> 1804				if (initctx != NULL) {
>> (gdb)
>> 1799				initctx = NSS_InitContext( realcertdir, prefix, prefix, SECMOD_DB,
>> (gdb)
>> 1804				if (initctx != NULL) {
>> (gdb)

Ať už to předtím provádělo jakékoli běsy, tak ty asi nakonec proběhly 
nějak úspěšně.

>> 1805					certdb_slot = tlsm_init_open_certdb(ctx, realcertdir, prefix);
>> (gdb)
>> 1806					if (certdb_slot) {
>> (gdb)
>> 1808						ctx->tc_initctx = initctx;
>> (gdb) print PR_GetError()
>> $215 = -12285

Ale tady je to nějaká podivnost. PR_GetError() sice vrací novou hodnotu, 
ale jinak to vypadá, jako by pokračoval. Je možné, že PR_GetError() 
podobně jako errno může obsahovat zmatečné hodnoty, pokud funkce 
neindikuje, že došlo k chybě, návratovou hodnotou. Doporučil bych ještě 
pokračovat až k místu, kde to skutečně vzdá.

Jiná možnost by byla zkusit místo NSS databáze přece jen použít klíče a 
certifikáty v souborech a la OpenSSL. Sice jsem psal, že podle nového 
světového pořádku by to mělo být v db, ale když koukám na ty zdrojáky, tak 
to vypadá, že podporují i PEM (je k tomu potřeba knihovna nsspem.so, ale 
zdá se, že je přibalena v balíku nss). Nicméně to bych asi zkoušel až jako 
kdyby nepomohlo nic jiného.

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