The Manager signs certificates using the SHA256 algorithm instead of SHA-1 because SHA256 is more secure and is expected to have a longer life expectancy. Only the default for new certificates was changed. To change certificates for existing hosts, they need to be reinstalled, or to have their certificates enrolled. Other certificates require a completely new setup, using engine-cleanup and engine-setup, including the one for httpd. Document this change for signed certificates, how to change certificates for existing hosts,
Assigning to Emma for review.
Hi Didi I have several questions regarding the KB article that you sent me: https://access.redhat.com/solutions/2050903 1. This documentation bug discusses only the hosts, but the article also mentions the Manager. 2. If this is being introduced in 4.1, how comes the correct certificates are not installed automatically? 3. Please explain the exact scenario where the procedure would be required.\ 4. The article says "if the engine certificate needs to be replaced as well". Again, please specify when the engine's certificate should be replaced and when it shouldn't. 5. What is the connection with SSL certificates? 6. Would the same procedure be used for new and upgraded systems?
(In reply to Emma Heftman from comment #4) > Hi Didi > I have several questions regarding the KB article that you sent me: > https://access.redhat.com/solutions/2050903 > > 1. This documentation bug discusses only the hosts, but the article also > mentions the Manager. Indeed. And as was mentioned on the linked bug 1309930, there are a few others, including the CA cert and websocket-proxy. I don't think the article discusses the CA cert. Need to check what handling it will require. > > 2. If this is being introduced in 4.1, how comes the correct certificates > are not installed automatically? They are for new setups, but not for systems upgraded from previous versions. > > 3. Please explain the exact scenario where the procedure would be required.\ One of two I can think about: 1. People that get some warning/error from their new browser that warns against/prevents using https with certs signed with the SHA1 algorithm 2. People that care about their systems security, read/know/think that SHA1 is not secure enough for them, and want to change everywhere, or partially, to SHA256. > > 4. The article says "if the engine certificate needs to be replaced as > well". Again, please specify when the engine's certificate should be > replaced and when it shouldn't. See above. If you only want to get rid of a browser warning/issue, you only need to update the apache cert. > > 5. What is the connection with SSL certificates? Current bug is about SSL certificates. Such certificates have, among other things, a digital signature. There are several different ways (algorithms) to do such digital signatures, some more secure than others. > > 6. Would the same procedure be used for new and upgraded systems? Nothing is needed for new systems - these were handled by the patch in the linked bug. This procedure is for upgraded systems.
(In reply to Yedidyah Bar David from comment #5) > (In reply to Emma Heftman from comment #4) > > Hi Didi > > I have several questions regarding the KB article that you sent me: > > https://access.redhat.com/solutions/2050903 > > > > 1. This documentation bug discusses only the hosts, but the article also > > mentions the Manager. > > Indeed. And as was mentioned on the linked bug 1309930, there are a few > others, including the CA cert and websocket-proxy. > > I don't think the article discusses the CA cert. Need to check what handling > it will require. Please get back to me with the procedure for the CA certificate, if it needs to be documented too. Also for the websocket-proxy and any other entities that need to be updated. > > > > > 2. If this is being introduced in 4.1, how comes the correct certificates > > are not installed automatically? > > They are for new setups, but not for systems upgraded from previous versions. Do you think this documentation should be part of the Upgrade guide? I assume all users will receive an error message immediately after performing the upgrade. Perhaps it should be a standard upgrade procedure rather than waiting for them to receive an error message. OR Do only some broswers/browser versions issue the error message? > > > > > 3. Please explain the exact scenario where the procedure would be required.\ > > One of two I can think about: > 1. People that get some warning/error from their new browser that warns > against/prevents using https with certs signed with the SHA1 algorithm > 2. People that care about their systems security, read/know/think that SHA1 > is not secure enough for them, and want to change everywhere, or partially, > to SHA256. > > > > > 4. The article says "if the engine certificate needs to be replaced as > > well". Again, please specify when the engine's certificate should be > > replaced and when it shouldn't. > > See above. > > If you only want to get rid of a browser warning/issue, you only need to > update the apache cert. > Is the apache certificate on the host? > > > > 5. What is the connection with SSL certificates? > > Current bug is about SSL certificates. Such certificates have, among other > things, a digital signature. There are several different ways (algorithms) > to do such digital signatures, some more secure than others. > > > > > 6. Would the same procedure be used for new and upgraded systems? > > Nothing is needed for new systems - these were handled by the patch in the > linked bug. This procedure is for upgraded systems.
(In reply to Emma Heftman from comment #6) > (In reply to Yedidyah Bar David from comment #5) > > (In reply to Emma Heftman from comment #4) > > > Hi Didi > > > I have several questions regarding the KB article that you sent me: > > > https://access.redhat.com/solutions/2050903 > > > > > > 1. This documentation bug discusses only the hosts, but the article also > > > mentions the Manager. > > > > Indeed. And as was mentioned on the linked bug 1309930, there are a few > > others, including the CA cert and websocket-proxy. > > > > I don't think the article discusses the CA cert. Need to check what handling > > it will require. > > Please get back to me with the procedure for the CA certificate, if it needs > to be documented too. Also for the websocket-proxy and any other entities > that need to be updated. Setting needinfo on myself for this. Also pushed a patch that might be useful, still not sure: https://gerrit.ovirt.org/74199 > > > > > > > > 2. If this is being introduced in 4.1, how comes the correct certificates > > > are not installed automatically? > > > > They are for new setups, but not for systems upgraded from previous versions. > Do you think this documentation should be part of the Upgrade guide? Makes sense to me. > I > assume all users will receive an error message immediately after performing > the upgrade. Perhaps it should be a standard upgrade procedure rather than > waiting for them to receive an error message. Perhaps > OR > > Do only some broswers/browser versions issue the error message? Seems like chrome does, since version 56, released recently. Didn't check firefox. This does not affect the version of firefox packaged in RHEL. > > > > > > > > > 3. Please explain the exact scenario where the procedure would be required.\ > > > > One of two I can think about: > > 1. People that get some warning/error from their new browser that warns > > against/prevents using https with certs signed with the SHA1 algorithm > > 2. People that care about their systems security, read/know/think that SHA1 > > is not secure enough for them, and want to change everywhere, or partially, > > to SHA256. > > > > > > > > 4. The article says "if the engine certificate needs to be replaced as > > > well". Again, please specify when the engine's certificate should be > > > replaced and when it shouldn't. > > > > See above. > > > > If you only want to get rid of a browser warning/issue, you only need to > > update the apache cert. > > > Is the apache certificate on the host? It's on the engine machine, not on hosts. > > > > > > 5. What is the connection with SSL certificates? > > > > Current bug is about SSL certificates. Such certificates have, among other > > things, a digital signature. There are several different ways (algorithms) > > to do such digital signatures, some more secure than others. > > > > > > > > 6. Would the same procedure be used for new and upgraded systems? > > > > Nothing is needed for new systems - these were handled by the patch in the > > linked bug. This procedure is for upgraded systems.
(In reply to Yedidyah Bar David from comment #7) > (In reply to Emma Heftman from comment #6) > > (In reply to Yedidyah Bar David from comment #5) > > > (In reply to Emma Heftman from comment #4) > > > > Hi Didi > > > > I have several questions regarding the KB article that you sent me: > > > > https://access.redhat.com/solutions/2050903 > > > > > > > > 1. This documentation bug discusses only the hosts, but the article also > > > > mentions the Manager. > > > > > > Indeed. And as was mentioned on the linked bug 1309930, there are a few > > > others, including the CA cert and websocket-proxy. > > > > > > I don't think the article discusses the CA cert. Need to check what handling > > > it will require. > > > > Please get back to me with the procedure for the CA certificate, if it needs > > to be documented too. Also for the websocket-proxy and any other entities > > that need to be updated. > > Setting needinfo on myself for this. Do you have any new information with regards to these procedures? > > Also pushed a patch that might be useful, still not sure: > > https://gerrit.ovirt.org/74199 > > > > > > > > > > > > 2. If this is being introduced in 4.1, how comes the correct certificates > > > > are not installed automatically? > > > > > > They are for new setups, but not for systems upgraded from previous versions. > > Do you think this documentation should be part of the Upgrade guide? > > Makes sense to me. > > > I > > assume all users will receive an error message immediately after performing > > the upgrade. Perhaps it should be a standard upgrade procedure rather than > > waiting for them to receive an error message. > > Perhaps > > > OR > > > > Do only some broswers/browser versions issue the error message? > > Seems like chrome does, since version 56, released recently. > Didn't check firefox. > > This does not affect the version of firefox packaged in RHEL. So for this scenario, should we simply say if you receive an error message, without specifying which browsers do or don't issue an error? Or are you planning on checking firefox too? > > > > > > > > > > > > > > 3. Please explain the exact scenario where the procedure would be required.\ > > > > > > One of two I can think about: > > > 1. People that get some warning/error from their new browser that warns > > > against/prevents using https with certs signed with the SHA1 algorithm > > > 2. People that care about their systems security, read/know/think that SHA1 > > > is not secure enough for them, and want to change everywhere, or partially, > > > to SHA256. > > > > > > > > > > > 4. The article says "if the engine certificate needs to be replaced as > > > > well". Again, please specify when the engine's certificate should be > > > > replaced and when it shouldn't. > > > > > > See above. > > > > > > If you only want to get rid of a browser warning/issue, you only need to > > > update the apache cert. > > > > > Is the apache certificate on the host? > > It's on the engine machine, not on hosts. > > > > > > > > > 5. What is the connection with SSL certificates? > > > > > > Current bug is about SSL certificates. Such certificates have, among other > > > things, a digital signature. There are several different ways (algorithms) > > > to do such digital signatures, some more secure than others. > > > > > > > > > > > 6. Would the same procedure be used for new and upgraded systems? > > > > > > Nothing is needed for new systems - these were handled by the patch in the > > > linked bug. This procedure is for upgraded systems.
Summarizing all open issues for Didi to look into, both what appears hear and issues discussed offline: 1. Perform additional browser tests to see what we can/should do/document 2. Test whether the current procedure works in a self-hosted engine upgrade? 3. Check the documented procedure on the hosts. 4. Check what procedure will be required for the CA cert and websocket-proxy, and any other additional procedure not discussed in the KB article.
The current status is that as there are several different ways for customers to approach this important issue of security, PMs input is needed in order to define exactly which options we will document and which procedures should be mandatory. It has also been brought to light that the procedures referenced in https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/installation_guide/connecting_to_the_administration_portal are out-of-date and need to be updated. I will open separate bug for that issue.
Dan, I'm copying of the text from the email discussion that took place. Pls. continue the discussion here. I wrote: >> From 4.1, new system are automatically installed with a CA on the engine >> that uses SHA256 for communicating with the hosts, and it is used throughout >> the system, for SPICE console, image uploads, Administration Portal access >> etc. >> >> The issue is that for systems upgraded to 4.1, they must run these >> procedures manually. Some of which are extremely time-consuming, and will >> affect Support, etc. >> >> So, some customers may decide to make do with just installing apache >> certificate, or maybe they will need to get a CA certificate on the browsers >> too? >> >> There is the question of whether to set all hosts to Maintenance, Choose >> "Enroll Certificates", and Activate. Dan wrote: I probably do not understand you. Moving all hosts together to Maintenance after upgrade to 4.1 is unacceptable. What currently happens when Engine is upgraded? I believe that hosts with outdatet certificates should be marked as problematic. We can ship a script to iteratively move these hosts to Maintenance, Enroll Certs and Activate.
Moran, Can you please comment on this. Sandro would like you to define which browsers should be tested and later documented in order to understand how each environment will react and which steps need to be taken for each environment. >>Sandro Leaving this to PMs. 2. Should we test this procedure (especially with the partial flows) on many browsers and document each in detail? >>Didi Specifically - I didn't check, but it might be possible, that some browsers do already warn/mark sha1 server certs as insecure, but do not warn/mark server certs that are signed with sha256, even if the CA cert that signed them is sha1. If this is the case, it means the user does not need, for these browsers, to recreate the ca cert. >>Sandro I think we committed to support some browsers listed in https://access.redhat.com/help/browsers/ So I think we should check what happens there.
Sandro With regards to the statement below, will you be opening a separate bug, to handle this issue of customers who have implemented 3rd party CAs? I think we should also handle this with a separate documentation bug once the information is available? We have a section that explains how to install their own CA. I think we need to confirm that this is still correct, relevant, desirable: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/administration_guide/appe-red_hat_enterprise_virtualization_and_ssl#Replacing_the_Manager_SSL_Certificate IMO that's not very unrelated. We still want this, and it's up to users to use sha256 then. We do need to make sure (I didn't) that the procedure we write works well also for customers that used above article and use 3rd party CAs. >>>Sandro wrote: Agreed
(In reply to Emma Heftman from comment #17) > Sandro > With regards to the statement below, will you be opening a separate bug, to > handle this issue of customers who have implemented 3rd party CAs? Opened bug #1440662 > I think we should also handle this with a separate documentation bug once > the information is available? Maybe
(In reply to Emma Heftman from comment #14) > The current status is that as there are several different ways for customers > to approach this important issue of security, PMs input is needed in order > to define exactly which options we will document and which procedures should > be mandatory. > > It has also been brought to light that the procedures referenced in > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ > html/installation_guide/connecting_to_the_administration_portal > are out-of-date and need to be updated. > > I will open separate bug for that issue. This is the bug that I opened to document the out-of-date procedure that Didi pointed out while working with me on this bug.
(In reply to Emma Heftman from comment #15) > Dan, I'm copying of the text from the email discussion that took place. > Pls. continue the discussion here. > > I wrote: > > >> From 4.1, new system are automatically installed with a CA on the engine > >> that uses SHA256 for communicating with the hosts, and it is used throughout > >> the system, for SPICE console, image uploads, Administration Portal access > >> etc. > >> > >> The issue is that for systems upgraded to 4.1, they must run these > >> procedures manually. Some of which are extremely time-consuming, and will > >> affect Support, etc. > >> > >> So, some customers may decide to make do with just installing apache > >> certificate, or maybe they will need to get a CA certificate on the browsers > >> too? > >> > >> There is the question of whether to set all hosts to Maintenance, Choose > >> "Enroll Certificates", and Activate. > > Dan wrote: > > I probably do not understand you. Moving all hosts together to > Maintenance after upgrade to 4.1 is unacceptable. What currently > happens when Engine is upgraded? > > I believe that hosts with outdatet certificates should be marked as > problematic. We can ship a script to iteratively move these hosts to > Maintenance, Enroll Certs and Activate. Hi Dan Please let me know what the status is. Are you going to be shipping a script? If so, please provide details. If not, please let me know whether I should go ahead and document Didi's procedure for shutting down and updating the hosts.
(In reply to Emma Heftman from comment #16) > Moran, > Can you please comment on this. Sandro would like you to define which > browsers should be tested and later documented in order to understand how > each environment will react and which steps need to be taken for each > environment. > > >>Sandro > Leaving this to PMs. > > > > 2. Should we test this procedure (especially with the partial flows) on > many browsers > and document each in detail? > >>Didi > Specifically - I didn't check, but it might be possible, that some > browsers > do already warn/mark sha1 server certs as insecure, but do not warn/mark > server certs that are signed with sha256, even if the CA cert that signed > them is sha1. If this is the case, it means the user does not need, for > these browsers, to recreate the ca cert. > >>Sandro > > I think we committed to support some browsers listed in > https://access.redhat.com/help/browsers/ > So I think we should check what happens there. Hi Moran Can you please get back to me with regards to this issue.
Moran/Yaniv I met with Didi and Martin P and we discussed the remaining open issues. We need PM to define the following: 1. Which browsers do we need to document in terms of being to say exactly what will happen when upgrading to 4.1 and what they should do. Section 2.1.2 of the Installation Guide divides the browswers into tier support. Should we document only tier 1? https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/html/installation_guide/chap-system_requirements#Red_Hat_Enterprise_Virtualization_Manager_Requirements 2. How critical is it for all customers to use sha256 throughout the system? If we want this to happen ASAP, we need PM to approve that the current procedure is to shut down each host one by one. 3. If it is not critical to all customers, do we want to still document this procedure as an option for those who want the entire system to be sha256, or is this still unacceptable, and we should first QA the option of only restarting vdsm (Martin, correct me if this is incorrect). 4. Do we want to develop a script for 4.1.x or 4.2 to handle this? 5. If we only want to provide minimal sha256 support, should we document only replacing apache and spice? apache only?
(In reply to Emma Heftman from comment #23) > Moran/Yaniv > > I met with Didi and Martin P and we discussed the remaining open issues. > > We need PM to define the following: > > 1. Which browsers do we need to document in terms of being to say exactly > what will happen when upgrading to 4.1 and what they should do. Focus on tier 1 and 2. > > Section 2.1.2 of the Installation Guide divides the browswers into tier > support. Should we document only tier 1? > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/ > html/installation_guide/chap- > system_requirements#Red_Hat_Enterprise_Virtualization_Manager_Requirements > > > 2. How critical is it for all customers to use sha256 throughout the system? > If we want this to happen ASAP, we need PM to approve that the current > procedure is to shut down each host one by one. Kurt, can you please reply on this from a security aspect? Please respond on manager to host communication vs hosts to clients and manager to clients. > > 3. If it is not critical to all customers, do we want to still document this > procedure as an option for those who want the entire system to be sha256, or > is this still unacceptable, and we should first QA the option of only > restarting vdsm (Martin, correct me if this is incorrect). Yes. > > 4. Do we want to develop a script for 4.1.x or 4.2 to handle this? Moran, will the Ansible cluster update module be able to extend to do this? > > 5. If we only want to provide minimal sha256 support, should we document > only replacing apache and spice? apache only? Both.
(In reply to Yaniv Dary from comment #24) > (In reply to Emma Heftman from comment #23) > > Moran/Yaniv > > > > I met with Didi and Martin P and we discussed the remaining open issues. > > > > We need PM to define the following: > > > > 1. Which browsers do we need to document in terms of being to say exactly > > what will happen when upgrading to 4.1 and what they should do. > > Focus on tier 1 and 2. > > > > > Section 2.1.2 of the Installation Guide divides the browswers into tier > > support. Should we document only tier 1? > > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/ > > html/installation_guide/chap- > > system_requirements#Red_Hat_Enterprise_Virtualization_Manager_Requirements > > > > > > 2. How critical is it for all customers to use sha256 throughout the system? > > If we want this to happen ASAP, we need PM to approve that the current > > procedure is to shut down each host one by one. > > Kurt, can you please reply on this from a security aspect? > Please respond on manager to host communication vs hosts to clients and > manager to clients. So the biggest concern is web browsers because they are phasing out support for sha1 (I already get a LOT of ugly warnings when using some of our internal red hat sites): Chrome: https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html IE info: https://blogs.technet.microsoft.com/msrc/2017/02/23/sha-1-collisions-research/ Firefox: https://blog.mozilla.org/security/2017/02/23/the-end-of-sha-1-on-the-public-web/ so ideally we should phase out our use of SHA1 for anything browser facing prior to this (so no ugly warnings), and on the backends as quickly as we can because at some point the security bar will move and customers will start complaining. > > > > > 3. If it is not critical to all customers, do we want to still document this > > procedure as an option for those who want the entire system to be sha256, or > > is this still unacceptable, and we should first QA the option of only > > restarting vdsm (Martin, correct me if this is incorrect). > > Yes. > > > > > 4. Do we want to develop a script for 4.1.x or 4.2 to handle this? > > Moran, will the Ansible cluster update module be able to extend to do this? > > > > > 5. If we only want to provide minimal sha256 support, should we document > > only replacing apache and spice? apache only? > > Both.
Hi Yaniv Given Kurt's reply, could you please specify whether the current solution is satisfactory as they are and which steps need to be modified before they can be documented. Please specify exactly what part of the solution you would like documented, i.e. hosts and clients? Also, please confirm whether these steps have been verified by QE. Thanks!
Now published: https://www.ovirt.org/documentation/how-to/migrate-pki-to-sha256/
(In reply to Yedidyah Bar David from comment #27) > Now published: > > https://www.ovirt.org/documentation/how-to/migrate-pki-to-sha256/ Thanks Didi. A couple of issues: 1. As the document still is not entirely conclusive from a documentation perspective, e.g. "it might be enough to only re-sign the apache certificate, or only the CA+apache certificates. " IMO it is still not ready to be documented until we know exactly what the customer will experience in T1 browsers. 2. What did you meant by: "This procedure was only tested currently in its entirety."
The current status of this bug is that the browser behaviour still needs to be QAd before I can document the procedure. For that reason, I'm changing this bug's status back to New (approved by lbopf)
(In reply to Emma Heftman from comment #28) > (In reply to Yedidyah Bar David from comment #27) > > Now published: > > > > https://www.ovirt.org/documentation/how-to/migrate-pki-to-sha256/ > > Thanks Didi. A couple of issues: > 1. As the document still is not entirely conclusive from a documentation > perspective, e.g. "it might be enough to only re-sign the apache > certificate, or only the CA+apache certificates. " Of course. I just think that it's about time to publish it upstream. > > IMO it is still not ready to be documented until we know exactly what the > customer will experience in T1 browsers. Indeed. I didn't clear the needinfo... > > > 2. What did you meant by: "This procedure was only tested currently in its > entirety." I meant that although I wrote in it about some parts that they might be optional, I didn't test it without these parts - only tested everything together.
Who can assist with testing on this flow?
Petr, can you please confirm that all flows are now ready for documenting?
Didi, do you have a clear answer from PM as to which flows need to be documented? When we originally discussed it you had several different options, from lenient security policy (customer just gets rid of error message), to strong policy where we describe all certificate installations.
(In reply to Emma Heftman from comment #45) > Didi, do you have a clear answer from PM as to which flows need to be > documented? Not sure. Yaniv? > When we originally discussed it you had several different > options, from lenient security policy (customer just gets rid of error > message), to strong policy where we describe all certificate installations. Indeed. Based on Petr's results, it seems like the minimal flow (only getting rid of browser errors) is, when following [1]: - Change the default, if < 4.1 - Skip Re-sign CA cert - Re-sign certs for engine side entities: -- Choose entities to re-sign - choose 'names="apache"' -- Enter Maintenance -- Restart services - only httpd -- Exit maintenance -- Reconnect to web admin - as Petr mentioned, if the user already imported previous ca or https cert to the browser, the user will need to first find and remove them from the browser, then import the new ca cert. - Skip Enroll Certificates for hosts The other flow is doing all of [1], where the main extra work/investment is in re-enrolling certs for all hosts. This is mandatory for any security-concious installation. [1] https://www.ovirt.org/documentation/how-to/migrate-pki-to-sha256/
(In reply to Yedidyah Bar David from comment #46) > (In reply to Emma Heftman from comment #45) > > Didi, do you have a clear answer from PM as to which flows need to be > > documented? > > Not sure. Yaniv? > From the description: "Document this change for signed certificates, how to change certificates for existing hosts"
(In reply to Yaniv Lavi from comment #47) > (In reply to Yedidyah Bar David from comment #46) > > (In reply to Emma Heftman from comment #45) > > > Didi, do you have a clear answer from PM as to which flows need to be > > > documented? > > > > Not sure. Yaniv? > > > > From the description: > "Document this change for signed certificates, how to change certificates > for existing hosts" I do not understand. Do we want to document only the full procedure, re-signing all certs and re-enrolling on all hosts? Or do we want to document two (or more) flows, one of which is the minimum needed to make recent browsers happy with our certs, preventing them from popping up warning windows?
Emma, from QA perspective it's ready for documenting.
(In reply to Yedidyah Bar David from comment #48) > (In reply to Yaniv Lavi from comment #47) > > (In reply to Yedidyah Bar David from comment #46) > > > (In reply to Emma Heftman from comment #45) > > > > Didi, do you have a clear answer from PM as to which flows need to be > > > > documented? > > > > > > Not sure. Yaniv? > > > > > > > From the description: > > "Document this change for signed certificates, how to change certificates > > for existing hosts" > > I do not understand. > > Do we want to document only the full procedure, re-signing all certs and > re-enrolling on all hosts? > > Or do we want to document two (or more) flows, one of which is the minimum > needed to make recent browsers happy with our certs, preventing them from > popping up warning windows? We should tell the user to refer to the browser documentation and describe what needs to be done at a high level. Other than that the full needed flow to update the certs.
(In reply to Yaniv Lavi from comment #50) > We should tell the user to refer to the browser documentation and describe > what needs to be done at a high level. Agreed. This is already discussed in bug 1441676. > > Other than that the full needed flow to update the certs. But you need to define "needed" :-) I think this was thoroughly discussed earlier, but clarifying again. We considered two different reasons people might want to read/use the documentation we want to write: 1. Because they upgraded their browsers, and now their browsers started complaining about our certificates, and they want us to "fix" this - that is, just get rid of the warnings. Otherwise they have a secure network, or do not care about security, so would rather not enroll again all their hosts. 2. Because they care about security, and want all their certs to be sha256 everywhere. Do we want to write something for (1.), or only for (2.)? My current upstream doc does handle both.
(In reply to Yedidyah Bar David from comment #51) > (In reply to Yaniv Lavi from comment #50) > > We should tell the user to refer to the browser documentation and describe > > what needs to be done at a high level. > > Agreed. This is already discussed in bug 1441676. > > > > > Other than that the full needed flow to update the certs. > > But you need to define "needed" :-) > > I think this was thoroughly discussed earlier, but clarifying again. We > considered two different reasons people might want to read/use the > documentation we want to write: > > 1. Because they upgraded their browsers, and now their browsers started > complaining about our certificates, and they want us to "fix" this - that > is, just get rid of the warnings. Otherwise they have a secure network, or > do not care about security, so would rather not enroll again all their hosts. > > 2. Because they care about security, and want all their certs to be sha256 > everywhere. > > Do we want to write something for (1.), or only for (2.)? > > My current upstream doc does handle both. Include both, but I'm pretty sure that a KBase would be a better place for this than the documentation, since this is solving a issue, not describing the flow.
Hey Petr. Can you please clarify whether for the supported browsers, after the upgrade, did you receive warnings in the browser window at all - popups etc/ OR only when you look in the console? Thanks!
(In reply to Yedidyah Bar David from comment #46) > (In reply to Emma Heftman from comment #45) > > Didi, do you have a clear answer from PM as to which flows need to be > > documented? > > Not sure. Yaniv? > > > When we originally discussed it you had several different > > options, from lenient security policy (customer just gets rid of error > > message), to strong policy where we describe all certificate installations. > > Indeed. > > Based on Petr's results, it seems like the minimal flow (only getting rid of > browser errors) is, when following [1]: > - Change the default, if < 4.1 > - Skip Re-sign CA cert > - Re-sign certs for engine side entities: > -- Choose entities to re-sign - choose 'names="apache"' > -- Enter Maintenance -- Re-sign! Thanks, Emma, for noticing. > -- Restart services - only httpd > -- Exit maintenance > -- Reconnect to web admin - as Petr mentioned, if the user already imported > previous ca or https cert to the browser, the user will need to first find > and remove them from the browser, then import the new ca cert. > - Skip Enroll Certificates for hosts > > The other flow is doing all of [1], where the main extra work/investment is > in re-enrolling certs for all hosts. This is mandatory for any > security-concious installation. > > [1] https://www.ovirt.org/documentation/how-to/migrate-pki-to-sha256/
The procedure is now available in the Customer Portal: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/upgrade_guide/#Replacing_SHA-1_Certificates_with_SHA-256_Certificates
Removing needinfos as this bug has been closed. Any further feedback should be raised as a separate bug now.