Is it possible to create self-signed root CA certificate that Windows will import to Trusted Root by default instead of Intemediate certificate store ? Obviously, it won't do it without the big giant nag window asking if you're really sure - but it would be nice to not have to go the extra step of specifying which certificate store it goes in.

Currently, both our root CA and intermediate certificates by default (if you just right click > install) go into the intermediate certificate store. If I tell it to install to trusted root store for the root cert, then everything works as expected (trust chain etc). However, ideally we shouldn't have to set this and instead have it assume it should go there (it would still display the are-you-sure dialog). Is this possible?

We have built (and are still fine tuning) a CA using phpseclib. As an example here is a root CA I generated (with sanitized details):


Are we doing something wrong, setting or not setting an extension? Perhaps it needs to be in pfx or other format instead of PEM? Or will Windows always default to intermediate, and nothing to be done about it?

2 Answers 2


Windows applies some not-really-documented heuristics to know where your certificate should go. Apparently, these heuristics have changed: when I import your certificate on a Windows XP system, it defaults to the root store (with the big warning), but when I try on a Windows 2008R2 system, it goes to the intermediate CA store.

One way to side-step the issue is that root CA are very sensitive objects, and should not be imported "automatically". A rogue root CA can be used to deal considerable damage on the victim and I am not sure a single popup is really enough as a protection measure. The popup is not even red and scary-looking; it is more like a boring wall of text:

Warning popup for a new root CA

It is like license agreements: who really reads them, honestly ?

Under these conditions, I cannot really blame Microsoft for directing by default certificate imports to an intermediate CA store.

Now for your specific question, if I were to hazard a guess about what makes some Windows versions consider your certificate as "probably not a root CA", I would point at the short lifetime. Root CA certificates usually last longer than one year. I suggest trying to make that certificate valid for 20 years or so. This may or may not solve your problem, but if it does, so much the better.

Note: a certificate which is both self-issued (subject DN and issuer DN are equal) and self-signed is not necessarily a root; as per X.509, a CA may emit such things if it wants to handle a smooth transition when trying to change some characteristic in its certificate. The path validation algorithm includes a lot of provisions for such self-issued intermediate CA certificates.

  • Thanks for the detailed analysis. I will try various lifetimes and see if that has any effect, and report back. The whole project was back-burnered for awhile do to the usual IT stuff, only just now had a chance to check if anyone had any insight.
    – jvaughn
    Sep 18, 2013 at 23:15
  • Well, increasing the years hasn't worked thus far, have gone up to 25 year lifetime.
    – jvaughn
    Sep 18, 2013 at 23:49
  • I tried saving out an unsigned cert (since what you said about being self signed not necessarily a root, made it sound like from phrasing that a root can also be unsigned?) but at least with phpseclib that didn't work at all (emitted zero length X509 output). So, I guess TL;DR: This can't be done, at least with phpseclib.
    – jvaughn
    Sep 20, 2013 at 21:09

There is no way to control Windows certificate heuristics, but you can still make it a one-step operation.

You can distribute a script that does it. Note that this must be run by an administrator since the machine's root store cannot be modified by unprivileged users. Assuming the certificates are on a network share, you could use:

certutil -addstore Root \\path\to\rootcertificate.cer
certutil -addstore Intermediate \\path\to\intermediatecertificate.cer

Alternatively, I believe a non-administrator can install the certificate just for himself with the "-user" option, e.g.:

certutil -user -addstore Root \\path\to\certificatefile.cer

If you have a domain, it is far easier to distribute certificates to the appropriate stores via Group Policy. This makes it automatic upon joining the domain, so there is no action required on the client.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .