You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use PowerShell to initialize development and production environments with certificates with private keys across supported platforms, mirroring DotNet Core`s certificate store model. Development platforms are Windows 10, macOS and Ubuntu. Production platforms are Windows Server and RHEL. This should support user and machine locations and the various certificate stores supported on that platform by DotNet Core.
It should import the certificate and private key into specified certificate stores (my, trust/root etc) and locations (local user vs machine). They aren’t fully consistent across OS’s, so I’d suggest mirroring the same model as dotnet’s.
Specifically our use case is to initialize developer platforms and production servers with the right certificates for .net development and production workloads.
Yes, powershell initializes the environments, including certificates and private keys in each OS. .NET Apps use these certificates. Development platforms are Windows 10, macOS and Ubuntu. Production platforms are Windows Server and RHEL.
I updated the issue description with my current understanding of the Enhancement request. Please tell me if I got it wrong.
BTW, I checked about 3 Unix platforms and none of the certificate stores have certificates in them by default (vs Windows behavior). Also, very few stores were supported in the local machine context. But, I agree we should mirror the DotNet Core behavior. I just want to set expectations.
Another thing to consider, is that this CmdLet is provided by Windows, in Windows PowerShell, not PowerShell it self. So, we have to think about how to maintain compatibilty with Windows when implementing.
Thanks for the background. To share more, we're retooling our environments to support x-platform builds and products. Various OSes don't follow the same certificate store model (makes sense) but that makes it hell for end users like ourselves. The hope is that by .NET/Powershell abstracting away the underlying differences, users have a consistent API to work against productively.
Any update on this? Certificate store operations are pretty painful across the platforms supported by powershell/ps core, so having PS abstract this pain away would be great.
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 commented on Nov 16, 2023
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 commented on Nov 16, 2023
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.
Activity
TravisEz13 commentedon Jun 30, 2018
what would this do on Linux? I think we need a little more information.
SidShaytay commentedon Jun 30, 2018
It should import the certificate and private key into specified certificate stores (my, trust/root etc) and locations (local user vs machine). They aren’t fully consistent across OS’s, so I’d suggest mirroring the same model as dotnet’s.
Specifically our use case is to initialize developer platforms and production servers with the right certificates for .net development and production workloads.
TravisEz13 commentedon Jun 30, 2018
So the expectation would be able to use the certificates stored in DotNet Core applications?
SidShaytay commentedon Jul 1, 2018
Yes, powershell initializes the environments, including certificates and private keys in each OS. .NET Apps use these certificates. Development platforms are Windows 10, macOS and Ubuntu. Production platforms are Windows Server and RHEL.
TravisEz13 commentedon Jul 2, 2018
I updated the issue description with my current understanding of the Enhancement request. Please tell me if I got it wrong.
BTW, I checked about 3 Unix platforms and none of the certificate stores have certificates in them by default (vs Windows behavior). Also, very few stores were supported in the local machine context. But, I agree we should mirror the DotNet Core behavior. I just want to set expectations.
Another thing to consider, is that this CmdLet is provided by Windows, in Windows PowerShell, not PowerShell it self. So, we have to think about how to maintain compatibilty with Windows when implementing.
Thanks for the feedback.
SidShaytay commentedon Jul 3, 2018
Thanks for the background. To share more, we're retooling our environments to support x-platform builds and products. Various OSes don't follow the same certificate store model (makes sense) but that makes it hell for end users like ourselves. The hope is that by .NET/Powershell abstracting away the underlying differences, users have a consistent API to work against productively.
SidShaytay commentedon Sep 10, 2019
Any update on this? Certificate store operations are pretty painful across the platforms supported by powershell/ps core, so having PS abstract this pain away would be great.
TravisEz13 commentedon Sep 11, 2019
The request is understood. It's in our backlog, but if we decide to work on it, then it will be moved to a specific milestone.
microsoft-github-policy-service commentedon Nov 16, 2023
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 commentedon Nov 16, 2023
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 commentedon Nov 16, 2023
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 commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.