See Stack Overflow question Export certificate from IIS using PowerShell.
If the answer works for you, then you can run PowerShell code on remote server using PSRemoting
(Enter-PSSession or Invoke-Command) or psexec.
Does anyone know how to dir the cert store like, "dir
cert:\localmachine\my | Where-Object { $_.hasPrivateKey } | " AND then
feed that to the certutil export with the thumbprint?
Try this, works for me:
Get-ChildItem -Path 'Cert:\localmachine\My' |
Where-Object { $_.hasPrivateKey } |
Foreach-Object {
&certutil.exe @('-exportpfx', '-p', 'secret', $_.Thumbprint, "$($_.Subject).pfx")
}
Beware, that sometimes you wouldn't be able to use Subject
as file name, due to invalid foreign-language characters in the Unicode.
In this section we will generate a master CA certificate/key, a server certificate/key certificate and key which is used to sign each of the server and client certificates.
That... I'm guessing that's just the result of copy&paste accidentally mashing two different paragraphs together. It should be like this:
"In this section we will generate a master CA certificate/key which is used to sign each of the server and client certificates."
Why does the certificate Authority have keys in the first place? I thought the job of the Certificate Authority was to sign keys on servers and clients.
Well, yes, and that's exactly what the keys are for – all common types of digital signatures require a keypair. TLS clients & servers use their keys to sign the connection "handshake" data, while CAs use their keys to sign the issued certificates.
Is this private key with people referring to when they talk about master keys or root certificates. And are these root certificates the same thing as private keys?
Close, but no. Certificates only hold the public half of the keypair, along with some extra information (owner name, issuer name and signature, &c.). So they are never the same thing as private keys, but they do always come in matching pairs.
If someone signs a file with their private key, you can verify the signature against the public key stored in their certificate. For example, all issued certs are signed by the CA's private key, and verified against the CA's certificate.
(The CA's own certificate is signed by itself, but there's no point in actually verifying it, since it was explicitly configured as a trusted root.)
So in the end, all the terms you listed refer to the same thing – your new CA has one keypair (a private key and a matching certificate), and uses it to sign all issued certs.
Best Answer
The keys are stored via Microsoft's Cryptography API: Next Generation (CNG).
Storage locations:
%APPDATA%\Microsoft\Crypto\Keys
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\SystemKeys
%WINDIR%\ServiceProfiles\LocalService
%WINDIR%\ServiceProfiles\NetworkService
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\Keys
Description:
Note: