Sziasztok!
Szeretnék egy saját Private Public Key Infrastrukturát kialakítani OpenSSL-el. Nem megy. Már nagyon sok időt eltöltöttem vele, és ami a videóban pöpec nálam az se. Nem tudom mit rontok el. Van esetleg valakinek egy működő leírása, Egy linkje? Nem bánom, ha a fő (vagy szebben az intermediate) tanúsítványt kézzel kell importálni.
De mondom a problémámat, hátha arra egyszerűbb mondása lenne:
- Truenas Scale -ben szeretném a Samba 4 AD usereket latni. AD módon nem kapcsolódik, mert nem trusted a kapcsolat.
- Truenas-okat szeretnek pl szinkronizálni. A kapcsolat létrehozásához jelenleg a http-t kell használni, mert nem trusted a https.
- A proxmox-oknal is rauntam a kattogasra.
Ez volt a legígéretesebb, de nekem ez sem... :-(
- 1041 megtekintés
Hozzászólások
easyrsa nem segít hozzá?
- A hozzászóláshoz be kell jelentkezni
Anno amikor kellet par cert, en is azt hasznaltam.
https://github.com/OpenVPN/easy-rsa/blob/master/doc/Intro-To-PKI.md
- A hozzászóláshoz be kell jelentkezni
Először is a PKI nem Private, hanem Public. Lokálisan csinálhatsz olyant, hogy a truststore-okba felveszed a saját, privát CA-d gyökértanúsítványát, amelyik a konkrét tanúsítványt kiadta, ezzel menni fog a láncépítés, de persze, nem lesz szabályos, és lesz pár dolog, ami nem fog működni (revcheck pl., hiszen nincs OCSP respondered sem, gondolom). Inkább azt javaslom, hogy "rendes" tanúsítványokat használj, amelyeket igazi CA-k adnak ki, sok bosszúság és lokális hack megspórolható vele.
Update: az általad linkelt leírás egész korrekt, valószínű, csak a használati helyen levő truststore update maradt el, de látatlanban nem akarok jósolgatni.
Aláírás szünetel...
- A hozzászóláshoz be kell jelentkezni
Szerintem először érdemes megérteni hogyan működik a PKI, azon belül is a certification chain.
Én azt javaslom hogy:
- csinálj egy https-es nginx (v apache, mindegy) webservert
- tedd be a megfelelő "dolgokat" (direkt írom így) a böngésződbe
Ha szép "ződ" lesz az oldal, akkor vagy kész, akkor értetted meg.
Kérdezd a chatgpt-t, jó válaszokat fog adni.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Köszönöm a helyreigazítást javítottam.
Valószínűleg ez az én problémám: a "helyi store". Bookworm alatt bemásoltam /usr/local/shared/ca-certificates-be a CA.crt-t, dpkg-reconfigure ca-certificates és update-ca-certificates futtatásával is próbálkoztam. Látom is, "1 added...". A böngésző cache ürítve, de nem akar trusted lenni.
Nem tudom mit csinálok rosszul de azt következetesen, mert már ráment két napom. Bármilyen banálisnak tűnő javaslatot is kipróbálok! (Loginojak újra?)
- A hozzászóláshoz be kell jelentkezni
Egyszerűbb privát ablakban tesztelni. Csak mindig zárd be a régit és nyiss egy újat.
Még egyszerűbb: curl -vI https://domain.tld
- A hozzászóláshoz be kell jelentkezni
Az a kérdés, hogy az adott szerveren lévő tanúsítványt a root CA-d írta alá, amit betettél a klienseden a trust store-ba (nem a szervernek kell benne megbízni, hanem a kliensnek), vagy készítettél intermediate CA-t is, és az írta alá az ominózus szerver tanúsítványt? Ugyanis a root CA kliensen elhelyezésével nem lesz minden automatikusan elfogadva, csak az, amit közvetlenül a root CA írt alá.
Ha van intermediate CA-d, akkor a webszervernek ne a sima szerver cert-et, hanem a cert chain-t add oda (ez gyakorlatilag egy állományba bemásolva a szerver cert és az internediate CA cert), és onnantól a géped megbízik a root CA-ban, a szervertől kapott cert chain-nel pedig ellenőrizni tudja, hogy az intermediate a megbízható root által aláírt, a szerver cert meg az így megbízhatóvá vált intermediate által aláírt.
Ugyan ezen módon működik pl. a Let's Encrypt is, ott is a fullchain.cer kell a szerverre, mert a böngészők csak a root CA-ban bíznak, az intermediate CA-t meg kell ismerniük valahogy.
Egyébként javaslom az XCA programocska használatát, van minden platformra, és egy elég jól átlátható GUI-n tudod a CA-kat és a certeket, kucsokat kezelni vele. Még naptárat is tud exportálni, amiben benne van, mi mikor jár le, így azt sem kell fejben tartanod.
- A hozzászóláshoz be kell jelentkezni
a böngésző cache-nek semmi köze a certificate chain újraolvasásához.
első körben én a böngészőbe (firefox) importálnám direktben a certificate-et.
igen, a root certificate-et is kell, hogy meglegyen a teljes chain.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
A böngésződ nem foglalkozik a /etc/ssl/certs alatti dolgokkal, saját store-jai vannak, azok egyikébe kell felvenned a saját CA-d tanúsítványát ahhoz, hogy megbízzon a böngésződ a CA-dal aláírt tanúsítványban.
- A hozzászóláshoz be kell jelentkezni
Yup, jo par eve a bongeszok mar okosabbak, mint a system, es minden bongeszo sajat cert store-t hasznal. De sok mas program is, pl anno self-hosted Gitlabnal futottam bele, hogy valami eldugott helyen tarolta a trusted CA-kat.
- A hozzászóláshoz be kell jelentkezni
Böngészője válogatja. A Firefoxnak mindig saját store-ja volt, de tudtommal a Chrome a rendszerbeállításokat használja certificate esetén is.
- A hozzászóláshoz be kell jelentkezni
Amit én javasolnék: ha csak néhány szerverre akarsz certificate-et, ne építs saját PKI-t. Az már most látszik, hogy sok vesződés jól csinálni és főleg hosszú távon kezelni.
Ha amúgy van egy publikus DNS zónád megfelelő szolgáltatónál, akkor helyette igényelj kész Let's Encrypt-es certficate-eket azon belüli hostnevekre. Erre vannak előre gyártott scriptek és tool-ok, amik megteszik, és mindig meg is újítják. DNS validációval meg tudod tenni olyan hostokra is, amik privát hálózaton vannak, és nincsenek is semmilyen porton publikálva. Az egyetlen dolog, ami kell hozzá, hogy a publikus DNS zónádban a server1.example.com mondjuk a 192.168.0.10 címre mutasson, ami a szervered privát IP címe. (Ez lehet kicsit véleményes, hogy zavar-e téged, hogy a privát IP címe megtudható a szerverednek, attól függetlenül, hogy amúgy kívülről emiatt amúgy még nem fognak tudni vele kommunikálni.)
És akkor ha a privát hálózatodon vagy, akkor a server1.example.com -ot megszólítva az egy érvényes cert-et fog mutatni, ráadásul ezt minden kliens el fogja fogadni, nem kell sehová a saját Root CA-t importálni.
- A hozzászóláshoz be kell jelentkezni
Ez egy járható út de az eredeti AD-s kínlódásán nem biztos h segít.
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Igen, a publikus dolgokra revproxy mögött használom a Let's Encryptet. Kezelem a külső és a belső zónát is, certbot-tal szoktam frissítgetni. A public zónában nem akartam privát címeket felvenni (véleményes :-) ), de ha azt mondod működik... lehet ráveszem magam. Az biztos hogy szívás, de elegánsabbnak tűnt (volna első gondolatra). Már csak azért is, mert belső hálózaton valami.lan domain-t használtam/használok mát régóta.
A Let's Encrypt kulcsait meg fogja enni a Samba is? Ha váltok valami public domain-re belül, akkor a Samba-t is újra kell telepítenem. (userek, jelszavak, join-ok...) :-( Fájni fog ez így is úgy is...
- A hozzászóláshoz be kell jelentkezni
Én nem értem, a Samba AD-be hová kell x509 tanúsítvány...
Pontosan miért kell a Samba-hoz ez?
- A hozzászóláshoz be kell jelentkezni
Ja, leesett. A Samba AD kapcsolat nem azért nem trused szerintem, mert a TrueNAS-on nem jó a cert, hanem azért, mert ami klienssel próbálod, az nincs beléptetve az AD-be... Az egy tök más dolog, semmi köze az x509 tanúsítványokhoz.
- A hozzászóláshoz be kell jelentkezni
igen, samba az kerberos, nem x509. hacsak nem ldaps-en akar a sambabol infot kinyerni... de abba se vagyok biztos hogy a samba ezt by default tudja, lehet kell ele valamilyen proxy/stunnel ehhez?
- A hozzászóláshoz be kell jelentkezni
Nyilván neked kell döntened, hogy melyik irányba mész. Pl. ha Samba domaint kell váltani emiatt, akkor lehet, hogy nem éri meg.
Én ezt a Let's Encrypt-es dolgot belső hálózati webszerverekkel, meg egy másik esetben RDP szerver certificate-ekkel csináltam, azokkal működött.
- A hozzászóláshoz be kell jelentkezni
btw szerintetek ez a feladat: hozz létre PKI-t, ez "informatikai szakközép" szintű? (csak h a másik thread-re utaljak)
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
A feladat "bonyolultsága" alapján szerintem oda simán beillene, ez szerintem nem főiskola/egyetem szintű kérdés. Azt nem tudom, hogy a tananyag része-e a PKI/x509 alapok, meg a tool-ok amik kellenek hozzá.
- A hozzászóláshoz be kell jelentkezni
98% a pályázóknak elbukna rajta, végzettségtől függetlenül.
Az elbukottak 80%-a iszonyat fel is lenne háborodva... :)
zászló, zászló, szív
- A hozzászóláshoz be kell jelentkezni
Szerintem ezeket végignézed, és jobban megérted a témát.
ez egy 3részes minisorozat:
-----------
ez meg néhány összetartozó + néhány össze-nem-tartozó, de mind a témáról beszélő:
-----------
Fontos: egyik videó sem a kész megoldást fogja neked adni! Hanem elmagyarázza neked azokat az alapfogalmakat, amiknek megértése után itt újra fel fogod tudni tenni a konkrét kérdésedet. De azt már úgy, olyan formában, amit a többiek is meg fognak tudni érteni, és fognak is tudni érdemben válaszolni rá.
- A hozzászóláshoz be kell jelentkezni
Az openssl az alapja a cuccnak Linuxon - de van elé hat marék alapvertően jól használható frontend is. Ha van X felületed, akkor tinyca2, de inkább xca.Faék egyszerű, mindnt megcsinál, ami egy PKI-hez kell.
- A hozzászóláshoz be kell jelentkezni
Ezt: https://jamielinux.com/docs/openssl-certificate-authority/
olvasd végig egyszer, aztán csináld végig amit ír az ember, a végén lesz egy működő tanúsítvány szolgáltatód.
Ne felejtsd el minden hostra (ahol szeretnéd használni a tanúsítványait) feltelepíteni a root és intermediate CA certeket.
Pár jótanács a certekhez (a böngésző programok kedvéért):
- Ne legyen hosszabb az érvényessége a kiadott (vég felhasználói) certeknek mint 395 nap
- SAN mező mindig legyen és legyen benne a CN feltétlen (én a hostnevet és a host IP -t is bele szoktam tenni)
- A kérelmek generálását és a certek aláírását is érdemes scriptbe rakni, ne gondolj nagy dologra, csak annyi, hogy a tucatnyi kapcsoló közül egy se maradjon ki, soha
- Rakd el a fentebbi linket és terjeszd az igét ;)
----
올드보이
- A hozzászóláshoz be kell jelentkezni
1) kicsi rendszer esetén nem feltétlenül érdemes interediateCA-kat használni
2) az intermediateCA-t a szolgáltatás is leküldheti a tanúsítványával együtt - ebben az esetben elég a rootCA importálása
- A hozzászóláshoz be kell jelentkezni
A root CA nem ír alá végfelhasználói tanúsítványt, így muszáj, hogy legyen intermediate ca. E nélkül törött lesz a tanúsítási lánc.
Minden TLS titkosított szolgáltatás tanúsítvány láncot kell, hogy vissza adjon a handshake -kor, de a lánc ellenőrzése részben nem kötelező, részben pedig az ellenőrzés mélysége tetszőleges.
Ha TLS titkosítást állítasz be egy szolgáltatáson, érdemes testssl.sh -val ellenőrizni, de ez már egy másik topik.
----
올드보이
- A hozzászóláshoz be kell jelentkezni
A root CA nem ír alá végfelhasználói tanúsítványt, így muszáj, hogy legyen intermediate ca. E nélkül törött lesz a tanúsítási lánc.
Ez persze nem igaz :)
- A hozzászóláshoz be kell jelentkezni
Aláírhat, csak nem szokás. Így a root CA-t jobban lehet védeni, azt gyakorlatilag csak akkor kell elővenni ha bármely okból kell egy új intermediate CA.
- A hozzászóláshoz be kell jelentkezni
A root CA nem ír alá végfelhasználói tanúsítványt, így muszáj, hogy legyen intermediate ca. E nélkül törött lesz a tanúsítási lánc.
Bocs, nem tudtam. Nekem az itthoni kis PKI esetén az a 8 tanúsítvány, ami kellett, mind olyan, hogy a rotCA írta alá és mégis működik.
Igen, nagyobb PKI esetén több okból is érdemes bevezetni az inetmediateCA-kat, de a topic indító kérdése alapján én a max 10 cert kategóriában gondolkodtam.
- A hozzászóláshoz be kell jelentkezni
Ilyen még a Microsoft tanúsítványos oktatóanyaga sem ír, pedig azokban szoktak meredek dolgok előfordulni... Az is úgy mondja, hogy egyszerű egy tartományos esetben elég a két szintű PKI, akkor érdemes 3 vagy esetleg több szintűt használni, ha több al-tartomány van, és akkor az intermediate kötődhet egy-egy altartományhoz.
Ezen felül elsősorban akkor használnak intermediate CA-t, ha komoly a dolog annyira, hogy a root CA-nak tényleg megbízhatónak kell lennie, és ezért a kulcsát is HSM-en tartják, és maga a root CA offline. Ilyenkor irtózat macerás lenne a napi használata, így csak intermediate CA-k hitelesítéséhez használják, ráadásul így valami logika mentén szeparálhatóak a tanúsítványok, így egy intermediate kompromittálódása esetén sem a root-ot, sem a többi ágat nem kell kidobni.
Amikor ez az egész csak egy "kényelmi" dolog (ne reklamáljon a böngésző), akkor simán lehet 2 szintű a PKI (root CA és tanúsítványok).
Mi pl. csak azért használunk 3 szintet, mert van egy saját root CA, és minden ügyfélhez van egy intermediate CA, és az írja alá az ügyfél rendszerében lévő tanúsítványokat (amiket a belső menedzsment felületeken használunk - azért, hogy ne reklamáljon a böngésző...). Így nekem csak a saját root CA-t kell felvennem (meg bárkinek, akinél ez szükséges), és a szolgáltatások pedig nem csak a saját tanúsítványt adják, hanem a "láncot" (intermediate+cert).
- A hozzászóláshoz be kell jelentkezni
ráadásul így valami logika mentén szeparálhatóak a tanúsítványok
Nálunk a céges root alatt két intermediate CA van, az egyik a júzereknek, a másik a hálózati eszközök számára állít(hat) ki tanúsítványokat.
- A hozzászóláshoz be kell jelentkezni
2009-ben leírtam a könyvemben, hogyan kell saját CA-t és vele aláírt tanúsítványokat létrehozni. Szerintem azóta is működnek az akkor leírt dolgok: https://www.kosaek.hu/halozat.pdf (a 35. oldaltól kezdődően).
- A hozzászóláshoz be kell jelentkezni