windows - Does anybody know how the powershell certificate provider paths map to certmgr.msc folders? -

when using powershell investigate certificate provider noticed paths seem similar not same folder structure within certmgr. seems pretty clear that:

certs:\localmachine ~= certificates (local computer) certs:\currentuser ~= certificates - current user 

i'm guessing that:

root ~= trusted root certification authority ~= personal webhosting ~= webhosting ... 

but have been unable find sort of official reference (or sensible explanation) give me warm fuzzy i'm looking for...

my intent test https wcf service locally (both server , client side). can generate self signed certificate needed server using new-selfsignedcertificate. however, if try point client (also .net) @ service fails connect given service serves non-trusted certificate.

i have found various out-dated references (like this one), showing how use combination of makecert (now deprecated), , certmgr generate certificate authority, use sign cert https service, install certificate authority cert trusted root certification authority container working. while approach work, not developer/automation friendly.

that said, able use powershell this:

$my_cert_store_location = "cert:\localmachine\my" $root_cert_store_location = "cert:\localmachine\root" $root_friendly_name = "test root authority" $root_cert_subject = "cn=$($root_friendly_name)" # ip , port want reserve app $ipport = "127.0.0.11:8734" # app guid (found in applicationinfo.cs) $appid = "{f77c65bd-d592-4a7b-ae32-cab24130fdf6}" # dns name $dns_name = "my-machine-local" $rebuild_root_cert = $false  $root_cert = get-childitem $my_cert_store_location |      where-object {$_.subjectname.name.equals($root_cert_subject)} if ($root_cert -and $rebuild_root_cert)  {     get-childitem $root_cert_store_location |         where-object {$_.subjectname.name.equals($root_cert_subject)} |         remove-item      remove-item $root_cert     $root_cert = $false } if (-not $root_cert)  {     $root_cert = new-selfsignedcertificate `         -type custom `         -friendlyname $root_friendly_name `         -hashalgorithm sha384 `         -keyalgorithm rsa `         -keylength 4096 `         -subject $root_cert_subject `         -keyusage digitalsignature, certsign `         -notafter (get-date).addyears(20) `         -certstorelocation $my_cert_store_location     write-output "created root cert: $($root_cert.thumbprint)"      $exported_cert = new-temporaryfile     export-certificate -cert $root_cert -filepath $exported_cert.fullname     $imported_root_cert = import-certificate -filepath $exported_cert.fullname `         -certstorelocation $root_cert_store_location     write-output "imported root cert to: $($root_cert_store_location)\$($imported_root_cert.thumbprint)" }  write-output "root cert is: $($root_cert.thumbprint)"  $test_signed_cert_subject = "cn=$($dns_name)" $test_signed_cert = get-childitem $my_cert_store_location |      where-object {$_.subjectname.name.equals($test_signed_cert_subject)} if (-not $test_signed_cert) {     $test_signed_cert = new-selfsignedcertificate `         -type custom `         -subject $test_signed_cert_subject `         -friendlyname $dns_name `         -signer $root_cert `         -certstorelocation $my_cert_store_location     write-output "created signed cert: $($test_signed_cert.thumbprint)" }  write-output "signed cert is: $($test_signed_cert.thumbprint)"  if ($test_signed_cert) {     netsh http delete sslcert `         ipport="$($ipport)"     netsh http add sslcert `         ipport="$($ipport)" `         appid="$($appid)" `         certstorename="my" `         certhash="$($test_signed_cert.thumbprint)"     write-output "assigned signed cert to: $($ipport)" } 

but question still stands... there information how certificate provider paths map certmgr folders?

here mapping between containers (in parentheses) , description:

• personal (my) — container used store certificates private keys. when certificate private key used, application looks container find appropriate certificate , associated private key.
• trusted root certification authorities (root) — container contains trusted, self-signed certificates without private keys. each certificate chain must chain certificate presented in self-signed form. self-signed certificate ‘root certificate’ or ‘trusted anchor.’ however, not root certificates can considered trusted. should choose new certificates consider trusted.
• enterprise trust (trust) — container used store certificate trust lists (ctl). example, key management server adds certificate container.
• intermediate certification authorities (ca) — container keeps many different types of ca certificates. these certificates used certificate chaining engine build certificate chains.
• trusted publishers (trustedpublisher) — container keeps explicitly trusted signing certificates. while digital signature certificate chains trusted root certification authority, many applications (such microsoft office , windows powershell) required store particular signing certificate in container in order trust signatures particular signer. means digital signature-aware application can trust 1 signing certificate not trust signing certificate if both certificates issued same certification authority.
• untrusted certificates (disallowed) — container keeps explicitly untrusted certificates. if decide not trust either particular certificate or certificates issued particular certification authority, add these certificates container. default, container contains 2 certificates. recommended not remove them container. additional info read following article: http://support.microsoft.com/kb/293817.
• third-party root certification authorities (authroot) — certificate container similar trusted root certification authorities. keeps certificates microsoft root certificate program. more information microsoft root certificate program, read following article: http://support.microsoft.com/kb/931125.
• trusted people (trustedpeople) — container keeps certificates issued people or end entities explicitly trusted. often, these self-signed certificates or certificates explicitly trusted in application such microsoft outlook. share efs–encrypted file other parties, must have certificate in store.
• certificate enrollment requests (request) — container stores certificate enrollment requests until these requests submitted certification authority. when certification authority issues certificate in response request, need install certificate container using special utility, such certreq.exe. after that, certificate enrollment request transferred personal (my) container certificate.
• smart card trusted roots (smartcardroot) — container used store trusted smart card certificates.
• other people (addressbook) — container maintains certificates have been added outlook contact.
• active directory user object (userdds) — container used store certificates associated user object , published in active directory. content of container equal certificates shown in advanced view of active directory users , computers console when properties of user object viewed.