Názory k článku
SSL autentizácia s webovým serverom Apache

„Ak je privátny kľúč chránený heslom, je potrebné ho zadávať iba pri štarte resp. reštarte daemona.“

Apache si take umi heslo zjistit sam pustenim externiho programu, kde jako parametr mu posila servername:port a pak na stdout ocekava heslo ke klici. Viz: SSLPassPhraseDialog

V současnosti se vůbec FQDN nedoporučuje dávat do CN a místo něj se dává textový popis určený člověku („Webový server společnosti První omezená“). Mnohé autority ani jiné certifikáty už nevydávají. Je to proto, že člověku je v podstatě jedno, jaké URL má daná služba.

Ano, pak ale je dobré uvést fqdn stroje do subjectAltName. Jinak to bude „řvát“. Uživatele to možná nezajímá, browser, nebo aplikaci při ssl handshake však ano. To jméno tam není kvůli uživateli.

Presne tak. Reverze IPcka se kontroluje.

Chválím, výbornej článek v češtině na SSL/TLS.

Zrovna nedavno jsem si s tim hral a docela uzitecne informace jsou treba i v tomto serialu: http://www.root.cz/…-na-openssl/

Clanek je super, jedine, co mi v nem chybi, je moznost odvolavat klientske certifikaty a implementace teto vlastnosti do apache.

Tohle by me taky docela zajimalo, hlavne jestli Apache (nebo nejaky jeho modul) umi ziskavat CRL automaticky z CDP, ktere(a) je(jsou) v certifikatu. Aby se nemuseli stahovat nejakym externim skriptem.

odvolání platnosti certifikátu není věcí apache. to je věc certifikační autority. mod_ssl je možné nastavit, aby kontroloval certifikáty dle revokačního seznamu (to znamená odmítal pokusy o autentizaci zneplatněným certifikátem).

direktivou SSLCARevocationPath modulu řeknete kde najde seznam zneplatněných certifikátů. ten musíte pravidelně aktualizovat např. skriptem v cronu.

týká se to samozřejmě pouze certifkátů, které byly zneplatněny např. z důvodu kompromitace klíče. certifikáty, kterým vypršela časová platnost v revokačním seznamu nejsou. ty jsou modulem odmítány automaticky v rámci základní kontroly platnosti ( kontrola platnosti notBefore & notAfter, kontrola podpisu CA …).

ale to je snad jasné. :)

Copak v tý SSLCARevocationPath neni možný použít rovnou URL adresu CRL?

Víš jak by to dlouho trvalo, kdyby se při každým dotazu na server stahoval CLR?

Umí Apache vybírat k virtuálním HTTPS serverům serverový certifikát podle rozšířeného TLS požadavku klienta (RFC 3546)? Nechce autor napsat pokračování na toto téma?

V podstatě jde o to, že při masivním HTTPS hostingu je nesmyslné vydávat certifikát rozšířený o nové subjectAltName. Navíc zákazník by mohl chtít vlastní certifikát.

HTTPS klient si pak při sestavování TLS řekne, se kterým FQDN chce mluvit a server vybere správný certifikát. Takže je možné mít více HTTPS serverů na stejné TCP adrese každý s jiným certifikátem.

http://en.gentoo-wiki.com/…irtual_Hosts

Ahoj,

Vyborny clanok! Chcem sa opytat, akym sposobom riesit problem 1 certifikatu pre viac virtualhostov v apachi. Existuje nejake elegantne riesenie?

dat do subjectAltName všechny jména pod kterými je možné na server dosáhnout, tedy fqdn všech virtuálů. To ale není vhodné, pokud poskytuješ hosting. Dá se to použít pokud těch virtuál máš pár. Být tebou, vydám každému virtuálu vlastní certifikát.

Ahoj,

S vidanim certifikatov nie je problem, ale je mozne v apache pouzivat viac certifikavot naraz?

Pokial viem, tak so SSLv3 nemozes na jednom sockete (IP:PORT) prevadzkovat viac virtualhostov kvoli tomu, ze SSL sa nachadza medzi transportnou a aplikacnou vrstvou. Kym server nenadviaze s klientom SSL spojenie nemoze zistit z klientskeho dotazu (aplikacna vrstva) na aku URL pristupuje. Rieseni tohto obmedzenia je viacero: mozes napriklad pridavat dalsie IP adresy a pustat virtualhost s inym certifikatom na kazdej z nich, mozes vyuzit dalsie porty na jednej IP adrese (pouzivatel ale bude musiet v URL tento port uviest) alebo ako uz bolo uvedene vyssie da sa vydat jeden certifikat, ktory bude obsahovat v rozsireni subjectAlterna­tiveName FQDN vsetkych obsluhovanych webov.

Pozri sa vsak aj na link uvedeny vyssie v diskusii – http://en.gentoo-wiki.com/…irtual_Hosts – kde sa pise, ze TLS 1.0 uz podporuje aj stav, ked klient pri nadvazovani SSL spojenia zasle serveru informaciu na aky hostname pristupuje a web server podla toho moze zvolit virtualhost (a certifikat), ktorym klienta obsluzi. Na uvedenej adrese mas aj priklad konfiguracie pre Apache s mod_ssl. Viem si vsak predstavit, ze spolocnosti poskytujuce hosting toto riesenie nebudu chciet pouzit kedze napriklad (bohuzial stale pouzivany) IE6 TLS 1.0 nepodporuje.

da sa vyuzit protocol upgrade v ramci nesifrovaneho HTTP (http://www.ietf.orgrfc/rfc2817.txt), ale v praxi som sa s tym nestretol. ide prakticky o nieco podobne ako STARTTLS v ramci SMTP…

pre uri schemu https sa da vyuzit Server Name Indication.