Bug 1210486

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.