Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
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.
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: