BlogMarch 24, 2022Certificate 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.
Expand Your PKI Visibility
Discover why seeing is securing with revolutionary PKI monitoring and alerting.
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 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:
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
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
August 1, 2024
PKI Insights Recap – Past, Present, and Future of PKI with Brian Komar
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!
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.