Forum Discussion

vdrjrmylair's avatar
vdrjrmylair
Copper Contributor
Apr 04, 2023
Solved

Import certificate with automatic store affectation

Hi,

I would like to know if there is a way to import certificates to the local computer store without specifying the store location using the Import-Certificate cmdlet ?

What I want

I want that the certificate automatically save itself in the right store based on his type. We can have this behavior if we use the Windows certificate import wizard, where we can let the assistant choose automatically the right store based on the certificate's type.

What I have tried

I used the Import-Certificate cmdlet however I did not find a way to achieve this, as I have to specifiy the -CertStoreLocation parameter. This parameter is not mandatory but if I specifiy nothing, the certificate is imported into the current location path.

 

  • vdrjrmylair 

     

    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

4 Replies

  • LainRobertson's avatar
    LainRobertson
    Silver Contributor

    vdrjrmylair 

     

    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

    • vdrjrmylair's avatar
      vdrjrmylair
      Copper Contributor

      Hi LainRobertson 


      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.

      • LainRobertson's avatar
        LainRobertson
        Silver Contributor

        vdrjrmylair 

         

        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

Resources