Seahorse unable to import pkcs12 certificates

When trying to import the certificate via command line I get the following output:

$ gnome-keyring import <my certificate>.p12
gnome-keyring: couldn't parse: <my certificate>.p12
gnome-keyring: couldn't find any place to import files

That's all I know at the moment.

I'm getting the same grayed out Import button with the "Cannot import..." hint. My key was exported from seahorse 3.20.0-3.1 on Ubuntu 17.10.

Status changed to 'Confirmed' because the bug affects multiple users.

I also see the greyed out Import button using Seahorse 3.20.0-5 on Ubuntu MATE 18.04 LTS.

Affects email signing, encryption through Thunderbird and signing of documents through LibreOffice. Had to show a demo to my boss on how Ubuntu + G Suite could be used for field users and got an unpleasant surprise.

Can confirm the problem. I really appreciate a fix, as email encryption by s/MIME does not work in evolution since I cannot import certificates.

Thanks a lot!
Markus

I can't find a workaround and it is crucial that I have a new certificates, because we use them to authenticate ourselves and send emails in our company.

This bug is affecting my job. I am not able to encrypt or sign my e-mails.

I'm facing the same bug on Linux Mint 19 Cinnamon.

I have the same issue in 18.04.

Does anyone know a workaround for this issue please? It is also affecting my job. Thanks.

I'll join the choir here:

Ubuntu 18.04.1;
Neither Seahorse nor gnome-keyring will import a .p12 certificate file.

Seahorse does not support .p12 certificates. It supports GPG and SSH certificates.

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software at https://gitlab.gnome.org/GNOME/seahorse/issues . If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Also tested it with .pem not working either

The output just changes to:
$ gnome-keyring import <my certificate>.pem
gnome-keyring: couldn't find any place to import files

seahorse can preview p12 and pem just fine, but can't import any.

See: https://gitlab.gnome.org/GNOME/seahorse/issues/205

Please note that I could not add this link as affected project because launchpad is configured to point to a seahorse Bugzilla, instead of GitLab. Seahorse migrated to GitLab.

See also:
https://askubuntu.com/questions/1037524/how-can-import-private-key-and-certificate-to-seahorse-in-ubuntu-18-04

For what I have tested this bug affects also Network Manager - can't set certificates for WPA(2) Enterprise and/or 802.1X.

So is there a fix available or in its way?

> Seahorse does not support .p12 certificates. It supports GPG and SSH certificates.
I believe this statement and the categorization of the issue as "wishlist" to be incorrect.

On a Debian stretch system with seahorse 3.20.0 this issue does not exist.
I can import *.p12 certificates. There, seahorse has the following categories:
Passwords
Certificates
PGP keys
Secure Shell

In "Certificates" there is "Gnome2 Key Storage". This is where the *.p12 certs go on stretch.
On my Ubuntu box this category does not exist.
So I guess it is an issue of missing packages or misconfiguration rather than an upstream bug.

Same here, cannot import and sign LibreOffice Documents (as I did since last week with 16.04) . Any news on that?

I have installed VirtualBox on my Mac laptop, and built Ubuntu 19.04 guest VM - but had issues with everything that requires HTTP/HTTPS access. Eventually, I came across this post - which matches the issue I have and explains why that's so...

To have another look at it, I searched for other ways (other than using SSL import utility) - and came across 'pk12util' which "supposed to" be able to import PK12 certificates (under normal circumstances). Using this utility, I'm getting "SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format" errors:

vpogrebi@vpogrebi-VirtualBox:/usr/local/share/ca-certificates$ sudo pk12util -i cacert.pem
pk12util: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.
vpogrebi@vpogrebi-VirtualBox:/usr/local/share/ca-certificates$ sudo pk12util -i IDEXX-NewPKI-SHA2-Chain.crt
pk12util: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.
vpogrebi@vpogrebi-VirtualBox:/usr/local/share/ca-certificates$ sudo pk12util -i dockercom.crt
pk12util: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.

Hope this can help resolving the issue; but in the meantime - it seems that I have to completely delete Ubuntu 18.04 VM and start all over using older (16.04 ?) version.

I have the same problem, with xubuntu 18.04.2, @samweis say that is a problem in ubuntu, seahorse can import p12 keys well in debian

As I've explained in the Bug Description, before filling this bug, I'd tested the same process in my wife's laptop then with 'Ubuntu 16.04 LTS' and it imported the certificates ('.cer' and '.p12') without issues. But in my laptop with 'Ubuntu 18.04 LTS' the problem exist (greyed button).

Therefore, there are two possibilities: 1) I'm mad or a liar; or 2) the statement on comment #15 is wrong.

I may well be mad, but not a liar! But the experiences described on comments #21 and #24 corroborate to the second possibility, i.e., that the statement on comment #15 is wrong.

So, I also have the same problem using Ubuntu 19.04, is there any workaround to import p12 certificates?

It's been over a year.. Is anyone going to fix this? Like pls

Regarding #17 and the bug (issue) report at Seahorse Gitlab, the latest comment is that Seahorse 3.20.0 which is the latest available on Ubuntu 18.04, is "an ancient version". Can 18.04 receive a newer version such that upstream can be brought into the issue if it persists with that?

The problem is still here and for instance it prevents LibreOffice Draw to check PDFs signatures. I think marking this as "wishlist" is terribly wrong, it is a major bug as there is no workaround to import certificates in LibreOffice.

As suggested in post #15, I just filled a bug report on GitLab: <https://gitlab.gnome.org/GNOME/seahorse/issues/232>, however, as I have my doubts if it is really an upstream bug, as it didn't occur on Ubuntu 16.04, just on Ubuntu 18.04, and some users reported that in Debian it works.

Hope anyone will be able (and willing) to fix it.

Well, after filling the report on GitLab, as suggested in comment #15, I receive the following statement from there:

 Andre Klapper 💬 @aklapper · 14 hours ago
Developer

You are using a version that is too old and not supported anymore by GNOME developers. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes by GNOME developers for the version that you use.

By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME.

Please feel free to reopen this bug report if the problem still occurs with a recent version of GNOME (3.32), or feel free to report this bug in the bug tracking system of your Linux distribution if your distribution still supports the version that you are using.

---

I may well be wrong (I'm a lawyer, not a developer) but I understand that this issue is an "Ubuntu bug" not a "GNOME bug", as it apparently just happens in Ubuntu 18.04 LTS, which is supposed to be supported for 5 years until April 2023. Nevertheless, the solution was marked herea mere "wishlist".

I assume no one will spend time trying to fix it, despite de lifespan support of Ubuntu 18.04
LTS is supposed to last 4 years more. That's sad!

You can ignore that upstream bug triager comment, Andre tends to dismiss reports based on first reporting version without checking if that's still an issue which is often the wrong thing to do, https://gitlab.gnome.org/GNOME/seahorse/issues/205 has a one week old comment stating that it's still a problem in 3.32 which is their current and supported version.

Off-topic for Seahorse, but the reporter's (and my) real problem is about signing in LibreOffice.
I've found a way to sign document in LibreOffice on Ubuntu:

LibreOffice searches a keystore in this order:
a.) The environment variable MOZILLA_CERTIFICATE_FOLDER
b.) The Thunderbird profile
c.) The Mozilla suite profile
d.) The Firefox profile.
(source: https://wiki.openoffice.org/wiki/How_to_use_digital_Signatures )

So you do not need seahorse to sign documents in LibreOffice, only Thunderbird or Firefox.

Steps:
1. Import your certificate into Thunderbird or Firefox key store (Edit, Preferences, etc.).
2. LO help says: "It is also necessary that the trust settings for the root certificates are set to trust the certificate to identify web sites and e-mail users."
Make sure they are set.
3. In LibreOffice, Tools, Options, LibreOffie\Security, in "Certificate Path" the first keystore (for me) is "/home/lml/.thunderbird/something.default".
(Note:
  - It seems you can choose between thunderbird and firefox keystore, but you can't.
  - The LO help mentions the "Certificate Detection" page,
    the Basic script there gives the same result.
)
Override this detected value using the following command to start LibreOffice using terminal:

MOZILLA_CERTIFICATE_FOLDER=sql:/home/lml/.thunderbird/something.default soffice

(use your own path for Thunderbird or Firefox keystore)

The trick is to add "sql:" to the beginning of the value and override the (otherwise correct) detected path. Maybe there is a problem in LibreOffice not able to use the certificate folder...

I'm using Ubuntu 19.10, LibreOffice 6.3.2, Thunderbird 60.9.

Nothing yet? Jesus!

I compiled 3.30.1.1 and yet: The same error message—“No compatible importer found”

Fascinating, I am seeing this exact same issue with SSH keys. When using ssh-add these keys will load into the agent without a problem, but I cannot import them into Seahorse. The files have been generated with OpenSSH, but their file names aren't following the standard id_<algo> and id_<algo>.pub pattern ...

I also followed the advice from that AskUbuntu answer to generate accompanying .pub files, but that didn't work either.

Seahorse also outright refused to import the id_ed25519, whereas the id_rsa worked previously. This seems at least inconsistent.

Package versions:

gnome-keyring 3.28.0.2-1ubuntu1.18.04.1
seahorse 3.20.0-5

The keys I was trying to import into Seahorse were located in an encrypted container (mounted, obviously). As I cannot influence (or haven't learned how to influence) the standard file modes when mounting said container, they all had 0700 as file mode, including the .pub files I had generated based on that AskUbuntu answer.

Once I copied them over to ~/.ssh they popped up immediately in Seahorse. So it's definitely not the file format that is/was the issue here.

Either it's the file mode, a certain expectation of what it ought to be or it's the fact that the keys I was trying to import weren't in ~/.ssh; or something else altogether?! ...

Not seahorse but the same problem described in #33, my Mint 19.3 was not being able to sign with Libreoffice 6.0.7.3 (nor other apps like AutoFirma) It was solved by:
- downgrading to openjdk 1.8 (sudo apt install openjdk-8-jre; sudo update-java-alternatives -s java-1.8.0-openjdk-amd64 )
- leaving just one profile for thunderbird with name default
- upgrading to LibreOffice 6.4.2

 Maybe not all the steps were neede, maybe LibreOffice was a matter of reinstalling with no need to upgrade (Autofirma worked just reinstalling) but now it works

Regards.

As the problem is still not solved in seahorse 3.36

May I can help someone with this link that explains how you can sign a libreoofice document without seahorse, it works for me.
https://askubuntu.com/questions/122058/how-do-i-make-a-digital-certificate-available-to-libreoffice-writer-for-digital

This is really amazing. I still have the same problem.

And yes, it is NOT triaged.

I have Ubuntu 18.04.4 LTS. LibreOffice is version 6.0.7.3.

I would expect some things just work in 21tg century. But obviously, I am wrong.

Maybe the problem is, that Ubuntu developers does not use encryption and digital signatures? C'mon people, we are in 2020. How do you expect that business will not use such things?

Or maybe Ubuntu is targeted for home playing only?

I have a very simple question: I am using Ubuntu version, which is still officially supported. What should I do that I will be able to sign LibreOffice documents and PDF's?

To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/project/about-ubuntu/conduct. Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind. Venting frustration in a bug report isn't fine.

The bug is triaged with reference to upstream report explaining the details of the issue. Ubuntu is perfectly capable to import certificates and sign documents, it's just that the GNOME frontend isn't featuring that capability.

Alternative solutions have been listed in previous comment or on online articles, see e.g https://askubuntu.com/questions/122058/how-do-i-make-a-digital-certificate-available-to-libreoffice-writer-for-digital

Still unable to import .p12 and .cer certificates on Ubuntu 20.04.1 LTS / GNOME 3.36.3 / Seahorse 3.36.

Still unable to import openssh-formatted RSA PRIVATE KEYs on Ubuntu 20.04.1 LTS / Gnome 3.36.8 / Seahorse 3.36-1

(Sorry for #43, wrong bug/thread - but yes, the same goes for .p12 at the versions stated.)

I can't undestand why this bug still unatended.

Certificates and signing is a common practice for today. This bug affects any application who searchs for certificates on operating system storage.

Install the same certificate many times in multiple applications increase probabilities for vulnerabilities impacts and private key leaks.

It impacts in user experience too, and make hard to handle digital identities in Ubuntu for personal and SOHO users.

Finally, it impacts Ubuntu image.
less deb
Please, considere to change priority for this bug.

Also been hit here. Are there any alternatives, is there an older working version of the software?

same problem. LTS Ubuntu 20.04 update today 01-2022, seahorse 3.36-1

Same Problem : Linux Mint 20.3 Una / Cinnamon 5.2.7 / Seahorse 3.36

I reported this bug 4 years ago.
I'm a lawyer, and I depend on digital certificates and signatures to do my
job. From 2012 to 2017 I had no problem doing that using Ubuntu/Seahorse.
However, since upgraded to Ubuntu 18.04 LTS, found no linux distribution
able to import pcks12 certificates anymore. Since then, had been forced to
use Windows (dual boot) just to sign digital files.

I simply cannot understand how Seahorse developers have been ignoring such
critical and serious issue for such a long time. No one can blame the world
to stick with MS Windows and proprietary software.

I still using linux (currently Fedora) but have to spend a huge stake of my
SSD with a Windows 10 instalation because Linux distributions are unable
to deal with pcks12 certificates since 2018.

Sad, very sad. I gave up my hope of seeing this bug fixed. Waiting for 4
years now.

Red Hat corporate customers doesn't need to import pcks12 certificates? It
seems that they don't, unfortunately.

On Tue, 1 Feb 2022, 12:11 loizbec, <email address hidden> wrote:

> Same Problem : Linux Mint 20.3 Una / Cinnamon 5.2.7 / Seahorse 3.36
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1771880
>
> Title:
> Seahorse unable to import pkcs12 certificates
>
> Status in seahorse:
> New
> Status in gnome-keyring package in Ubuntu:
> Triaged
> Status in seahorse package in Ubuntu:
> Triaged
> Status in gnome-keyring package in Fedora:
> New
> Status in seahorse package in Fedora:
> Unknown
>
> Bug description:
> seahorse 3.20.0-5 / gnome-keyring 3.28.0.2-1ubuntu1.18.04.1 / Ubuntu
> 18.04 LTS / GNOME 3.28.1
>
> When trying to import a certificate into seahorse/gnome-keyring on
> Ubuntu 18.04, seahorse GUI application shows the 'import' button
> greyed out, while mouse hovering the "import" button shows the message
> "Cannot import because there are no compatible importers".
>
> This problem doesn't occur on Ubuntu 16.04 LTS (Seahorse 3.18.0), as
> I've just tested on my wife's laptop, but happens in my Laptop with
> Ubuntu 18.04 LTS (Seahorse 3.20.0-5).
>
> Because that problem, it's not possible to digitally sign documents
> with LibreOffice.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/seahorse/+bug/1771880/+subscriptions
>
>

I am still having the same issue, along with many others issues lol... I have stopped trying to find any useful answers, as most sources seem content with being in control, obfuscating, complaining about people's questions or just plain bullying.

I actually saw this as advice in a 'support forum' (an oxymoron):
User: "I can't get 'x' to work properly"
'Support' User: "You can uninstall it by typing ...."
Is NOT a solution, no matter how dense you are.

In the future, software will be developed when people feel like it. Bugs which plague modern systems will only be fixed if we act like sycophants, otherwise some of us will have the unique opportunity to discuss these various and endemic plague of software bugs which our grandchildren, no doubt, will also experience.

Encryption software that doesn't encrypt; the poisonous sprawl of large-scale software projects managed by children and professional mini-nazis; file managers which can't mount drives; Error messages which never see the light of day, ever perpetuating everyone's desire to run a stable system; puerile arguments between projects, leaving the fallout for the end users to deal with; Non-existent documentation; When Developers basically say: "But I want it to work MY way, NOT the NORMAL, EXPECTED, AVERAGE way!"... Oh, this project has moved.... (Yet again... But we're leaving the old, inaccurate web site and forum up from 2011 to soil relevant search results"; Regularly requiring specific system/software information from end users posting reports, but offer said users NO framework for doing so... The list of mistakes and lapses of care goes on.

Open source = Unfinished; buggy; elitist/out-of-touch/narcissistic developers. I mean, this stuff is written in people's 'free time'... What can we expect, really? A cohesive development and debugging roadmap? lol

I haven't found anything useful on a support forum for years and have, sadly, grown accustomed to the modern Linux staples of the 'workaround' and the 'do without, then'.

On one hand you have Microsoft advertising on your paid-for desktop, or you have a bunch of part-timers making out that they're the best thing since sliced bread... Humanity is embarrassing.

And I will leave you all with this absolute gem from the MIT OS license...

"THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."

Basically: It's your own fault if you trust this software to do anything remotely useful. The author is not responsible for anything that goes wrong.

This is one of the modern standards in production quality we have to look forward to.

TL;DR: Don't expect all FOSS developers to even remotely consider the quality of their software or their support, these ad-hoc organisations have no charter and no legal responsibility to their end users. A...

This is a real shame. I am using Ubuntu 22.10 with Seahorse 42, and the problem still persists. The bug is several years old and there is no solution yet.

The world is going paperless, people want to use their Linux systems for serious work and business, but certificate management is not supported.

Just a short question - is this issue not important? You think adding some new features in a form of new shiny icons is more important than ability to digitally sign documents in 21th century? (Yes, I am actually asking that question).

Ubuntu doesn't have one actively working on that component, the right place to fix the issue would be upstream

I've been using Fedora for tha last few years, and I confirm that the bug
isn't exclusive in Ubuntu, is upstream.

 Sadly, I'm obliged to keep Windows installed in my computer in dual boot
mode due exclusively to this issue, otherwise I'd diched Windows
completely. Other people, on the other hand, had ditched Linux completely
because this issue.

 I think this issue have been undervaluated for long time. I reported the
bug in 2018, 4 years ago and it still there. It use to work fine until
Ubuntu 16.04 LTS (Seahorse 3.18.0), the problem began in Ubuntu 18.04 LTS
(Seahorse 3.20.0-5).

On Tue, 8 Nov 2022, 06:55 Sebastien Bacher, <email address hidden>
wrote:

> Ubuntu doesn't have one actively working on that component, the right
> place to fix the issue would be upstream
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1771880
>
> Title:
> Seahorse unable to import pkcs12 certificates
>
> Status in seahorse:
> New
> Status in gnome-keyring package in Ubuntu:
> Triaged
> Status in seahorse package in Ubuntu:
> Triaged
> Status in gnome-keyring package in Fedora:
> New
> Status in seahorse package in Fedora:
> Unknown
>
> Bug description:
> seahorse 3.20.0-5 / gnome-keyring 3.28.0.2-1ubuntu1.18.04.1 / Ubuntu
> 18.04 LTS / GNOME 3.28.1
>
> When trying to import a certificate into seahorse/gnome-keyring on
> Ubuntu 18.04, seahorse GUI application shows the 'import' button
> greyed out, while mouse hovering the "import" button shows the message
> "Cannot import because there are no compatible importers".
>
> This problem doesn't occur on Ubuntu 16.04 LTS (Seahorse 3.18.0), as
> I've just tested on my wife's laptop, but happens in my Laptop with
> Ubuntu 18.04 LTS (Seahorse 3.20.0-5).
>
> Because that problem, it's not possible to digitally sign documents
> with LibreOffice.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/seahorse/+bug/1771880/+subscriptions
>
>

https://gitlab.gnome.org/GNOME/seahorse/-/issues/205

On Tue, 8 Nov 2022, 07:11 Angelo Giacomini Ribas, <
<email address hidden>> wrote:

> I've been using Fedora for tha last few years, and I confirm that the bug
> isn't exclusive in Ubuntu, is upstream.
>
> Sadly, I'm obliged to keep Windows installed in my computer in dual boot
> mode due exclusively to this issue, otherwise I'd diched Windows
> completely. Other people, on the other hand, had ditched Linux completely
> because this issue.
>
> I think this issue have been undervaluated for long time. I reported the
> bug in 2018, 4 years ago and it still there. It use to work fine until
> Ubuntu 16.04 LTS (Seahorse 3.18.0), the problem began in Ubuntu 18.04 LTS
> (Seahorse 3.20.0-5).
>
> On Tue, 8 Nov 2022, 06:55 Sebastien Bacher, <email address hidden>
> wrote:
>
>> Ubuntu doesn't have one actively working on that component, the right
>> place to fix the issue would be upstream
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1771880
>>
>> Title:
>> Seahorse unable to import pkcs12 certificates
>>
>> Status in seahorse:
>> New
>> Status in gnome-keyring package in Ubuntu:
>> Triaged
>> Status in seahorse package in Ubuntu:
>> Triaged
>> Status in gnome-keyring package in Fedora:
>> New
>> Status in seahorse package in Fedora:
>> Unknown
>>
>> Bug description:
>> seahorse 3.20.0-5 / gnome-keyring 3.28.0.2-1ubuntu1.18.04.1 / Ubuntu
>> 18.04 LTS / GNOME 3.28.1
>>
>> When trying to import a certificate into seahorse/gnome-keyring on
>> Ubuntu 18.04, seahorse GUI application shows the 'import' button
>> greyed out, while mouse hovering the "import" button shows the message
>> "Cannot import because there are no compatible importers".
>>
>> This problem doesn't occur on Ubuntu 16.04 LTS (Seahorse 3.18.0), as
>> I've just tested on my wife's laptop, but happens in my Laptop with
>> Ubuntu 18.04 LTS (Seahorse 3.20.0-5).
>>
>> Because that problem, it's not possible to digitally sign documents
>> with LibreOffice.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/seahorse/+bug/1771880/+subscriptions
>>
>>

Hi, thought I'd chime in here as just ran into the same issue on debian bullseye. Obtained an oh-so-precious "mycert.p12" file and resolved thus:

Step 1:

a) In Firefox ESR: Settings -> Privacy and Security -> View Certificates button (way down at the bottom).
b) "Certificate manager" popup window, "Your Certificates", Import button
c) Select mycert.p12 file and it appears in Firefox.

Step 2:

a) In LibreOffice Write: Tools -> Options -> Security, click "Certificate" button under "Certificate Path"

This is where it got interesting - there were two selections there:

x firefox:default
o firefox:default-esr

the top one, "firefox-default" was selected and was not working. Clicking "firefox:default-esr" instead, restart LibreOffice Write... fixed.

Another important note: After changing the certificate path, it prompts "LibreOffice Write needs to restart in order to take effect. Do this now?" ...which I answered yes, but it did not actually restart. Initially thinking it didn't work. But upon manual restart, it *did* work.

Maybe this approach is better since it takes Seahorse out of the loop.

Would also be curious to know if Jammy is fixed and/or above works? I'm going to upgrade one of the three debian bullseye systems I did this on successfully, to debian bookworm right now. If anything breaks, I'll be sure to post that here.

Hope this helps someone out there.