Self Signed tanúsítványok használata konzolon (Lynx, Links, PHP fopen)

Debian GNU/Linux

Sziasztok!

Egy számomra érdekes probléma megoldásában kérném segítségeteket. Van egy ügyfelünk, akitől megkaptuk a saját Root tanúsítványukat, és elküldték a számunkra generált kliens tanúsítványt. CA.cel, illetve client.pfx. A tanúsítványokat beállítottam FF-ban, tökéletesen megy. A cím megnyitásakor rákérdez, hogy melyik kliens tanúsítványt akarom használni. IE alatt ugyanígy, tökéletesen működik. Viszont... Nem nézegetni akarnánk ezt a szervert, hanem PHP függvényeken keresztül, Debian szerverről kommunikálni vele :)

Tehát... Ugyanezekkel a tanúsítványokkal konzolról:
links: Egy szép nagy fekete hiba, ahol közli, hogy bizony kliens tanúsítvány kellene....
lynx: SSL error:no issuer was found-Continue? Azt mondom igen, és kilép...

De ha teszem azt, így még el is indulna... Mint ahogyan XP-n külön be kellett állítani IE és FF alá, itt is külön be kell állítani, vagy okosabb a Linux és egy helyen tárolja a tanúsítványokat? Mert attól félek, hogyha esetleg be is jön az oldal mondjuk links -sel, attól még nem biztos, hogy PHP függvényekkel is fog menni :(

Várom az építő jellegű ötleteket, hogyan tudnám a szerverről is elérni az oldalt, köszönöm!

  • 1857 megtekintés

( Elbandi v | 2009. 06. 25., cs – 18:59 )

php-curl, annak meglehet adni tanusitvanyokat

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( hrgy84 | 2009. 06. 25., cs – 20:09 )

/etc/ssl ala bekopizod a gyoker CA-d tanusitvanyat. Alapbol nem masolja be, a gyoker.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Na igen... A kapott root tanúsítvány cer kiterjesztésű és kódolt, vagy hogy is mondjam. Tehát ha belenézek, olyan, mint egy program kód. Ezt szépen visszafejtettem openssl -el, létrehoztam egy pem filet, titkosítás nélkül. ---Begin Certificate--- stb, stb. Na ezt a pem fájlt másoltam be a /etc/ssl/certs mappába. Még egy c_rehash parancsot is futattam. Nem ment... Fogtam a saját, kliens tanúsítványomat. A pfx -ből szintén csináltam egy pem-et, amit ugyanide bemásoltam. Ismét c_rehash, semmi. Fogtam, /etc/ssl/private mappába is beraktam, továbbra is semmi... :(

Nem tudom, hogy befolyásol-e vmit, de a tanúsítványokat Win2K3 szerveren generálták.

Ui: de ez még mindig csak a rootCA. Viszont a megnyitott oldal client certificate miatt krehál... :(

Ekhmm... oke, akkor PKI, ahogy en ismerem:
- root CA cert: ezzel szokjak alairni a certifikacios kereseket, hogy ne selfsigned legyen
- server cert: ezt kuldi el a SSL alapu szerver a kapcsolat egyeztetesekor. Tehat, ha azt mondom, hogy https://mail.google.com akkor a mail.google.com eloszor elkuldi a sajat certjet, es ezutan a kliens tud kommunikalni, a ketkulcsu titkositas szabalyai menten
- client cert: ezt a kliens kuldi a szerver fele, authentikacios celzattal. A szerver validalja, majd az eredmenytol fuggoen bologat vagy ingatja a fejet.

Itt most melyikrol beszelunk a fenti harom kozul?

A W2k3 szerveren generalt certeket valoban at kell konvertalni PEM formatumuva, mert ha igaz, akkor DER formatumba araszol ki a certsrv oldalrol az ilyen. Lenyegtelen mi a kiterjesztes. Viszont a cim akkor nem jo, a W2k3 server _nem_ selfsigned certeket allit ki.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Teljesen jogos amit írsz, és bocsi, hogy nem voltam világos! Bár ezek szerint nekem se világos vmi :P

Tehát!
Kaptunk egy file.cer nevű fájlt. Ne haragudj, de ezt tényleg nem tom máshogy mondani, ez a saját root tanúsítványuk. Ezt kell beállítani a böngészőbe, hogy a tanúsítványukat kérdés nélkül hitelesnek vegye. Illetve ebben is az szerepel:
Tulajdonos: CÉGNÉV ROOT CA 2K3
Kiállító: CÉGNÉV ROOT CA 2K3
Na akkor ez legyen DER formátumú, és ezt konvertáltam át PEM -re.

És akkor a másik fájl, amit kaptunk az egy micegunk.pfx fájl, ez a saját kliens tanúsítványunk. Ez is kódolt, ha a forrást akarom megnézni, csak kockákat meg hieroglifákat látok. Ebből is konvertáltam egy "normális", PEM tipusú tanúsítványt. Egyébként MSSQL -es webservice -hoz akarunk csatlakozni.

Az a pfx fajl, az egy pkcs12 fajl, abban lakik egy privat meg egy publik kulcs. Ha van egy webszervered, akkor mindketto kell ala.

Most akkor elmondom en mit gondolok a ti rendszeretekrol:

- Van egy Windows alapu halo, ott egy AD integralt PKI infrastruktura oszt SSL kulcsokat.
- Van egy Linuxos gep, ami konnektalni kivan egy MSSQL-es szerverhez

Namarmost, a kerdesem a kovi: Ezek szerint akkor nektek ugy van beallitva a MSSQL webservice, hogy tanusitvany alapjan authentikaljon (illetve ehhez nem igazan az MSSQL kell, a IIS serverbe kell ezt jol beloni, na mindegy)? Vagy csak siman SSL van beallitva, es SSL protokollon at kapcsolodnatok?

Masik kerdes: a PEM-be mit raktatok? A privat vagy a publikus kulcsot? (normal esetbe a pfx fajl mindkettot tartalmazza) Mert az authentikaciohoz a _publikus_ kulcs is kell, meg a _privat_ is. Lehet ugyanis turmix PEM-et csinalni, amiben ez is van, meg az is van, meg meg DH is van.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( djsilas | 2009. 06. 26., p – 09:53 )

up, csak mert hétfőre mennie kellene a projektnek :S

( djsilas | 2009. 06. 27., szo – 22:57 )

Köszönjük mindenkinek a segítséget, nekem mennem kellett egy ügyfélhez, úgyhogy a programozó kolléga oldotta meg a dolgot a PHP curl módszerrel.

Ha esetleg más is hasonlókkal küzd, íme a lényeg:

$options = array(
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HEADER => true,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_SSL_VERIFYHOST => '0',
CURLOPT_SSL_VERIFYPEER => '0',
CURLOPT_SSLKEYTYPE => 'PEM',
CURLOPT_SSLCERT => '/var/www/domain.hu/cert/publikus.pem',
CURLOPT_CAINFO => '/var/www/domain.hu/cert/rootCA.cer',
CURLOPT_SSLKEY => '/var/www/domain.hu/cert/privat.pem',
CURLOPT_SSLKEYPASSWD => 'jelszo',
CURLOPT_SSLCERTPASSWD => 'jelszo',
CURLOPT_USERAGENT => 'Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)',
CURLOPT_VERBOSE => true,
);