Fórum Root.cz
Hlavní témata => Server => Téma založeno: majvan 29. 09. 2024, 22:58:10
-
Mám embedded zariadenie, ktoré má read-only root filesystem a ktoré bude nainštalované bez ďalšieho prístupu k nemu niekde v teréne.
Chcem dať naňho aplikačného klienta, ktorý komunikuje s https serverom, ktorý bude mať certifikát podpísaný od Let's Encrypt.
Ako zabezpečiť, aby bolo toto zariadenie stále schopné akceptovať certifikát https servera?
Akú periódu obnovy má Let's Encrypt certifikát? Ako funguje v Linuxe update trusted root certifikátov?
-
clientovi (web browser) staci mit certifikat od CA (certifikacni autority), ktery je soucasti instalace a nepotrebuje mit u sebe konkretni certifikat ziskany z letsencrypt. server posle clientovi svoje verejne info k certifikatu a client vyuzije CA k overeni.
-
Trvale to zabezpečit nejde, protože i certifikáty certifikačních autorit se jednou za několik let mění. Už s tím bylo dost problémů, že někdy byly certifikáty CA napevno a CA pak začala používat jiný certifikát.
Let's Encrypt nyní používá kořenový certifikát ISRG Root X1 s platností do roku 2035, ale pravděpodobně přestane být používán mnohem dříve.
V Linuxových distribucích je seznam důvěryhodných certifikátů součástí některého distribučního balíčku, takže se pravidelně aktualizuje tak, jak aktualizujete balíčky. Ovšem pozor na to, že aplikace nemusí používat systémové důvěryhodné certifikáty, může mít vlastní úložiště.
-
a nemuze zarizeni obsahovat krome ro filesystemu treba i nejakou sd karticku, kde by se mohly rw zapisovat potrebne veci? pripadne pokud je zarizeni stale zapnute, nemuze se vyclenit kousek ram, flash, atp. pameti, kde se muze zapisovat a tam to drzet?
-
Pokud máte toho HTTPS klienta v ruce, zkusil bych použít DANE (https://www.root.cz/clanky/bezpecne-dns-a-dane-do-kazdeho-pocitace/), kdy budete certifikáty ověřovat přes DNS a nemusíte záviset na certifikační autoritě.
Ovšem aby to bylo bezpečné, potřebujete používat DNSSEC, kde zase potřebujete mít důvěryhodný kořenový certifikát, který se také jednou za několik let mění (možná častěji, než kořenový certifikát Let's Encrypt) – jestli se nemýlím, zrovna na příští rok je naplánována výměna.
No a nebo to můžete ošidit – používat pro serverový certifikát (pokud je to jeden server) stále ten samý klíč dokola a v klientech důvěřovat certifikátu s tím konkrétním klíčem. Pak samozřejmě ale nebudete schopen klíč vyměnit v případě úniku privátního klíče.
-
No a nebo to můžete ošidit – používat pro serverový certifikát (pokud je to jeden server) stále ten samý klíč dokola a v klientech důvěřovat certifikátu s tím konkrétním klíčem. Pak samozřejmě ale nebudete schopen klíč vyměnit v případě úniku privátního klíče.
Tohle už se řeší snadno, do toho klienta se dá víc veřejných klíčů, kterým věří. Jeden soukromý klíč se pak nasadí na server a ostatní se nechají bezpečně v záloze. Když něco selže, vyndá se jeden ze záložních klíčů a jede se dál.
Pokud to má být v tomhle režimu opravdu dlouhodobě bezúdržbové, pak je to jediná cesta. Kořenové certifikáty autorit se opravdu jednou za čas mění, stejně jako klíč (tam není certifikát) v kořenové zóně kvůli DNSSEC. Jediná jistá cesta je vyhnout se těmhle stromům a pinovat si vlastní koncové veřejné klíče.
-
@majvan - ak predpokladas, ze zariadenie ma fungovat dlhsie ako 5-6 rokov, tak urcite bude potrebovat neaky extra storage, kam vies nahrat nove root certifikaty Let's Encrypt. Aktualne maju RSA root do 2030-06-04 a ECDSA root do 2035-09-04, ale je sanca, ze jeden alebo aj oba budu rotovat aj skor.
Moznost vlastnych certifikatov (ako pisu Petr Krcmar a Filip Jirsak vyssie) nastupuje az v pripade, ak zavrhnes povodnu ideu fungovat pod Let's Encrypt, pripadne budes chciet mat nejaku vlastnu zalohu napr. pre pripad ze LE skonci. Na bezpecne fungovanie ale na klientovi tiez potrebujes to iste - nejake ulozisko certifikatov, kde vies novy certifikat pridat a stary zmazat.
Mimo toto neexistuje cesta, ako to moze bezpecne fungovat. Vastne ano, raz za cas vymenit cele zariadenie (resp. k update firmwaru nahrat aj nove root crertifikaty, ak to zariadenie umoznuje).
-
@majvan - ak predpokladas, ze zariadenie ma fungovat dlhsie ako 5-6 rokov, tak urcite bude potrebovat neaky extra storage, kam vies nahrat nove root certifikaty Let's Encrypt. Aktualne maju RSA root do 2030-06-04 a ECDSA root do 2035-09-04, ale je sanca, ze jeden alebo aj oba budu rotovat aj skor.
Vdaka za odpoved. Pozeral som tiez nejake certifikaty a ISRG, ktory je root pre Let's Encrypt ma naozaj do 2035. Nakolko vsak tvrdite viaceri, ze budu rotovat skor, pozrel som si, ako to prebieha.
Ak spravne chapem, tak je tam nejaka perioda prekryvu, kedy je este platny stary certifikat a uz je platny aj novy certifikat. Pocas tejto periody prekryvu je potrebne patchovat operacne systemy (alebo prehliadace / systemy s vlastnym uloziskom root certifikatov).
Aka dlha byva tato doba? Je nejaky mechanizmus na query "je novy certifikat", alebo v sucasnosti sa spolieha na to, ze pocas tejto doby prebehne update, ktory ten novy certifikat ziska?
-
Aktualne maju RSA root do 2030-06-04
To mají napsané v textu (https://letsencrypt.org/certificates/), nicméně ve skutečnosti je i ten RSA root vydaný s platností do 2035-06-04.
Moznost vlastnych certifikatov (ako pisu Petr Krcmar a Filip Jirsak vyssie) nastupuje az v pripade, ak zavrhnes povodnu ideu fungovat pod Let's Encrypt, pripadne budes chciet mat nejaku vlastnu zalohu napr. pre pripad ze LE skonci.
Nikoli, i DANE nebo používání stále stejného klíče je možné použít s certifikáty od Let's Encrypt. Ten HTTPS klient v zařízeních by sice používal DANE nebo by měl v sobě několik klíčů a bylo by mu jedno, že jsou ty certifikáty vystavené pomocí LE. Ale server by měl normálně uznávané certifikáty, takže kdyby se k serveru připojil někdo běžným webovým prohlížečem (třeba proto, že by ten server poskytoval i nějaké webové rozhraní), dostal by klasický certifikát od LE.
Na bezpecne fungovanie ale na klientovi tiez potrebujes to iste - nejake ulozisko certifikatov, kde vies novy certifikat pridat a stary zmazat.
Není to potřeba, pokud si budete věřit, že nedojde ke kompromitaci privátního klíče.
Tohle už se řeší snadno, do toho klienta se dá víc veřejných klíčů, kterým věří. Jeden soukromý klíč se pak nasadí na server a ostatní se nechají bezpečně v záloze. Když něco selže, vyndá se jeden ze záložních klíčů a jede se dál.
To je dobré řešení, ale pak je potřeba mít zajištěné, aby nemohlo dojít ke kompromitaci privátního klíče, tj. mít privátní klíč v HSM nebo aspoň nějakém USB tokenu.
-
Aka dlha byva tato doba? Je nejaky mechanizmus na query "je novy certifikat", alebo v sucasnosti sa spolieha na to, ze pocas tejto doby prebehne update, ktory ten novy certifikat ziska?
Obvykle je to několik měsíců, i přes rok. Ale ono je to dost různé, protože často je ta změna kořenového certifikátu důsledkem jiných změn.
Pokud je víc alternativních certifikačních cest (což je třeba případ výměny kořenového certifikátu), je možnost při vydávání certifikátu si zvolit, která cesta se má použít. Takže ty informace jsou dostupné přes API. A Let's Encrypt o tom také dopředu informuje, takže je dobré sledovat třeba jejich blog.
-
Ak začínam správne chápať, tak Let's Encrypt je CA najvyššej úrovne, t.j. ten ISRG, ktorý ma Expiration Date v roku 2035, patrí Let's Encrypt?
Tomuto celkom nerozumiem:
Pokud je víc alternativních certifikačních cest (což je třeba případ výměny kořenového certifikátu), je možnost při vydávání certifikátu si zvolit, která cesta se má použít.
Znamená to, že už pri vydávaní certifikátu má certifikát zapísaných viacero alternatív k (PKI) rodičovským certifikátom?
Ak som správne pochopil, tak Let's Encrypt vydáva certifikáty na krátke obdobie (niekoľko mesiacov, alebo pár rokov), takže ak pôjdem cestou certifikačnej autority, tak vidím skôr riešenie v manažovaní tých koreňových trusted certifikátov pre klienta a to tak, že bude treba vystihnúť dobu, počas ktorej sa budú musieť certifikáty na všetkých embedded zariadeniach updatovať.
V prípade, že si sám podpíšem certifikát, tak si musím update manažovať tiež sám. Poprípade nebudem updatovať certifikát vôbec, čím viac riskujem zvýšenú možnosť kompromitácie po nejakom čase...
-
Ak začínam správne chápať, tak Let's Encrypt je CA najvyššej úrovne, t.j. ten ISRG, ktorý ma Expiration Date v roku 2035, patrí Let's Encrypt?
Tomuto celkom nerozumiem:
Pokud je víc alternativních certifikačních cest (což je třeba případ výměny kořenového certifikátu), je možnost při vydávání certifikátu si zvolit, která cesta se má použít.
Znamená to, že už pri vydávaní certifikátu má certifikát zapísaných viacero alternatív k (PKI) rodičovským certifikátom?
Ak som správne pochopil, tak Let's Encrypt vydáva certifikáty na krátke obdobie (niekoľko mesiacov, alebo pár rokov), takže ak pôjdem cestou certifikačnej autority, tak vidím skôr riešenie v manažovaní tých koreňových trusted certifikátov pre klienta a to tak, že bude treba vystihnúť dobu, počas ktorej sa budú musieť certifikáty na všetkých embedded zariadeniach updatovať.
V prípade, že si sám podpíšem certifikát, tak si musím update manažovať tiež sám. Poprípade nebudem updatovať certifikát vôbec, čím viac riskujem zvýšenú možnosť kompromitácie po nejakom čase...
letsencrypt nemusi byt top level, ale jeho certifikaty co certifikuji nizsi urovne jsou certifikovane top certifikaty, takze se letsencrypt certifikatum veri.
muzete si sam delat certifikaty pomoci nastroje openssl, ale pak si je musite rucne datna server, do prohlizece a treba i do systemu.
-
Ak začínam správne chápať, tak Let's Encrypt je CA najvyššej úrovne, t.j. ten ISRG, ktorý ma Expiration Date v roku 2035, patrí Let's Encrypt?
Ano, Let's Encrypt je „obchodní značka“, pod kterou poskytují certifikační služby, ale právní subjekt za tím je veřejně prospěšná společnost Internet Security Research Group (ISRG). Dříve měly svůj kořenový certifikát křížově podepsaný ještě jinou autoritou, ale ten už letos přestali úplně používat.
Znamená to, že už pri vydávaní certifikátu má certifikát zapísaných viacero alternatív k (PKI) rodičovským certifikátom?
Certifikát je podepsaný vždy jedním klíčem certifikační autority, ale ten jeden klíč certifikační autority se může nacházet v několika různých certifikátech. Tj. ten koncový certifikát, který máte na HTTPS serveru, je jen jeden, ale může k němu vést několik různých cest od různých kořenových certifikátů. No a protože si při vydání certifikátu od Let's Encrypt stahujete i ty nadřazené certifikáty, můžete si zvolit, kterou cestu chcete poslat. Pokud si nevyberete, pošle LE to, co v daném času má nastavené jako výchozí.
Ak som správne pochopil, tak Let's Encrypt vydáva certifikáty na krátke obdobie (niekoľko mesiacov, alebo pár rokov)
Koncové certifikáty (třeba pro váš HTTPS server) vydává vždy s platností 90 dnů (a chtějí to ještě zkracovat). Mezilehlé a kořenové certifikáty mají nastavenou platnost 20 let, ale tak dlouho se nejspíš používat nebudou.
takže ak pôjdem cestou certifikačnej autority, tak vidím skôr riešenie v manažovaní tých koreňových trusted certifikátov pre klienta a to tak, že bude treba vystihnúť dobu, počas ktorej sa budú musieť certifikáty na všetkých embedded zariadeniach updatovať.
Ano, přičemž ta doba výměny bude u kořenových certifikátů určitě několik měsíců. Přičemž Let's Encrypt na to vždy opakovaně upozorňuje a na začátku zveřejňuje harmonogram, jak to bude probíhat. Třeba tady (https://letsencrypt.org/2023/07/10/cross-sign-expiration) je zpráva z července 2023 s harmonogramem výměny kořenového certifikátu, jehož platnost končí shodou okolností dnes.
V prípade, že si sám podpíšem certifikát, tak si musím update manažovať tiež sám. Poprípade nebudem updatovať certifikát vôbec, čím viac riskujem zvýšenú možnosť kompromitácie po nejakom čase...
Když ten certifikát nebudete updatovat vůbec (resp. nebudete mít tu možnost), existuje riziko, že když dojde ke kompromitaci privátního klíče, nemáte jak to vyřešit – jak ta zařízení přesvědčit, aby kompromitovanému klíči nevěřila. Tj. ani tak nejde o to, že by s delším používáním rostlo riziko kompromitace, to není tak velký problém – podstatné je, že kdyby k tomu došlo, nemáte jak tu situaci vyřešit. (Maximálně můžete informovat všechny zákazníky, ať to zařízení přestanou používat a odpojí ho od sítě.)
Pak je tam ještě jedno riziko – vystavíte certifikát s dlouhou platností, třeba 10 let, a pak zapomenete, že je potřeba to za 10 let nějak řešit. To se před pár lety stalo FlexiBee, když jim po 10 letech vypršel certifikát podepisující licence (https://www.lupa.cz/aktuality/ucetnictvi-flexibee-resi-vypadky-vyprsel-certifikat-podepisujici-licence/).
-
Mám embedded zariadenie, ktoré má read-only root filesystem a ktoré bude nainštalované bez ďalšieho prístupu k nemu niekde v teréne.
Chcem dať naňho aplikačného klienta, ktorý komunikuje s https serverom, ktorý bude mať certifikát podpísaný od Let's Encrypt.
Ako zabezpečiť, aby bolo toto zariadenie stále schopné akceptovať certifikát https servera?
Akú periódu obnovy má Let's Encrypt certifikát? Ako funguje v Linuxe update trusted root certifikátov?
A jak budes na read-only filesystemu resit patchovani exploitu?
Jen priklad, proc resis vec ktera roky nenastane. Ale exploitu vyjde mezitim hromada. Samozrejme nevim o jake zarizeni se jedna. Ale vsechno se da dneska reversnout a cim vic je to zarizeni uzavrenejsi tim vic zajimavejsi to je, pro urcitou skupinu lidi ;-)
-
A jak budes na read-only filesystemu resit patchovani exploitu?
Jen priklad, proc resis vec ktera roky nenastane. Ale exploitu vyjde mezitim hromada. Samozrejme nevim o jake zarizeni se jedna. Ale vsechno se da dneska reversnout a cim vic je to zarizeni uzavrenejsi tim vic zajimavejsi to je, pro urcitou skupinu lidi ;-)
Pokud to zařízení nebude poslouchat na síti a bude jenom v roli klienta dvou známých protokolů (DNS a HTTPS), přičemž to HTTPS bude omezené na jeden server pod kontrolou poskytovatele zařízení, je vektor útoku velmi malý. Takové zařízení bude podstatně bezpečnější, než pravidelně aktualizované zařízení, kde běží spousta služeb.
-
Když ten certifikát nebudete updatovat vůbec (resp. nebudete mít tu možnost), existuje riziko, že když dojde ke kompromitaci privátního klíče, nemáte jak to vyřešit – jak ta zařízení přesvědčit, aby kompromitovanému klíči nevěřila. Tj. ani tak nejde o to, že by s delším používáním rostlo riziko kompromitace, to není tak velký problém – podstatné je, že kdyby k tomu došlo, nemáte jak tu situaci vyřešit. (Maximálně můžete informovat všechny zákazníky, ať to zařízení přestanou používat a odpojí ho od sítě.)
To je isto pravda, ale to zariadenie dokáŽe pracovať samostatne aj bez toho serveru, takže sa len nepodarí nejaká operácia. Na to, aby som nenechal všetky zariadenia pracovať v tomto degradovanom režime, tak by mali zariadenia vždy inštalované 2 certifikáty. Jeden súčasne používaný a druhý jeho náhrada. Ak príde ku kompromitácii, vymením certifikát a zariadenia budú fungovať ďalej.
Tým som získal dostatok času na vytvorenie nového záložného certifikátu a postupné servisovanie zariadení pre výmenu starého kompromitovaného certifikátu za nový.
Pokud to zařízení nebude poslouchat na síti a bude jenom v roli klienta dvou známých protokolů (DNS a HTTPS), přičemž to HTTPS bude omezené na jeden server pod kontrolou poskytovatele zařízení, je vektor útoku velmi malý. Takové zařízení bude podstatně bezpečnější, než pravidelně aktualizované zařízení, kde běží spousta služeb.
Presne tak. Príde mi, že vzdialený servis s možnosť patchovania celého systému, a teda možnosť úpravy celého FS, má oveľa väčšie riziko (severity * probability) ako kompromitácia https certifikátu.
-
To je isto pravda, ale to zariadenie dokáŽe pracovať samostatne aj bez toho serveru, takže sa len nepodarí nejaká operácia. Na to, aby som nenechal všetky zariadenia pracovať v tomto degradovanom režime, tak by mali zariadenia vždy inštalované 2 certifikáty. Jeden súčasne používaný a druhý jeho náhrada. Ak príde ku kompromitácii, vymením certifikát a zariadenia budú fungovať ďalej.
Tým som získal dostatok času na vytvorenie nového záložného certifikátu a postupné servisovanie zariadení pre výmenu starého kompromitovaného certifikátu za nový.
Tohle platí v případě, že přijedete o ten privátní klíč (např. se zničí token, kde je uložený). Pokud by došlo ke kompromitaci privátního klíče (tj. získal by ho někdo jiný), čas nemáte – protože i když vy začnete používat druhý klíč na serveru, úročník má k dispozici ten první kompromitovaný klíč, kterému ta zařízení stále důvěřují.
Proto jsem psal, že v tomto případě je potřeba mít dobře zabezpečený ten privátní klíč, ideálně na nějakém HSM nebo tokenu, odkud nejde vyexportovat. Aby se minimalizovalo riziko kompromitace privátního klíče. Protože ztrátu privátního klíče dokážete ošetřit tím, že zařízení bude důvěřovat většímu množství klíčů, ale kompromitaci takhle ošetřit nelze.
-
Tohle platí v případě, že přijedete o ten privátní klíč (např. se zničí token, kde je uložený). Pokud by došlo ke kompromitaci privátního klíče (tj. získal by ho někdo jiný), čas nemáte – protože i když vy začnete používat druhý klíč na serveru, úročník má k dispozici ten první kompromitovaný klíč, kterému ta zařízení stále důvěřují.
Súhlasím, zle som sa vyjadril. Ak by bol predchádzajúci certifikát zničený (ale nie kompromitovaný), mám čas na update.
Existuje teda nejaký spôsob, ako riešiť, že bol privátny kľúč kompromitovaný? Napríklad, že by sa pri TLS verifikovali dva certifikáty naraz Len to by potom si musel zvoliť TLS jeden, s ktorým začne komunikáciu - a môže to byť práve ten kompromitovaný.
Asi neexistuje iné riešenie v tomto prípade, len práve ísť cestou PKI a obmieňať v zariadeniach certifikáty root CA.
-
Existuje teda nejaký spôsob, ako riešiť, že bol privátny kľúč kompromitovaný? Napríklad, že by sa pri TLS verifikovali dva certifikáty naraz Len to by potom si musel zvoliť TLS jeden, s ktorým začne komunikáciu - a môže to byť práve ten kompromitovaný.
Asi neexistuje iné riešenie v tomto prípade, len práve ísť cestou PKI a obmieňať v zariadeniach certifikáty root CA.
V rámci TLS spojení můžete ověřovat vždy jen jeden certifikát serveru.
Odvolání certifikátu v případě kompromitace privátního klíče se řeší pomocí CRL nebo OCSP. CRL ovšem vyžaduje pravidelně si stahovat seznam odvolaných certifikátů a udržovat si ho u sebe. Tj. opět to vyžaduje zápis na disk. OCSP se ověřuje online, ale Let's Encrypt se snaží přestat OCSP poskytovat. Obojí (CRL i OCSP) je opět závislé na certifikátu certifikační autority, takže byste stejně musel řešit tu aktualizaci certifikátů CA.
Pokud je to něco, co musí být opravdu bezpečné, nezbyde vám, než umět ty certifikáty CA aktualizovat. Nicméně pokud by to bylo něco takového, nebudete řešit certifikáty od LE, protože by pro vás nebyl problém zaplatit za nějaký komerční certifikát a HSM.
Pokud se smíříte s tím, že pravděpodobnost napadení není úplně neměřitelná, ale potřebujete to mít levné, pak bych zvolil variantu s tím, že v zařízení bude několik veřejných klíčů, kterým bude HTTPS klient důvěřovat. Jeden budete používat, ostatní budou záložní. Ty záložní klíče budou uložené třeba někde v trezoru (nebo radši dvou), abyste o ně nepřišel. A používaný klíč bude na nějakém USB tokenu nebo něčem podobném, přinejhorším v softwarovém HSM s dostatečnou úrovní zabezpečení (tj. aby se ke klíči nedalo dostat s jedním heslem, ale těch bezpečnostních prvků bylo víc). Pak je samozřejmě důležité, jak se s tím tokenem/HSM bude komunikovat. Bude to poskytovat klíče pro webový server, takže to musí být online. Tj. pak je nekritičtější komunikace mezi webovým serverem a tím HSM/tokenem – to je místo, které by se útočník pokusil napadnout a nechat si podepsat svou vlastní komunikaci. Pořád to ale má tu výhodu, že kdyby se to útočníkovi povedlo, bude se moci za server vydávat v danou chvíli – ale nezíská privátní klíč trvale. Takže až útok odhalíte a chybu opravíte, útočník o přístup přijde.
Pozor ale také na to, že pak musí HSM/token podepsat každé navázané TLS spojení, takže musí mít potřebnou propustnost. Běžné levné USB tokeny jsou dělané na to, že tím člověk podepisuje nějaké dokumenty, takže mu bohatě stačí propustnost jeden podpis za několik sekund. To by vám na webovém serveru asi nestačilo.
-
Vďaka za odpoveď.
Možno som sa zle vyjadril, pre mňa nie je Let's Encrypt nejaký požiadavok, ak by som šiel cestou CA. Akú má výhodu komerčný certifikát, resp. certifikát od inej CA ako Let's Encrypt?
Tiež som celkom nepochopil s tým HSM. Predpokladám, že k serveru nebudem mať prístup (cloud), takže TLS bude bežať s privátnym kľúčom z úložiska cloudu.
Ja si len zapíšem u mňa na Trezor ten privátny kľúč pre prípad, že by som potreboval certifikát a kľúč opätovne uploadoval do cloudu (napríklad pre prípad, že by som službu so zdrojmi musel ešte raz definovať).
Správne tomu rozumiem?
-
HSM je najbezpecnejsi sposob uschovy privatneho kluca. Je to bezpecnejsie ako mat ho niekde v beznom ulozisku, pretoze tam sa otvara moznost, ze hacker alebo admin ten kluc pouzije alebo skopiruje (vytiahne zo zalohy atd...) Oproti tomu samotne HSM len prijima poziadavky a za pouzitia PK ich vybavuje (napr. dodava podklady pre vytvorenie sifrovaneho spojenia, alebo podpisuje dokumenty).
-
Akú má výhodu komerčný certifikát, resp. certifikát od inej CA ako Let's Encrypt?
Aktuálně vydávají komerční CA certifikáty s roční platností. Takže pokud nemůžete použít automatizaci přes ACME protokol a musíte certifikáty řešit a někam nahrávat ručně, je jednodušší to dělat jednou za rok než 4–5 krát za rok. Ale jsou tlaky na zkrácení platnosti certifikátů, takže pravděpodobně i ty komerční CA budou někdy donucené platnost certifikátů ještě zkrátit.
Tiež som celkom nepochopil s tým HSM. Predpokladám, že k serveru nebudem mať prístup (cloud), takže TLS bude bežať s privátnym kľúčom z úložiska cloudu.
To chce vybrat nějaký důvěryhodný cloud, a pak s tím klíčem rozumně pracovat. Ideálně pokud ten cloud má nějaké úložiště citlivých informací a dá se to nějak rozumně dostat do aplikace (aby to nebyl soubor na disku, který bude moci přečíst i ta aplikace běžící na webovém serveru, nebo dokonce jiné aplikace běžící na stejném serveru).
V tomhle případě je hodně důležité, jaká bude povaha těch dat, která ta zařízení budou odesílat. Pokud to bude posílat teplotu ve skleníku u pár desítek či stovek českých klientů, pak se asi nestane nic vážného, pokud by ta data unikla nebo by je někdo zfalšoval. Pokud to bude něco, že z těch dat půjde odvodit, zda je někdo doma u desítek tisíc domácností po celém světě, nebo přes to půjde v podobném počtu domácností vypnout vzdáleně lednici, tak bych asi nešel do toho, že nějaká poměrně banální chyba může způsobit únik privátního klíče a já ho pak nebudu schopen zneplatnit.
Ja si len zapíšem u mňa na Trezor ten privátny kľúč pre prípad, že by som potreboval certifikát a kľúč opätovne uploadoval do cloudu (napríklad pre prípad, že by som službu so zdrojmi musel ešte raz definovať).
V tom případě musíte mít klíč uložen tak, aby byl exportovatelný, což nevím, zda Trezor umožňuje.