
OPERATIONAL DEFECT DATABASE
...

...
What were you trying to do that didn't work? Spinning a 3rd-party RHEL 10.0 image from an Azure or AWS cloud account results in the system getting automatically registered, but not having access to content from the CDN on time. The SCA certificate is fetched by the client too late. What is the impact of this issue to you? If this goes live, that means customers will not have access to content from the CDN for up to 4 hours (in the worst case), and would have to manually remove the redhat-cloud-client-configuration-cdn package, and re-enable RHUI as a workaround to be able to access content. This is obviously an issue for users that may want to run automation (e.g. kickstarts) that needs access to content almost immediately after booting. Please provide the package NVR for which the bug is seen: subscription-manager: 1.30.6-1.el10_0 redhat-cloud-client-configuration-cdn-1-13.el10.noarch How reproducible is this bug?: At the time of writing, 100% on RHEL 10.0 (tested on 2 RHEL 10 VMs, one in Azure, one in AWS), however, we are unsure if RHEL9.6 is unaffected. More investigation is required. Steps to reproduce Spin up a RHEL10 3rd party image VM from Azure or AWS. After a few seconds (maximum 2 minutes), look at the /var/log/rhsm/rhsm.log and /etc/yum.repos.d/redhat.repo Expected results There is no/minimal delay (a few seconds) between when the VM got autoregistered, and when the SCA cert got updated (fetched for the first time). E.g.: 2025-05-08 09:04:24,249 [INFO] rhsmcertd-worker:10478:MainThread @rhsmcertd_worker.py:230 - Standard automatic registration was successful. 2025-05-08 09:04:30,646 [INFO] subscription-manager:11024:MainThread @entcertlib.py:108 - certs updated: Total updates: 1 Found (local) serial# [] Expected (UEP) serial# [1233442352352352] Added (new) [sn:1233442352352352 ( Content Access,) @ /etc/pki/entitlement/1233442352352352.pem] Deleted (rogue): <NONE> The /etc/yum.repos.d/redhat.repo file is populated with repos after the 'certs updated'. Actual results The VM got autoregistered, but the SCA cert did not get fetched. E.g.: 2025-05-08T09:06:07.313+00:00 [INFO] rhsmcertd-worker:11406:MainThread @rhsmcertd_worker.py:230 - Standard automatic registration was successful. The /etc/yum.repos.d/redhat.repo file is not populated. In this case the 'certs updated' action may happen in up to 4 hours after the registration.
Unresolved
Red Hat Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.