Forum Discussion
Import certificate with automatic store affectation
So, it's not actually the system (i.e. Windows) that looks at the certificate and makes a decision on where to place it. It's the MMC - or more correctly the snap-in, which is just a .dll "program" - that contains that logic.
With respect to the "how", that snap-in will look at various fields such as the key and enhanced key usages (sample provided below from a root authority) and make a "best guess" at where the certificate should possibly go.
But this is still a guess and why it provides the user with the ability to manually specify where the certificate should go, which recognises the fact that its own logic can definitely get it wrong.
This MMC snap-in is analogous to you writing your own script - i.e. the final point I made above. You can go to great lengths to try and reproduce what that snap-in does using PowerShell but it would only ever be to varying degrees of success.
So, there's nothing automatic about the placement. As I said earlier, any certificate can be placed in any store. It's just the Certificates "program" has some logic in it to make educated guesses, while the PowerShell PKI module commandlets does not (again, you'd have to do that coding yourself.)
Cheers,
Lain
Hi.
This isn't really about PowerShell but certificates.
Any certificate can live in any store - there's no such thing as alignment.
For example, I often see people "incorrectly" dumping full certificate chains in their "personal" store when conceptually, only the leaf certificate should go in there. But mechanically, every certificate is the same thing (or class, in technical parlance) which is why there is no such thing as alignment.
It falls to the user to correctly place the certificate in the appropriate store.
So, in short: no, there is no way for Import-Certificate to magically know where a certificate should be placed, which is why you need to specify a location using the "CertStoreLocation" parameter (or use the "cert:" drive.)
You could write your own script to place certificates with particular key usages into particular stores, but that's just as likely to result in incorrect placements as correct placements given how common some key usages are. i.e. it might make sense for a well-defined process but be useless as a generic script.
Cheers,
Lain
Thank you for your answer and sorry for the bad location of this topic.
If I understand your answer correctly, everytime a certificate is imported, the user (or admin) has to manually choose into which store to import it. All certificate object instances are generate from the same class.
So now, how do you explain that if you use the Windows Certificate Import Wizard, there is an option saying "Automatically select the certificate store based on the type of the certificate" ?
I understand that the system can somehow identify the certificate (type?) automatically and import it into the correct store without the need of the user (or admin) to choose it manually. And it's actually working well, as my certificates that are meant to be imported into the "Trusted Root Certification Authorities" are imported exactly into this store (the same happens for my certs who need to be imported into the "Intermediate Certification Authorities store").
How do you explain this ?
For this reason, I was assuming that doing an import with the Import-Certificate cmdlet would have an "auto" value for the parameter "-CertStoreLocation" to behave the same way as the graphical wizard can do.
So, it's not actually the system (i.e. Windows) that looks at the certificate and makes a decision on where to place it. It's the MMC - or more correctly the snap-in, which is just a .dll "program" - that contains that logic.
With respect to the "how", that snap-in will look at various fields such as the key and enhanced key usages (sample provided below from a root authority) and make a "best guess" at where the certificate should possibly go.
But this is still a guess and why it provides the user with the ability to manually specify where the certificate should go, which recognises the fact that its own logic can definitely get it wrong.
This MMC snap-in is analogous to you writing your own script - i.e. the final point I made above. You can go to great lengths to try and reproduce what that snap-in does using PowerShell but it would only ever be to varying degrees of success.
So, there's nothing automatic about the placement. As I said earlier, any certificate can be placed in any store. It's just the Certificates "program" has some logic in it to make educated guesses, while the PowerShell PKI module commandlets does not (again, you'd have to do that coding yourself.)
Cheers,
Lain
Thank you very much for your answers and the details provided. I understand better the behavior differences now.
I will find a way to import the certificates into the right store, by adding for examples, some extra properties in my custom certificate object (like "Store").
Cheers !