IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
1. Vytvořím klíč pro certifikační autoritu CA.key. 2. Pomocí CA.key vytvořím žádost CA.csr. 3. Pomocí CA.key a CA.csr podepíšu žádost a vytvořím certifikát CA.crt 4. Vytvořím klíč pro můj webový server MUJWEB.key. 5. Pomocí MUJWEB.key vytvořím žádost MUJWEB.csr. 6. Pomocí CA.key a CA.crt podepíšu žádost MUJWEB.csr a vytvořím certifikát MUJWEB.crt 7. Vytvořím klíč pro klienta mého webového serveru KLIENT.MUJWEB.key. 8. Pomocí KLIENT.MUJWEB.key vytvořím žádost KLIENT.MUJWEB.csr. 9. Pomocí CA.key a CA.crt podepíšu žádost KLIENT.MUJWEB.csr a vytvořím certifikát KLIENT.MUJWEB.crt 10. Převedu KLIENT.MUJWEB.crt na KLIENT.MUJWEB.pk12Otázka: Je špatně, pokud vynechám body 4, 5 a 6 a pro webový server použiju CA.crt?
Řešení dotazu:
Je špatně, pokud vynechám body 4, 5 a 6 a pro webový server použiju CA.crt?Přijde mi to koncepčně divné. „Správně“ bys měl mít jednu CA, která vydá certifikáty třeba pro 5 různých serverů, a privátní klíč té CA by se na těch serverech válet neměl.
Podle toho, jak definuješ špatně.
Certifikát serveru by neměl mít nastavený CA bit, protože browsery a jiné klientské aplikace se na to můžou tvářit kysele. Jinak (obecně) může být samopodepsaný.
Pokud místo certifikátu od (své) autority použiješ přímo na serveru samopodepsaný certifikát, zaděláváš si tím na určitý „logistický“ problém. S autoritou stačí, aby měl každý klient u sebe certifikát autority. Pak může ověřovat identitu všech serverů, kterým autorita v budoucnu vydá certifikát. Se samopodepsanými certifikáty musíš nějak bezpečně dostat každý certifikát na každého klienta, aby zabezpečení dávalo smysl.
Když už tam autoritu tak nebo tak máš (pro vydávání těch klientských certifikátů), pak podle mě není důvod nepoužít ji taky pro podepsání certifikátu serveru. Ušetří to manuální distribucí toho serverového certifikátu na klienty, což je pořád drobné plus, i když každý klient musí dostat svůj klientský .p12 balíček.
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 3660Záleží na tom, kde pak certifikát chcete použít - unixové servery obvykle používají OpenSSL rozhraní, takže jim bude vyhovovat certifikát a privátní klíč ve formátu OpenSSL. Pokud byste to chtěl použít ve Windows nebo v Javě, budete spíš potřebovat formát PFX/PKCS12, což je certifikát i s privátním klíčem v jednom souboru, takže to pomocí OpenSSL musíte převést. (V tom vašem kroku 10 máte chybu, pro vytvoření .pk12 vám nestačí jen certifikát, potřebujete k tomu i privátní klíč.) Pokud byste to chtěl na víc, než jen jednoduché testování, nebo byste těch certifikátů potřeboval víc (a uvažoval o vlastní autoritě), doporučuju raději upravit infrastrukturu tak, abyste mohl používat certifikáty Let's Encrypt. Se self-signed certifikáty a vlastními CA budete mít čím dál tím víc problémů - HTTP se dnes používá jako aplikační protokol, konečně se víc zabezpečuje, takže se přechází na HTTPS, a tak najednou problémy s nedůvěryhodnými certifikáty neřešíte jen v prohlížeči, ale s wgetem, curl, v Gitu, Dockeru, u spousty management konzolí atd.
example.com
, použijte pro intranet adresu intranet.example.com
, která se může překládat na IP adresu ve vnitřní síti a klidně se může překládat jen ve vnitřní síti. Ve veřejném DNS akorát vystavíte TXT záznam _acme-challenge.intranet.example.com
, pomocí kterého to doménové jméno LE ověří.
Používat přímo IP adresy ve vnitřní síti je nešťastné, je to nepohodlné pro uživatele a když potřebujete něco změnit, musíte všem uživatelům rozeslat novou IP adresu.
Tiskni Sdílej: