RHEL 9 (SSL Server Certificate Status verification FAILED)

Latest response

good day everyone!

I already did a dnf cache clear
dnf clean all
did reboot
subs unregister and register
i disabled and enabled both BaseOS and StreamApp Repos
disabled proxy in dnf.conf, and rhsm.conf
insecure=1 is set aswell
performed sslverify=false via yum.conf

here is the error

[root@labserver entitlement]# yum update -v
Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, product-id, repoclosure, repodiff, repograph, repomanage, reposync, subscription-manager, uploadprofile
Updating Subscription Management repositories.
YUM version: 4.10.0
cachedir: /var/cache/dnf
User-Agent: constructed: 'libdnf (Red Hat Enterprise Linux 9.0; generic; Linux.x86_64)'
repo: downloading from remote: rhel-9-for-x86_64-baseos-rpms
error: Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml [No OCSP response received] (https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml).
error: Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml [No OCSP response received] (https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml).
error: Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml [No OCSP response received] (https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml).
error: Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml [No OCSP response received] (https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml).
Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository 'rhel-9-for-x86_64-baseos-rpms':
- Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml [No OCSP response received]
Error: Failed to download metadata for repo 'rhel-9-for-x86_64-baseos-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

verbose

Responses

Having the same issue, I've created a bug report

https://bugzilla.redhat.com/show_bug.cgi?id=2131029

Also seen here

https://access.redhat.com/discussions/6978227

thanks for taking the time to post bugs!

Same issue...

Same issue

Same here, fresh install, it worked till the first update, and now stopped.

Same here, fresh install, it worked till the first update, and now stopped.

Same here, fresh install, it worked till the first update, and now stopped.

I'm seeing this same issue as well, on two newly-installed RHEL 9.0 servers.

On one of them, "dnf check-update" executed normally once. Since then, both machines give the error:

"- Curl error (91): SSL server certificate status verification FAILED .... [No OCSP response received]"

One of my machines tries the "baseos" repository first while the other tries "appstream".

My RH subscription is "Red Hat Developer Subscription for Individuals". The two newly-installed machines' usage-type are "production", and below the usage-type field of their listings in https://access.redhat.com/management/systems/ the message:

"The intended usage type does not match the attached subscription(s). "

appears. Could this be a factor? The Developer Subscription for Individuals is billed as allowing up to 16 machines used as development/test, production, or disaster-recovery.

I don't think the usage type of 'Production' is valid for the Red Hat Developer Subscription since it's not meant to be used in production.

Make sure the service level and usage match the output under ‘Red Hat Developer Subscription for Individuals’ when you run…

# subscription-manager list --available --all

For me, the correct service level is ‘Self-Support’ and usage is ‘Development/Test’.

I had assumed that I could set a usage type of "production" based on the URL below. Is this no longer the case?

https://access.redhat.com/discussions/5719451

I'm having the same issue. I also have a developer subscription and I only have two systems registered including the one I'm getting the error on when checking for updates.

I’ve already tried removing the DNF cache using ‘dnf clean all’, removed ‘/var/cache/dnf’, and unregistered then re-registered my system and still get the same error.

┌──(quentin@lpt-dell-dymv2)-[~]
└─$ sudo dnf clean all && sudo dnf --refresh update
Updating Subscription Management repositories.
0 files removed
Updating Subscription Management repositories.
1Password Stable Channel                                                                                                                                                                                                      4.0 kB/s | 1.9 kB     00:00    
Extra Packages for Enterprise Linux 9 - x86_64                                                                                                                                                                                3.7 MB/s |  10 MB     00:02    
Microsoft Linux Software Repository                                                                                                                                                                                           360 kB/s | 206 kB     00:00    
Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs)                                                                                                                                                                         0.0  B/s |   0  B     00:00    
Errors during downloading metadata for repository 'rhel-9-for-x86_64-baseos-rpms':
  - Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml [No OCSP response received]
Error: Failed to download metadata for repo 'rhel-9-for-x86_64-baseos-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

same or similar issue, started today.

dnf check-update

Updating Subscription Management repositories. Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) 0.0 B/s | 0 B 00:01
Errors during downloading metadata for repository 'rhel-9-for-x86_64-baseos-rpms': - Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml [No OCSP response received] Error: Failed to download metadata for repo 'rhel-9-for-x86_64-baseos-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

I had the same error on a fresh install of RHEL 9. Here is what tried.

First Attempt : The first time, I created a hostname during install (network interface section) and also selected register during install itself. Right after install, none of yum commands worked with the same error listed above. Yum did not work even once. I tried everything from every forum/help article. Finally gave up.

Second Attempt : I re-installed RHEL9 fresh. This time, i skipped the registration during install, just set the hostname. After the system came up, waited for few minutes, then went through the registration process. Tada. The yum command worked, i was able to run 'yum update', install chrome etc. I could have waited but decided to fly close to sun. I tried to install KDE Workspaces, for which I have to install epel repo. As soon as i did that, the yum broke again with the same error above. Tried all sort of subscription registration/clear cache etc. Nothing worked.

I then removed the physical system from redhat account, unregistered and re-registered. This time yum update worked nicely. The instructions I followed are here - https://access.redhat.com/articles/433903

Will continue to monitor. Fingers Crossed. Not going to install anything to see if the system/subscription stays stable.

Nevertheless this whole subscription system is finicky at at is best. Very fragile. Also seems to have a self signed certificate somewhere in the chain that is causing the issue as well. Too many variables to figure out what the heck is going on.

Try this solutions if match this criteria: Red Hat Enterprise Linux for x86_64 - 9.0 - x86_64 You can configure the certificate of Red Hat Enterprise Linux for x86_64 - 9.0 - x86_64 by using a script or manually with the instructions below.

Option 1: Scripted Configuration Download Red_Hat_Product_Certificates.sh chmod +x Red_Hat_Product_Certificates.sh ./Red_Hat_Product_Certificates.sh

Option 2: Manual Configuration Create directory /etc/pki/product/.

Change the permission and ownership of this file.

Change the permission and ownership of this file.

restorecon -Rv /etc/pki/product chown root.root /etc/pki/product/479.pem chmod 644 /etc/pki/product/479.pem rct cat-cert /etc/pki/product/479.pem

Register your system.

Register your system.

subscription-manager register --auto-attach subscription-manager refresh subscription-manager identity

Just tried checking for updates again, and everything seems to be working as normal for me. Not sure what changed, and I didn't do anything differently.

It's working for me as well today

It's failing again

Facing the same issue on Freshly installed RHEL9 machine. Tried Registration twice & cleanup, still facing the same issue.

Do we have the resolution ?

Try this solutions if match this criteria: Red Hat Enterprise Linux for x86_64 - 9.0 - x86_64 You can configure the certificate of Red Hat Enterprise Linux for x86_64 - 9.0 - x86_64 by using a script or manually with the instructions below.

Option 1: Scripted Configuration Download Red_Hat_Product_Certificates.sh chmod +x Red_Hat_Product_Certificates.sh ./Red_Hat_Product_Certificates.sh

Option 2: Manual Configuration Create directory /etc/pki/product/.

Change the permission and ownership of this file.

Change the permission and ownership of this file.

restorecon -Rv /etc/pki/product chown root.root /etc/pki/product/479.pem chmod 644 /etc/pki/product/479.pem rct cat-cert /etc/pki/product/479.pem

Register your system.

Register your system.

subscription-manager register --auto-attach subscription-manager refresh subscription-manager identity

I had the same issue when I wanted to install Development Tools and others packages (yum groupinstall "Development Tools"). I resolved that by changing time (My fresh VM was 3 days earlier than actual time because of the saved state).

Same issue This workaround - https://access.redhat.com/solutions/6978398 works for me

Try this solutions if match this criteria: Red Hat Enterprise Linux for x86_64 - 9.0 - x86_64 You can configure the certificate of Red Hat Enterprise Linux for x86_64 - 9.0 - x86_64 by using a script or manually with the instructions below.

Option 1: Scripted Configuration Download Red_Hat_Product_Certificates.sh chmod +x Red_Hat_Product_Certificates.sh ./Red_Hat_Product_Certificates.sh

Option 2: Manual Configuration Create directory /etc/pki/product/.

Change the permission and ownership of this file.

Change the permission and ownership of this file.

restorecon -Rv /etc/pki/product chown root.root /etc/pki/product/479.pem chmod 644 /etc/pki/product/479.pem rct cat-cert /etc/pki/product/479.pem

Register your system.

Register your system.

subscription-manager register --auto-attach subscription-manager refresh subscription-manager identity

Try this solutions if match this criteria: Red Hat Enterprise Linux for x86_64 - 9.0 - x86_64 You can configure the certificate of Red Hat Enterprise Linux for x86_64 - 9.0 - x86_64 by using a script or manually with the instructions below.

Option 1: Scripted Configuration Download Red_Hat_Product_Certificates.sh chmod +x Red_Hat_Product_Certificates.sh ./Red_Hat_Product_Certificates.sh

Option 2: Manual Configuration Create directory /etc/pki/product/.

Change the permission and ownership of this file.

Change the permission and ownership of this file.

restorecon -Rv /etc/pki/product chown root.root /etc/pki/product/479.pem chmod 644 /etc/pki/product/479.pem rct cat-cert /etc/pki/product/479.pem

Register your system.

Register your system.

subscription-manager register --auto-attach subscription-manager refresh subscription-manager identity

I've resolved the issue setting the automatic date & time option. It turned out that I had the wrong time on my computer.

Good call, thanks.

Clean install of 9.1 on a laptop today, and got this issue. Only thing I did to fix it was enable NTP.

/Oivind

Hi good afternoon,
Better you can config NTP severs in your machine. NTP servers update from Redhat.com!
$ cat /etc/chrony.conf
$ man chrony.conf
$ man chronyc
you may face a issue about UTC/GMT timezone
fixed time for machine

Config System timezone
timezone America/New_York

My timezone ASIA/Dhaka
You can solve this problem your self.

Thank you very much

Anyone facing this, please try the resolutions some have mentioned here. Otherwise, please submit a case with Red Hat because with the volume of people dealing with this, the best way to get Red Hat's attention is with cases from everyone, not a "me too" post here. When Red Hat sees cases for issues, and the same issue becomes apparent, then they work according to that..

Regards,
RJ

I had the same issue and corrected the time to make it work (used timedatectl as I was not able to download other dependent software to configure NTP)

Thank you this works for me!

This worked for me! Thanks

This did the trick, thank you!

I had the same issue and it's fixed after yum upgrade

Anyone facing this, please try the resolutions some have mentioned here. Otherwise, please submit a case with Red Hat because they need to see multiple customers having issues in cases - Red Hat works with cases and if these cases stack up, they will work it with more priority

Regards,
RJ

It's the time... Correcting the time resolved the issue for me.

Temporary Workaround:

https://access.redhat.com/solutions/6978398

I had the same problem , systemctl restart chronyd and than worked with no problem

systemctl restart chronyd this works

Just check the time is configured systemctl start chronyd and issue chronyc sources to make sure the pools are synced to your system then you can update

I had the same problem. Register to subscription again forcefully using subscription-manager register --force. It solved my issue.

Multiple solutions have already been provided and I agree that it's mostly a time sync issue. The below command is also worth trying,

sudo chronyc -a makestep

Please have a look to below logs,

[root@controller ~]# dnf update
Updating Subscription Management repositories.
Repository ansible-automation-platform-temp is listed more than once in the configuration
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)                                                                                                                      0.0  B/s |   0  B     00:00
Errors during downloading metadata for repository 'rhel-8-for-x86_64-appstream-rpms':
  - Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel8/8.8/x86_64/appstream/os/repodata/repomd.xml [OCSP response has expired]
Error: Failed to download metadata for repo 'rhel-8-for-x86_64-appstream-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
[root@controller ~]#
[root@controller ~]# date
Mon Jun 26 10:04:48 EDT 2023
[root@controller ~]# chronyc -a makestep
200 OK
[root@controller ~]# date
Sun Jul 16 21:02:14 EDT 2023
[root@controller ~]# dnf update
Updating Subscription Management repositories.
Repository ansible-automation-platform-temp is listed more than once in the configuration
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)                                                                                                                       13 MB/s |  58 MB     00:04
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)                                                                                                                          13 MB/s |  62 MB     00:04
Last metadata expiration check: 0:00:32 ago on Sun 16 Jul 2023 09:03:21 PM EDT.
Dependencies resolved.
==============================================================================================================================================================================================================
 Package                                                  Architecture         Version                                                                   Repository                                      Size
==============================================================================================================================================================================================================
Installing:
 kernel                                                   x86_64               4.18.0-477.15.1.el8_8                                                     rhel-8-for-x86_64-baseos-rpms                  9.4 M
 kernel-core                                              x86_64               4.18.0-477.15.1.el8_8                                                     rhel-8-for-x86_64-baseos-rpms                   42 M
 kernel-devel                                             x86_64               4.18.0-477.15.1.el8_8                                                     rhel-8-for-x86_64-baseos-rpms                   23 M

when running dnf upgrade with FIPS enabled I get SSL issues with RHEL repos - exaple below. RHEL repos doesn't provide SSLv3 certificate?

"rhel-9-for-x86_64-baseos-rpms error: Curl error (35): SSL connect error for https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml [error:0A000410:SSL routines::sslv3 alert handshake failure] (https://cdn.redhat.com/content/dist/rhel9/9/x86_64/baseos/os/repodata/repomd.xml)."

openssl s_client -showcerts -connect cdn.redhat.com:443

CONNECTED(00000003)

406C2897657F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1600:SSL alert number 40 no peer certificate available No client certificate CA names sent

SSL handshake has read 7 bytes and written 135 bytes

Verification: OK

New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1700360025 Timeout : 7200 (sec) Verify return code: 0 (ok)

Extended master secret: no

Recommend a ticket with Red Hat.. Some regions occasionally have CDN issues that are region specific. Please include an SOS report with the ticket

Regards,
RJ

I only have developer account - probably can't add a case. I think that's not "occasional", as of certificate is not compliant with FIPS. With disabled system-wide FIPS mode, RHEL can in fact update ;-)

Ok. Problem was setting FIPS:OSCP .. On regular FIPS mode RHEL updates fine.

Here is the error message: Updating Subscription Management repositories. Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) 0.0 B/s | 0 B 00:00 Errors during downloading metadata for repository 'rhel-8-for-x86_64-baseos-rpms': - Curl error (91): SSL server certificate status verification FAILED for https://cdn.redhat.com/content/dist/rhel8/8/x86_64/baseos/os/repodata/repomd.xml [OCSP response has expired] Error: Failed to download metadata for repo 'rhel-8-for-x86_64-baseos-rpms': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried

Did you check if this is not the time/clock/chrony issue?