• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • Support for BIND DNS has been removed from Plesk for Windows due to security and maintenance risks.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS.

Resolved Weak Algorithm Warning (DSA1024) for Plesk Repositories on Ubuntu 24.04 LTS

me too
Synchronizing the Debian APT package index files...
Hit:2 Index of /pool/PSA_18.0.70_16953 noble InRelease
Hit:3 LiveConfig® Repository main InRelease
Hit:5 LiveConfig® Repository noble InRelease
Hit:6 Index of /PHP74_17 noble InRelease
Get:8 Index of /PHP80_17 noble InRelease [3545 B]
Hit:10 Index of /PHP81_17 noble InRelease
Get:11 Index of /PHP82_17 noble InRelease [4009 B]
Hit:12 Index of /grafana/deb stable InRelease
Get:13 Index of /PHP83_17 noble InRelease [4009 B]
Hit:14 Index of /PHP84_17 noble InRelease
Hit:15 Index of /pool/WPB_18.0.69_87 all InRelease
Hit:16 Index of /apps/ubuntu/ noble-apps-security InRelease
Hit:17 Index of /apps/ubuntu/ noble-apps-updates InRelease
Hit:18 Index of /ubuntu/24.04/slot-1/ noble InRelease
Hit:19 Index of /infra/ubuntu/ noble-infra-security InRelease
Hit:1 Index of /linux/distributions/ubuntu/ubuntu/ noble InRelease
Hit:4 Index of /linux/distributions/ubuntu/ubuntu/ noble-updates InRelease
Hit:20 Index of /infra/ubuntu/ noble-infra-updates InRelease
Hit:7 Index of /linux/distributions/ubuntu/ubuntu/ noble-backports InRelease
Hit:21 Index of /ubuntu/24.04/slot-2/ noble InRelease
Err:6 Index of /PHP74_17 noble InRelease
The following signatures were invalid: 8BADC1A02FC9C07FB8C20EC0BD11A6AA914BDF7E (untrusted public key algorithm: dsa1024)
Hit:9 Index of /linux/distributions/ubuntu/ubuntu/ noble-security InRelease
Hit:22 Index of /ubuntu/24.04/slot-3/ noble InRelease
Err:8 Index of /PHP80_17 noble InRelease
The following signatures were invalid: 8BADC1A02FC9C07FB8C20EC0BD11A6AA914BDF7E (untrusted public key algorithm: dsa1024)
Hit:23 Index of /ubuntu/24.04/slot-4/ noble InRelease
Hit:24 Index of /ubuntu/24.04/slot-5/ noble InRelease
Hit:25 Index of /ubuntu/24.04/slot-6/ noble InRelease
Hit:26 Index of /ubuntu/24.04/slot-7/ noble InRelease
Err:12 Index of /grafana/deb stable InRelease
The following signatures were invalid: 8BADC1A02FC9C07FB8C20EC0BD11A6AA914BDF7E (untrusted public key algorithm: dsa1024)
Hit:27 Index of /ubuntu/24.04/slot-8/ noble InRelease
Get:28 Index of /imunify360/ubuntu/24.04/ noble InRelease [1168 B]
Err:18 Index of /ubuntu/24.04/slot-1/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Err:21 Index of /ubuntu/24.04/slot-2/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Err:22 Index of /ubuntu/24.04/slot-3/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Err:23 Index of /ubuntu/24.04/slot-4/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Err:24 Index of /ubuntu/24.04/slot-5/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Err:25 Index of /ubuntu/24.04/slot-6/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Err:26 Index of /ubuntu/24.04/slot-7/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Err:27 Index of /ubuntu/24.04/slot-8/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Err:28 Index of /imunify360/ubuntu/24.04/ noble InRelease
The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
Reading package lists...
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: Index of /PHP74_17 noble InRelease: The following signatures were invalid: 8BADC1A02FC9C07FB8C20EC0BD11A6AA914BDF7E (untrusted public key algorithm: dsa1024)
W: GPG error: Index of /PHP80_17 noble InRelease: The following signatures were invalid: 8BADC1A02FC9C07FB8C20EC0BD11A6AA914BDF7E (untrusted public key algorithm: dsa1024)
E: The repository 'Index of /PHP80_17 noble InRelease' is not signed.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: Index of /grafana/deb stable InRelease: The following signatures were invalid: 8BADC1A02FC9C07FB8C20EC0BD11A6AA914BDF7E (untrusted public key algorithm: dsa1024)
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: Index of /ubuntu/24.04/slot-1/ noble InRelease: The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: Index of /ubuntu/24.04/slot-2/ noble InRelease: The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: Index of /ubuntu/24.04/slot-3/ noble InRelease: The following signatures were invalid: 9EE467641C635726A184D64B8C55A6628608CB71 (untrusted public key algorithm: dsa1024)
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: Index of /ubuntu/24.04/slot-4/ noble
 
Yes same here,

Reason: 2025-06-02 06:25:19 INFO: pum is called with arguments: ['--list', '--repo-info', '--json']
/usr/lib/python3/dist-packages/apt/cache.py:562: Warning: W:An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: Index of /grafana/deb stable InRelease: The following signatures were invalid: 8BADC1A02FC9C07FB8C20EC0BD11A6AA914BDF7E (untrusted public key algorithm: dsa1024), W:Failed to fetch https://autoinstall.plesk.com/grafana/deb/dists/stable/InRelease The following signatures were invalid: 8BADC1A02FC9C07FB8C20EC0BD11A6AA914BDF7E (untrusted public key algorithm: dsa1024), W:Some index files failed to download. They have been ignored, or old ones used instead.
res = self._cache.update(fetch_progress, slist, pulse_interval)
2025-06-02 06:25:21 ERROR: Apt cache fetch failed. Try to run the `apt-get update` command.
2025-06-02 06:25:21 ERROR:
2025-06-02 06:25:21 ERROR: Exited with returncode 1.
 
Same here on a machine that's now running Plesk Obsidian 18.0.70 on Ubuntu 24 for PHP 7.4 and Imunify360.

Also it seams like related to now system updates being reported available but fail updating with "Error: Unable to receive update information for the package(s)"
 
I confirm the bug on PLESK versions from 18.0.64 upwards for Ubuntu 24.04.
untrusted public key algorithm: dsa1024 for PHP7.4, grafana, PHP8.0
No error for: PHP8.1, 8.2, 8.3
 
oradke said:
This fixes the problem for system packages (but not for imunify360):

tldr: Add a file
Code: 
/etc/apt/apt.conf.d/99weakkey-warning
with
Code: 
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";
inside to disable the warning.

To undo, rm the file.
Click to expand...

This is a legit workaround also suggested by our team. However, please do proceed with caution as the action can impact the overall security of the system. Our team is already working on releasing a fix. I will follow up with more details.
 
This is caused by the update to the Ubuntu package update-manager 1:24.04.12 published on 2025-05-28 23:24:55 UTC.

Here are three temporary workarounds for Ubuntu 24.04. All will generate warnings, but no errors. We're using the first one.

Workaround 1 (the one I recommend), it reenables dsa1024 and still verify all repo signatures (credits to @oradke):

Code: 
echo 'APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";' > /etc/apt/apt.conf.d/99weakkey-warning

Workaround 2, modify your `/etc/apt/source.list.d/repo_failing` file this way, it will allow a specific repo to work if unsigned or improperly signed (basically stop verifying a specific repo only, example below with NewRelic):

Old:
Code: 
deb http://apt.newrelic.com/debian/ newrelic non-free

New:
Code: 
deb [trusted=yes] http://apt.newrelic.com/debian/ newrelic non-free

Workaround 3 (I advise against it), put this in /etc/apt/apt.conf, it will bypass all GPG signatures verification for all repos:

Code: 
Acquire {
        AllowInsecureRepositories "true";
        AllowDowngradeToInsecureRepositories "true";
}
APT {
        Get {
                AllowUnauthenticated "true";
        }
}
 
I cannot update Imunify360 or any system packages - same issues as above. I have the 'package information not found' error when checking for updates.

I have two servers. For me the issue is only on the one running Ubuntu 24.04.2 LTS, my other server is on Ubuntu 22.04.5 LTS and it's updating normally.

I'm very new to Linux and Plesk - will the lack of system and Imunify updates pose a security threat if not available for a few days? I'm hoping Plesk and Imunify can release a fix asap. I'm not confident enough to apply the workaround fix shown above.
 
Ash155 said:
I cannot update Imunify360 or any system packages - same issues as above. I have the 'package information not found' error when checking for updates.

I have two servers. For me the issue is only on the one running Ubuntu 24.04.2 LTS, my other server is on Ubuntu 22.04.5 LTS and it's updating normally.

I'm very new to Linux and Plesk - will the lack of system and Imunify updates pose a security threat if not available for a few days? I'm hoping Plesk and Imunify can release a fix asap. I'm not confident enough to apply the workaround fix shown above.
Click to expand...

This is due to an update to the "update-manager" package on 28 May 2025 on Ubuntu 24.04.

It's affecting a lot of people, so either the repo owners will fix this quick and/or Ubuntu will roll it back temporarily.

If you ask me, their update makes sense security-wise, but not the way they rolled it out.

In any case, check here for temporary workarounds for Ubuntu 24. Make sure you revert them when they are not necessary anymore. DSA1024 is not deemed secure anymore, so allowing it unless you really need to (like now) isn't a good idea.
 
tlacroix said:
This is due to an update to the "update-manager" package on 28 May 2025 on Ubuntu 24.04.

It's affecting a lot of people, so either the repo owners will fix this quick and/or Ubuntu will roll it back temporarily.

If you ask me, their update makes sense security-wise, but not the way they rolled it out.

In any case, check here for temporary workarounds for Ubuntu 24. Make sure you revert them when they are not necessary anymore. DSA1024 is not deemed secure anymore, so allowing it unless you really need to (like now) isn't a good idea.
Click to expand...
Thank you for the useful info. Fingers crossed they will release a fix asap.

The workaround 1 seems the easiest to implement (I'm a little nervous about creating or modifiying files). Excuse my lack of knowledge, but do I literally just type:

echo 'APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";' > /etc/apt/apt.conf.d/99weakkey-warning

after I've logged in to my SSH remote console? or do I need to do anything else?

Also, how do I revert this afterwards?

Thanks again, feels like a rather inconvenient time to be a Plesk newbie!
 
Ash155 said:
Thank you for the useful info. Fingers crossed they will release a fix asap.

The workaround 1 seems the easiest to implement (I'm a little nervous about creating or modifiying files). Excuse my lack of knowledge, but do I literally just type:

echo 'APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";' > /etc/apt/apt.conf.d/99weakkey-warning

after I've logged in to my SSH remote console? or do I need to do anything else?

Also, how do I revert this afterwards?

Thanks again, feels like a rather inconvenient time to be a Plesk newbie!
Click to expand...
For workaround #1, you need to perform the command as root.

It will create the file "/etc/apt/apt.conf.d/99weakkey-warning" and write...:
Code: 
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";
... into it.

You can do the same with nano or vi or any other editor if you prefer.

To revert the change, you only need to remove the file this command created, like this:
Code: 
rm -f /etc/apt/apt.conf.d/99weakkey-warning

It's not directly Plesk's fault (my failing repos are extensions, not Plesk ones). IMHO, it's Ubuntu's, they made a necessary change (dsa1024 isn't really secure anymore), but they rolled it out way too fast or with too little prior warning. Plesk users (and NewRelic, and many others) are just collateral damage.
 
tlacroix said:
For workaround #1, you need to perform the command as root.

It will create the file "/etc/apt/apt.conf.d/99weakkey-warning" and write...:
Code: 
APT::Key::Assert-Pubkey-Algo ">=rsa2048,ed25519,ed448,dsa1024";
... into it.

You can do the same with nano or vi or any other editor if you prefer.

To revert the change, you only need to remove the file this command created, like this:
Code: 
rm -f /etc/apt/apt.conf.d/99weakkey-warning

It's not directly Plesk's fault (my failing repos are extensions, not Plesk ones). IMHO, it's Ubuntu's, they made a necessary change (dsa1024 isn't really secure anymore), but they rolled it out way too fast or with too little prior warning. Plesk users (and NewRelic, and many others) are just collateral damage.
Click to expand...
Thank you, that's massively helpful. Much appreciated.. now I know why this forum is so useful!
 
@tlacroix

Sorry - last question! Would you recommend I delete the file and just add it on when I need to do an update, or leave it in place until Plesk / Imunify release a proper fix?
 
Ash155 said:
@tlacroix

Sorry - last question! Would you recommend I delete the file and just add it on when I need to do an update, or leave it in place until Plesk / Imunify release a proper fix?
Click to expand...
Reenabling the dsa1024 algorithm (workaround 1) is better than nothing (workaround 2 and 3), but there's a reason why they disabled it: it isn't considered secure anymore.

So to answer your question: Yes, you probably don't want to keep dsa1024 enabled longer than you need to, and you want to recheck it once in a while.

The risk with insecure keys is someone being able to break them and impersonate a repository and inject their hacked packages while your systems think they are legitimate. It would be super complexe and it is improbable, but it is possible.

Same as for TLS 1.0 which is now considered insecure, and TLS 1.2 + 1.3 being now the norm, with TLS 1.0 and 1.1 being usually entirely disabled.

You probably won't ever have any problem if you don't disable dsa1024 when you don't need it anymore. But better safe than sorry.
 
tlacroix said:
Reenabling the dsa1024 algorithm (workaround 1) is better than nothing (workaround 2 and 3), but there's a reason why they disabled it: it isn't considered secure anymore.

So to answer your question: Yes, you probably don't want to keep dsa1024 enabled longer than you need to, and you want to recheck it once in a while.

The risk with insecure keys is someone being able to break them and impersonate a repository and inject their hacked packages while your systems think they are legitimate. It would be super complexe and it is improbable, but it is possible.

Same as for TLS 1.0 which is now considered insecure, and TLS 1.2 + 1.3 being now the norm, with TLS 1.0 and 1.1 being usually entirely disabled.

You probably won't ever have any problem if you don't disable dsa1024 when you don't need it anymore. But better safe than sorry.
Click to expand...
Thanks again for your detailed reply, totally understand the reasons now, and makes sense.

Interestingly, I have another server which is running on Ubuntu 22.04.5 LTS, and haven't had these issues (yet!). I'm kind of assuming that's because Ubuntu prioritise changes on their latest versions and then roll out the same security fixes on older versions? I'd rather not update the older version, as it's stable and I was told you can run different versions as long as they are LTS ones.

P.S. for anyone who's having problems with Imunify, they suggested the same temporary workaround 1, and they are working on a fix - no ETA yet.
 
You must log in or register to reply here.

Similar threads

Daveo
Issue Ubuntu upgrade from 22.04 to 24.04 getting issue with key algorithms
Replies
2
Views
818
Daveo
Daveo
J
Resolved PUM error persists....
Replies
13
Views
2K
Jeroentje
J
K
Resolved Apt update warning weak algorithm (dsa1024)
Replies
5
Views
4K
Sebahat.hadzhi
Sebahat.hadzhi
M
Resolved error occurred during the signature verification
2
Replies
20
Views
2K
yohanr
Y
W
Issue Atomicorp repository - Debian 11 - NO_PUBKEY
Replies
2
Views
598
websb
W
Back
Top