Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
LibreOffice 24.8 bude vydán jako finální v srpnu 2024, přičemž LibreOffice 24.8 Alpha1 je první předběžnou verzí od začátku vývoje verze 24.8 v prosinci 2023. Od té doby bylo do úložiště kódu odesláno 4448 commitů a více než 667 chyb bylo v Bugzille nastaveno jako opravené. Nové funkce obsažené v této verzi LibreOffice najdete v poznámkách k vydání.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 141 (pdf) a HackSpace 78 (pdf).
Zdravím,
rád bych rozběhal https na mé VPS, ale jelikož nastavení conf souborů apache dopadlo tragicky (musel jsem nakonec zažádat o obnovu VPS ze záloh Wedosu :) ), rád bych bezpečnější cestu a rád bych vše nastavil v ISPConfig3.
Postupoval jsem dle tohoto návodu:
https://blog.giuseppeurso.net/free-ssl-certificate-to-ispconfig-website-with-startssl-how-to/
- Mám přidělenou dodatečnou IP adresu: např. 1.2.3.4
- SSL certifikátjsme zakoupil u SSLRapid (přes SSLMarket.cz)
dorazili mi tytosoubory:
- certificate_nazev.domeny.txt
- linux_cert+ca.pem (tam jsou dva certifikáty v text. podobě)
- nazev.domeny.cz.key.csr - má část vygenerovaného certifikátu
- windows_intermediate.p7b
V ISPConfig3 jsem dle návodu nakopíroval u patřičné domény tyto certifikáty:
SSL Klíč - certificate_nazev.domeny.txt
SSL Požadavek - nazev.domeny.cz.key.csr - veřejný klíč
SSL Certifikát - linux_certca.pem - druhá certifikát v tomto souboru
SSL Bundle - windows_intermediate.p7b
Po té jsem certifikát uložil, projistotu restartoval apache2 a zkusil jít na adresu:
https://nazev.domeny
prohlížeč domény mi zobrazil chybu - chybný certifikát. Nevím proč, ale neustále se zobrazuje certifikát Wedosu.
A když dám přesto pokračovat na stránky (nedůvěryhodné), tak se zobrazí defaultní stránka apache - it's works, nikoliv požadované stránky na doméně.
ping ukazuje ze doména je již na nové IP adrese 1.2.3.4
Nevíte kde jsem udělal chybu? Opravdu nechci něco podělat znova a byť obnova u Wedosu byla bez problému a byli ochotní, nerad bych toto martýrium podstoupil znova :)
Řešení dotazu:
Vy myslíte certifikát který jsem vytvořil pomocí příkazu:
openssl genrsa -out nazev.domeny.key 2048
?
Takže bych měl dát do těch požadovaných polí v ISP Config tyto certifikáty?
SSL Klíč - certificate_nazev.domeny.txt
SSL Požadavek - výše uvedený vygenerovaný certifikát?
SSL Certifikát - linux_cert+ca.pem - druhá certifikát v tomto souboru
SSL Bundle - windows_intermediate.p7b
Měl bych ještě dotaz ohledně souboru linux_cert+ca.pem - v tomto souboru jsou dva certifikáty, jaký tam mám nakopírovat?
Omlouvám se, ale po cca 4 dnech hledání a studování mám už v hlavě bordel... :)
Jinak problém je, že prohlížeč pořád detekuje certifikát wedosu, nikoliv můj (byť by byl špatně zadaný).
Každý prohlížeč umí zobrazit seznam certifikátů (osobních, ostatních lidí, autorit), které má nainstalované ve svém úložišti kryptografických dat. Nezbývá tedy než se ve Firefoxu k příslušnému menu doklikat a zkontrolovat, zda je příslušná autorita nainstalovaná a důvěryhodná.
Pak to taky může být chybějící článek v řetězci certifikátů. Například má certifikační autorita kořenový samopodepsaný certifikát, který podepisuje certifikáty jejích podautorit a teprve ty podautority podepisují přímo certifikáty zákazníků. Kroků může být i víc. Pak jde o to, jestli se prohlížeči podaří sestavit celý řetězec až k samopodepsanému kořenovému certifikátu autority, který má označený jako důvěryhodný. To se může podařit ze dvou důvodů. Prvním důvodem může být, že jsou certifikáty podautorit (tedy nejen kořenový certifikát) přímo přidané do seznamu důvěryhodných autorit v prohlížeči. Tak by to ale rozhodně být nemělo. Druhým důvodem může být, že webový server při navazování TLS spojení pošle nejen svůj certifikát, ale i potřebný počet dalších článků řetězce (zpravidla jeden další článek), které vedou celou cestu až na krok od kořenového certifikátu. Ten už pak má prohlížeč a může tedy celý řetězec certifikátů ověřit. A takhle by to určitě mělo být.
Některé SSL konfigurační optiony na jednom z mých webů, jen tak namátkou:
SSLCertificateFile /etc/httpd/conf/public/some.web.crt SSLCertificateKeyFile /etc/httpd/conf/secret/some.web.key SSLCertificateChainFile /etc/httpd/conf/public/some.web.chain SSLCACertificateFile /var/myawesomeca/ca-cert.pem SSLCARevocationFile /var/myawesomeca/ca-crl.pem
Tohle říká, kde je certifikát, kde je k němu příslušný klíč, kde jsou další certifikáty v řetězci, které se mají prohlížeči poslat taky, kde je autorita pro ověřování certifikátů klientů poslaných prohlížečem — protože tohle je web, na kterém funguje autentifikace certifikátem — a konečně revocation list pro ověřování identity klientů toho webu, aby se tam nedalo dostat se zneplatněným certifikátem. Zajímavé tady je, že certifikáty, kterými se prokazuje server, jsou od jiné (veřejné) autority než je ta (soukromá), jejíž certifikáty server vyžaduje po klientech. To jen na vysvětlenou; ne že by to bylo až tak podstatné. Podstatný je ten chain, ve kterém je „intermediate“ certifikát podautority té veřejné autority, aby se prohlížeč dopočítal až ke kořeni, který má mezi důvěryhodnými certifikáty.
/etc/apache2/sites-enabled/ nebo /etc/nginx/sites-enabled/zkusit to nastartovat
/etc/init.d/apache2 start nebo /etc/init.d/nginx starta obvykle to trochu nepresne zapise i do error.logu a syslogu pak v isp opravis dany vhost (domenu) - musis dat aby byl napred neaktivni -> Ulozit, pockat aspon 60 sekund a pak ho znova zapnout a to bude asi tak vsechno jo u nginxu je to trochu komplikovanejsi s tema certama kazdopadne UTFG
openssl s_client
.
…musel jsem nakonec zažádat o obnovu VPS ze záloh Wedosu…
Doporučuji vytvořit si v adresáři /etc
(nebo v jiných adresářích, pokud nějaké nevychované distro má konfiguraci i jinde) Git repository a každou funkční konfiguraci si do ní commitnout. Kromě snadného a rychlého sdílení konfigurací mezi spoustou strojů to pak taky umožňuje hledání v historii, rychlý návrat ke kterékoliv verzi atd. atp. V podstatě není mnoho důvodů ten Git v /etc
nemít.
Tiskni Sdílej: