Self-signed certificates limited to a host? - powershell

I am generating self-signed .pfx certificates for a java application running on a couple of Windows servers. These certificates will be imported into their respective java keystores.
My question is: Can I generate a self-signed certificates for server2, server3 and server4 on server1? Is there anything in a certificate, apart from the dns name, that would bind it to the machine on which it was generated?
My concern is that if I generate the certificate for server2 on server1, the certificate will still be somehow bound to server 1 only.
I am using the following powershell script to generate the certificates:
$cert = New-SelfSignedCertificate -keyfriendlyname server1 -certstorelocation cert:\localmachine\my -dnsname server1.mydomain.com
Export-PfxCertificate -cert ‘cert:\localMachine\my\’ -FilePath C:\Certificates\server1.pfx -Password dummypassword
My idea was to simplify the process of generating the certificates by running the script on a single server and just altering the dnsname, alias and file name for each certificate.

You can generate a certificate on any machine for any machine, just set the common name correctly (certificate's CN field).
See parameter -Subject of the PowerShell command
Note that moving private keys around is a bad practice, you should instead generate the key-pair on the same machine that it is to be used by.

Related

certutil not importing all certs

p12 file with 7 certificates in it.
Following the instruction that came along with the cert file, we have to use MMC and a password to import all certs into a personal store.Instruction also says to check mark private key exportable.
in order to automate this, I tried using certutil -importpfx but that only added 4 out of 7 certificates. I am unable to see other 3 certs. The diff i noticed is the imported certs are the ones with "ext issuing CA" and missing certs are with "issuing CA" in the Subject .
Any pointers please
I found an alternate solution using powershell instead of certutil .
Import-pfx with flag -exportable imported all the certs.
Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\My -Password $Securepwd -FilePath $findP12Cert.FullName -Exportable -Verbose

Installing a .pfx Cert in TrustedRootCA WITH private key from command line in powershell on win7

My question is this: how would I go about installing a .pfx cert into TrustedRootCA with its private key from command line using powershell in windows 7?
I've got it to install the cert using this command: certutil -importpfx -p "mypasswordhere" "cert path location here"
The above installs it to the personal store of the local computer fine (With the private key intact) And also installs it to TRCA, only without the private key. This is my issue as the program requires the TRCA to have the private key.
but when I try to use the program that needs the cert it says : "It is likely that "My cert" may not have a private key that is capable of key exchange or the process may not have axxess rights for the private key. Please see inner exception for more detail.
However, I checked the TRCA store and verfied that my cert indeed does not have its private key.
So again my question is there anyway using powershell to automate this process on windows 7? Thanks in advance.
You can use the command
Import-PfxCertificate -FilePath C:\setup\TestCertImport.pfx -CertStoreLocation 'Cert:\LocalMachine\Root'
Root = Trusted root,
My = Local Machine Personal certificate folder
if the certificate has password you can add the -Password parameter and if you want it to be exportable the -Exportable

Certificate imported to trusted root is placed under Intermediate CA

I try to import certificate in powershell as the following
Import-PfxCertificate -FilePath "$certFolder\$certFile" -CertStoreLocation Cert:\LocalMachine\Root -Password $securedPassword
The command run without any errors but the certificate is placed under Intermediate CAs with the information that CA root is not trusted.
When I import the same certificate manually with the option checked "Automatically select the certificate store..." it is placed properly under the Trusted CAs.
What do I miss while importing the certificate automatically?

Can't Bind Certificate to SSL When Imported using .NET API

I've created a self-signed SSL certificate using openssl. When I import the certificate using the .NET APIs, I can't bind it to my website with netsh. I'm importing the certificate with PowerShell:
$Certificate = New-Object 'security.Cryptography.X509Certificates.X509Certificate2' $PathToCertificate
$keyFlags = [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::MachineKeySet
$keyFlags = $keyFlags -bor [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::PersistKeySet
$keyFlags = $keyFlags -bor [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable
$store = New-Object 'Security.Cryptography.X509Certificates.X509Store' 'My','LocalComputer'
$store.Open( 'ReadWrite' )
$store.Remove( $Certificate )
$store.Add( $Certificate )
$store.Close()
I then use netsh to bind to the certificate:
netsh http add sslcert ipport=0.0.0.0:443 certhash=<thumbprint> appid=<app ID>
Which succeeds the first time run, but fails on subsequent attempt with this error:
SSL Certificate add failed, Error: 1312
A specified logon session does not exist. It may already have been terminated.
However, when I import the certificate manually through the Certificates MMC/snap-in, I never have any problems running the netsh command.
I'm seeing this error on some of our Windows 7 and Windows 2012 R2 computers. Strangely, more than half our computers don't have this problem. Am I adding the cert incorrectly? Could I have generated a bad certificate?
I lied. Looks like I thought I was setting the key storage flags in the code above. Turns out I was loading the certificate in a different part of our script, and it wasn't specifying the correct key storage flags. After correcting my script so it actually does what I claimed it did, everything works.

How to trust a certificate in Windows Powershell

I am using Windows 7, and want to run signed scripts from Powershell, the security-settings of Powershell are set to "all-signed", and my scripts are signed with a valid certificate from my company. I have also added the .pfx-file to my local certificate store (right-clicked the pfx-file and installed).
However, when I start a signed script, I get a message that says:
"Do you want to run software from this untrusted publisher?
File Z:\Powershell Signed Scripts\signed.ps1 is published by CN=[MyCompanyName] and is not trusted on your system. Only run scripts from
trusted publishers.
[V] Never run [D] Do not run [R] Run once [A] Always run [?] Help
(default is "D"):"
Since I want to automatically call these scripts on my systems, I would like to add my imported certificate to the trusted list on my system, so that I do not get a message anymore when I run a signed script for the first time. How can I make my certificate a trusted one?
How to trust a certificate in Windows Powershell
Indeed, you can do this without any mmc :)
First, check the location of your personal certificate named for example "Power" :
Get-ChildItem -Recurse cert:\CurrentUser\ |where {$_ -Match "Power"} | Select PSParentPath,Subject,Issuer,HasPrivateKey |ft -AutoSize
(This one should be empty:)
gci cert:\CurrentUser\TrustedPublisher
Build the command with the path to your certificate:
$cert = Get-ChildItem Certificate::CurrentUser\My\ABLALAH
Next work on certificate store (Here I work on two certificate store : user & computer)
$store = New-Object System.Security.Cryptography.X509Certificates.X509Store "TrustedPublisher","LocalMachine"
$store.Open("ReadWrite")
$store.Add($cert)
$store.Close()
Check, you should find your certificate :
ls cert:\CurrentUser\TrustedPublisher
Sounds like you need to verify that the script is signed properly and that you have the correct certificate installed in the correct certificate store.
Use the Get-AuthenticodeSignature cmdlet to get information about the signed script.
Also review Scott's guide for signing certificates.