Bug 1420577 - [Docs][RFE][Upgrade] Document change to signed certificates.
Summary: [Docs][RFE][Upgrade] Document change to signed certificates.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.1.3
: ---
Assignee: Emma Heftman
QA Contact: Tahlia Richardson
URL: https://access.redhat.com/solutions/2...
Whiteboard:
Depends On: 1309930
Blocks: 1440662
TreeView+ depends on / blocked
 
Reported: 2017-02-09 01:25 UTC by Byron Gravenorst
Modified: 2019-05-07 12:56 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-12 07:47:44 UTC
oVirt Team: Docs
Target Upstream Version:
didi: needinfo-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1440662 0 unspecified CLOSED [TestOnly] 3rd party CA with / without sha256 2021-02-22 00:41:40 UTC

Internal Links: 1440662

Description Byron Gravenorst 2017-02-09 01:25:13 UTC
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,

Comment 1 Lucy Bopf 2017-03-06 05:09:21 UTC
Assigning to Emma for review.

Comment 4 Emma Heftman 2017-03-16 12:57:46 UTC
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?

Comment 5 Yedidyah Bar David 2017-03-16 14:01:44 UTC
(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.

Comment 6 Emma Heftman 2017-03-16 14:27:39 UTC
(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.

Comment 7 Yedidyah Bar David 2017-03-16 15:33:02 UTC
(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.

Comment 8 Emma Heftman 2017-03-21 12:37:18 UTC
(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.

Comment 9 Emma Heftman 2017-03-21 13:17:55 UTC
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.

Comment 14 Emma Heftman 2017-04-06 08:39:21 UTC
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.

Comment 15 Emma Heftman 2017-04-09 08:26:51 UTC
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.

Comment 16 Emma Heftman 2017-04-09 08:37:47 UTC
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.

Comment 17 Emma Heftman 2017-04-09 08:42:50 UTC
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

Comment 18 Sandro Bonazzola 2017-04-10 08:39:49 UTC
(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

Comment 19 Emma Heftman 2017-04-12 12:44:44 UTC
(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.

Comment 20 Emma Heftman 2017-04-23 11:14:11 UTC
(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.

Comment 21 Emma Heftman 2017-04-23 11:17:58 UTC
(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.

Comment 23 Emma Heftman 2017-04-25 13:48:21 UTC
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?

Comment 24 Yaniv Lavi 2017-04-25 14:01:32 UTC
(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.

Comment 25 Kurt Seifried 2017-04-25 17:24:14 UTC
(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.

Comment 26 Emma Heftman 2017-05-07 08:30:06 UTC
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!

Comment 27 Yedidyah Bar David 2017-05-18 08:58:27 UTC
Now published:

https://www.ovirt.org/documentation/how-to/migrate-pki-to-sha256/

Comment 28 Emma Heftman 2017-05-18 09:26:44 UTC
(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."

Comment 29 Emma Heftman 2017-05-18 09:29:11 UTC
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)

Comment 30 Yedidyah Bar David 2017-05-18 09:38:23 UTC
(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.

Comment 31 Yaniv Lavi 2017-05-21 07:41:32 UTC
Who can assist with testing on this flow?

Comment 44 Emma Heftman 2017-06-20 10:35:00 UTC
Petr, can you please confirm that all flows are now ready for documenting?

Comment 45 Emma Heftman 2017-06-20 10:37:39 UTC
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.

Comment 46 Yedidyah Bar David 2017-06-20 11:58:54 UTC
(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/

Comment 47 Yaniv Lavi 2017-06-21 08:46:47 UTC
(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"

Comment 48 Yedidyah Bar David 2017-06-21 09:07:54 UTC
(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?

Comment 49 Petr Kubica 2017-06-21 10:13:34 UTC
Emma, from QA perspective it's ready for documenting.

Comment 50 Yaniv Lavi 2017-06-21 13:53:41 UTC
(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.

Comment 51 Yedidyah Bar David 2017-06-21 14:22:30 UTC
(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.

Comment 53 Yaniv Lavi 2017-06-25 14:30:42 UTC
(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.

Comment 54 Emma Heftman 2017-07-03 08:38:11 UTC
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!

Comment 55 Yedidyah Bar David 2017-07-03 11:50:57 UTC
(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/

Comment 67 Lucy Bopf 2017-08-25 03:38:13 UTC
Removing needinfos as this bug has been closed. Any further feedback should be raised as a separate bug now.


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