Support the Cert:/ PSDrive on non-Windows platforms

[DexterPOSH]

Steps to reproduce

Switch to Cert:/ Drive and run Get-ChildItem

Expected behavior

PS Cert:/> get-childitem

Location : CurrentUser StoreNames :

Location : LocalMachine StoreNames :

Actual behavior

PS Cert:/> get-childitem get-childitem : Cannot find path '/Cert:/' because it does not exist. At line:1 char:1

• get-childitem

• 
  - CategoryInfo          : ObjectNotFound: (/Cert:/:String) [Get-ChildItem], ItemNotFoundException
  - FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
  ## Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   3.0.0.0
GitCommitId                    v6.0.0-alpha.8
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[TravisEz13]

What OS was this on?

[DexterPOSH]

This was on an Ubuntu box.

vagrant@vagrant:/vagrant_data$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.1 LTS
Release:        14.04
Codename:       trusty
vagrant@vagrant:/vagrant_dat

[TravisEz13]

I don't think the Cert provider is currently supported on Ubuntu, but the drive probably shouldn't show up in that case.

[DexterPOSH]

The Cert provider yields expected result in the below case on my Ubuntu host.

PS /vagrant_data> Get-ChildItem -path Cert:/

Location   : CurrentUser
StoreNames :

Location   : LocalMachine
StoreNames :

But it fails when the Get-ChildItem is run from the PSDrive itself.

[joeyaiello]

The Certificate store is not currently supported on non-Windows platforms, and isn't in scope in the near future.

[TravisEz13]

@joeyaiello What would an x509 cert provider do on a Linux machine? Well, it could enumerate the certs in /etc/ssl, /etc/pki/tls , /system/etc/security/cacerts, but the semantics would need to be quite different than on windows to be useful.

[markekraus]

In researching supported and unsupported features in .NET core's Web Cmdlets I discovered that the certificate stores are working in .NET on both Linux and macOS. they can be directly manipulated via the .NET APIs through pwsh. On Linux, the current user my store gets created in ~/.dotnet/corefx/cryptography/x509stores/my. on macOS it is using Apple's Security.Framework API.

Using the ClientCert.pfx in the WebListener, I can initialize the Linux CurrentUser\My store like so:

# Do some prep work
$StoreName = [System.Security.Cryptography.X509Certificates.StoreName]
$StoreLocation = [System.Security.Cryptography.X509Certificates.StoreLocation]
$OpenFlags = [System.Security.Cryptography.X509Certificates.OpenFlags]
$Store = [System.Security.Cryptography.X509Certificates.X509Store]::new(
    $StoreName::My, $StoreLocation::CurrentUser)

# Get a certificate
$X509Certificate2 = [System.Security.Cryptography.X509Certificates.X509Certificate2]
$CertPath = (Resolve-Path 'ClientCert.pfx').Path
$Cert = $X509Certificate2::New($CertPath, 'password')

# Open the store, Add the cert, Close the store.
$Store.Open($OpenFlags::ReadWrite)
$Store.Add($Cert)
$Store.Close()

After doing that on Linux, I am able to use cert auth via thumbprint:

$Thumbprint = '2DECF1348FF21B780F45D316A039B5EB4C6312F7'
$Uri = 'https://prod.idrix.eu/secure/'
Invoke-RestMethod -Uri $Uri -CertificateThumbprint $Thumbprint

Cert auth doesn't work at all on macOS, but, I can still manipulate and search the CurrentUser\My store using the .NET APIs.

I think this support should be readded for x-plat in 6.1.0.

[SteveL-MSFT]

Spent some time on this and the provider builds, but it doesn't work as it heavily relies on calling native Win32 apis to do anything. There may be sufficient managed api support to remove the native calls, but it's a non-trivial amount of work.

[SidShetye]

Related to *nix certificate activities, we need Import-PfxCertificate. Added as a ticket @ https://github.com/PowerShell/PowerShell/issues/7213

[andreesteve]

@SteveL-MSFT - do you know if this feature is planed for a future release or just in the backlog for now? Thanks!

[SteveL-MSFT]

@andreesteve this feature is not currently in any active plan and is just in the backlog. Since the provider currently relies on Win32 APIs and not .NET APIs, it's not a small work item. A PR would be gladly accepted :)

[microsoft-github-policy-service[bot]]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service[bot]]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service[bot]]

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

[microsoft-github-policy-service[bot]]

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.