Hello @Isabella Brown
Event ID 64 by itself doesn't identify an RPC/proxy failure. It normally means that a certificate in the user or computer certificate store is expired or approaching expiration.
I'd troubleshoot this in this order.
First, identify the certificate referenced by Event 64 using its thumbprint:
Get-ChildItem Cert:\LocalMachine\My |
Where-Object Thumbprint -eq "<thumbprint>" |
Format-List Subject,Issuer,Thumbprint,NotBefore,NotAfter
Then force auto-enrollment:
gpupdate /force
certutil -pulse
certutil -pulse is Microsoft's supported method for triggering the auto-enrollment engine.
Next, verify the certificate template:
- Template is published on the issuing CA.
- Client has Read, Enroll and Autoenroll permissions.
- Auto-enrollment GPO is applied.
- The CA and domain controllers are reachable.
- Client/DC time and Kerberos authentication are healthy.
For diagnostics, review:
Applications and Services Logs → Microsoft → Windows → CertificateServicesClient-AutoEnrollment → CertificateServicesClient-CertEnroll
If you're using Certificate Enrollment Policy Web Service (CEP) / Certificate Enrollment Web Service (CES), troubleshoot the HTTPS endpoint separately. CES accepts enrollment requests over HTTPS and then communicates with the CA using DCOM.
I would not delete RPC-related registry keys as an initial troubleshooting step. There isn't a generally supported procedure for fixing AD CS auto-enrollment by clearing arbitrary “stale RPC keys,” and doing so can introduce additional problems.
If certutil -pulse stalls, please post the Event IDs and error codes immediately following the attempt, along with whether you're using direct domain enrollment or CEP/CES. That will tell us whether the failure is certificate/template, LDAP/Kerberos, RPC/DCOM, or HTTPS enrollment related.
Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.