Crafting a dummy certificate with specific serial number in Microsoft ADCS

Vadims Podans PKI Developer

Today I went through a thread on Twitter with claims that there is no supported way to revoke a rogue certificate with known serial number in Microsoft CA.

TL;DR skip to next section

The long story short: the thread originally was focused on an OCSP deterministic response support. The idea behind this is that by default, Microsoft OCSP responds with “Good” status for any requested serial number which is not placed in CA-issued reference CRL. However, RFC 6960 §2.2 includes a special certificate status called “Unknown”. This flag means that OCSP is aware that requested serial number is not revoked, but is not aware if CA ever has issued a certificate with requested serial number. Microsoft OCSP is CRL-based, so it has no information about ever issued by CA serial numbers. To address this issue and be more compliant with RFC, Microsoft issued a KB2960124 hotfix for Windows Server 2008 R2, 2012 and 2012 R2 which enables deterministic response support in Microsoft OCSP. After applying this KB hotfix and configuring OCSP server to lookup for issued serial numbers directory, its logic is changed as described in RFC:

  • Good — requested serial number isn’t presented in referenced or local CRL and is known to be issued by CA
  • Revoked — requested serial number is presented in either, referenced or local CRL
  • Unknown — requested serial number isn’t presented in referenced and local CRL and is not known to be ever issued

You should be aware, that in Microsoft OCSP, there is a support for local CRL where you can put rogue/missing certificate serials numbers in revocation configurations:

image

This feature is primarily intended for scenarios when CA database was restored to certain point in time and doesn’t include certificates issued after last database backup was taken. Since these certificates are not presented in CA database, you cannot revoke them. And if you have knowledge of such serial numbers, you can simply add them to OCSP revocation configuration and OCSP will respond with “Revoked” status.

Crafting a dummy certificate with specific serial number in Microsoft ADCS

It was just to reiterate the thread point where I jumped in. So far so good. Then, someone put a quite bold claim that:

there is no supported way to revoke a rogue certificate, even if you previously identified its serial number

In fact this statement is incorrect. I was on a phone and could give only short hints on how to do this and found that hints require a more complete/verbose explanation. Remaining part of this post provides a step-by-step process how to solve the problem. The idea is plain and simple:

  1. Generate arbitrary certificate with known in advance serial number (I chose 12345678, because “why not”?)
  2. Sign it with ADCS keys
  3. Import signed certificate to CA database
  4. Revoke the certificate from Microsoft CA management console
  5. Publish new CRL
  6. ?????
  7. PROFIT

All steps are done on a Microsoft CA server we will work with. First two steps are done using single certutil command:

PS C:\> certutil -sign "12345678" cert.cer
Signing certificate Subject:
    CN=Contoso Standalone SubCA
    DC=contoso
    DC=com
  Name Hash(sha1): ed8c3076c53915db9c0817c2f88c146994a3c578
  Name Hash(md5): 1d3c545d33366338a3bc999a16da3ac1
cert.cer: Output Length = 673
CertUtil: -sign command completed successfully.
PS C:\>

This command will generate and sign with CA keys a dummy certificate with requested serial number. The certificate exist as a file, now we need to import certificate to CA database:

PS C:\> certutil -importcert cert.cer
Imported Certificate, Assigned RequestId 4.
CertUtil: -ImportCert command completed successfully.
PS C:\>

let’s revoke it with “Superseded” reason:

PS C:\> certutil -revoke "12345678" 4
Revoking "12345678" -- Reason: Superseded
CertUtil: -revoke command completed successfully.
PS C:\>

publish new CRL:

PS C:\> certutil -CRL
CertUtil: -CRL command completed successfully.
PS C:\>

Now, most important part: ?????

and check CRL:

PS C:\> certutil -cainfo crl > crl.crl
PS C:\> certutil crl.crl
X509 Certificate Revocation List:
Version: 2
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Issuer:
    CN=Contoso Standalone SubCA
    DC=contoso
    DC=com
  Name Hash(sha1): ed8c3076c53915db9c0817c2f88c146994a3c578
  Name Hash(md5): 1d3c545d33366338a3bc999a16da3ac1

 ThisUpdate: 09.08.2021 18:45
 NextUpdate: 17.08.2021 07:05
CRL Entries: 1
  Serial Number: 12345678
   Revocation Date: 09.08.2021 18:54
  Extensions: 1
    2.5.29.21: Flags = 0, Length = 3
    CRL Reason Code
        Superseded (4)
<...>
CertUtil: -dump command completed successfully.
PS C:\>

The job is done!

HTH

About Vadims Podāns

Senior PKI Developer

9 Comments

  1. Stan Morisse on August 10, 2021 at 5:17 am

    Very straightforward article, Vadims!
    I had a look at the twitter conversation. Just my 2 cents: maybe update your twitter comment with a link to this article that proves the case?

  2. Mike Elliott on August 10, 2021 at 6:38 am

    Nice summary, thanks.

  3. Ernest on August 10, 2021 at 7:33 am

    Hello Vadims

    Another excellent post, thanks for taking the time to share 🙂

    Ernest

  4. David Wozny on August 11, 2021 at 3:32 am

    Great post Vadims,
    I thought I’d add a comment on how I used dummy certificates with ADCS in a disaster recovery capacity. I was always paranoid about the potential of “orphaned certificates” issued since the last good ADCS backup being “unrevokable”. As a consequence, I used the SMTP exit module on certificate issuance such that I had a record of every certificate serial number issued since the last full backup of ADCS. This would mean that in the event of needing to do a DR restore of the ADCS database, I could go through the creation of a dummy certificates which had been orphaned and import them into ADCS – as described by Vadims.

    Please note that I am a lowly retired muggle, quite lacking in any magical capacity, unlike the characters listed below:
    – Vadims Podans aka Harry Potter
    – Mark Cooper aka Albus Dumbledore
    – Jacob Grandlienard aka Neville Longbottom
    – Carolyn Ballo aka Hermione Granger
    – Nick Sirikulbut aka Ron Weasley
    – Paul Adare aka Severus Snape
    – Brian Komar aka Lord Voldemort

    • Vadims Podāns on August 11, 2021 at 5:25 am

      Yes, any sort of exit module is useful. For basic purposes you can use built-in SMTP exit module (bear in mind, SMTP exit module isn’t available on server core installs). for advanced scenarios I would write a custom exit module which can log stuff to external database, for example, MS SQL.

  5. Uwe Gradenegger on August 11, 2021 at 12:10 pm

    Sure you’re done with revoking a “rogue” Certificate that was signed by someone else having control over your private key? Ó.ò

    • Vadims Podāns on August 11, 2021 at 12:15 pm

      That’s why I focused on an incomplete CA database when restoring from last backup and you will have to restore missing entries using same technique. If CA keys are compromised, then CA certificate must be revoked.

  6. David Wozny on August 12, 2021 at 1:10 am

    Yes Vadims (aka Harry Potter), using a custom exit module to leverage an external database is a great solution. I recall engaging WiseKey in Switzerland a few times – their CertifyID Guardian XM product was built upon a custom exit module, which did just what you suggested.
    http://www.wisekey.com/products-services/digital-identity-pki/pki-technology/enhancements-for-microsoft-ca

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.