Cannot acces cdn.redhat.com

hello
i have imported my manifest in foreman but i cannot refresh it.
when i go to “manage manifest” page i have a message that say “server broke connection” and the refresh button is grey and say that it cannot access cdn.redhat.com

foreman access internet is made throught a corporate proxy and i can sync all my others repository without problem

the network guys say that when i try to refresh the manifest, the proxy try to access himself
to explain, on the proxy called for example my_proxy , he see access to my_proxy when foreman try to access cdn.redhat.com like a loop.

in the content/redhat repositories i can see all the repos on left but when i try to open repos it say “No repositories available.”

in the production log i have a message :
2022-05-11T10:49:48 [I|app|] CDN: Requesting path https://cdn.redhat.com:443/content/dist/rhel/server/7/listing
2022-05-11T10:49:48 [E|app|e66cf6b9] Failed at scanning for repository: SSL_connect returned=1 errno=0 state=error: certificate verify failed (self signed certificate in certificate chain)

when i set CDN SSL version with SSLv23

and

2022-05-11T10:55:43 [I|app|] CDN: Requesting path https://cdn.redhat.com:443/content/dist/rhel/power-le/7/7Server/listing
2022-05-11T10:55:43 [E|app|c8a52c28] Failed at scanning for repository: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: tlsv1 alert protocol version

when i set CDN SSL version with TLSv1

:Expected outcome:

Foreman and Proxy versions:

Foreman and Proxy plugin versions:

Distribution and version:

Other relevant data:

Is your proxy trying to break open the SSL connection?
That’s not supported.

network guys say that all url used for foreman are ssl whitelisted

Hi,

does your proxy only allow the connection to cdn.redhat.com?
You will also need subscription.rhsm.redhat.com and akamaiedge.net (following the documentation: Installing Foreman nightly server with Katello nightly plugin on Enterprise Linux )
I had a case recently where the missing subscription.rhsm.redhat.com permission did allow me to sync repositories but not attach licenses to hosts or to refresh my manifest.
Since redhat-repositories use certificates for authentication to their repositories maybe something is blocking there as well.

However, from the error message I suspect that somewhere in your setup some certificates are switched so that you end up with wrong certificates.
Is your proxy trying to replace SSL connections at any point?

hello
yes the 3 url are allowed on proxy
for the certificates, i made a standart katello scenario install. how can i verify that something is wrong ?

network guys say me that ssl connections are whitelisted on the proxy for the foreman server

another thing. when i access the subscription page i have a red message that say “server broke connexion” and in production.log there is this line :
2022-05-11T14:23:36 [E|app|86471f5a] Katello::HttpErrors::BadRequest: Server broke connection
86471f5a | /opt/theforeman/tfm/root/usr/share/gems/gems/katello-4.4.0.2/app/controllers/katello/api/v2/api_controller.rb:271:in rescue in check_upstream_connection' 86471f5a | /opt/theforeman/tfm/root/usr/share/gems/gems/katello-4.4.0.2/app/controllers/katello/api/v2/api_controller.rb:268:in check_upstream_connection’

Did you create a SSL certificate for your server using the same CA that your Firewall/Proxy uses for it’s SSL decryption? I saw the message in your initial post mentioning a self signed cert but you are doing SSL decryption. Is the CA cert for your firewall/proxy SSL decryption added to the OS CA trust store?

In our environment we have our internal CA issue certificates for our firewalls, Katello, and smart proxy servers. Katello and the smart proxies were configured with specifying our internal CA cert and it was added to the systems CA trust store. We also added *.redhat.com to the SSL decryption bypass rule. This then allowed the use of the Red Hat supplied certs in the manifest to communicate properly with Red Hat and all other external communication to get SSL decrypted but still be trusted.

it seem that the problem came from a “bug” ibt he proxy that didn’t bypass the ssl decryption…
it works with another proxy without pbm