Moc se v tématice v článku nevyznám (prakticky vůbec) ale chtěl bych se zeptat, možná dát podmět autorovi článku.
Nemění se podpora certifikátů u prohlížečů v čase?
Zdá se mi, že certifikát který dříve šel všude (všechny prohlížeče/os) již v nových verzích Firefoxu (na a to jen Windows Wista a lepších, XP stále jde) se označuje jako nedůvěryhodný.
Pokud se mění, lze napsat článek o tom jak a případně zahrnout informaci co navíc máme od certifikačních autorit dožadovat?
(více informací, včetně skutečné ukázky dodám případně emailem)
Tenhle problém se nejčastěji vyskytuje, pokud server neposílá všechny certifikáty mezilehlých CA až po důvěryhodnou CA. V takovém případě se certifikát jeví někde jako důvěryhodný, jinde jako nedůvěryhodný v závislosti na tom, zda došlo k zavlečení certifikátů mezilehlých CA do systémového uložiště (např. navštívením jiného místa s certifikátem od stejného vydavatele), nebo ne.
Napadá mě, že by to mohlo souviset se změnou přístupu k důvěryhodným kořenovým certifikátům ve Windows 7/Vista.
Windows XP si nainstaluje všechny kořenové certifikáty CA, které MS považuje za důvěryhodné, během update Windows.
Windows 7/Vista si kořenové důvěryhodné certifikáty stáhne ze stránek MS až v okamžiku, kdy se poprvé použijí. Důležité je, aby podepsaný dokument (kód/...) obsahoval všechny potřebné certifikáty, které jsou nutné k ověření, včetně kořenového.
Netuším ale, jestli Firefox pro ověřování pravosti používá CryptoAPI od Microsoftu, nebo jestli používá pouze vlastní řešení (NSS).
Skutečně nevím, čím to je a jako začátečník netuším jak toto řešit. Prostě jsem v Apache ty klíče nahrál a o více se nestaral ;o)
Pokud se chcete podívat, nebo mi nevěříte, nebo Vás to jen zajímá tak adresa je: https://www.fitness14.cz/ - jak říkám, na kombinaci firefox+vista(w7) to bude hlásit nedůvěryhodný certifikát, přitom ostatní prohlížece (opera, chrome a IE) na stejném systému v pohodě, v ubuntu a debianu vše ok a to i se stejnou verzi Firefoxu.
(Každopádně platí, že najít dneska certifikační autoritu která umí všechny prohlížeče a není předražená, nebo zdarma, je téměř nemožné.)
k prohlizecum
* IE bere certifikaty vzdy z WINDOWS uloziste cert. (windows update)
* FF a ostatni maji svoje VLASTNI uloziste certifikatu (FF update)
zkousel jsem stranku z debianu 6 stable s FF (3.5.16) a ukazuje mi untrusted
problem bude v tom, ze Vam v FF apod chybi intermediate cert od starcomu (v IE uz se o to postaral windows update) - zde je ke stazeni http://www.startssl.com/certs/class1/sha1/der/sub.class1.server.sha1.ca.crt - po jeho importu do FF to bude fungovat
otazka jestli vubec certum od tehle "postizenejch" CA duverovat...
A ještě přesný postup řešení - výše odkazovaný mezilehlý certifikát přilep (pomocí utility cat) k souboru certifikátem (nikoli privátním klíčem) pro apache. A ještě pro jistotu přilep certifikát kořenové autority (pro případ W7).
Správné chování ověř pomocí
openssl s_client -connect www.fitness14.cz:443
teď to vypisuje:
Certificate chain 0 s:/description=546967-qzoGLMILu7453B3H/CN=demo11.diskety.cz/emailAddress=bibapub@gmail.com i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
Později to bude vypisovat navíc toto:
1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority 2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
Ještě teď jsem si všiml, že používáš SNI a toto není výchozí virtualhost pro danou IP/port. Takže je potřeba přidat za openssl přepínač -servername www.fitness14.cz
. Jinak dostanu certifikát pro demo11.diskety.cz :)
Protože používáte SNI, nebude certifikát důvěryhodný na platformách, kde SNI nefunguje, tj. WinXP + IE, Konqueror a dále spousta mobilů. Viz článek Petra Krčmáře z listopadu.
Navíc jak koukám, na diskety.cz je jen nějaké administrační rozhraní... V tom případě bude asi lepší přehodit pořadí virtualhostů v apache, aby na prvním místě bylo fitness24.
V řetězci, který zasílá server, chybí intermediate ("mezilehlý") certifikát pro "StartCom Class 1 Primary Intermediate Server CA". Ten by měl být v řetězci posílán za certifikátem serveru.
Důvod, proč na některých prohlížečích funguje a na jiných ne, je lokální cache intermediate certifikátů.
Malá demonstrace:
1. spustíme Firefox s novým čistým profilem: firefox -P -no-remote
2. naklikáme nový profil
3. jdeme na https://www.fitness14.cz/
4. FF zahlásí "The certificate is not trusted because no issuer chain was provided."
5. Jdeme na https://msw.companycrypt.com (nějaký náhodný web používající stejnou CA a stejný řetězec intermediate certifikátů)
6. vrátíme se na https://www.fitness14.cz/ a ověření certifikátu projde, protože FF mezitím nacachoval ten intermediate certifikát
Na vývojáře browserů je tlak, aby chyby v řetězci potichu "opravili", pokud je to možné. Výsledek je, že administrátoři pak neví, že mají něco špatně na straně serveru.
Různé triky při budování řetězce dělá každý známější TLS klient. Výsledek je, že dva browsery můžou vidět různé řetezce.
Problem je v tom, ze tam mas v ceste este intermediate sub CA.
Postup ako na to je napr. tu:
http://www.digicert.com/ssl-certificate-installation-apache.htm