We're headed to GridSecCon 2024, October 22-25 in Minneapolis, MN! Learn more here
Schedule a Demo
Blog March 24, 2022 Certificate Requests, Certificate Templates, Enrollment, Known Issues, PKI

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

by Vadims Podāns

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.

Person sitting at a laptop while viewing the PKI Spotlight Dashboard.

Expand Your PKI Visibility

Discover why seeing is securing with revolutionary PKI monitoring and alerting.

Learn More About PKI Spotlight®

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-SignaturemsPKI-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.

Related Resources

  • Blog Image of a person sitting at a desk working on a laptop with PKI Spotlight on the screen.
    October 4, 2024

    Announcing the October 2024 PKI Spotlight® Release

    PKI, PKI Spotlight
  • Blog
    August 16, 2024

    To Revoke or Not to Revoke: Balancing Security with Performance and Operational Complexity

    CA, Certificate Authority, Certificate Revocation List, CRL, OCSP, PKI, VPN
  • Blog A representation of PKI and digital certificate with a key lying on a blue circuit board
    August 1, 2024

    PKI Insights Recap – Past, Present, and Future of PKI with Brian Komar

    PKI, PKI Insights

Vadims Podāns

PKI Software Architect

View All Posts by Vadims Podāns

Comments

  • Hi Vadims. After struggeling to get CEP/CES to work, I am forced to ask you 🙂

    I want a client from a different domain to get a certificate via CEP/CES. I have a template with “Subject Name > Supply in the Request + Use subject information from existing certificates for autoenrollment renewal requests” and with “Issuance Requirements > CA certificate manager approval + Valid existing certificate + Allow key based renewal”.
    The client gets the first certificate via CEP1/CES1 with username + password. I can manually renew this certificate using CEP2/CES2 with certificate without any problem. If it comes to auto renewal time, the system wants to renew the certificate. It authenticates to CEP2 with certificate, but then the error “Certificate enrollment for Local system cannot enroll for a XXX certificate because the certificate enrollment server XXX-CA is ROBO and only renewal is supported” (I guess this is from CES2 with certificate auth). The process falls back to CEP1/CES1 via username and password, authenticates successfully but the request ends up in PENDING state.
    Can you confirm that my case is as well affected by your described topic? This is the ONLY thing that I can imagine, because I reinstalled the scenario for quite a few times and I always end up there… I’d be happy if you could help me out, this is frustrating!

    • If it is machine certificate, then yes, you are a victim of the problem described in this blog post. If it is user certificate, then it should work (as long as UPN is supplied in previous certificate).

  • I tried it with a user certificate template, same settings. I filled CN and UPN with an existing user. The error from CES2 is the same, it is ROBO and does only support renew. The auto renew process seems to think that it is a request and not a renew. I am testing this by just changing the time on a workgroup client to the future… Do you have any idea what I am doing wrong? Thank you!

  • Dear All,

    I have one query regarding the renewal of an intermediate enterprise CA certificate of Microsoft PKI. Its a 2 tier architecture and I need to renew this CA certificate with same key pair. This CA is also working with 3 NDES RA services which are running on 3 different servers.
    I would like to ask if I renew the CA certificate with same key pair then will there be any impact on these NDES RA certificates, do I also need to renew these RA certificates with new CA certificate or not.

    • If you renew with the same key, the CA’s SKI will remain the same. This ties to the AKI of anything the CA issues, so as far as anything below the CA, it will chain up properly. We have seen some instances, especially with tIntune and others that also look at certificate serial number, and that would change with a renewal. So there could be other issues at play in your renewal.

  • Took me a while to figure out when “CA Manager” was set so thought I’d share.

    $adobject = get-adobject $template.DistinguishedName -Properties msPKI-Enrollment-Flag
    $bitwise = [convert]::ToString($adobject.”msPKI-Enrollment-Flag”,2)

    if ($bitwise -band 2)
    {
    $CT_FLAG_PEND_ALL_REQUESTS = 1
    }
    else
    {
    $CT_FLAG_PEND_ALL_REQUESTS = 0
    }

Leave a Reply

Your email address will not be published. Required fields are marked *