Bug 1210486 - [PKI] CA certificate notBefore should confirm to rfc2459
Summary: [PKI] CA certificate notBefore should confirm to rfc2459
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-installer
Version: 3.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.5.3
Assignee: Alon Bar-Lev
QA Contact: Jiri Belka
URL:
Whiteboard: infra
Depends On:
Blocks: 1214860 1259601
TreeView+ depends on / blocked
 
Reported: 2015-04-09 20:35 UTC by Alon Bar-Lev
Modified: 2016-02-10 19:34 UTC (History)
12 users (show)

Fixed In Version: ovirt-3.5.3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-16 07:20:28 UTC
oVirt Team: Infra


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1214860 0 high CLOSED [RFE][PKI] renew important certificate when about to expire during engine-setup 2021-02-22 00:41:40 UTC
oVirt gerrit 39738 0 master MERGED pki: comply with rfc2459 UTCTime restriction Never
oVirt gerrit 39739 0 master MERGED pki: pki-create-ca.sh: add renew Never
oVirt gerrit 39742 0 master MERGED packaging: setup: pki: renew pki certificate if invalid Never
oVirt gerrit 39816 0 ovirt-engine-3.5 MERGED pki: comply with rfc2459 UTCTime restriction Never
oVirt gerrit 39817 0 ovirt-engine-3.5 MERGED pki: pki-create-ca.sh: add renew Never
oVirt gerrit 39818 0 ovirt-engine-3.5 MERGED packaging: setup: pki: renew pki certificate if invalid Never
oVirt gerrit 40161 0 master MERGED pki: comply with rfc2459 UTCTime restriction Never
oVirt gerrit 40163 0 ovirt-engine-3.5 MERGED pki: comply with rfc2459 UTCTime restriction Never
oVirt gerrit 40186 0 master MERGED pki: renew CA for same length as enrollment Never
oVirt gerrit 40238 0 ovirt-engine-3.5 MERGED pki: renew CA for same length as enrollment Never
oVirt gerrit 40324 0 ovirt-engine-3.5.3 MERGED pki: renew CA for same length as enrollment Never
oVirt gerrit 40330 0 master MERGED packaging: setup: pki: renew about to expire certificates Never
oVirt gerrit 40508 0 ovirt-engine-3.5 MERGED packaging: setup: pki: renew about to expire certificates Never
oVirt gerrit 40509 0 ovirt-engine-3.5.3 MERGED packaging: setup: pki: renew about to expire certificates Never

Internal Links: 1214860

Description Alon Bar-Lev 2015-04-09 20:35:26 UTC
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

Comment 1 Alon Bar-Lev 2015-04-09 21:08:00 UTC
Migration existing (if any) will be done in different bug.

Comment 2 Alon Bar-Lev 2015-04-10 11:20:35 UTC
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.

Comment 3 Alon Bar-Lev 2015-04-15 09:46:47 UTC
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.

Comment 4 Pavel Stehlik 2015-05-21 11:43:25 UTC
Upgrade to 3.5.3 (vt15) doesn't work yet - fix: https://gerrit.ovirt.org/#/c/41264/

Comment 5 Alon Bar-Lev 2015-05-21 12:13:02 UTC
(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.

Comment 6 Alon Bar-Lev 2015-05-28 11:55:17 UTC
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.

Comment 7 Jiri Belka 2015-05-28 14:08:22 UTC
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

Comment 8 Alon Bar-Lev 2015-06-03 07:32:22 UTC
(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!

Comment 9 Yaniv Lavi 2015-06-15 12:20:13 UTC
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.

Comment 10 Eyal Edri 2015-06-16 07:20:28 UTC
released as part of ovirt 3.5.3

Comment 11 Simone Tiraboschi 2015-09-11 14:56:06 UTC
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.

Comment 12 Jiri Belka 2015-09-11 15:27:12 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.