Problem: leapp upgrade stuck at “The installed OS version is not supported for the in-place upgrade to the target RHEL version”
Expected outcome: leapp upgrade allowed to proceed
Foreman and Proxy versions: Foreman 3.11.1; Katello 4.13.1
Foreman and Proxy plugin versions:
Distribution and version: Rocky Linux 8.10
Other relevant data:
I’m trying to follow the directions in the “Upgrading Foreman to 3.11.1” page to use leapp to upgrade Rocky 8.10 to Rocky 9. I’m able to install everything and run “leapp preupgrade”, but the leapp-report.txt file starts with:
Risk Factor: high (inhibitor)
Title: The installed OS version is not supported for the in-place upgrade to the target RHEL version
Summary: The supported OS releases for the upgrade process:
RHEL 8.8
RHEL 8.10
RHEL-SAPHANA 8.8
RHEL-SAPHANA 8.10
CENTOS 8.999
Key: 1c7a98849a747ec9890f04bf4321de7280970715
Is there any way around this? The doc mentions using “leapp answer” but I don’t see anything that would allow me to use “leapp answer --section” since I don’t see anything that tells me what section to give or what answer to provide.
WerVa
August 20, 2024, 5:01am
2
Hi you can try edit line
/usr/share/leapp-repository/repositories/system_upgrade/common/libraries/config/version.py
'8': {'rhel': ['8.8', '8.10'], 'rhel-saphana': ['8.8', '8.10'], 'centos': ['8.999']},
to
'8': {'rhel': ['8.8', '8.10'], 'rhel-saphana': ['8.8', '8.10'], 'centos': ['8.999'], 'rocky':['8.8','8.10']},
or try alma leapp tool
Dirk
August 20, 2024, 6:50am
3
Did you follow this guide ? Asking because I think you missed step 3 and did not install leapp-data-rocky
.
evgeni
August 20, 2024, 8:10am
4
I forgot to add a patch to leapp-repository, so it doesn’t properly detect Alma and Rocky as supported source platforms.
Working on fixing it.
3 Likes
WerVa
August 20, 2024, 8:40am
5
@evgeni Can you let us know when the problem will be solved?
evgeni
August 20, 2024, 11:29am
6
I’ve released fresh leapp-upgrade-el8toel9
and leapp-data-*
that should work on Alma and Rocky now.
Sorry for the oversight!
1 Like
I’m able to get past the ‘leapp preupgrade’ now, but the ‘leapp upgrade’ fails because of package conflicts with some python files. Here’s a sample:
file /usr/lib/python3.9/site-packages/__pycache__/six.cpython-39.opt-1.pyc from install of python3-six-1.15.0-9.el9.noarch conflicts with file from package python39-six-1.16.0-2.el8.noarch
file /usr/lib/python3.9/site-packages/__pycache__/six.cpython-39.pyc from install of python3-six-1.15.0-9.el9.noarch conflicts with file from package python39-six-1.16.0-2.el8.noarch
file /usr/lib/python3.9/site-packages/six.py from install of python3-six-1.15.0-9.el9.noarch conflicts with file from package python39-six-1.16.0-2.el8.noarch
file /usr/lib/python3.9/site-packages/idna/__init__.py from install of python3-idna-2.10-7.el9_4.1.noarch conflicts with file from package python39-idna-3.3-2.el8.noarch
file /usr/lib/python3.9/site-packages/idna/__pycache__/__init__.cpython-39.opt-1.pyc from install of python3-idna-2.10-7.el9_4.1.noarch conflicts with file from package python39-idna-3.3-2.el8.noarch
file /usr/lib/python3.9/site-packages/idna/__pycache__/__init__.cpython-39.pyc from install of python3-idna-2.10-7.el9_4.1.noarch conflicts with file from package python39-idna-3.3-2.el8.noarch
evgeni
August 22, 2024, 4:53am
8
Python 3.9 was used by Pulp in the past, but isn’t anymore. It should be safe to uninstall it via dnf autoremove
or dnf remove python39
.
WerVa
August 22, 2024, 10:45am
9
if you have a problem with EFI during migration then before restart give grub2-mkconfig -o /boot/grub2/grub.cfg
oamg:master
← rmetrich:RHEL-36186
opened 03:18PM - 13 May 24 UTC
When upgrading a UEFI system with /boot on Software Raid, the `/boot/efi/EFI/red… hat/grub.cfg` wrapper is created with unexpected content, causing the system to land into `grub>` prompt upon upgrade completion.
jira: https://issues.redhat.com/browse/RHEL-36186 RHEL-36249
opened 02:38PM - 03 Jul 24 UTC
bug
**Actual behavior**
System doesn't boot because of missed `/boot/grub2/grub.cfg… ` GRUB configuration file, after upgrading of recent _Red Hat Enterprise Linux release_ **8.10** to **9.4**, and if Extensible Firmware Interface (**_EFI_**) is used.
**To Reproduce**
1. Get system with most recent RHEL8 and EFI. Register it with RHSM, upgrade, disable zone drifting in the firewall.
2. Setup Leapp
3. Pre-upgrade check with Leapp, review results
4. Upgrade with `leapp upgrade --debug`
5. Reboot the system
6. Get into the system's main console, wait for Leapp to do the upgrade
7. After the upgrade, Leapp will reboot the system, and grub will enter its CLI because of missed configuration file (see screenshot attached)
**Expected behaviour**
> Assuming a kind of "emergency shell", and chroot into the broken system
- OS version
```
[root@localhost-live /]# cat /etc/redhat-release
Red Hat Enterprise Linux release 9.4 (Plow)
```
- GRUB packages
```
[root@localhost-live /]# rpm -qa | grep grub2
grub2-common-2.06-80.el9_4.noarch
grub2-tools-minimal-2.06-80.el9_4.x86_64
grub2-tools-2.06-80.el9_4.x86_64
grub2-efi-x64-2.06-80.el9_4.x86_64
grub2-tools-efi-2.06-80.el9_4.x86_64
grub2-tools-extra-2.06-80.el9_4.x86_64
```
- GRUB's config file in case if EFI:
```
[root@localhost-live /]# ls -la /etc/grub2-efi.cfg
lrwxrwxrwx. 1 root root 22 May 30 19:20 /etc/grub2-efi.cfg -> ../boot/grub2/grub.cfg
```
points into the broken symlink:
```
[root@localhost-live etc]# ls -la ../boot/grub2/grub.cfg
ls: cannot access '../boot/grub2/grub.cfg': No such file or directory
[root@localhost-live /]# ls -la /boot/grub2/grub.cfg
ls: cannot access '/boot/grub2/grub.cfg': No such file or directory
```
Upgrade worked till _Red Hat Enterprise Linux release 9.4 (Plow)_ and **GRUB** version **2.06-80.el9_4**.
Leapp should correctly handle such configuration.
**System information (please complete the following information):**
- OS and version:
```
# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.10 (Ootpa)
```
- system information
```
# uname -a
Linux rhel8.tst 4.18.0-553.8.1.el8_10.x86_64 #1 SMP Fri Jun 14 03:19:37 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux
```
- EFI configuration
```
# efibootmgr
BootCurrent: 0004
BootOrder: 0004,0000,0001,0002,0003
Boot0000* EFI Virtual disk (0.0)
Boot0001* EFI VMware Virtual SATA CDROM Drive (0.0)
Boot0002* EFI Network
Boot0003* EFI Internal Shell (Unsupported option)
Boot0004* Red Hat Enterprise Linux
```
- installed leapp packages
```
# rpm -qa "*leapp*"
python3-leapp-0.17.0-1.el8.noarch
leapp-upgrade-el8toel9-0.20.0-2.el8.noarch
leapp-deps-0.17.0-1.el8.noarch
leapp-0.17.0-1.el8.noarch
leapp-upgrade-el8toel9-deps-0.20.0-2.el8.noarch
```
- RHSM information
```
# subscription-manager list
+-------------------------------------------+
Installed Product Status
+-------------------------------------------+
Product Name: Red Hat Enterprise Linux for x86_64
Product ID: 479
Version: 8.10
Arch: x86_64
Status: Subscribed
Status Details:
Starts: xx/xx/xxxx
Ends: xx/xx/xxxx
```
- GRUB configuration files on the system:
```
# ls -la /etc/grub2-efi.cfg
lrwxrwxrwx. 1 root root 31 Feb 21 15:12 /etc/grub2-efi.cfg -> ../boot/efi/EFI/redhat/grub.cfg
# ls -la /boot/efi/EFI/redhat/grub.cfg
-rwx------. 1 root root 6645 May 29 11:01 /boot/efi/EFI/redhat/grub.cfg
```
**Attachments**
<img width="818" alt="Screenshot 2024-07-03 at 16 51 32" src="https://github.com/oamg/leapp-repository/assets/1556475/f406e154-e046-40d7-8547-50f12ecf6bea">
[leapp-logs.tar.gz](https://github.com/user-attachments/files/16086412/leapp-logs.tar.gz)
Finally had a chance to try it out – dnf autoremove
found a lot of stuff to uninstall, including the python39 packages. I’ll give the 8→9 upgrade another go when I have a chance and report how it goes.
I finally made the time to do this today. I was able to complete the upgrade, but afterwards, none of my systems are reporting (the “Last Report” column on the All Hosts page shows “3 Hours ago” right now for all hosts, which is when I started the upgrade. Is there something I need to do to get that working again?
I checked a few hosts and was able to run “puppet agent -t” without issue.
evgeni
September 10, 2024, 6:02am
12
So your Foreman is updated (and working), your clients can do puppet agent -t
, but the “last report” timestamp doesn’t update? That’s weird.
Could you provide us with some logs (especially /var/log/foreman/production.log
, but a full sos report would be awesome) around the time you perform a puppet agent -t
?
Feel free to DM it me here or mail to evgeni at redhat dot com if you do not want so share these publicly.
Logs sent via email. Let me know if you have any trouble accessing them from the Google Drive link I sent.
evgeni
September 11, 2024, 6:38am
14
Thanks. Logs received!
production.log
confirms your observation (via grep "Import.*for " production.log
):
2024-09-09T12:15:11 [I|app|21133d3e] Import facts for 'testrocky9.example.com' completed. Added: 0, Updated: 4, Deleted 0 facts
2024-09-09T12:15:15 [I|app|5766a1ca] Imported report for testrocky9.example.com in 40.5 ms, status refreshed in 49.7 ms
2024-09-09T12:16:18 [I|app|88e98c91] Import facts for 'udocker1.example.com' completed. Added: 0, Updated: 8, Deleted 0 facts
2024-09-09T12:16:23 [I|app|b6bd1b26] Imported report for udocker1.example.com in 37.8 ms, status refreshed in 63.4 ms
…
2024-09-09T12:55:41 [I|app|8d5dd404] Import facts for 'ipam2.example.com' completed. Added: 0, Updated: 5, Deleted 0 facts
2024-09-09T12:55:52 [I|app|2dcbff95] Import facts for 'devubuntu22.example.com' completed. Added: 0, Updated: 7, Deleted 0 facts
2024-09-09T12:56:17 [I|app|2f110b5e] Import facts for 'gitlab1.example.com' completed. Added: 0, Updated: 10, Deleted 0 facts
Until 2024-09-09T12:16 we had fact and report imports in tandem (which makes sense, both are sent by the Puppetserver to Foreman – albeit by different code and at different places of the whole thing), starting with 12:55 we still see facts, but no more reports.
I guess in between 12:16 and 12:55 was the actual downtime where the upgrade happened.
Now, if we look at var/log/puppetlabs/puppetserver/puppetserver*.log*
we see:
2024-09-09T12:55:53.671-07:00 ERROR [qtp1362430252-56] [puppetserver] Puppet Report processor failed: Could not send report to Foreman at https://foreman.example
.com/api/config_reports: Certificates do not conform to algorithm constraints
(and many more after this)
I must admit my Puppet reporting knowledge is a bit rusty, but I think that’s a good lead to look further.
ekohl
September 11, 2024, 8:55am
15
It would be good to see the certificate. You can use openssl x509 -in /path/to/cert -noout -text
to get a human readable description of it. You can find the paths in /etc/puppetlabs/puppet/foreman.yaml
.
My suspicion is that it started to reject sha1 certificates.
Here it is:
[root@foreman ~]# openssl x509 -in /etc/pki/katello/puppet/puppet_client.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
62:b8:15:bd:6f:b5:26:dc:d0:bc:c7:d2:1a:17:01:3b:46:ae:c1:ef
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, ST = North Carolina, L = Raleigh, O = Katello, OU = SomeOrgUnit, CN = foreman.fsautomation.com
Validity
Not Before: Apr 13 18:27:25 2023 GMT
Not After : Jan 17 18:27:25 2038 GMT
Subject: C = US, ST = North Carolina, O = FOREMAN, OU = PUPPET, CN = foreman.fsautomation.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:ba:f3:8b:ea:a9:6d:c1:64:f7:03:a5:1d:43:0d:
b6:65:99:c8:86:d2:0b:65:1d:cb:99:8a:4a:9a:fa:
64:75:92:3c:3b:85:74:5b:5a:4c:a1:3e:33:7a:ab:
dd:61:dd:36:8b:f4:37:de:73:2b:a5:cf:d9:b3:7f:
2e:3d:e9:47:f7:52:b2:62:c8:8f:c7:f3:62:ae:e4:
c2:d1:00:a9:2a:b1:39:7f:ee:f7:a4:48:08:d2:b3:
c6:8b:c4:bd:fe:a7:6c:61:f5:3b:d3:ac:93:65:bc:
4e:7b:58:48:67:56:a0:65:77:cd:ab:61:98:b2:10:
4f:59:48:aa:a4:69:f3:30:12:eb:fe:b4:c4:f8:fd:
c6:63:db:13:0c:7c:8a:cd:b8:25:67:7f:ba:99:9f:
78:f9:49:71:9b:f2:c0:95:57:cb:5e:d5:05:1e:3c:
ea:ad:61:f2:05:59:0b:91:b8:f6:91:9f:85:44:11:
53:91:86:9b:5a:e2:14:3b:84:ec:12:fd:48:31:f8:
6a:a9:b0:8a:93:8c:15:14:12:af:80:d4:f7:29:28:
a6:14:f5:4f:c6:a5:b7:61:39:a6:79:3b:d9:96:d5:
93:91:9e:0d:63:08:34:bc:3c:1e:1d:fa:64:bf:11:
d4:4b:33:c4:18:c7:eb:6a:b9:86:de:f4:b9:f7:4d:
03:4d:c6:12:87:e3:24:6b:fe:e5:dd:41:1b:ff:86:
29:45:7f:df:d8:f5:29:f1:29:cf:b5:6c:6f:fe:a3:
0a:43:3d:4d:10:42:ef:66:87:e4:d0:10:15:68:46:
3a:fa:b9:98:e2:68:fd:81:f0:23:9e:d9:f9:24:5d:
43:b6:b6:61:91:a6:55:c6:21:78:9b:ce:a5:3c:bd:
5e:80:31:2d:4a:1d:ba:e4:4e:bb:4f:e1:6f:07:1d:
dc:4d:c2:58:1e:5a:04:f3:40:61:99:1b:4c:2d:b2:
9b:8d:53:dd:18:f7:23:bc:d5:ea:70:e3:f1:d4:c2:
e9:c0:d9:26:47:59:b7:b4:4b:c7:ee:f8:cc:fb:be:
02:06:84:3c:67:3a:ea:1f:b5:7e:77:e4:72:3c:6a:
cc:d1:7b:00:c9:b3:39:5f:de:3a:7e:18:92:9c:df:
d9:3c:19:f7:a3:00:eb:21:35:23:28:03:51:13:8c:
08:f0:a1:14:ba:d4:58:bb:96:aa:2b:ff:f9:e0:00:
0f:92:a0:9b:4e:25:6e:ce:fc:3b:1c:b2:35:e5:82:
64:88:61:90:72:5e:a7:fc:48:95:d7:d9:07:f3:47:
ec:0c:fd:59:a9:2c:44:dc:95:d6:7c:47:a6:02:23:
13:27:0c:ee:c0:2e:a9:00:cf:cc:4c:a0:c2:b5:3e:
43:12:25
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Netscape Cert Type:
SSL Client
Netscape Comment:
Katello SSL Tool Generated Certificate
X509v3 Subject Key Identifier:
EC:67:72:D0:48:EE:2E:A7:7C:5D:02:FD:BB:3E:A7:31:72:03:A7:C6
X509v3 Authority Key Identifier:
keyid:09:D2:30:01:E5:75:04:E4:D5:76:A7:EE:EA:65:8D:FA:4F:F5:CE:F0
DirName:/C=US/ST=North Carolina/L=Raleigh/O=Katello/OU=SomeOrgUnit/CN=foreman.fsautomation.com
serial:62:B8:15:BD:6F:B5:26:DC:D0:BC:C7:D2:1A:17:01:3B:46:AE:C1:CA
X509v3 Subject Alternative Name:
DNS:foreman.fsautomation.com
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
20:9d:98:16:e8:a1:e0:b4:a6:57:39:b9:a6:ea:3c:78:b1:a4:
b2:83:86:25:97:ea:d7:b2:29:e9:98:dd:4d:1e:ad:eb:17:48:
2e:9a:09:72:0a:43:cd:7a:36:2e:26:7b:16:8f:fe:0b:0b:30:
cf:78:c8:c7:8f:b9:ef:d7:17:89:dd:b3:7d:52:e3:e5:54:58:
2d:83:38:63:f9:18:91:4e:fe:59:02:4d:3b:f0:1b:99:0e:ce:
50:fd:0a:28:04:4c:c2:6b:ba:49:57:94:e6:3e:1f:b0:e3:af:
b1:6c:d2:d4:8c:fe:f4:5b:77:e7:50:df:59:af:d8:a1:08:39:
65:63:f5:f4:0a:0f:04:12:8e:32:56:5e:57:6b:2b:49:c5:23:
dd:e2:1f:af:7c:09:f4:7e:09:c5:bd:50:31:05:20:0c:12:9e:
2f:2e:ee:50:c4:6d:66:83:d8:ef:19:cd:ed:3f:68:9b:11:19:
19:75:61:07:54:7d:4b:10:8b:3e:16:f7:8f:cd:7e:55:69:eb:
98:57:6c:66:c5:33:78:19:e2:67:8e:7b:46:7e:d1:12:73:26:
4a:2c:99:78:f1:f5:81:17:e0:d9:f8:e5:c6:ca:3c:f8:79:df:
cf:c7:27:02:90:01:c2:64:b6:11:8c:b1:fe:35:3f:63:06:3d:
45:ac:63:79:df:0a:25:4d:8f:7f:96:87:46:dd:58:6f:c8:ae:
4f:36:72:ef:37:6a:ee:e1:a3:51:fe:ce:b3:f1:71:af:14:13:
66:c3:e9:e1:cf:bf:93:83:ba:34:1f:c4:30:9c:ee:e0:46:6a:
9c:c8:29:12:f5:d1:9d:6f:9d:76:85:45:93:41:7e:af:13:ef:
b1:69:13:8b:87:dd:5f:c2:bd:bf:75:9a:c2:94:c3:6c:82:b5:
9d:5f:eb:18:a0:5d:a3:d0:17:bc:47:0e:8f:aa:a5:1f:08:bc:
c9:49:9d:88:21:c5:93:ed:b9:5c:56:97:7e:1a:97:79:3d:4a:
36:5a:3e:dd:cf:dc:ec:6f:29:85:8a:72:19:f5:ee:cf:ec:9f:
71:79:62:7b:b5:a0:d4:8e:87:c0:b5:b7:4e:e1:d5:29:7f:b1:
06:6b:a4:92:1f:19:81:45:12:61:7e:a6:b8:de:67:a5:b1:38:
62:e8:8a:ac:87:05:9c:e8:2e:21:c4:c4:bd:59:82:f9:0e:f4:
32:e4:36:15:5a:06:0a:04:56:cd:12:4e:d0:ed:29:41:2e:b8:
e8:cf:f0:f4:f1:0c:0b:f3:13:47:97:17:82:ab:cc:fc:05:df:
28:24:2a:bc:49:77:3f:1c:57:86:25:29:ac:ce:7f:13:b9:cb:
69:c1:f8:c0:92:70:c8:1d
ekohl
September 11, 2024, 5:29pm
17
That invalidates my sha1 theory.
evgeni
September 11, 2024, 6:08pm
18
Can you do the same for /etc/pki/katello/certs/katello-apache.crt
aka /etc/pki/wildcard.example.com/certs/wildcard.example.com.crt
?
And technically also /etc/pki/katello/certs/katello-server-ca.crt
, which is the CA Cert who signed yours.
Here’s /etc/pki/katello/certs/katello-apache.crt
:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
02:6f:2d:59:a1:7c:b1:0e:7c:9d:89:5d:1e:ec:e9:0d
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
Validity
Not Before: Mar 1 00:00:00 2024 GMT
Not After : Apr 1 23:59:59 2025 GMT
Subject: CN = *.fsautomation.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:de:7a:ff:d1:cc:80:95:52:ea:e7:8a:b6:7f:ff:
1e:6e:b4:e8:35:0e:3a:0d:cf:30:b2:c2:50:83:4c:
0f:9e:8f:f3:d5:7b:32:96:8f:92:24:38:99:d8:13:
c0:08:5c:9f:f0:7d:37:93:2f:74:5c:cd:bb:95:c1:
0a:21:39:4d:ef:18:b4:1a:45:ba:09:3d:ac:5c:d4:
84:7b:27:ec:66:60:b2:7c:77:d4:83:ef:10:f4:4e:
c0:92:83:bd:cf:08:88:90:11:9c:18:3e:0c:44:a1:
dd:9f:e1:6d:f4:bc:5f:a2:55:7d:9e:36:44:c2:ad:
86:3f:a2:7d:a2:b5:63:bc:05:fd:00:0e:43:21:76:
b3:70:0f:78:8d:e2:57:19:22:54:ae:63:39:bf:3a:
11:c4:19:cb:77:8b:01:61:eb:56:2f:59:ed:92:3b:
81:6b:2e:09:f0:e9:e3:1b:00:2a:ed:e4:f3:e3:fd:
20:b8:23:a8:a2:4f:16:ec:b9:4b:d1:23:cc:4f:d9:
e3:e1:51:9c:77:39:f1:ff:9b:68:54:cb:d5:53:19:
81:4a:d3:c4:b8:87:3f:7c:09:01:2b:6a:8b:02:c4:
6d:9c:0b:be:7c:6a:eb:f1:5e:4f:f4:a7:53:d2:2d:
5d:57:d7:6f:63:26:06:3e:37:09:4b:1a:2a:6f:bb:
7a:bb
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
8D:8C:5E:C4:54:AD:8A:E1:77:E9:9B:F9:9B:05:E1:B8:01:8D:61:E1
X509v3 Subject Key Identifier:
35:A6:2C:E2:BA:39:19:0F:EA:3C:99:53:61:A7:C1:AA:37:74:E4:AF
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.7
CPS: https://sectigo.com/CPS
Policy: 2.23.140.1.2.1
Authority Information Access:
CA Issuers - URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt
OCSP - URI:http://ocsp.sectigo.com
X509v3 Subject Alternative Name:
DNS:*.fsautomation.com, DNS:fsautomation.com
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : CF:11:56:EE:D5:2E:7C:AF:F3:87:5B:D9:69:2E:9B:E9:
1A:71:67:4A:B0:17:EC:AC:01:D2:5B:77:CE:CC:3B:08
Timestamp : Mar 1 22:11:52.205 2024 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:86:49:52:5E:C6:75:DF:AF:D8:2E:40:
04:C4:91:E8:BD:E7:6A:6D:C2:AF:83:D8:D7:D5:8D:5F:
C2:7F:20:36:09:02:20:1E:86:47:EC:74:B9:F8:1F:96:
EE:CF:D6:51:0B:70:02:2F:3A:D0:C7:29:5B:AC:E2:32:
2E:F8:0C:F8:7D:DB:C6
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : A2:E3:0A:E4:45:EF:BD:AD:9B:7E:38:ED:47:67:77:53:
D7:82:5B:84:94:D7:2B:5E:1B:2C:C4:B9:50:A4:47:E7
Timestamp : Mar 1 22:11:52.238 2024 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:0E:37:43:DC:12:2A:6F:B4:58:DB:E7:96:
3A:62:81:7A:AB:EC:8F:BE:A3:68:14:CA:55:52:73:0E:
68:68:E6:36:02:20:5F:B4:F1:D7:70:54:C0:09:F1:08:
3C:F3:0B:50:33:68:13:CF:4D:3B:86:1A:1E:76:D6:82:
94:57:1F:D8:D8:60
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 4E:75:A3:27:5C:9A:10:C3:38:5B:6C:D4:DF:3F:52:EB:
1D:F0:E0:8E:1B:8D:69:C0:B1:FA:64:B1:62:9A:39:DF
Timestamp : Mar 1 22:11:52.246 2024 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:24:A5:AF:FB:02:36:0E:5E:C0:0B:57:EE:
74:B0:A8:8A:A3:0D:63:8A:86:43:FF:5A:0C:EB:C1:99:
54:ED:12:4C:02:21:00:B1:9C:76:CE:B7:36:A4:74:F6:
F6:3D:81:F2:91:98:22:EE:15:0D:38:CE:A0:DD:5B:4F:
53:4B:B1:53:8F:E2:D0
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
0f:d5:ff:94:44:50:8d:c8:77:f4:41:e3:1c:b4:d2:65:50:d1:
b2:c0:f3:68:4b:d2:e1:1c:37:16:fb:55:b9:42:02:37:3c:d2:
a4:17:3b:26:0e:11:4e:63:d7:73:d4:1e:59:01:4d:66:fb:29:
90:2b:75:07:36:c6:ef:20:94:b3:19:3b:b1:0e:7d:90:c7:72:
f0:52:88:97:70:29:f0:a7:50:89:9e:84:1e:db:41:80:f0:d7:
a0:d4:95:49:a2:f4:38:e5:e1:fe:a3:15:56:7d:e1:f1:1f:46:
3f:7b:82:e6:f4:ba:49:22:15:4e:98:87:c2:b6:34:51:8f:62:
ba:1c:48:ad:35:cc:c7:9f:d3:f5:a1:16:2f:ec:70:6c:2a:a1:
33:9d:12:56:8c:fe:2c:76:88:87:e2:d8:1d:51:35:98:b0:53:
01:82:a4:3d:c7:2c:9b:4e:fc:00:22:06:be:5f:99:5c:60:49:
1c:0e:ff:9e:a7:c9:b0:91:c3:92:49:43:1c:1a:68:70:98:a2:
44:c5:d5:de:a0:b7:ec:b1:1c:32:7e:7f:b8:48:8a:d1:bc:bb:
a1:32:d0:50:6e:72:4a:ae:d1:60:54:c1:b8:cf:f0:25:1e:b9:
db:54:28:bb:0e:a8:8a:c7:ef:9f:7c:58:a3:6e:3c:5a:44:8b:
0a:cf:a9:90
and here’s /etc/pki/katello/certs/katello-server-ca.crt
:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
7d:5b:51:26:b4:76:ba:11:db:74:16:0b:bc:53:0d:a7
Signature Algorithm: sha384WithRSAEncryption
Issuer: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
Validity
Not Before: Nov 2 00:00:00 2018 GMT
Not After : Dec 31 23:59:59 2030 GMT
Subject: C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:d6:73:33:d6:d7:3c:20:d0:00:d2:17:45:b8:d6:
3e:07:a2:3f:c7:41:ee:32:30:c9:b0:6c:fd:f4:9f:
cb:12:98:0f:2d:3f:8d:4d:01:0c:82:0f:17:7f:62:
2e:e9:b8:48:79:fb:16:83:4e:ad:d7:32:25:93:b7:
07:bf:b9:50:3f:a9:4c:c3:40:2a:e9:39:ff:d9:81:
ca:1f:16:32:41:da:80:26:b9:23:7a:87:20:1e:e3:
ff:20:9a:3c:95:44:6f:87:75:06:90:40:b4:32:93:
16:09:10:08:23:3e:d2:dd:87:0f:6f:5d:51:14:6a:
0a:69:c5:4f:01:72:69:cf:d3:93:4c:6d:04:a0:a3:
1b:82:7e:b1:9a:b9:ed:c5:9e:c5:37:78:9f:9a:08:
34:fb:56:2e:58:c4:09:0e:06:64:5b:bc:37:dc:f1:
9f:28:68:a8:56:b0:92:a3:5c:9f:bb:88:98:08:1b:
24:1d:ab:30:85:ae:af:b0:2e:9e:7a:9d:c1:c0:42:
1c:e2:02:f0:ea:e0:4a:d2:ef:90:0e:b4:c1:40:16:
f0:6f:85:42:4a:64:f7:a4:30:a0:fe:bf:2e:a3:27:
5a:8e:8b:58:b8:ad:c3:19:17:84:63:ed:6f:56:fd:
83:cb:60:34:c4:74:be:e6:9d:db:e1:e4:e5:ca:0c:
5f:15
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
53:79:BF:5A:AA:2B:4A:CF:54:80:E1:D8:9B:C0:9D:F2:B2:03:66:CB
X509v3 Subject Key Identifier:
8D:8C:5E:C4:54:AD:8A:E1:77:E9:9B:F9:9B:05:E1:B8:01:8D:61:E1
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: X509v3 Any Policy
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.usertrust.com/USERTrustRSACertificationAuthority.crl
Authority Information Access:
CA Issuers - URI:http://crt.usertrust.com/USERTrustRSAAddTrustCA.crt
OCSP - URI:http://ocsp.usertrust.com
Signature Algorithm: sha384WithRSAEncryption
Signature Value:
32:bf:61:bd:0e:48:c3:4f:c7:ba:47:4d:f8:9c:78:19:01:dc:
13:1d:80:6f:fc:c3:70:b4:52:9a:31:33:9a:57:52:fb:31:9e:
6b:a4:ef:54:aa:89:8d:40:17:68:f8:11:10:7c:d2:ca:b1:f1:
55:86:c7:ee:b3:36:91:86:f6:39:51:bf:46:bf:0f:a0:ba:b4:
f7:7e:49:c4:2a:36:17:9e:e4:68:39:7a:af:94:4e:56:6f:b2:
7b:3b:bf:0a:86:bd:cd:c5:77:1c:03:b8:38:b1:a2:1f:5f:7e:
db:8a:dc:46:48:b6:68:0a:cf:b2:b5:b4:e2:34:e4:67:a9:38:
66:09:5e:d2:b8:fc:9d:28:3a:17:40:27:c2:72:4e:29:fd:21:
3c:7c:cf:13:fb:96:2c:c5:31:44:fd:13:ed:d5:9b:a9:69:68:
77:7c:ee:e1:ff:a4:f9:36:38:08:53:39:a2:84:34:9c:19:f3:
be:0e:ac:d5:24:37:eb:23:a8:78:d0:d3:e7:ef:92:47:64:62:
39:22:ef:c6:f7:11:be:22:85:c6:66:44:24:26:8e:10:32:8d:
c8:93:ae:07:9e:83:3e:2f:d9:f9:f5:46:8e:63:be:c1:e6:b4:
dc:a6:cd:21:a8:86:0a:95:d9:2e:85:26:1a:fd:fc:b1:b6:57:
42:6d:95:d1:33:f6:39:14:06:82:41:38:f5:8f:58:dc:80:5b:
a4:d5:7d:95:78:fd:a7:9b:ff:fd:c5:a8:69:ab:26:e7:a7:a4:
05:87:5b:a9:b7:b8:a3:20:0b:97:a9:45:85:dd:b3:8b:e5:89:
37:8e:29:0d:fc:06:17:f6:38:40:0e:42:e4:12:06:fb:7b:f3:
c6:11:68:62:df:e3:98:f4:13:d8:15:4f:8b:b1:69:d9:10:60:
bc:64:2a:ea:31:b7:e4:b5:a3:3a:14:9b:26:e3:0b:7b:fd:02:
8e:b6:99:c1:38:97:59:36:f6:a8:74:a2:86:b6:5e:eb:c6:64:
ea:cf:a0:a3:f9:6e:9e:ba:2d:11:b6:86:98:08:58:2d:c9:ac:
25:64:f2:5e:75:b4:38:c1:ae:7f:5a:46:83:ea:51:ca:b6:f1:
99:11:35:6b:a5:6a:7b:c6:00:b0:e7:f8:be:64:b2:ad:c8:c2:
f1:ac:e3:51:ea:a4:93:e0:79:c8:e1:81:40:c9:0a:5b:e1:12:
3c:c1:60:2a:e3:97:c0:89:42:ca:94:cf:46:98:12:69:bb:98:
d0:c2:d3:0d:72:4b:47:6e:e5:93:c4:32:28:63:87:43:e4:b0:
32:3e:0a:d3:4b:bf:23:9b:14:29:41:2b:9a:04:1f:93:2d:f1:
c7:39:48:3c:ad:5a:12:7f
evgeni
September 11, 2024, 6:27pm
20
Welp, it was worth a shot. Still no SHA1 to blame.