Megérkezett a wildcard és ACMEv2 támogatás a Let's Encrypt-nél

Titkosítás, biztonság, privát szféra

Részletek a bejelentésben.

( traktor | 2018. 03. 14., sze – 17:43 )

Ez mire jo? A widecard cert akkor jo, ha "kezzel" kell csinalnom egyet, (raadasul fizetek is erte) es sok helyen akarom hasznalni. A Let's Encrypt cert viszont ingyen van, az osszes szerveremen az osszes domainra automatikusan tudok kerni ilyet... akkor minek a wildcard?

Egyet tudok elkepzelni, hogy valaki egy webszerveren uzemeltett csillio _es_ elore nem ismert subdomaint... ez gondolom ugy az esetek 0.001%-a lehet.

Vagy valami mas?

Meg ez is félelmetes:


A Google arra ösztönzi az összes tanúsítványkibocsátót, hogy tüntessék fel az általuk kibocsátott tanúsítványokat nyilvánosan ellenőrizhető, csak kiegészíthető, hamisítástól védett naplókban. A jövőben a Chrome és más böngészők dönthetnek úgy, hogy nem fogadják az ilyen naplókban nem szereplő tanúsítványokat.

Szóval belső felhasználású certet se tudj csinálni anélkül, hogy ne tudjon róla mindenki.

Nem kell pánikolni, csak a publikus, mindenki számára elfogadott cert providerekre vonatkozik a transparency és már tavaly óta csak ilyet fogad el a chrome.

Hogy mi szükség erre?
Enélkül bármelyik cert provider észrevétlenül kiadhatna a fű alatt egy certet pl. a gmail.com domainre, amivel mondjuk az NSA belelátna bárki levelezésébe.


Enélkül bármelyik cert provider észrevétlenül kiadhatna a fű alatt egy certet pl. a gmail.com domainre, amivel mondjuk az NSA belelátna bárki levelezésébe.

És itt akkor pont nincs értelme annak, hogy "megbízható" a kibocsájtó, ha úgyis egyesével kell ellenőrizni a kibocsájtott certeket.

Hasznos maga az ötlet, h. a sunyi v. csak szimplán ostoba cert authority cégeket képes legyen az "átlagember" (gyk. aki nem tagja semmilyen PKI jeditanácsnak) ellenőrizni.
A félelmetes megint csak az, h. a gugli "iamevil" játszik megint internetrendőrséget. Nyilván csak a közjó érdekében, néhány gugli-mérnök nyomja a ráérős heti2napkötelező nonproject kreatívkodós társadalmi munkában, nem-Google infrastruktúráb futtatva a Service-t.
Nem pedig üzlethaszon hátsószándékkal.
--

Öröm látni h. még itt sincs központi megegyezés melyik CA-t használják a tagszervezetek, nehogy lehessen 1 v. max 2 root CA-t cert pinning-elni.
Innentől lesse az ember h. a NAV-nál a Letsencrypt-es cert nem hacking miatt van használatban, de a gate.gov.hu ügyfélkapu loginportálon már azt lesse h. Netlock, 3.-on meg vmi holland tökömtudja CA van. Remélem vmelyik gov.hu vett a Trustico-tól is: http://www.zdnet.com/article/trustico-compromises-own-customers-https-p…
--

( cadmagician | 2018. 03. 15., cs – 09:30 )

Azt mondjatok meg inkabb hogy lanon levo embedded devicera hogyan tudok valid certet kesziteni?
------------------------
Jézus reset téged

Publikálhatnád pár mondatban, mert én szoptam már AD-s környezetben TLS-WPA Enterprise wifi-vel, és az "internal root CA cert publish to any random Apple *.shit" -be annó beletört a bicskám.

Nyilván vmi fizetős MDM-et ráb@szni az almás szarokra jó kerülőmegoldás, de talán egy root CA feltolása még az almás hulladék ios/ Macos-re se lenne szabad h. gond legyen így 2018 környékén. Vagy tényleg az?
--

ez volt az alap. ezzel nekem működött.
https://gist.github.com/fntlnz/cf14feb5a46b2eda428e000157447309

a rootCA-t utána beraktam a brozerekbe, és azzal hitelesíttettem a többit és működött. a vége egy php class lett openssl_* függvényekkel.
ez is fontos:

Add multiple SANs into your CSR with OpenSSL http://wiki.cacert.org/FAQ/subjectAltName

openssl_csr_sign-nél használhats saját cnf-et.


------------------------
Jézus reset téged