The mystery of “Valid existing certificate” setting in ADCS certificate templates – demystified

This is a follow-up of “Certificate renewal request is placed in pending state when Valid Existing Certificate is selected in certificate template” blog post and final nail into the subject.

Let’s re-iterate the problem. ADCS Certificate Templates provide configuration for issuance requirements, which allows you to forcibly put request in pending state (no automatic issuance) and/or enrollment agent co-signing:

DKw2zqUiLc

Many articles suggest to enable “Valid existing certificate” option and you will be fine. Unfortunately, there is very little information on what this option does or how it works. In general, it is known that it will override other issuance requirements, such as CA manager approval and/or enrollment agent co-signing. This is useful, when initial request requires additional checks/steps and they are not enforced by automatic certificate renewal. However, it is not true in various scenarios. A couple of examples:

Admins expect this flag to work in always, but it doesn’t. I was under same delusion of this flag and communicated with Open Specifications support to figure out what’s wrong with the setting. A week ago, Microsoft updated [MS-WCCE] document which contains a clear and definitive behavior:

If the CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT flag is set in the template, the CA MUST verify that all the following conditions are satisfied before enforcing the CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT flag:

  • The old certificate, based on which the reenrollment is occurring, MUST contain the Certificate Template OID extension.
  • The TemplateID from the old certificate MUST match the TemplateID of the current template.
  • If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is set, then the CA MUST verify that subject name is supplied in the request, and that it matches with the subject of the old certificate.
  • If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set, then the old certificate MUST contain the subject alternative name (SubjectAltName) extension.
  • If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set, then the SubjectAltName extension from the old certificate MUST contain either an rfc822Name or otherName with OID szOID_NT_PRINCIPAL_NAME (1.3.6.1.4.1.311.20.2.3).
  • If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set and the SubjectAltName contains otherName, then the value of otherName MUST match the value of the userPrincipalName attribute from the requestor’s user object in the working directory.
  • If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set,and the SubjectAltName contains the rfc822Name, then the value of rfc822Name MUST match the value of the mail attribute from the requestor’s user object in the working directory.

If we look at failing examples, first example fails 5th requirement. Machine certificates don’t use RFC822 or UPN name types, they use DNS Name name which is ignored by this logic. Second example fails on 2nd requirement, new template doesn’t match the one in signing certificate.

About Vadims Podāns

Senior PKI Developer

5 Comments

  1. Matt Wells on December 1, 2022 at 10:36 am

    Fascinating – does this basically kill any chance of getting any custom CEP templates with initial CA Manager approval working with auto-enrollment after the initial approval?

    • Vadims Podāns on December 1, 2022 at 10:42 am

      > does this basically kill any chance of getting any custom CEP templates with initial CA Manager approval working with auto-enrollment after the initial approval?

      right.

  2. Matt Wells on December 6, 2022 at 6:40 am

    Vadims,

    I was able to get this working if I chose “Supply In The Request” and “Use subject information from existing certificates for autoenrollment renewal requests.” I’m guessing that is because the flag referenced in the fifth condition is set and the condition is therefore bypassed:

    If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set, then the SubjectAltName extension from the old certificate MUST contain either an rfc822Name or otherName with OID szOID_NT_PRINCIPAL_NAME (1.3.6.1.4.1.311.20.2.3).

    I suspect you already know this which leads me to ask the question; aside from the obvious security concerns around that setting — is there another reason this is not preferred or best practice?

    Lastly, is there any guidance or explanation around the various policy types and application policy for the “This number of authorized signatures” setting under Issuance Requirements? I noticed your template includes that setting for “Certificate Request Agent” – I suspect I know what it means, but I’m not 100%. Is this just a setting to ensure the enrollment request must include a valid certificate with the Certificate Request Agent application policy? I am testing this setting on the next renewal and I will see if automatically re-enrolls – thanks.

    Thanks again for the post!

    • Vadims Podāns on December 7, 2022 at 7:50 am

      > Use subject information from existing certificates for autoenrollment renewal requests.

      with this option, renewal request copies identity information from existing cert, so it should be fine

      > is there another reason this is not preferred or best practice?

      I would ask Microsoft what they thought.

      > Is this just a setting to ensure the enrollment request must include a valid certificate with the Certificate Request Agent application policy?

      yes. This is used for ROBO enrollments and enrollment agent’s cert must comply with settings in Issuance Requirements tab.

      • Matt Wells on December 7, 2022 at 10:55 am

        Thanks Vadims!

        Just as a follow-up for those that may read this; if I set the template on the initial enrollment to “Supply In The Request” and “Use subject information from existing certificates for autoenrollment renewal requests”, I was able to get auto-renewal to process successfully. Likewise; I was able to apply signature requirements that bound the request to have the certificate request agent application policy within the cert for subsequent renewals AFTER I performed the initial enrollment manually.

Leave a Comment





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