"A Google is megbízhatatlanná nyilvánította a Gattyán-féle Netlock egyik online tanúsítványát"

De ez csak akkor érdekes ha az OS-ekbol veszik ki.

Ez nem a jövő, hanem már történik, lásd: Apple.

Másrészt, ha a Google lép valami jelentősebbet, jelen esetben, valakitől megvonja a bizalmat, azt a korábbi tapasztalatok alapján a többi (birka?) is hamarosan követni fogja.

Harmadrészt, én is szeretnék tisztában lenni vele, hogy milyen alternatívák vannak a jelenleg igénybevett szolgáltatásokra, pláne, ha a technikain felül jelentősebb pénzügyi vonzata is van.

Dehogynem. Ha az aláíró tanusítványt kibocsátó tanusítványát kibocsátó tanusítványt (ejj de szép ez a magyar nyelv a dupla birtokos szerkezettel...) az OS nem ismeri/nem bízik meg, annak kihatása lehet az aláírás ellenőrzésére is (hiába passzol az aláírás, mivel nem hitelesíthető maga a tanusítvány, amihez az aláírás passzol, nem lesz hiteles). A trust chainnek meg kell lennie mindenféle tanusítvány alapú ellenőrzés esetén, különben egy támadó küldhetne neked egy digitálisan aláírt dokumentumot ami LÁTSZÓLAG a küldő tanusítványával van aláírva, kivéve, hogy azt a tanusítványt nem a NetLock hanem a LockNet írta alá mondjuk. Ha nem ellenőrzünk hitelességet az aláíró tanusítványt aláíró kibocsátó tanusítványon, akkor nem garantálható a trust chain konzisztenciája, így nem hitelesíthető a digitális aláírás - akkor sem, ha amúgy a dokumentum integritását igazolná az aláírás.

És ezen az se biztos, hogy segít, ha csatolják a CA főtanusítványt. Elvileg a legfölső (amúgy self-signed) tanusítványban az OS-nek magának kell megbíznia (épp azért, mert self-signed!), attól teljes mértékben függetlenül, hogy az csatolva van-e.

Mivel a Netlocknak a Gold a topmost főtanusítványa (azaz: ez egy self-signed tanusítvány), annak az invalidációja az összes Netlock által kibocsátott intermediate CA és normál tanusítvány érvényességét viszi magával.

Én is mocsok sokat küzdöttem mire megértettem a PKI logikáját, és most sem állítanám 100%-ra, hogy a fenti kocc nélkül megállja a helyét, de a tapasztalataim + a józan paraszti ész ezt diktálja.

Aztán ahogy fentebb is írták, ki tudja azoknál is mekkora a munkaerő csere-bere. Aztán elég ha elmegy a topgun employee, nem tudnak a magyar piacról felvenni másik olyan embert, aki kívül-belül vágja a PKI folyamatokat ilyen szinten. Az új embernek meg elég 1 illegálisan kiadott "véletlen" cert (mondjuk egy wildcard a *.google.com-ra ;) és 60 másodpercen belül rájuk szakad az ég haragja. A 60 másodperc, és az ég haragja is szószerint.

- Nem tud magyarul :D
- Nem feltétlenül tudja fejből az összes kis tanusítványkiadó elérhetőségét
- Lehet, hogy indirekt módon derült ez ki, és mellékesen jelezték, hogy ez IS gond
- Lehet, hogy nem hivatásos Firefox tesztelő, hanem egy random felhasználó jelezte Bugzillában. Sokan mindent, ami a böngészőben történik, lejelentenek a böngészőre mint hiba, akkor is, ha mondjuk a Facebook reagál egy HTTP 502-vel. Nem választják szét

És ez csak 4 dolog ami a délutáni kávém szürcsölése közben eszembe jutott.

- Eleve, gond volt az, hogy a "tesztelő rendszer" csak lejáratot néz, szignaturát nem. Nehogy már ez megbocsátható legyen egy tanusítványkiadótól... Még nyilván sosem hallottak kompromittálódó kiadókról...

- 5 vagy 6 kommenten keresztül nem bírt egyenesen válaszolni arra, hogy ők üzemeltetik a tesztrendszert vagy más, esetleg koprodukció van. Hallom, ahogy a főnök ott állt felette, és mondja, hogy ezt ne mondjuk meg. Közben meg okkal kérdezték. És a végén amikor válaszolt is olyan fura volt a válasz.

- Mi az, hogy az intermediate tanusítvány kiállítása egy tanusítványkiadó életében nem business as usual? Miért, mi az, a kávéfőzés? Középületek átadása? Vagy mit csinál egy tanusítványkiadó, ha nem tanusítványokat állít ki? Amúgy, pont tavaly v tavalyelőtt variáltak az intermedite tanusítványaikkal, szóval annyira még nem is volt régen egy intermediate CA cert kiadása... már ha nem Alzheimeres a fele cég.

- Weekly update nem történt meg: egy ekkora cégnél biztos van elég ember, hogy valaki odaüljön és gépelgesse ezeket az updateket. Ha nincs, akkor érdemes lenne felvenni egyet. A tanusítványok árait elnézve: futná rá.

Komolyan, nem az a bajom, hogy hibák vannak. Az a bajom, hogy hibát hibára halmoznak egy ilyen esetben, ebből nekem nem a professzionalitás az első 15 dolog ami eszembe jut.

Cserébe mocsok drágák, és kizárólag az ő tanusítványuk számít államilag is elismertnek, lehet, hogy egy kicsit több komolysággal kéne ehhez hozzáállni.

De persze én csak egy üzemeltető maci vagyok.

+100.

A fenti listán kívül még van pár cég, ahol PKI-val is foglalkoznak. Mindemellett valóban csak pár, ahol a PKI elméleti és gyakorlati oldalával is egyszerre.

DÁP-ot fejlesztő Qualysoft

Nem kevered az Idomsoft-tal?

Személyes véleményem az hogy függetlenül a politikai helyzettől a magyar piac túl kicsi ahhoz hogy több CA is megéljen rajta, egyszerűen annyira kevés a témához értő szakember (technikai, üzleti ÉS jogi részről is). Nagyon speciális domain tudás kell ami 2-3 év mire felszed valaki alapszinten, magas szinten meg 5-10 is lehet.

Ugye itt látszik a külön nehezítés: felelj meg a folyamatosan változó magyar szabályozásnak is, az EU-s szabályozásnak is, és mindezek mellett mindenféle egyéb olyan szabályozásnak amelyre törvény ugyan nem kötelez viszont a különböző termékfejlesztő cégek rákényszerítenek. 

Nagyon nem hálás terület a CA világa, és hosszú távon én azt látom hogy az állam megcsinálta a saját CA-ját és ezzel fedik le az összes állami és államközeli szervezetet (de innentől kezdve nem kell harmadik féllel foglalkozni) és megmarad egy piaci szereplő aki pedig az összes többit viszi, olyan áron, ahogy akarja.

A Netlocknak ez a core business, nehogy már egy excelt kelljen kézzel töltögetni és lesegetni, nyilván kell lennie ott egy automata riportnak, amiben benne vannak a lejáratok. Az, hogy egy akármilyen cég belefut ilyenbe, az még csak-csak elképzelhető, de ha ebből élnek, akkor legyen a riasztás automatizálva (ha a rootCA offline, akkor pedig induljon be egy processz még a lejárat előtt jóval, úgy, hogy még legyen idő a rendszereken is kicserélni mielőtt eléri a lejárati dátumot). 

Másik oldalról: Te vevőként itt fogsz tanúsítványokat venni, ha ne kap(hat)sz riportot tőlük rendszeresen a lejáratokról (és hogy be tudd tervezni a lejáratkori budget-be a megújítás költségeit), akár beépítve az árba, akár opcióként? 

Pl. figyelem valami monitoring eszközzel az oldalt, ami szól, hogy esedékes a megújítás. Vagy cert igényléskor a megújítás esedékességét felírom egy naptárba. (egyéb eszköz is képes figyelni, az F5 loadbalanceren beállítható, hogy az ott tárolt certificate-ek közeli lejáratáról menjen SNMP trap). Szóval vannak eszközök a kézi megújításnál is emlékeztetőre.

Ne haragudjon már a világ de nekem a saját kis belső dolgaimra is van librenms monitoringom, ami a konkrét URL-eket nézegeti.
Kívülről, mintha user lenne.

Nyilván hanyattesik akkor is ha lejár a certificate. Rendes helyen ez max. a második védelmi vonal lenne.
Első védelmi vonal az konkrétan beleolvashatna a certificate-be hogy mikor jár le és szól előre x idővel (minden nap).

Valszeg librenms-sel is meg lehetne csinálni de nekem annyit nem ér, a certificate-ek eddig mindig megújultak szépen.

Azért az régen rossz, ha valakinek szólnia kell emiatt.

Néhány primitív megoldás - SSL/TLS tansikra:
- Kössük be az egész weboldalt monitoringba. Egy Zabbix, Icinga etc. már a lejárat előtt akár 60 nappal képes szólni.
- Pár soros Bash / Openssl parancsot összerakni még egy kezdőnek is legyen egy fél délután. Felteszi a szerverre, helyben lefut. Riasztást meg küldi emailben. Nem nagy ügy. Utána ez 5 perc alatt adoptálható más weboldalakra, szerverekre is. Na jó, ha Windowsra kell átvinni, akkor esetleg picit faragni kellhet még. 😀

Alkalmazások által használt nem SSL / TLS tanúsítványnál van az igazi rémálom: valaki letesz egy .pfx-t, beírják az alkalmazás konfigba, aztán mindenki elfeledkezik róla. "Működik, ne nyúlj hozzá!". Aztán 1-2-3 év múlva meg lehal az alkalmazás. A logokból túrják ki - ha normálisan logol egyáltalán az alkalmazás -, hogy a tansi lejárt. Láttam már sok ilyen sztorit.

Miért kellhetett 1 hét (nem dolgozom a Netlocknál, csak ismerem a céges folyamatokat általában): simán túl sok emberen megy át az információ. A döntéseket is valakinek meg kell hoznia - általában nem ő kezeli a jegyeket, nem ő adja ki a tansit stb. Minél nagyobb egy cég, annál lassabbak az ilyen folyamatok.

Persze, de nekik saját maguktól kellett igényelni.

Megfelelő szerződés esetén a szolgáltató általában egy nap alatt elkészül, a többi idő a jóváhagyáshoz és a tényleges cseréhez szokott kelleni.

ÁtNyERgelt másokhoz a lakat.