Dotaz: HTTPS - nastavení v ISP Config

[perrada]

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 :)

---

---

Odpovědi

[Filip Jirsák]

Určitě někde musíte mít uložený privátní klíč patřící k certifikátu, ten vám ve výčtu úplně chybí. Požadavek na vystavení certifikátu tam máte zbytečně, ten webový server nepotřebuje (slouží jenom certifikační autoritě jako žádost pro vystavení certifikátu). Ten odkazovaný návod popisuje postup, kdy žádost o certifikát vytváří přímo ISPConfig. Vy už certifikát máte, takže serveru musíte předat jenom privátní klíč, serverový certifikát (certificate_nazev.domeny.txt) a případně certifikát certifikační autority (linux_cert+ca.pem) – ale HTTPS by muselo fungovat i bez certifikátu certifikační autority, akorát by vám prohlížeč možná psal, že certifikát není vystaven důvěryhodnou autoritou.

[perrada]

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ý).

[perrada]

Tak se omlouvám, nakonec pomohla editace .vhost soubotu pro apache2. Nebylo to nakonec tak slozite ;)

Jen se potýkám s problémem, že Chrome, Opera mi stránky zobrazí správně - tzn. jako důvěryhodné - certifikát od RapidSSL je v pořádku, kdežto Firefox má s důvěryhodností problém.

Neví někdo co s tím?

[Andrej]

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.

[MMMMMMMMM]

Tak mi ve .vhost chybela tato radka, ted vse funguje jak má ;)

SSLCACertificateFile /etc/ssl/nazev.domeny/linux_cert+ca.pem

Díky za nasměrovaní a omlouvám se za možná zbytečný příspěvek :)

[cold]

pokud nemas uplne outdated isp tak je tam na to primo pole v zalozce SSL, jestli to bylo z nejake typicke sablony wedosu (co sem zatim videl tak i doted tam maji tunu spatnych nastaveni a nesmyslu v OS a neverim ze je to nahoda)

to co ti poslala certifikacni autorita napastujes do tech spravnych poli (key, crt(cert) + intermediate) a nesmi tam byt volne nove radky nebo mezery na konci specialni znaky a dalsi kraviny u kazdeho pole, musi to byt proste presne stejne

nez si nechas obnovit system ze zalohy tak vetsinou je postup: apache2ctl -t nebo nginx -t to obvykle vypise duvod proc apache nebo nginx neni schopen nastartovat, pak staci smazat symlink na dany vadny vhost a to v

/etc/apache2/sites-enabled/   nebo 
/etc/nginx/sites-enabled/

zkusit to nastartovat

/etc/init.d/apache2 start   nebo
/etc/init.d/nginx start

a 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

[Filip Jirsák]

Server posílal jenom serverový certifikát, ne i intermediate certifikát CA. Některé prohlížeče ten intermediate certifikát mají a dokázaly si váš certifikát propojit až k důvěryhodné autoritě, Firefox ten intermediate certifikát nemá. Touhle změnou jste to upravil, aby server posílal i intermediate certifikát.

Dobrá stránka na testování je Qualys SSL Server Test, kde vám to vypíše všechny možné údaje o SSL spojení, i to, jaké certifikáty server posílá - ale především to vyhodnotí bezpečnost (zda se nepoužívají slabé šifry apod.). Ty certifikáty vám vypíše i openssl s_client.

[Andrej]

…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.

[ttt]

etckeeper případně obstará nastavení a automatizaci okolo.