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
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?
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.
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.
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:
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
Please confirm all sequences in comment#3 were checked.
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
While in the network debug panel ( chrome://net-internals/#events ) you can find:
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.