Bug 1883594

Summary: Capsule-certs-generate Fails to Create New Data if Capsule Directory Exists in SSL-BUILD
Product: Red Hat Satellite Reporter: myoder
Component: CertificatesAssignee: Eric Helms <ehelms>
Status: CLOSED DUPLICATE QA Contact: Omkar Khatavkar <okhatavk>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.7.0CC: ahumbe, chrobert, zhunting
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-05 16:36:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description myoder 2020-09-29 16:17:37 UTC
Description of problem:

If the /root/ssl-build/<CAPSULE-FQDN>/ directory already exists on the Satellite server, running the capsule-certs-generate command for said Capsule, will not update that directory.  Likewise, the tar file provided from that command, that is to be scp'd to the Capsule server, is not updated either.  

Thus, if we try to update a Capsule's certificate, we cannot do so.  Satellite keeps generating stale data from the time before.  The only way to get Satellite to generate new data, is to manually remove the /root/ssl-build/<CAPSULE-FQDN>/ directory from the Satellite server.  Then run the capsule-certs-generate command with the new certs.


Version-Release number of selected component (if applicable):
Red Hat Satellite 6.7.2

How reproducible:
always

Steps to Reproduce (one way):
1. Before using custom certs on Satellite or Capsule, install them with the default self signed certificates.
2. Then, get custom certificate for both Satellite and Capsule server
3. Update Satellite server with custom certificate
4. Then run the capsule-certs-generate command on the new custom certificates for the Capsule server.
5. scp the tar file to capsule, and run the given satellite-installer command on the Capsule server.

Actual results:
Capsule server install fails, due to 500 error, because the Capsule is giving the Satellite a self-signed cert, when Satellite expects to be given the new custom certificate.

Expected results:
Capsule should be giving Satellite the new custom certificate.  However, the Capsule is never given a new certificate from the tar file that Satellite generated.  Instead, it is given the same old default certificate that was generated earlier.


Another way to reproduce, if we already have a custom certificate on our Capsule server:
1. Generate a new custom certificate (signed by same CA), but edit the Subject Alt Names, to include additional DNS or IPs
2. Give custom cert to Satellite and run capsule-certs-generate command.
3. scp tar file to capsule, and run the satellite-installer command given.

Actual results:
Capsule install succeeds, but we don't see the additional DNS or IPs in the Subject Alt Names.  Meaning, we just gave the Capsule the original custom certificate, and not the recently modified one.


Expected results:
We should see the extra DNS and IP we added to our custom certificate in the Subject Alt Names


Additional info:

Again, the only way I could rectify either situation, was to remove the /root/ssl-build/<CAPSULE-FQDN> directory, and re-run the capsule-certs-generate command.  I did several comparisons of the /root/ssl-build directory, as well as the tar file generated by Satellite.  Only when I cleared that directory, did I get the behavior I was expecting.

Comment 2 Eric Helms 2020-11-05 16:36:29 UTC

*** This bug has been marked as a duplicate of bug 1857176 ***