To add to the above, the ports which need these changes are:  

9090 (connection to the proxy in the capsule)
8443 (subscription-manager)
5000 (connection to katello for docker registry)
443  (Connections to Katello, Foreman, Foreman API, and Pulp)

Thanks,
Hradayesh Shukla
Red Hat - Technical Support

The satellite-installer provides the ability to customize both the CA and generated certificates expiration periods through configuration values. Specifically:

  --certs-ca-expiration
  --certs-expiration

I would advise users to customize these to their needs but with caution. All Satellites, Capsules and Hosts would have to get updated certificates in place when a new CA is generated. In a large deployment, this can lead to a large churn across the footprint of Satellite, Capsules and Hosts. Please consider this in longer term infrastructure planning if changing these values.

The current CAB[1] requirement is:

  Subscriber Certificates issued after March 1, 2018 MUST have a Validity Period no greater than 825 days.

This is relevant when requesting a certificate from a public (commercial) Certificate Authority. However, it's unclear if browsers do anything with this when using a private CA as we do in Satellite. Given it's been over a year and we still default to 20 years, I think it's safe to assume we're not impacted.

In my experience CAs generally also ignore the days field in the CSR and force their own value. This is usually chosen somewhere in the order process where the CA customer pays for the certificate.

With that in mind, I'd suggest not adding any more documentation. Suggesting parameters that are later ignored may just introduce more confusion. If the default value is invalid, it should be changed it to a working default.

[1]: https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/

Hi Ewoud, 

Thanks very much for the clarification. 

With this information, I am going to close off this bug. 

Thanks,

Melanie

It seems that with MacOS Catalina, certs with greater than 825 day expiration are getting flagged as revoked in Chrome:
Your connection is not private
Attackers might be trying to steal your information from my.satellite.server (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_REVOKED
Subject: my.satellite.server

Issuer: my.satellite.server

Expires on: Jan 17, 2038

Current date: Dec 4, 2019


https://support.apple.com/en-us/HT210176
"TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

Connections to TLS servers violating these new requirements will fail and may cause network failures, apps to fail, and websites to not load in Safari in iOS 13 and macOS 10.15.

Published Date: November 03, 2019"


Maybe this bug should be reopened and the default certificate expiration should be addressed?

Hello jheinze,

The validity of a certificate is set by the certificate authority during signing the certificate. 
The information you provided is not related to Satellite specifically and is only applicable to deployments that use MacOS to navigate to Satellite web UI. Such low-level information is hard to maintain in our docs, therefore we expect such custom configuration to be sorted out by the CA that signs a certificate.

Thank you

It appears that since I wrote https://bugzilla.redhat.com/show_bug.cgi?id=1562967#c15 the difference is that MacOS started to apply the rules to custom CAs. Since the CA that signs these out of the box is managed by us, I think this may be good to address. Right now I'm reopening this against the installer so we can triage it.

The Satellite Team is attempting to provide an accurate backlog of bugzilla requests which we feel will be resolved in the next few releases. We do not believe this bugzilla will meet that criteria, and have plans to close it out in 1 month. This is not a reflection on the validity of the request, but a reflection of the many priorities for the product. If you have any concerns about this, feel free to contact Red Hat Technical Support or your account team. If we do not hear from you, we will close this bug out. Thank you.

Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Thank you.