Slackware64-current updated
I have personal certificate released from government authority valid worldwide.
Imported to Firefox and Chromium (Alien).
Two problems arise:
1. on windows I can set strong security, when importing cert, then providing password.
On Linux there is no security level to select when importing certificate.
2. on windows: When accessing pages with personal cert authorization, password is asked and then access is allowed (Chromium and Firefox).
On Slackware: Firefox access - provide certificate selection, then authorization is done without password. Chromium access to cert authorized web page offer cert selection and when selected, web page respond with failure.

How to enable strict and only strong cert security in Slackware? - always ask for password when accessing cert authorized web pages. Now I can not access that pages with Chromium, with Firefox access is without password.

Usually a Government Authority specifies clearly the operating systems intended to be used for accessing its web portals.

And usually the supported operating systems are Windows and Mac OS/X .

So, permit me to ask: your Government Authority recommends and clearly specifies to use Slackware (or any other Linux distribution) for accessing their web portals?

Not quite through. Web pages are not restricted to some OSes in our Country.
Thoroughly reading my previous post show, that I can access our government pages (public services, health for instance) with Firefox and installed private certificate without providing password when selecting certificate. That is in Linux (Slackware). On Windows the same page access request a password for my private certificate.

Please read my questions again:

1. I can not find a way to import a private certificate to Slackware with high security - ask for a certificate password EVERY TIME it is used, as it can be done in Windows

2. in Slackware I can access web pages with private certificate WITHOUT providing certificate password (low security) in Firefox only. Chrome returns error after selecting private certificate (not asking for a password) "Internal Server Error" And this is NOT related to OS, as Firefox access is allowed.

zdolar --

This is an interesting topic.

I see that you said in your original post: Not sure how you imported your personal cert, but I found this google page: Chromium Docs > Linux Cert Management

I've not read all the docs in the links but it looks like maybe you need to import your personal cert via `certutil` or `pk12util` into a DB on your Slackware Linux Box ?

Slackware64 15.0 includes /usr/bin/certutil and /usr/bin/pk12util ( part of Package l/mozilla-nss-3.87-x86_64-1_slack15.0 )
So maybe you can install your personal cert(s) via the mozilla nss tools and make your personal cert work ???

HTH and I would love to hear how this works out for you

-- kjh

What type of certificate is it exactly?

Thank you for the above link to Chromium manual.
I exported cert from Firefox to P12 format and then imported to Chromium, which asked for a password.
Now I can access government pages with Chromium.
This is partial (working) solution.

Still open is a security: Firefox and Chromium both access is allowed with cert selection, but without password requested. This is serious security breach.
On Windows after cert selection always requests password insertion to authenticate with certificate.

In Firefox and Chromium do you use a master password to protect your data? Perhaps that is the safeguard which allows usage of your certificate without asking for its password after the import.

I only have KdeWallet (configured by mistake) to ask for a master password when open Chromium.
Two passwords are stored in KDE Wallet: my home WiFi password and Samba share password.
Chromium password store is empty, and there is no Firefox password store in KDE Wallet.

zdolar --

I didn't read all the docs at the Google site carefully but I see that when you install Certs via /usr/bin/certutil there is a three-segment TRUST string.

I wonder if one of the three segments applies to Chromium ?

-- kjh

Looks like "no password required for certificate authentication" is a Linux feature/flaw:
https://security.stackexchange.com/q...sword-in-linux

And nobody care.

I finished searching for a solution (and let Thread open).

1 members found this post helpful.

The reason is right there in the very first sentence in the first answer to that thread:

"First of all, note that this is a behavior of the Windows key store... not of certificates in general or anything like that."

The keys you're using are clearly unencrypted, therefore your browsers are not asking for passwords.

If you want it work the same as it does in Windows, then you'd have to use KDE Wallet or something similar.

The documentation on how to do that can be found here:

https://docs.kde.org/trunk5/en/kwall...roduction.html

https://store.kde.org/p/1080814/

https://wiki.archlinux.org/title/KDE_Wallet

Also from the first answer in that thread:

"It's also only insecure if you let other people, who you don't trust, access your machine using your user account (or as the superuser). That is, to put it mildly, already an extremely bad idea. All your other browser secrets... are also all stored either in plain text or reversibly encrypted using keys available to the user. Plus, of course, everything else in your user profile (documents, pictures/videos, non-browser apps and all their saved data, etc.). It could also be a risk if your machine was stolen and you don't have full volume encryption enabled.

Microsoft put a lot of effort into the cryptographic security module used for key storage on Windows, including the ability to store keys such that they can't be retrieved (only used for various operations, like signing, which is how TLS client certs work) and the ability to store the keys encrypted not just with a per-user (or per-machine) key but also with a key-specific password-derived key. It's mostly useful for legacy reasons, though; back in the days when there were non-NT-based Windows versions, or when NT could be installed on a FAT-based file system that doesn't support access controls, a computer that was used by multiple people had no way to prevent one user from accessing another user's data, so highly-sensitive data like private keys offered the option of requiring a password on every use. These days, just give every user their own non-admin account and you've achieved most of the same protection."

Do you let other people use your login? Or are you running as root?

2 members found this post helpful.

It stands to reason that the Windows key store behaves this way because Windows never had any other security features until XP service pack 3 was released.

They had to have a way of preventing users from accessing each other's keys. Windows 9x/Me (and earlier versions) did not have file permissions or user accounts, so they had to make the key store secure.

Linux doesn't have these problems.

It's only the users who have access to your login who can use your certificate. If you want to put additional security around it, you can use KDE Wallet or gnupg ("man gpg").

2 members found this post helpful.

Thanks rkilsen

CBHacking's reply and your further explanations make perfect sense to me.

So it is a feature for Linux and a Flaw in early Windows.

-- kjh

Thank you for a clear explanation.
I'm not root user, except for administration.
My primary concern was security when using private certificate without password - Malicious web pages access with certificate and no password.

And private password export/backup is possible without password provided in Firefox and Chromium. This is huge security concern. A malicious web page can steal a private certificate with a proper script. Or am I wrong?

The chances of that happening these days are quite low. HTML5 and https should prevent that stuff. I mean, anything is possible, but if a webpage can steal your certificates then it could steal other possibly more important things.

Anyhow, as I said there are mechanisms in Linux to do what you want. You just have to read the instructions I linked to above.

1 members found this post helpful.