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:

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:

• Auto-Enrollment with manager approval, but auto-approval for re-enrollment
• Superseding certificate templates and signatures

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.