none
CertUtil -delkey CAName fails

    Question

  • Hey all...

    Following this guide when I get to step 4 I get this:

    C:\Users\admin>certutil
    Entry 0: (Local)
      Name:                         `Corp-Root-CA'
      Organizational Unit:          `'
      Organization:                 `'
      Locality:                     `'
      State:                        `'
      Country/region:               `'
      Config:                       `CA-Root.corp.ca\Corp-Root-CA'
      Exchange Certificate:         `'
      Signature Certificate:        `CA-Root.corp.ca_Corp-Root-CA.crt'
      Description:                  `'
      Server:                       `CA-Root.corp.ca'
      Authority:                    `Corp-Root-CA'
      Sanitized Name:               `Corp-Root-CA'
      Short Name:                   `Corp-Root-CA'
      Sanitized Short Name:         `Corp-Root-CA'
      Flags:                        `13'
      Web Enrollment Servers:       `'

    C:\Users\admin>certutil -delkey `Corp-Root-CA'
    CertUtil: -delkey command FAILED: 0x80090016 (-2146893802 NTE_BAD_KEYSET)
    CertUtil: Keyset does not exist

    C:\Users\admin>certutil -delkey Corp-Root-CA
    CertUtil: -delkey command FAILED: 0x80090016 (-2146893802 NTE_BAD_KEYSET)
    CertUtil: Keyset does not exist

    C:\Users\admin>certutil -delkey "Corp-Root-CA"
    CertUtil: -delkey command FAILED: 0x80090016 (-2146893802 NTE_BAD_KEYSET)
    CertUtil: Keyset does not exist

    What am I missing, logged in as Enterprise Admin, Domain Admin, Schema Admin, elevated CMD.... I don't get what I'm doing wrong?

    Monday, January 29, 2018 9:02 PM

Answers

  • Ok, so what you are missing is the argument to tell delkey that this is a KSP provider. So the command would be:

    certutil -csp ksp -delkey "Corp-Sub-CA"


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com


    • Edited by Mark B. Cooper Thursday, February 1, 2018 8:54 PM
    • Marked as answer by Zewwy Thursday, February 1, 2018 9:06 PM
    Thursday, February 1, 2018 8:53 PM

All replies

  • Hi,
    The error message indicated “Keyset does not exist”, I suspect CA’s private key might be deleted or damaged. To verify this, please run the commands: certutil -key to see if private key is listed, if not, we can ignore the above error and go head to process the next operation.
    If private key do exist, please continue to run the commands: certutil –delkey le-DomainController-a5dd9dd0-a654-466e-bf20-999fc219a0c7 to delete the private key associated with the CA and check if it helps.

    Best regards, 
    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, January 30, 2018 6:15 AM
    Moderator
  • Thanks for the reply Wendy, I kinda figured that was the case, I just didn't understand how that could have happened.. Maybe I didn't generate one?

    Sure is odd, I did have 9 issued certificates that I did revoke, from what I can tell there was only about one or two that were actually created by me, and I could tell they were not in use for anything other than an old Proof of Concept. 

    Also I did run that command but I guess I was in the same boat as this guy

    So this was a Server 2016 Core server, and I ran Install-AdcsCertifcationAuthority. That at least what I had in my documentation. (Probably the lamest documentation I've ever done and good reason why I'm redoing this haha.) Anyway, I could connect to the CA fine with the CA MMC snap-in. I could see the cert listed under the CA properties. If I loaded the Certificates snap-in under the computer account and pointed it at the CA server, I would see the self-signed Root-CA certificate in the personal store with the little yellow golden Key saying I have the key associated with the certificate. Yet, I found the %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys to be empty.

    My question is if you set-up a CA this way, is this common?

    Also, when I run CertUtil -key I get:

    C:\ProgramData\Microsoft\Crypto\RSA>certutil -key
    Microsoft Strong Cryptographic Provider:
      TSSecKeySet1
      f686aace6942fb7f7ceb456778eef4a4_ae50584c-54c3-4b6f-8b60-f9f8471c0525
      RSA
        AT_KEYEXCHANGE

    CertUtil: -key command completed successfully.

    I still get this even after running Uninstall-AdcsCertificationAuthority

    OH ALSO

    I found this... 

    So even though the Certificates Snap-in said I had the Key for the Primary Root-CA Cert, I took the Serial number of it and ran CertUtil -repairstore my "serialnumber" and it said it worked successfully, but attempting to run the CertUtil -delkey was still failing on me.

    So figuring I don't need the key for anything cause I really don't, moving forward with the removal. I noticed the MS guide states that "the CA Database, as well as existing certs remain, as well as the CRL" Certs and CRL I guess make sense, but what about this database? There's no reference of what this database contains or where you can locate it and clear it. 

    My goal here was to renew it to be a subordinate Enterprise CA with a whole new Cert Chain, granted by an off-line Standalone Root-CA. I always could build the server from scratch and simply clear out the AD objects, but figured it be good practice to know whats going on "under the hood". To do a clean-up manually. 

    Anyway moving away from this, I decided to keep up with the AD object cleanup. The Sites n Services (services node) part was super easy and straight forward.... till they came across the ldiffde commands for verification.

    Step 12, part B says, change "changetype: add" to "changetype: delete". If you do ONLY this the next command will fail...

    C:\Users\admin>ldifde -i -f output.ldf
    Connecting to "DC1.domain.ca"
    Logging in as current user using SSPI
    Importing directory from file "output.ldf"
    Loading entries.
    There is a syntax error in the input file
    Failed on line 3.  The last token starts with 'd'.
    0 entries modified successfully.
    An error has occurred in the program
    No log files were written.  In order to generate a log file, please
    specify the log file path via the -j option.

    I googled this and came across some interesting answers about changing unicode to UTF8 and what not. Which were all still failing for me with different "last token starts" fields. Till I found this.

    The interesting part is noting that there are no other lines beyond the delete line. So I followed suit and deleted all the additional information that was provided from the initial commands output file and changed to delete. It then finally succeeded...

    C:\Users\admin>ldifde -i -f output.ldf
    Connecting to "DC1.domain.ca"
    Logging in as current user using SSPI
    Importing directory from file "output.ldf"
    Loading entries..
    1 entry modified successfully.
    C:\Users\admin>ldifde -r "cn=Corp-Root-CA" -d "CN=Public Key Services,CN=Services,CN=Configuration,DC=DOMAIN,DC=CA" -f output.ldf
    Connecting to "DC1.domain.ca"
    Logging in as current user using SSPI
    Exporting directory to file output.ldf
    Searching for entries...
    Writing out entries
    No Entries found

    Which showed to have worked. It be nice if the source documentation provided screen shots of of outputs and altered files to compare against, so we have a better indication if we are getting the same results.

    Another thing I noted, was that the command:

    certutil -dcinfo deleteBad

    Didn't work for me, i wasn't sure if this was due to the fact I shutdown the CA, and the CRL was not retrievable in alert the DC's that the certs have been revoked and should be cleaned up or not. So instead I simply opened up the Certificates Snap-in as my admin account, selecting computer type, and pointing it to my DC's, then manually removing the certs in the personal stores that were issued by the now removed CA.

    Rerunning the command:

    certutil -dcinfo

    Then returned clean... well returned:

    *** Testing DC[1]: DC1
    ** Enterprise Root Certificates for DC DC1
    No certificates in Enterprise Root store!
    Enterprise Root store: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)
    ** KDC Certificates for DC DC1
    0 KDC certificates for DC1
    No KDC Certificate in MY store
    KDC certificates: Cannot find object or property. 0x80092004 (-2146885628 CRYPT_E_NOT_FOUND)

    So looks like I finally got everything cleaned up. Also The database part is covered under Step 8) The whole guide is really oddly written so I'll more than likely write my own blog post on my findings. Since I'll be creating yet another Test environment from the ground up, I'll see what gets created where during initial deployment of a Enterprise-Root-CA


    • Edited by Zewwy Tuesday, January 30, 2018 5:28 PM
    Tuesday, January 30, 2018 2:09 PM
  • Hi,
    Thanks very much for your detailed sharing! It will be very helpful for other customers who encounter the same issue. 

    For AD database issue, the default database path is:%SystemRoot%\System32\CertLog, the CA database contains a copy of every certificate issued, every certificate that has been revoked, and a copy of failed and pending requests. If a CA is configured for key Archival and Recovery, the CA database will also contain the private keys for any certificates whose templates are configured for archival. Corrupted database would also result in losing all of these archived keys. You may refer the following articles:
    The Case of the Enormous CA Database
    https://blogs.technet.microsoft.com/askds/2010/08/31/the-case-of-the-enormous-ca-database/
    How to move the Certificate Server database and log files
    https://support.microsoft.com/en-us/help/283193/how-to-move-the-certificate-server-database-and-log-files
    Best regards, 
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, January 31, 2018 9:26 AM
    Moderator
  • Thanks for the details on the Database Wendy, much appreciated.

    There was one thing I noticed in the guide I was following to setup a new subordinate CA.

    I decided to complete clear the "C:\Windows\System32\certsrv\CertEnroll" folder, then noticed I accedently also removed the .asp file that was in there, I thought at first there was only an old crt file and the old crl files, but this file was also in there and I deleted it.

    Do you know what this asp file is used for?!

    Wednesday, January 31, 2018 3:33 PM
  • Hi, 
    As far as I know, the file is related to the legacy Netscape (iPlanet) application certificate revocation service, and it just locate in CertEnroll folder no matter if you install Netscape (iPlanet) or not.
    Best regards, 
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, February 1, 2018 8:58 AM
    Moderator
  • Wow interesting... thanks for that info too.

    You're being an amazing help.

    I just wanted to follow up here with a couple more findings.

    1) When I stated I couldn't see the keys in my initial post, it was cause I wasn't calling the DIR command correctly. (Remember my CA's are core):
    "Yet, I found the %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys to be empty."

    Turns our I was using simply "dir" or "dir /w" this isn't good enough to see these files, the correct way turns out to be - "dir /a" (Although they state /a:h shows only hidden files, it wouldn't show for me unless I did JUST /a)

    Then I was able to see keys with names exactly as listed in the CertUtil -key command like you specified, HOWEVER! even after I completed rebuilding my Enterprise-Sub-CA, signed by my offline root ca, running CertUtil -key...

    2) My very first record in the "CertUtil -Key" command and what's listed under my MachineKeys folder is that of "iisConfigurationKey"... I even triple checked this by following what this guy said in this technet post....

    On Sub-CA... run "CertUtil -store my" check the existing Sub-CA cert, and it lists the Key Container...
    Run the CertUtil -delkey KeyContainer and reports Key does not exist... But it HAS TO SOMEHWERE!

    I also literally JUST noticed this from me posting it... Why is it saying Cert Hash (Sha1) when I selected SHA256 (as default now in Server 2016)? Yet another bug? something that wasn't coded for change since the move to default to SHA256? When I open the actual Certificate via the Certificate Snap-in, it does show that its SHA256....

    Scary that there are so many inconsistencies...

    • Edited by Zewwy Thursday, February 1, 2018 5:40 PM
    Thursday, February 1, 2018 5:31 PM
  • The Cert Hash (SHA1) is just the thumbprint computed on the local computer. It does not reflect the hash that the certificate was signed with from the CA. This is just used so that Windows has a unique name to uniquely refer to any certificate on the local system. This is not a bug, just has no requirement to use a higher hash as it is not a security element and is not in the certificate itself.

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Thursday, February 1, 2018 6:47 PM
  • To your point #1, you are looking in the wrong folder. The location "%ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys" is antiquated. Since you are using the Microsoft KSP, that is using CNG. Those paths are:

    Machine Keys - C:\ProgramData\Microsoft\Crypto\Keys
    User Keys - %userprofile%\AppData\Roaming\Microsoft\Crypto\Keys

    If you were using a CSP provider, those locations are:

    Machine Keys - C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
    User Keys - %userprofile%\AppData\Roaming\Microsoft\Crypto\RSA\<SID>


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Thursday, February 1, 2018 6:53 PM
  • Thanks for stepping in Mark,

    I indeed did catch that it was Thumbprint Hash and not the actual Cert Hash, I personally think it shown incorrectly via the CertUtil command and should state Thumb Hash, and not Cert Hash.

    Anyway...

    If you have some reading for me on this KSP, CNG and CSP. Throughout this whole process those are Acronyms I haven't yet come across.

    Sorry editing, I noticed I was looking in the wrong path as you mentioned, investigating

    • Edited by Zewwy Thursday, February 1, 2018 8:01 PM
    Thursday, February 1, 2018 7:57 PM
  • What are the contents of the MachineKeys folder? That is where the CA key would be stored - its a computer context key.

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Thursday, February 1, 2018 7:59 PM
  • Right?!?! That's what've been saying this whole time, but it's not there.. like all the Keys that "CertUtil -key" puts out Match those in the folder "%ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys".

    But I never have a first key that matches my CAName...

    So I decided to look into the Crypto\Keys Folder (Not Crypto\RSA\Keys) casue they couldn't make the folder paths any more confusing... and There are 4 keys listed in there, none of which match the keys output by "CertUtil -key"

    Sigh this is an annoying problem

    OK so you were RIGHT!

    Looking at it the "Unique Container Name: " Field Matches the string of the key...
    This String Matches the very first Key under "Machine Keys - C:\ProgramData\Microsoft\Crypto\Keys"

    So the question still becomes how do you properly clean this now if the old way "CertUtil -delkey Container-Name" doesn't work?

    Another question would be, how do you get CertUtil cmd to display Keys associated in the "Machine Keys - C:\ProgramData\Microsoft\Crypto\Keys" folder?
    • Edited by Zewwy Thursday, February 1, 2018 8:14 PM
    Thursday, February 1, 2018 8:04 PM
  • The file names do not match the key container names. If you can share the contents of the folders it would be much easier to point you at the right issue. It’s poasible the key file isn’t there or it could just be a matter of looking at the wrong file name. Key files are usually stored by a unique guid name, not the container name.

    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com

    Thursday, February 1, 2018 8:21 PM
  • Indeed Mark,

    As I said the Unique Container name (Not the common Container Name)
    EG:

      Unique container name: 4f729eeb80404bef62bc2f3771f12345_ae50584c-54c3-4b6f-8b60-f9f8471c0525
      Key Container = Corp-Sub-CA

    As outputted by the cmd "CertUtil -store my" (if you have only the one cert of course, or enter the serial number of the certificate to narrow down the results) You can see this (sort of as I blocked it out) THIS Unique srting MATCHES exactly the first record in my "C:\ProgramData\Microsoft\Crypto\Keys" path:

    "Directory of C:\ProgramData\Microsoft\Crypto\Keys

    01/30/2018  12:35 PM    <DIR>          .
    01/30/2018  12:35 PM    <DIR>          ..
    01/31/2018  10:37 PM             1,547 4f729eeb80404bef62bc2f3771f12345_ae50584c-54c3-4b6f-8b60-f9f8471c0525"

    As you can see they DO match, so my question again remains the same, how does one get CertUtil to list this PrivateKey, or how do i get CertUtil to delete Keys in ""C:\ProgramData\Microsoft\Crypto\Keys". I suppose I COULD manually do so myself but there usually some backend cmd or something else to handle this properly. Which was suppose to be "CertUtil -delkey <Key Container>"...

    Thursday, February 1, 2018 8:30 PM
  • Thanks so much for you input Mark, I'll investigate the other Acronyms you provided me, and I'll do some more research on how CertUtil plays with these other keys folder.
    Thursday, February 1, 2018 8:48 PM
  • Ok, so what you are missing is the argument to tell delkey that this is a KSP provider. So the command would be:

    certutil -csp ksp -delkey "Corp-Sub-CA"


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com


    • Edited by Mark B. Cooper Thursday, February 1, 2018 8:54 PM
    • Marked as answer by Zewwy Thursday, February 1, 2018 9:06 PM
    Thursday, February 1, 2018 8:53 PM
  • Finally!!!! Man why is that not mentioned anywhere else?! You got a white paper i can read on the different types, I didn't even know about this difference and it doesn't seem to be noted anywhere!

    Also That did work a treat, does that mean I have to do something similar to list the keys.... checking....

    Yup! There they ARE!

    CertUtil -csp ksp -key

    Listed it!

    Final question for testing purposes.. I deleted the Key successfully but My attempt to repair it failed...

    certutil -repairstore my "26000000024a5bc123458957ae2000000000002"

    It then prompted me to select a Smart Card for some reason, since there was none to pick from, (attempting to click OK alerted me to pick one, where there was none) and clicking Cancel told me "Access denied" I know I'm fully elevated... 

    How would I recover this key lol (This is all a Test enviro, so no worries if there is no other way other than to rerun the wizard or start over) I'm ok with this and can do it, just figured there might be an easy fix and it be great to blog about. ;)

    I seriously can't thank you enough for pointing me down the required path of learning. Kudos to you sir!


    • Edited by Zewwy Thursday, February 1, 2018 9:11 PM
    Thursday, February 1, 2018 9:04 PM
  • If you delete the key, there is no way to repair it - the key is gone.

    The reason you are prompted for a smartcard is repairstore is looking in all providers (including the smartcard provider) to find a potential private key that matches the certificate you are repairing.

    There isn't much detail on keys to this level. So much so that I have a whole section on keys and the windows protection mechanism in my Advanced PKI class.

    You are most welcome for the assistance.


    Mark B. Cooper, President and Founder of PKI Solutions Inc., former Microsoft Senior Engineer and subject matter expert for Microsoft Active Directory Certificate Services (ADCS). Known as “The PKI Guy” at Microsoft for 10 years. He is also co-founder of Revocent (revocent.com) and its CertAccord product that offers Linux certificate enrollment from a Microsoft CA. Connect with Mark at https://www.pkisolutions.com


    Thursday, February 1, 2018 9:22 PM
  • I kinda figured that was the case, this is where backups help! ;) 

    Which if this was production I would have. But this was all a POC in a test environment.

    No harm done. You are da man. 

    Pretty cool that you run your own business and learning institution! Also super cool you take time to help others here on TechNet!

    For others:

    CSP - Cryptographic Service Provider.

    Cryptography API (CryptoAPI); Cryptography API: Next Generation (CNG)

    Key storage providers (KSPs)

    Thursday, February 1, 2018 9:27 PM
  • I am having a similar problem when trying to delete the keystore of a RootCA I am trying to decommission.

    certutil -delkey "keystore_name" FAILS with Keyset does not exist

    certutil -csp ksp -delkey "keystore_name" FAILS with Invalid provier specified

    This is a 2008 R2 CA which I am trying to kill off gracefully.  I've followed through this post, but am having no luck removing the keystore.  Any help is appreciated!

    Thursday, May 31, 2018 2:52 PM
  • Figured it out.

    For those running 2008 R2, here's what I did get through the certutil -delkey portion of this process:

    certutil -csp "Microsoft Software Key Storage Provider" -key

    *Will list your key stores along with the  name of your CA

    certutil -csp "Microsoft Software Key Storage Provider" -delkey "name_of_ca_from_previous_command"

    *will delete the key store as expected

    Friday, June 1, 2018 12:37 PM