Certificate renewal request is placed in pending state when Valid Existing Certificate is selected in certificate template

Hello S-1-1-0, here is a new blog post in a long time. Today I want to talk about the issue when “Valid existing certificate” does not bypass CA Manager approval and/or enrollment agent requirement during certificate renewal in Microsoft CA.

In certificate template settings, Issuance Requirements we can configure additional requirements for enrollment and re-enrollment (or renewal). These settings include CA Manager approval and a number of enrollment agent (EA) signatures:

There are two major use cases of settings in Issuance Requirements tab:

• For smart card certificate initial enrollment (provisioning) using EA. Often we configure EA certificate requirements (application and certificate policies);
• For certificates that require the subject to be supplied in request. Often we configure CA Manager approval so manager can review the request and reject the request if it contains names requester is not authorized for. Such cases are web server or code signing certificates.

Additionally, the setting specifies requirement for renewal, either same requirements as initial enrollment or just having valid existing certificate based on same certificate template. If you select “Same criteria” option, then renewal request will be unconditionally pended. If you select “Valid existing certificate” option, then renewal request should ignore settings above during renewal. This enables automatic certificate renewal using certificate autoenrollment of any certificate that requires manual initial validation/process process. For example, we should manually review web server certificate for approved names. Once approved, it often ok to keep these names unchanged without repeated validations.

However, it was discovered that this behavior is broken for computer certificates. Let’s dig into this issue.

Client Request Process

Client request process isn’t much of interest here, I will just outline major properties of both, initial certificate enrollment and existing certificate renewal:

• Initial request — the process produces a standard PKCS#10 request which is signed using subject’s private key, or PKCS#7 request with signatures of each enrollment agent.
• Renewal request — the process produces a CMS with CMC request is generated. This request contains renewal PKCS#10 request which is signed with existing certificate’s private key. This is how request is mapped to “Valid existing certificate” setting in certificate template.

Issuance Requirements technical implementation

This section contains relevant parts of certificate template object in Active Directory:

• When you enable “CA Manager” approval checkbox, a CT_FLAG_PEND_ALL_REQUESTS flag is enabled in msPKI-Enrollment-Flag certificate template attribute.
• When you configure enrollment agent requirements (additional signatures), a msPKI-RA-Signature, msPKI-RA-Application-Policies and msPKI-RA-Policies attributes are set in certificate template object.
• When you select “Valid existing certificate”, a CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT flag is enabled in msPKI-Enrollment-Flag certificate template attribute.

This information will help us to dive into the problem.

CA Request processing rules

Microsoft CA processes CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT as follows:

CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT

The CA MUST enforce this flag only for certificate renewal requests.

If this flag is set in the template:

• The CA MUST NOT enforce the signature processing rules specified for the following attributes: msPKI-RA-Signature, msPKI-RA-Policies, and msPKI-Application-Policy.
• The CA MUST ignore the CT_FLAG_PEND_ALL_REQUESTS flag.

In other words, “Valid Existing Certificate” setting in certificate template overrides all other settings in “Issuance Requirements” (RA) tab for renewal requests. So far, so good. The question is, what requirements applied to request in order to consider it as renewal request from CA perspective (a quote from MS docs at the point of writing this blog post) [MS-CSRA] §3.2.1.4.2.1.4.2.2 Renewing a Certificate Request Using CMS and CMC Request Format:

The request MUST be compliant with the information specified in [RFC2797], otherwise the CA MUST return a non-zero error. The processing rules for the following fields MUST be adhered to by the CA but are not specified by [RFC2797]:

• ContentType: This field MUST be OID szOID_RSA_signedData (1.2.840.113549.1.7.2, id-signedData). If not, the CA MUST return a non-zero error.

• Content: The content structure MUST be SignedData. The SignedData structure MUST adhere to the following requirements:

  • encapContentInfo: This field MUST have the following values for its fields:
    • eContentType: This field MUST be szOID_CT_PKI_DATA (1.3.6.1.5.5.7.12.2, Id-cct-PKIData). If not, the CA MUST return a non-zero error.
    • eContent: This field MUST be a PKIData. The PKIData structure MUST adhere to the following requirements:
      • TaggedRequest: This field contains a single PKCS #10 certificate request. If the content of this field is not exactly one PKCS #10 certificate request conforming to the rules specified in sections 2.2.2.6.5 and 3.2.1.4.2.1.4.1.1, the CA MUST return 0x8007000D (ERROR_INVALID_DATA) to the client. In addition, the Attributes field in the PKCS #10 certificate request MUST include the szOID_RENEWAL_CERTIFICATE (1.3.6.1.4.1.311.13.1) attribute. If this attribute is not included, the CA assumes that this is a new certificate request and follows the processing rules in section 3.2.1.4.2.1.4.1.1. The value for this attribute MUST be the already issued certificate DER encoded. If the issued certificate is not included in the value of this attribute, the CA MUST return 0x8009400E (CERTSRV_E_BAD_RENEWAL_CERT_ATTRIBUTE) to the client.
      • TaggedAttribute: This field MAY contain additional enrollment attributes. If the field contains the RegInfo attribute (as specified in [RFC2797] section 5.12), processing rules for its value are identical to the ones for the pwszAttributes parameter (as specified in section 3.2.1.4.2.1.2).

• Certificates: This field MUST include the already issued certificate associated with the private key used to sign the request (the same certificate as the one in the PKCS #10 Attributes that MUST be included in the PKCS #10 attribute). If this field does not contain the already issued certificate, the CA MUST return 0x8009400E (CERTSRV_E_BAD_RENEWAL_CERT_ATTRIBUTE) to the client

• SignerInfo: The signing MUST be done with the key associated to the already issued certificate that is passed in the Certificates field.

While this works for user certificates, this doesn’t work for computer certificates. CA fail to consider computer renewal requests as renewal and always apply new request processing rules, i.e. applying CA Manager approval and enrollment agent requirements (if any). This behavior kills the benefit of using autoenrollment to automatically renew IIS certificates that use Certificate Rebind feature.

Problem Status

I was forced to contact Microsoft Support regarding this issue and here is the response from them:

In order to apply renewal requirements on a request, subjectAltName type in the existing certificate should be either other_name (type 1) or RFC822_NAME (type 2)

This means that the doc has missing requirement on renewal signing certificate, which MUST include either, a User Principal Name (UPN) or RFC822 (email) name. Computers use neither of these name types, they use DNS Name or IPAddress name types in SAN extension. Microsoft Support confirmed that this behavior is by design and documentation will be updated accordingly. No product behavior changes are planned.

Unfortunately, there is no viable workaround I could think of.