The key generated by the engine install ended up with a bad CN; it has a five-digit number appended to the host name, and no SAN. I've lived with this through setup, but now I'm getting close to prod use, and need to clean up so that it is usable for general consumption. And the SPICE HTML client is completely busted due to this; that's a problem because we're mostly MacOS on the client side, and the Mac Spice client is unusable for normal humans. I'm wary of attempting to regenerate these manually, as I don't have a handle on how the keysare used by the various components. What is the approved method of regenerating these keys? -j
On Sat, May 13, 2017 at 2:35 AM, Jamie Lawrence <jlawrence@squaretrade.com> wrote:
The key generated by the engine install ended up with a bad CN; it has a five-digit number appended to the host name, and no SAN.
The 5 random digits are supposed to be OK, and are actually a feature - it ensures uniqueness if you re-generate (most likely reinstall your Engine), as otherwise some browsers fail miserably if a CA cert mismatches what they know. SAN is being worked on - we are aware of Chrome 58 now requiring it. I sincerely hope to see it in 4.1.2 (see https://bugzilla.redhat.com/1449084 ). Y.
I've lived with this through setup, but now I'm getting close to prod use, and need to clean up so that it is usable for general consumption. And the SPICE HTML client is completely busted due to this; that's a problem because we're mostly MacOS on the client side, and the Mac Spice client is unusable for normal humans.
I'm wary of attempting to regenerate these manually, as I don't have a handle on how the keysare used by the various components.
What is the approved method of regenerating these keys?
-j _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Sun, May 14, 2017 at 11:01 AM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Sat, May 13, 2017 at 2:35 AM, Jamie Lawrence <jlawrence@squaretrade.com> wrote:
The key generated by the engine install ended up with a bad CN; it has a five-digit number appended to the host name, and no SAN.
In addition to Yaniv's explanation below, can you explain why it was bad? That is, what software/process was broken by it? Please note that this is the CN of the CA's cert, not of the individual certs its signs (such as the one for the web server for https) - these have the FQDN you supplied to engine-setup as their CN.
The 5 random digits are supposed to be OK, and are actually a feature - it ensures uniqueness if you re-generate (most likely reinstall your Engine), as otherwise some browsers fail miserably if a CA cert mismatches what they know.
SAN is being worked on - we are aware of Chrome 58 now requiring it. I sincerely hope to see it in 4.1.2 (see https://bugzilla.redhat.com/1449084 ).
Indeed, and see my comment 5 there for how to add SAN to an existing setup, _after_ you upgrade to 4.1.2 when it's out.
Y.
I've lived with this through setup, but now I'm getting close to prod use, and need to clean up so that it is usable for general consumption. And the SPICE HTML client is completely busted due to this; that's a problem because we're mostly MacOS on the client side, and the Mac Spice client is unusable for normal humans.
I'm wary of attempting to regenerate these manually, as I don't have a handle on how the keysare used by the various components.
What is the approved method of regenerating these keys?
This depends on several different factors, including the expected cost of full export/reinstall/import compared to partial solutions. If you have a small setup that can have downtime, and have enough resources to prepare a more-or-less complete test environment where you can verify what you plan to do, then export/reinstall/import (where export is not really needed these days, the engine can import an existing storage domain) is the safest option. See also: https://www.ovirt.org/documentation/how-to/networking/changing-engine-hostna... Best,
-j _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Didi
On May 14, 2017, at 3:35 AM, Yedidyah Bar David <didi@redhat.com> wrote:
In addition to Yaniv's explanation below, can you explain why it was bad? That is, what software/process was broken by it? Please note that this is the CN of the CA's cert, not of the individual certs its signs (such as the one for the web server for https) - these have the FQDN you supplied to engine-setup as their CN.
You're absolutely right; my apologies for that red herring. I confused myself after too long at the keyboard.
The 5 random digits are supposed to be OK, and are actually a feature - it ensures uniqueness if you re-generate (most likely reinstall your Engine), as otherwise some browsers fail miserably if a CA cert mismatches what they know.
SAN is being worked on - we are aware of Chrome 58 now requiring it. I sincerely hope to see it in 4.1.2 (see https://bugzilla.redhat.com/1449084 ).
Indeed, and see my comment 5 there for how to add SAN to an existing setup, _after_ you upgrade to 4.1.2 when it's out.
Great, that's handy.
See also:
https://www.ovirt.org/documentation/how-to/networking/changing-engine-hostna...
Thanks for the pointer! That was the missing piece for me; my Google-fu failed to uncover it. I think I have what I need. Thanks again to both of you, -j
participants (3)
-
Jamie Lawrence -
Yaniv Kaul -
Yedidyah Bar David