ever since 3.0 (or before) CA certificate was assigned a notBefore custom field one day in past using: date --date "now -1 days" +"%y%m%d%H%M%S%z" this was later modified to be use UTC, instead of local time: date --utc --date "now -1 days" +"%y%m%d%H%M%S%z" format of this includes timezone offset and confirm to ASN.1 UTCTime, but violates rfc2459, it was accepted by many (all) browsers and remotes, but now has issue with Firefox who enforces this[1] the proper format should be with Z suffix. this effects every engine out there. no issue to do this with every new installation. how do we do this for existing? re-enroll CA? manual procedure? [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1152515
Migration existing (if any) will be done in different bug.
OK, all is ready, including reissue of the CA certificate. I tested this, looks like it is working. Pavel, I suggest to test this in master before backporting.
Pavel, This was merged to 3.5 branch, so next 3.5 snapshot can be tested with these fixes. This should be tested early in release cycle so we have enough time to fix if it introduces new issues. Important tests: 1. 3.5.0 -> 3.5.3 upgrade - existing hosts, websocket proxy, engine https should continue to work without an issue. 2. 3.5.0 -> 3.5.3 post upgrade - adding new host should succeed, migration between hosts with new and old certificates should work. 3. 3.0 -> 3.5.3 upgrade - should work, ca certificate should be renewed, the .truststore should contain only the new ca certificate, the AIA in cacert.conf should be valid.
Upgrade to 3.5.3 (vt15) doesn't work yet - fix: https://gerrit.ovirt.org/#/c/41264/
(In reply to Pavel Stehlik from comment #4) > Upgrade to 3.5.3 (vt15) doesn't work yet - fix: > https://gerrit.ovirt.org/#/c/41264/ no private comments in upstream please, remove private from this and previous. this is different issue, apparently the upgrade of engine did not enroll certificates as in clean 3.5 install. this should be fixed.
In firefox if sec_error_reused_issuer_and_serial is displayed as an error, the old CA should be removed then refresh and trust the new certificate.
testing till now (only engine, no reports): - 3.5.0 (vt14.4): bad UTCTime visible in guiDumpASN and FF makes trouble - 3.5.0 -> 3.5.3-1 (vt15.10): certs got regenerated, CA in guiDumpASN is without errors, FF is ok
(In reply to Jiri Belka from comment #7) > testing till now (only engine, no reports): > > - 3.5.0 (vt14.4): bad UTCTime visible in guiDumpASN and FF makes trouble > - 3.5.0 -> 3.5.3-1 (vt15.10): certs got regenerated, CA in guiDumpASN is > without errors, FF is ok Hi, Please confirm all sequences in comment#3 were checked. Thanks!
I'm moving this to VERIFIED as to my understanding clean install works after this change and upgrade is not affected. Upgrade flows mentioned and affects should be be tested as part of BZ #1214860.
released as part of ovirt 3.5.3
After replacing the CA with a new one with the same serial number Chrome (45.0.2454.85 - 64-bit - Fedora 22) fails without providing helpful details, it just says: This webpage is not available ERR_FAILED While in the network debug panel ( chrome://net-internals/#events ) you can find: 1295105: SOCKET ssl/tiramd1.localdomain:443 Start Time: 2015-09-10 15:31:52.957 t=2815 [st=0] +SOCKET_ALIVE [dt=4] source_dependency = 1295104 (CONNECT_JOB) t=2815 [st=0] +TCP_CONNECT [dt=0] address_list = ["192.168.1.115:443"] t=2815 [st=0] TCP_CONNECT_ATTEMPT [dt=0] address = "192.168.1.115:443" t=2815 [st=0] -TCP_CONNECT source_address = "192.168.1.120:36405" t=2815 [st=0] +SOCKET_IN_USE [dt=4] source_dependency = 1295103 (CONNECT_JOB) t=2815 [st=0] +SSL_CONNECT [dt=4] t=2815 [st=0] SOCKET_BYTES_SENT byte_count = 211 t=2818 [st=3] SOCKET_BYTES_RECEIVED byte_count = 2525 t=2819 [st=4] SSL_HANDSHAKE_ERROR net_error = -2 (ERR_FAILED) ssl_lib_error = -8054 t=2819 [st=4] SOCKET_BYTES_SENT byte_count = 7 t=2819 [st=4] -SSL_CONNECT net_error = -2 (ERR_FAILED) t=2819 [st=4] -SOCKET_IN_USE t=2819 [st=4] -SOCKET_ALIVE It necessary to manually remove the previous CA to go further.
This BZ is not about regeneration, see https://bugzilla.redhat.com/show_bug.cgi?id=1214860#c23 IIUC chrome (which we do not support in downstream) behaves like FF.