The following set-up is given:
We are a fairly small branch of a big enterprise sitting on the bottom of a complex WinServer 2012 R2 AD. Therefore we are somehow restricted in our policies.
Our development department has three PowerShell developers who want to use their scripts securely.
We implemented an AD CS to sign our scripts by our own root certificate authority.
The technical steps to implement our certificates are the following:
Create a private key with a public certificate using openssl.
Sign the certificate by our certificate authority.
Import the signed certificate into an AD users account along with the public certificate of the CA into the trusted CAs.
The certificate user "ScriptUser" is not an AD user, therefore we import his certificate into the trusted users area.
Signing and testing:
On the client system (Windows 7 or Windows 10) we tested to sign a
PowerShell script which went ok.
When running the script locally we get an error message that the certificate owner is not trustworthy. After committing the script runs.
We expected the script to run without any dialogue.
What's our fault?
Related
I came with error after creating the certificate ,
This app package’s publisher certificate could not be verified. Contact your system administrator or the app developer to obtain a new app package with verified certificates. The root certificate and all immediate certificates of the signature in the app package must be verified (0x800B010A)
We have an application where we use several PowerShell scripts. We received a complain regarding about they aren't signed and unable to run them if they have the strictest Execution Policy - AllSigned.
I signed with our certificate issued by well-known issuer via signtool as we do it for dlls and exe app but even after that there is an issue if I try running the script I'm getting warning:
Do you want to run software from this untrusted publisher?
It's signed by a certificate issued by know CA (Sectigo). Only how can I get rid of this warning is to add the certificate to Trusted Publishers. It's not good for customers to do those steps (but maybe it's necessary security step). Note: With the same certificate, we sign exe app and it works fine and Windows doesn't complain. (Look like PowerShell policies are stricter.)
Is it possible somehow avoid getting this warning on a customer side without manually adding our certificate into Trusted Publishers? Looks to me that it is not possible.
What I've found out so far:
I've searched across internet and it looks like there is no solution for that. Even if I used PowerShell script signed by Microsoft Corporation I get the same warning unless I add to the Trusted Publishers folder.
Also e.g. HP directly recommends to add the certificate manually to the cert store.
In a documenation about execution policies is written in AllSigned section: Prompts you before running scripts from publishers that you haven't yet classified as trusted or untrusted.
From those all information, I got it as there is no way how to avoid getting this warning on a customer side without adding to the cert store. I want just to assure myself I'm right.
I am developing a desktop application. I can code sign it with .pfx file. I will get that from CA. But what if I want to install it in a different system. Will it reflect there as well? Because I can't share my .pfx file with everyone.
You should not share the *pfx as it contains the private key.
The trust to the signature comes from the trust chain - so when the issuing CA and all intermediate CAs up to the root CA are in the trust store (Windows Trust Store, MAC Key Chain or cacerts.pem for OpenSSL/Java) the signature is trusted as long as
the certificate is not revoked
the signature certificate is not expired or the signature contains a counter signature (RFC3161 timestamp).
in the past, we used VSTS build agents, running with domain accounts on on-prem build machines. In such scenario, certificates could be stored into the domain accounts personal store (manually, by logging in once with this account). So a later build could get the certificates by thumbprint for signing e.g. a manifest.
Now, the agents run with "Network Service", because we no longer have a local domain (all moved to Azure AD). All works, except the retrieval of certificates from the store. I already used the mmc snap-in to connect to the service (VSTSAgent), and installed certificates to this personal store, but still the build fails with "Error MSB3323: Unable to find manifest signing certificate in the certificate store.".
If I log-on to the machine and run from within VS, all works well, but of course here I am using a different account (with a different personal store), but this at least tells me that solution & projects are fine. And the pipelines are OK as well, because they still work OK on the "old" build-machines that use a domain account.
So, if anyone has an idea or can point me to some information on how to use the VSTSAgent running as "Network Service" together with signing (from the certificate store), that highly appreciated.
Many thanks, Sebastian
We have Windows Server 2012 R2 with installed Certification Authority role.
There we have certificate templates.
I want to get certificate from this server of specific template into specific container automatically by autoenrollment.
Now I automatically get certificate into personal store by group policy and autoenrollment.
But I want to get certificate into the specific store (for example, custom SCCM or SMS) automatically by autoenrollment.