Bug 1802294

Ian,

Agree, But clients are always opening cases for how to renew steps

I also get this question quite often from the customers that I cover. I do link to the deployment article but that leaves a dozen or more questions about what steps are neeeded to "only" replace the expired certs. It would be helpful if this option was built into the installer and propigated to Capsules and satellite clients. or if the steps are specifically called out in the documentation around replacing certificates as it's not clear in the current documentation. - MH, RH Solution Architect.

NOTE: 

If your satellite/Capsule is already configured with SSL certs and you have renewed it from the same CA then there is no need to replace the consumer package on each client.

If you have Custom/Third-party SSL certificates installed on the satellite/capsule from "A" CA and after the expiry of that certificate, 
     If you have taken an SSL certificate from "B" CA and you installed it on satellite/Capsule, then you have to remove the old consumer package and install the new consumer package after the installation of NEW certificates on each registered client. 
     It is because you will be having NEW CA on satellite and capsule if the CA of SSL certificate changes.

Howdy,

I wanted to better understand what specifically this is asking for as part of our consideration. If we look at [1] this section describes how to configure Satellite with custom certificates. If those certificates need to change (due to expiration, due to hostname change, due to CA change, any reason), the process is the same.


1. Can this be solved by adding a sentence at the start that says:


     Use this procedure to configure your Satellite Server any time you add or change custom SSL certificates.

2. Do we need to explicitly list some of the reasons certificates might be changed and emphasize that no matter what, you still use the procedure [1]?


3. I would agree that we can bulk up [2] with wording that states if you change certificates, you must update any hosts connected to the Satellite or Capsule that has a certificate change.

4. We should add a note that indicates changes to the custom certificates CA require not only host updates, but also Capsule certificate updates.


egolov -- Would you add anything else?


[1] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.12/html/installing_satellite_server_in_a_connected_network_environment/performing-additional-configuration#Deploying_a_Custom_SSL_Certificate_to_Server_satellite
[2] https://access.redhat.com/documentation/en-us/red_hat_satellite/6.12/html/installing_satellite_server_in_a_connected_network_environment/performing-additional-configuration#deploying-a-custom-ssl-certificate-to-hosts_satellite

(In reply to Eric Helms from comment #23)
> Howdy,
> 
> I wanted to better understand what specifically this is asking for as part
> of our consideration. If we look at [1] this section describes how to
> configure Satellite with custom certificates. If those certificates need to
> change (due to expiration, due to hostname change, due to CA change, any
> reason), the process is the same.

hostname change is special and in that case the process is actually not the same, as you have to use satellite-change-hostname for that.

> 1. Can this be solved by adding a sentence at the start that says:
> 
> 
>      Use this procedure to configure your Satellite Server any time you add
> or change custom SSL certificates.

I guess that's a fair addition, especially given that step 2 of the procedure in [1] already says:
… enter the satellite-installer command that installs a new Satellite with custom SSL certificates or updates certificates on a currently running Satellite …

> 2. Do we need to explicitly list some of the reasons certificates might be
> changed and emphasize that no matter what, you still use the procedure [1]?

I'd avoid that.

> 3. I would agree that we can bulk up [2] with wording that states if you
> change certificates, you must update any hosts connected to the Satellite or
> Capsule that has a certificate change.

That's not true. You do not have to update any hosts unless the CA (any CA).
When you just update the certificate (aka: you used the same Private Key and Certificate Signing Request), the only thing that really changes is the signature (and the dates) in the certificate, and that can be perfectly verified using the old files.
I am not 100% sure, but I think even changing the private key should be "OK" and still verifiable by the old files (as I don't think we do any certificate pinning, just CA pinning)
(The one machine I have at hand here has 3 certs in /etc/rhsm/ca/katello-server-ca.pem and none of them has the satellite as Subject)

> 4. We should add a note that indicates changes to the custom certificates CA
> require not only host updates, but also Capsule certificate updates.

That's correct.

> egolov -- Would you add anything else?

I think the original request looks for two things:
1. *when* does the user have to update the hosts ("always" is tad broad, as shown above)
2. *how* can the user update the hosts in bulk

> [1]
> https://access.redhat.com/documentation/en-us/red_hat_satellite/6.12/html/
> installing_satellite_server_in_a_connected_network_environment/performing-
> additional-
> configuration#Deploying_a_Custom_SSL_Certificate_to_Server_satellite
> [2]
> https://access.redhat.com/documentation/en-us/red_hat_satellite/6.12/html/
> installing_satellite_server_in_a_connected_network_environment/performing-
> additional-configuration#deploying-a-custom-ssl-certificate-to-
> hosts_satellite

(In reply to Evgeni Golov from comment #24)
> (In reply to Eric Helms from comment #23)
> > Howdy,
> > 
> > I wanted to better understand what specifically this is asking for as part
> > of our consideration. If we look at [1] this section describes how to
> > configure Satellite with custom certificates. If those certificates need to
> > change (due to expiration, due to hostname change, due to CA change, any
> > reason), the process is the same.
> 
> hostname change is special and in that case the process is actually not the
> same, as you have to use satellite-change-hostname for that.

Oh yes, I was not specific in my wording enough. I was meaning this from a CN perspective of the custom certificates. If the user wanted to change the hostname within the custom certificates without changing the actual hostname on the box.

> 
> > 1. Can this be solved by adding a sentence at the start that says:
> > 
> > 
> >      Use this procedure to configure your Satellite Server any time you add
> > or change custom SSL certificates.
> 
> I guess that's a fair addition, especially given that step 2 of the
> procedure in [1] already says:
> … enter the satellite-installer command that installs a new Satellite with
> custom SSL certificates or updates certificates on a currently running
> Satellite …
> 
> > 2. Do we need to explicitly list some of the reasons certificates might be
> > changed and emphasize that no matter what, you still use the procedure [1]?
> 
> I'd avoid that.
> 
> > 3. I would agree that we can bulk up [2] with wording that states if you
> > change certificates, you must update any hosts connected to the Satellite or
> > Capsule that has a certificate change.
> 
> That's not true. You do not have to update any hosts unless the CA (any CA).
> When you just update the certificate (aka: you used the same Private Key and
> Certificate Signing Request), the only thing that really changes is the
> signature (and the dates) in the certificate, and that can be perfectly
> verified using the old files.
> I am not 100% sure, but I think even changing the private key should be "OK"
> and still verifiable by the old files (as I don't think we do any
> certificate pinning, just CA pinning)
> (The one machine I have at hand here has 3 certs in
> /etc/rhsm/ca/katello-server-ca.pem and none of them has the satellite as
> Subject)


I meant this to mean only CA changes and flubbed the wording. You are correct here it should only be if the CA changes.

> 
> > 4. We should add a note that indicates changes to the custom certificates CA
> > require not only host updates, but also Capsule certificate updates.
> 
> That's correct.
> 
> > egolov -- Would you add anything else?
> 
> I think the original request looks for two things:
> 1. *when* does the user have to update the hosts ("always" is tad broad, as
> shown above)
> 2. *how* can the user update the hosts in bulk

I think this has to be done manually in all cases? Given that as soon as the CA changes, the client's connection breaks. 

Perhaps they could:

 * Add new CA to the old CA as a bundle, run installer to update everything and then roll out new CA ahead of time?

> 
> > [1]
> > https://access.redhat.com/documentation/en-us/red_hat_satellite/6.12/html/
> > installing_satellite_server_in_a_connected_network_environment/performing-
> > additional-
> > configuration#Deploying_a_Custom_SSL_Certificate_to_Server_satellite
> > [2]
> > https://access.redhat.com/documentation/en-us/red_hat_satellite/6.12/html/
> > installing_satellite_server_in_a_connected_network_environment/performing-
> > additional-configuration#deploying-a-custom-ssl-certificate-to-
> > hosts_satellite

(In reply to Eric Helms from comment #25)

> > > egolov -- Would you add anything else?
> > 
> > I think the original request looks for two things:
> > 1. *when* does the user have to update the hosts ("always" is tad broad, as
> > shown above)
> > 2. *how* can the user update the hosts in bulk
> 
> I think this has to be done manually in all cases? Given that as soon as the
> CA changes, the client's connection breaks. 
> 
> Perhaps they could:
> 
>  * Add new CA to the old CA as a bundle, run installer to update everything
> and then roll out new CA ahead of time?

Yes, that's how I'd do it.

*** Bug 2190337 has been marked as a duplicate of this bug. ***

Link to the updated and published documents: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.13/html/administering_red_hat_satellite/renewing-the-custom-ssl-certificate_admin