Re: certificate and trust store feature for systemd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The only tools I know of that manage the files in /etc/pki are part of “ca-certificates” and they only manage the CAs, not general app specific public/private keys.

 

And even so, command line tools aren’t APIs.

 

The prime reason you want an actual API that’s widely available is it encourages other solution providers to leverage it.

 

Again, the CAPI/CNG API in Windows Is an example.

 

You can very easily manage all kinds of key management via a central API, and in turn, you can then leverage that infrastructure in other tools.

What I would then like to see is an engine for OpenSSL be able to leverage this and then have access to the keychain infrastructure without the file management involved.

 

This is something you can do with OpenSSL on Windows via the CAPI engine (or other API solutions that have their own engine solution in OpenSSL), for instance.

 

Since most secure products in Linux use OpenSSL, this almost immediately would also give them access to a centrally managed keystore.

 

That’s what I would like to see.

 

From: Barry Scott <barry@xxxxxxxxxxxxxxxx>
Sent: Wednesday, May 25, 2022 1:30 PM
To: SCOTT FIELDS <Scott.Fields@xxxxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] Re: certificate and trust store feature for systemd

 

On 25 May 2022, at 19:22, SCOTT FIELDS <Scott.Fields@xxxxxxxxxxx> wrote: If you’re referring to files in /etc/pki, that’s not a management API, like CAPI or CNG provides in Windows (and a like API in OSX). There are tools that you run

 



On 25 May 2022, at 19:22, SCOTT FIELDS <Scott.Fields@xxxxxxxxxxx> wrote:

 

If you’re referring to files in /etc/pki, that’s not a management API, like CAPI or CNG provides in Windows (and a like API in OSX).

 

There are tools that you run that manage the files. Sorry I do not have the details in front of me.

The tools are the API at least for trust store from what I recall when I set it up.



 

There’s a keychain solution in Gnome (GNOME/Keyring) but not widely adopted that I’ve seen.

 

I use KDE and the kwallet is used in most apps I use. If there is an app in gnome that is not using the keyring

then that a problem with the app surely, not the API?



 

This just seems a good match to have available within systemd

 

I do not speak for systemd, just curious about why you think this is needed.

 

Barry

 



 

From: Barry Scott <barry@xxxxxxxxxxxxxxxx> 
Sent: Wednesday, May 25, 2022 1:16 PM
To: SCOTT FIELDS <Scott.Fields@xxxxxxxxxxx>
Cc: systemd-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] Re: certificate and trust store feature for systemd

 

On 25 May 2022, at 14:06, SCOTT FIELDS <Scott.Fields@xxxxxxxxxxx> wrote: I apologize for the very general inquiry. Are there any plans to have system natively support its own trust store for items like CAs, x509 certs, passwords &

 




On 25 May 2022, at 14:06, SCOTT FIELDS <Scott.Fields@xxxxxxxxxxx> wrote:

 

I apologize for the very general inquiry.

 

Are there any plans to have system natively support its own trust store for items like CAs, x509 certs, passwords & truststores akin to the keychain in Windows and OS X?

 

But these are solved problems on modern Linux systems aren't they?

 

At least with RHEL and Fedora they have trust store and keychains.




 

I still find the management of PKIs in /etc/pki to be problematic.

 

For my home network I have my own DNS domain and CA setup. It was easy to add the CA to

Fedora's trust store.




 

Having this available as a core service within systemd using like APIs either in (mostly deprecated) CAPI or the new CNG

 

Barry




 

 

Scott Fields

IBM/Kyndryl

SRE – BNSF

817-593-5038 (BNSF)

 


[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux