I get this error when browsing for a Subordinate CA certificate. Here's where I'm at: Stand Alone Offline Root CA installedRoot CA cert in trusted authorities on subordinate CAInstalled ADCS on subordinate using EnterpriseGenerated a .req file for the offline rootSubmitted request to offline root and extracted cert to USB driveInserted USB drive to subordinate CA and attempted to start ADCS in where it prompted me for the certI browsed to the USB drive with the cert and I get the error "The certificate is not a CA certificate" followed by an error "The data is invalid. 0x8007000d (WIN32: 13) Any ideas?

Hi, Just checking in to see if the information provided by Vadims was helpful. Please let us know if you would like further assistance. Have a great day! Regards Kevin TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.

Hi, As this thread has been quiet for a while, we will mark it as Answered as the information provided should be helpful. If you need further help, please feel free to reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish. BTW, wed love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems. Thanks for your understanding and efforts. Best Regards Kevin TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.

> The "Basic Constraints" field is missing from the cert generated from the root CA if basic constraints extension is missing then it is considered as non-CA certificate. You should fix this issue. > After migrating to a offline root, how is this CRL to be accessed if the root isn't domain joined? you have to reconfigure CDP and AIA extensions as follows: 1) file publication URLs must point to local drives 2) file retrieval (which are included in issued certificates) must point to a internally and (if necessary) externally accessible server (web server). each time a new CRL is issued you will have to manually transfer the file from offline CA to respective location (folder on a web server). My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Where do I start for fixing the basic constraints issue? Not sure why that'd be missing from the request. This is a base install in my test environment and I've duplicated the issue twice now. Don't mean to get off topic here, but I'm migrating from an Enterprise Root CA to a Stand Alone Offline root. Our current CRL location is in LDAP. If I migrate and that location can't be reached by the CA we're going to have problems. Do I need to modify my current CRL locations and reissue certs prior to migrating? Thanks again!

1) please, run the command: certutil path\carequestfile.req and paste here only certificate extension information. 2) > If I migrate and that location can't be reached by the CA we're going to have problems. then you will have to publish CRLs to LDAP manually. > Do I need to modify my current CRL locations and reissue certs prior to migrating? it is recommended (especially if you have web server) to use only HTTP links, instead of LDAP. This is because HTTP links can be reachable for non-domain clients.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Certificate Extensions: 5 1.3.6.1.4.1.311.21.1: Flags = 0, Length = 3 CA Version V0.0 2.5.29.14: Flags = 0, Length = 16 Subject Key Identifier ea 48 83 d0 aa 29 79 a9 2f 51 3a 42 d6 a4 c2 25 d2 48 64 fd 1.3.6.1.4.1.311.20.2: Flags = 0, Length = c Certificate Template Name (Certificate Type) SubCA 2.5.29.15: Flags = 1(Critical), Length = 4 Key Usage Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86) 2.5.29.19: Flags = 1(Critical), Length = 5 Basic Constraints Subject Type=CA Path Length Constraint=None Thanks for the help! I'll publish a new http CRL location, and remove the LDAP one prior to migrating and reissue all certs.

Request extensions looks correct. Now, can you get the following information from your root CA server (I assume you are using Windows CA): certutil -getreg policy\EnableRequestExtensionListcertutil -getreg policy\DisableExtensionList My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EnableRequestExtensionList: EnableRequestExtensionList REG_MULTI_SZ = 0: 1.2.840.113549.1.9.15 SMIME Capabilities 1: 1.3.6.1.4.1.311.21.1 CA Version 2: 1.3.6.1.4.1.311.21.2 Previous CA Certificate Hash 3: 2.5.29.15 Key Usage HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\DisableExtensionList: DisableExtensionList REG_MULTI_SZ =

on root CA server run the following commands: certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.19" net stop certsvc && net start certsvc and resubmit the request.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Problem persists.

Problem persists. did you restarted the certificate services after running the certutil -setreg command? Can you show again your settings: certutil -getreg policy\EnableRequestExtensionList and what is your root CA version and type?My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

This is the full output or stripped?My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Full output.

it is very odd. Somehow, old entries were replaced. Ok, try to add other required values as follows: certutil -setreg Policy\EnableRequestExtensionList +"1.2.840.113549.1.9.15" certutil -setreg Policy\EnableRequestExtensionList +"1.3.6.1.4.1.311.21.1" certutil -setreg Policy\EnableRequestExtensionList +"1.3.6.1.4.1.311.21.2" certutil -setreg Policy\EnableRequestExtensionList +"2.5.29.15" restart certificate services and show again the full output of the 'certutil -getreg policy\EnableRequestExtensionList' command.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Problem persists. Here's the output. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EnableRequestExtensionList: EnableRequestExtensionList REG_MULTI_SZ = 0: 2.5.29.19 Basic Constraints 1: 1.2.840.113549.1.9.15 SMIME Capabilities 2: 1.3.6.1.4.1.311.21.1 CA Version 3: 1.3.6.1.4.1.311.21.2 Previous CA Certificate Hash 4: 2.5.29.15 Key Usage

Ok, can you show the output of the following command: certutil -getreg policy\editflags My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CA\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags: EditFlags REG_DWORD = 11014e (1114446) EDITF_REQUESTEXTENSIONLIST -- 2 EDITF_DISABLEEXTENSIONLIST -- 4 EDITF_ADDOLDKEYUSAGE -- 8 EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64) EDITF_ENABLEAKIKEYID -- 100 (256) EDITF_ENABLEDEFAULTSMIME -- 10000 (65536) EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)

You are amazing. I apologize that I left that out, I hope I didn't waist too much of your time. I didn't realize that was required information. The subordinate installed the cert and started fine. I did get an error of the CRL being offline, but I think that's because I hadn't set up the http location prior to issuing the cert. (It's still LDAP on the offline root) I'm going to do another migration run through using your command to change the edit flags and see if I can get this done with no errors. Then it'll be time for production. Just out of curiosity, why is that setting required? What does it do? You've helped me in the past with my cert issues, and really appreciate the assistance.

> I didn't realize that was required information. Standalone CA and Enterprise CA has slightly different settings (not only within policy module) and migration from Enterprise CA to Standlone CA (and vice versa) requires additional reconfiguration which is not well described in official (and non-official) documents and in most cases such migrations are completed incorrectly. > Just out of curiosity, why is that setting required? What does it do? Enterprise CA ignores Basic Constraints extension with CA qualifier but allows basic constraints appearance with end-entity qualifier. This is because, the requester must use one of the available default templates: RootCA, SubCA or CrossCA. This extension is populated from the template settings regardless of what contains certificate request. Standalone CA (unlike Enterprise CA) does not use certificate templates and completely relies on request information and should allow any type of basic constratins extension. This setting is configured through policy module and EDITF_BASICCONSTRAINTSCA (0x00000080) flag which is enabled only on Stanalone CAs. For further information, the following default policy module flags for Standalone CA are: EDITF_REQUESTEXTENSIONLIST 0x00000002 EDITF_DISABLEEXTENSIONLIST 0x00000004 EDITF_ADDOLDKEYUSAGE 0x00000008 EDITF_ATTRIBUTEENDDATE 0x00000020 EDITF_BASICCONSTRAINTSCRITICAL 0x00000040 EDITF_BASICCONSTRAINTSCA 0x00000080 EDITF_ENABLEAKIKEYID 0x00000100 EDITF_ATTRIBUTECA 0x00000200 EDITF_ATTRIBUTEEKU 0x00008000 and for Enterprise CA: EDITF_REQUESTEXTENSIONLIST 0x00000002 EDITF_DISABLEEXTENSIONLIST 0x00000004 EDITF_ADDOLDKEYUSAGE 0x00000008 EDITF_BASICCONSTRAINTSCRITICAL 0x00000040 EDITF_ENABLEAKIKEYID 0x00000100 EDITF_ENABLEDEFAULTSMIME 0x00010000 EDITF_ENABLECHASECLIENTDC 0x00100000 HTHMy weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki