... taky by mohli prestat kazdou chvili menit certifikaty na xmmp/hangouts ...
Záleží na době platnosti certifikátu. Pokud konec jeho platnosti je až v roce 2017 nebo později, zobrazí se u ikony HTTPS žlutý trojúhelník jako výstraha, že vše není v pořádku. S dalšími verzemi se bude přitvrzovat – hraniční datum se bude posouvat blíž k dnešku a varování se změní na červený křížek „nezabezpečené spojení“.
GMail má certifikáty s platností pár měsíců, takže toho se to dnes nedotkne. Ale doufám, že se Google pochlapí, a přejde sám na SHA-2 certifikáty. Ale vzhledem k tomu, že SHA-1 jsou i certifikáty jejich CA, a spousta dalších CA má SHA-1 certifikáty, je ten harmonogram docela drsný.
Obávám se, že z toho bude docela zmatek. Aby zůstaly platné stávající certifikáty, dělají to CA tak, že vydají svůj nový certifikát s SHA-2, ale se stejným veřejným klíčem. Takže od serverového certifikátu vedou dvě různé certifikační cesty ke dvěma různým kořenovým certifikátům. To jsem zvědav, jak si s tím který software poradí.
CA vydává klientům certifikáty podepsané privátním klíčem. Veřejný klíč k tomuto privátnímu klíči se spojí s identifikačními údaji, udělá se SHA-1 hash těchto dat a ten podepíše CA svým kořenovým certifikátem – takhle vznikne intermediate certifikát. Když bude chtít CA posílit vazbu mezi údaji a klíčem toho intermediate certifikátu (zmenšit pravděpodobnost, že se někomu podaří vyrobit stejný certifikát, ale se svým klíčem), vezme ten samý veřejný klíč, připojí k němu pokud možno stejné identifikační údaje (musí ukazovat na toho samého vlastníka), a z těchto dat spočítá tentokrát SHA-256 hash, a ten opět podepíše svým kořenovým certifikátem. Takže klientské certifikáty podepsané tím privátním klíčem pak jdou ověřit přes oba ty intermediate certifikáty.
Např. tady máte dva starší kořenové certifikáty Thawte, oba dva jsou ke stejné dvojici klíčů, ale u jednoho je podepsáno MD5, druhý už má v podpisu SHA-1:
-----BEGIN CERTIFICATE----- MIIDEzCCAnygAwIBAgIBATANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTYwODAx MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCBxDELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYDVQQKExRUaGF3 dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEmMCQGCSqGSIb3 DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBANOkUG7I/1Zr5s9dtuoMaHVHoqrC2oQl/Kj0R1HahbUgdJSGHg91 yekIYfUGbTBuFRkC6VLAYttNmZ7iagxEOM3+vuNkCXDF/rFrKbYvScg71CcEJRCX L+eQbcAoQpnXTEPew/UhbVSfXcNY4cDk2VuwuNy0e982OsK1ZiIS1ocNAgMBAAGj EzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAB/pMaVz7lcxG 7oWDTSEwjsrZqG9JGubaUeNgcGyEYRGhGshIPllDfU+VPaGLtwtimHp1it2ITk6e QNuozDJ0uW8NxuOzRAvZim+aKZuZGCg70eNAKJpaPNW15yAbi8qkq43pUdniTCxZ qdq5snUb9kLy78fyGPmJvKP/iiMucEc= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDIjCCAougAwIBAgIQNKT/9jCvTKU8MxdCoZRmdTANBgkqhkiG9w0BAQUFADCB xDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhh d3RlIFNlcnZlciBDQTEmMCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0 ZS5jb20wHhcNOTYwODAxMDAwMDAwWhcNMjEwMTAxMjM1OTU5WjCBxDELMAkGA1UE BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlm aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZl ciBDQTEmMCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wgZ8w DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANOkUG7I/1Zr5s9dtuoMaHVHoqrC2oQl /Kj0R1HahbUgdJSGHg91yekIYfUGbTBuFRkC6VLAYttNmZ7iagxEOM3+vuNkCXDF /rFrKbYvScg71CcEJRCXL+eQbcAoQpnXTEPew/UhbVSfXcNY4cDk2VuwuNy0e982 OsK1ZiIS1ocNAgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEF BQADgYEAvkBpQW/G28GnvwfAReTQtUMeTJUzNelewj4o9qgNUNX/4gwP/FACjq6R ua00io2fJ3GqGcxL6ATK1BdrEhrWxl/WzV7/iXa/2EjYWb0IiokdV81FHlK6EpqE +hiJX+j5MDVqAWC5mYCDhQpu2vTJj15zLTFKY6B08h+LItIpPus= -----END CERTIFICATE-----
(Variantu s SHA-1 a SHA-2 jsem teď rychle nenašel.) Týká se to algoritmu podpisu, nebo je takhle možné před self-signed certifikát předřadit jiný kořenový certifikát, velikost klíče takhle samozřejmě změnit nelze.
Nezlobte se, ale Vas popis tvorby intermediate certifikatu je celkem zhuleny.
Kazdopadne vidim dve moznosti:
1) server poskytne chain s novym intermediate certifikatem a validace probehne proti nemu. To bych ostatne doporucil, protoze starsi browsery nektere intemediate certifikaty stejne neznaji. Treba zrovna thawti "C=US, O=Thawte, Inc., CN=Thawte SSL CA".
2) v systemovem keystore se nahradi stary SHA1 certifikat novym se SHA2, takze bude jenom jedna cesta, jak certifikat validovat.
Jinak treba openssl hleda certifikaty pres hash symlinky a ty jsou u obou Vami zminenych certifikatu samozrejme stejne. Hadam, ze kdyz zvaliduje proti 6cc3c4c3.0, uz se nebude obtezovat 6cc3c4c3.1.
Pokud je podle vás na popisu tvorby certifikátu něco špatně, neměl by pro vás být problém napsat, co konkrétně. Samozřejmě jsem to zjednodušil a napsal jsem jenom to, co je pro tuto diskusi podstatné.
Těch možností je spousta, přičemž problém je v tom, že klient zpravidla nemůže ovlivnit, jaké certifikáty bude posílat server, a server zase neovlivní, jaké certifikáty považuje za důvěryhodné klient. Takže jde o to, jak se budou chovat různé implementace. Ale vzhledem k tomu, že už se to samé řešilo při přechodu z MD5 na SHA1, je spolu snad většina používaného softwaru kompatibilní. Na druhou stranu, tenkrát se certifikáty používaly mnohem méně, a také od té doby vznikl nový software.