Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Evropský parlament dnes přijal směrnici týkající se tzv. práva spotřebitele na opravu. Poslanci ji podpořili 584 hlasy (3 bylo proti a 14 se zdrželo hlasování). Směrnice ujasňuje povinnosti výrobců opravovat zboží a motivovat spotřebitele k tomu, aby si výrobky nechávali opravit a prodloužili tak jejich životnost.
Bylo oznámeno (cs) vydání Fedora Linuxu 40. Přehled novinek ve Fedora Workstation 40 a Fedora KDE 40 na stránkách Fedora Magazinu. Současně byl oznámen notebook Slimbook Fedora 2.
ČTK (Česká tisková kancelář) upozorňuje (X), že na jejím zpravodajském webu České noviny byly dnes dopoledne neznámým útočníkem umístěny dva smyšlené texty, které nepocházejí z její produkce. Jde o text s titulkem „BIS zabránila pokusu o atentát na nově zvoleného slovenského prezidenta Petra Pelligriniho“ a o údajné mimořádné prohlášení ministra Lipavského k témuž. Tyto dezinformace byly útočníky zveřejněny i s příslušnými notifikacemi v mobilní aplikaci Českých novin. ČTK ve svém zpravodajském servisu žádnou informaci v tomto znění nevydala.
Byla založena nadace Open Home Foundation zastřešující více než 240 projektů, standardů, ovladačů a knihoven (Home Assistant, ESPHome, Zigpy, Piper, Improv Wi-Fi, Wyoming, …) pro otevřenou chytrou domácnost s důrazem na soukromí, možnost výběru a udržitelnost.
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: