Update 26.03.2020: Updated conditions for Renew Manually Enrolled Certificates section
This is a second part of the Certificate Autoenrollment in Windows Server 2016 whitepaper. Other parts:
This section discusses the autoenrollment architecture, an analysis of the components of the autoenrollment process, and working with certificate authority interfaces.
Autoenrollment consist of several components installed on each computer. Depending on environment (Active Directory or workgroup) some components may present or not present. The following diagram outlines autoenrollment components and their high-level interactions in both environments:
Figure 8: Autoenrollment component diagram. Blue color shows components available only in Active Directory environment
The meaning of each component is provided in next sections.
This component is not available in workgroup environments.
Client module that is responsible for Group Policy retrieval and processing from domain controller, policy storage and policy maintenance on a local computer. Group Policy client updates local configuration with certificate enrollment policy (CEP) information.
System Registry storage that contains information about certificate enrollment policies (CEP). This information is then used to populate configuration for: Enrollment Policies, AE Options and Certificate Issuers components. Local configuration is stored in System Registry in HKLM and HKCU registry hives:
SOFTWARE\Policies\Microsoft\Cryptography\AutoEnrollment\
Contains a collection of CEPs. In Active Directory environment, a LDAP domain policy is added by default. XCEP policies must be configured by an administrator in Group Policy on domain controllers (available only in Active Directory) and/or using local configuration tools. Each policy contains the following notable properties:
Specifies options that control autoenrollment behavior. These options contain the following flags:
Certificate template is set up for autoenrollment when its settings are compatible with silent initial enrollment and renewal operations. Certificate is not set up for autoenrollment when its settings are not compatible with initial certificate enrollment, but allow silent certificate renewal operation.
Enroll setting is controlled by a “Update certificates that use certificate templates” checkbox in autoenrollment configuration dialog in GPO (see Configuring autoenrollment policy section below)
Manage and RetrievePending settings are controlled by a “Renew expired certificates, update pending certificates, and remove revoked certificates” checkbox in autoenrollment configuration dialog in GPO (see Configuring autoenrollment policy section below).
Autoenrollment requires the computer on which it is executing to provide some implementation-specific persisted local certificate storage that can be logically organized into groups of certificates.
Autoenrollment requires that the computer on which it is executing provide some implementation-specific persisted local private key storage where it could store private keys associated with the certificates it is requesting.
For each request that requires user interaction as per the certificate template, the balloon user interface (UI) is invoked in system tray and is added in the notification center:
Figure 9: Certificate enrollment balloon user interface that requires user input
Balloon UI notification is displayed approximately 60 seconds after logon. If no user interaction is explicitly defined on the certificate template, no UI will be displayed to the user. This delay is incorporated to allow for speedy application and shell response times during the logon and booting of the client machine. If the 60-second delay is not desired, the following registry key may be added on a per-user basis:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEExpress
Using this key in a normal production environment is not recommended. If it is used, it must be created on a per-user basis.
Machine certificates do not support user interaction and must not be configured to require this setting.
The balloon UI waits for the user to see the balloon and is activated by a mouse click. Note that after approximately 15 seconds, the balloon pop-up window is replaced in the system tray by a certificate icon that may be activated by a mouse click. If no activation occurs within seven hours, the taskbar icon will disappear and the silent thread will re-activate at the next logon, machine reboot, or next autoenrollment trigger, whichever is first. Once the user activates the UI, the REQUEST store is checked first for pending requests.
This section describes a detailed process performed by autoenrollment each time it is activated.
The autoenrollment process is normally triggered by a set of built-in scheduled tasks which are stored under Task Scheduler Library\Microsoft\Windows\CertificateServicesClient
container in Task Scheduler:
Figure 10: Autoenrollment triggers in Task Scheduler
This container stores several scheduled tasks that can activate autoenrollment for machines and users. By default, autoenrollment is triggered at reboot for machines, or at logon for users, and is refreshed every eight hours. The refresh interval can be configured using Group Policy. Autoenrollment is also triggered by an internal timer that activates every eight hours after the last time autoenrollment was activated. Autoenrollment trigger for computer and user contexts can be activated manually, by running the following commands:
Certutil -pulse Certuil -user -pulse
Unlocking the workstation does not trigger autoenrollment.
An administrator may force all users to re-enroll for a given template by updating the major version number of the template. When Active Directory is queried during logon for required certificate templates, the version number is examined. If the version number has incremented, the certificate template is considered to be updated and the user must re-enroll for that template.
To manually force the template version to be updated (thereby forcing re-enrollment): right-click the template and select Reenroll All Certificate Holders (Figure 11):
Figure 11: Manually Forcing Certificate Re-Enrollment
This procedure will increase template’s Major Version attribute. Autoenrollment client will handle this attribute to force existing certificate renewal when Major Version is changed. When modifying certificate template, its Minor Version is incremented, but it doesn’t force client certificate reenrollment.
Templates are not updated automatically. By default, templates are updated at a minimum interval of 10 minutes.
Windows clients will perform automatic renewal of certificates as specified on a per-template basis. Renewal intervals are dictated by the certificate template, which is set to six weeks (before expiration) by default. When certificate renewal is performed, the old (previous) certificate enrollment is always archived on the client machine, and the user directory object is updated. Even if “Delete revoked or expired certificates” checkbox is selected in certificate template settings. In this case, previous certificate will be deleted after expiration or revocation. Important certificate renewal criteria include the following:
This section describes the process and operation sequence during autoenrollment initialization. Depending on autoenrollment configuration not all steps are performed. Each subsection provides conditions when particular task is executed.
In this step, autoenrollment feature examines local configuration storage (which is updated via Group Policy and/or manually by a computer administrator) to determine the process behavior. If autoenrollment state is set to Disabled, the process terminates, otherwise it continues with the next step. Autoenrollment initialize Enroll, Manage and RetrievePending flags.
This step is performed only by domain members. Workgroup members skip this step.
Autoenrollment automatically downloads and manages trusted root certificates, cross-certificates, and NTAuth certificates from Active Directory into the local machine registry for domain-joined machines. All users who log on to the machine inherit the trust and downloaded certificates that are downloaded and managed by autoenrollment. The following stores are located under the following DS path: CN=Public Key Services, CN=Services, {ConfigurationNamingContext}
:
Local Certificate Storage |
Certificates MMC container |
Corresponding Active Directory container |
---|---|---|
Cert.Roots |
Trusted Root Certification Authorities |
CN=Certification Authorities |
Certs.CAs |
Intermediate Certification Authorities |
CN=AIA |
Certs.KRA |
N/A |
CN=NTAuthCertificates |
Additionally, autoenrollment fetches object identifier (OID) registration information and writes it to the local cache. Administrators use Active Directory to register object identifiers for new application policies (enhanced key usages or EKU), certificate policies and certificate templates. OID information is downloaded from the following Active Directory container:
CN=OID, CN=Public Key Services, CN=Services, {ConfigurationNamingContext}
During this step, autoenrollment initializes runtime stores: Cert.CurrentCertificates, Cert.ToBeAdded, Cert.ToBeDeleted. Cert.CurrentCertificates will include all the certificates from client’s Personal store and, optionally, from additional stores if such are configured in local configuration. Other runtime stores are initialized to empty lists.
During this step, autoenrollment uses local configuration to obtain information about CEP policies. Autoenrollment groups policies by PolicyId attribute. Groups are sorted by Cost attribute, then by Authentication attribute. Kerberos authentication has higher precedence. The rest groups are placed in arbitrary order.
After grouping and sorting CEPs, each CEP is queried. During the query, client obtains the following information:
If CEP uses WCCE enrollment stack, then certificate templates and certificate issuers are downloaded from Active Directory, otherwise, this information is downloaded from XCEP server. Upon retrieval, every certificate issuer certificate is validated according to validation rules specified in RFC 5280. Certificate issuers that fail validation are excluded from processing.
After downloading certificate templates and certificate issuers, autoenrollment constructs a list of certificate templates applicable for autoenrollment. At a minimum, certificate template is considered applicable for autoenrollment when client has Autoenroll permissions on that template, and template is supported by any of certificate issuers in the current CEP group. Additional restrictions apply and will be covered in “Autoenroll based on certificate templates” section below.
If autoenrollment options has RetrivePending flag enabled, autoenrollment checks Certificate Enrollment Requests (REQUEST) local store for non-complete certificate requests. Pending requests are requests that require explicit CA manager approval. When client submits such request, it is placed in CA database and waiting for review and approval. CA manager can approve the request and issue the certificate, or cancel request.
For each pending request, autoenrollment checks the age of the request. If request is in pending state for 60 or more days, pending request is deleted from Certificate Enrollment Requests and excluded from further processing.
When stale pending requests are deleted, remaining pending requests are updated. Each pending request contains all relevant information to update request status. Autoenrollment contacts certificate issuer associated with the particular request and updates the request status. There are three possible outcomes:
When all pending requests are processed, autoenrollment performs existing certificates renewal.
If autoenrollment options has enabled Enroll flag, autoenrollment will perform a two-step Personal certificate store update. First step renews existing certificates (if applicable) and second step enrolls for certificates which don’t exist in certificate store, but are required by enrollment policy. These two steps are performed against certificate templates that have been set up for autoenrollment (support silent initial enrollment). Certificate autoenrollment consists of three steps:
Each step is described in the following sections
In the first step, autoenrollment enumerates all existing certificates (from Personal and additional stores provided in the configuration) that use certificate templates and checks its validity by passing it to a certificate chaining engine. Certificate is validated according to validation rules as specified in in RFC 5280. If certificate fails validation checks, it cannot be renewed. Instead, a new certificate request is issued as described in next section. If existing certificate passes validation checks, autoenrollment examines whether certificate template is set up for autoenrollment. Certificate template is set up for autoenrollment if none of the following conditions are true:
If any of these conditions are true, existing certificate cannot be renewed, and autoenrollment will skip such certificate. Otherwise, autoenrollment checks passes the certificate to certificate chaining engine (CCE) to determine its validity.
Autoenrollment will ignore revocation errors if a CRL Distribution Point (CDP) extension does not exist in the CA certificate or if the revocation status is offline.
If certificate is valid according to chain validation rules (as described in RFC 5280) autoenrollment estimated validity of the existing certificate:
If existing certificate’s validity meets renewal threshold, autoenrollment will submit renewal request to CA server.
If certificate lifetime hasn’t reached renewal threshold, autoenrollment checks certificate template Major Version attribute in existing certificate and certificate template obtained from XCEP server. If Major Version of certificate template is higher than Major Version in existing certificate, this will instruct autoenrollment to perform existing certificate renewal even if renewal threshold is not yet reached. Major Version attribute manipulation allows systems administrators to force existing certificate renewal when critical changes were made in certificate template settings.
After renewing existing certificates based on templates, autoenrollment examines a list of certificate templates that have been set up for autoenrollment (as described in previous section) and attempts to find a matching certificate in the Personal store. New request is not issued against certificate template if any of the following conditions are true:
userCertificate
Active Directory attribute of the current client account;If no valid certificate is found, or certificate chaining engine failed to validate existing certificate, a new certificate request is issued.
When new certificate request is created, autoenrollment checks if CA servers provided by a default CEP policy supports specified certificate template. If at least one CA supports specified certificate template, a request will be sent to CA server with lower Cost value. If no CAs in the default CEP policy are found, autoenrollment arbitrary enumerates all available CAs that support specified certificate template. If at least one CA is found, a first (arbitrary selected) CA is used to submit certificate request. If no CAs that support specified certificate templates are found, certificate template is skipped.
Some certificates require manual initial enrollment, but later can be automatically renewed. If autoenrollment options has Manage flag enabled, autoenrollment will examine current certificates in Certs.CurrentCertificates store to determine if any such certificates exist and attempt to renew them. Manually enrolled certificate renewal if none of the following conditions are true:
Clients prior to Windows 8 and Windows Server 2012 do not support the use of existing name in the renewal certificate and autoenrollment against the template that requires the subject to be supplied in the request will fail.
If neither of these blocking conditions met, autoenrollment submits certificate request. If initial enrollment results in an issued certificate, it is installed in the Personal store. If request results in a pending state, client keeps request information in the Certificate Enrollment Requests store and will check its status upon next autoenrollment trigger.
This section describes the certificate store cleanup process after each successful certificate renewal or new certificate enrollment.
If certificate renewal for existing certificate occurred and resulted in an issued certificate, autoenrollment performs existing certificate cleanup in local storage. Cleanup will either, mark existing certificate as “archived” or delete it. Cleanup action is configured in the certificate template’s Request Handling tab. The following image illustrates cleanup setting:
Figure 12: Certificate cleanup setting in certificate template
If autoenrollment options has Manage flag enabled, autoenrollment deletes revoked certificates in the userCertificate
attribute on the client object in Active Directory. Expired or superseded certificates are not deleted automatically from Active Directory, they must be deleted manually.
If certificate purpose is Encryption, existing certificate is always marked as “archived” and cannot be deleted by autoenrollment.
Добрый день
Извиняюсь, что не в ту ветку пишу, но к сожалению не нашел у Вас на сайте вот этот Ваш материал https://habr.com/company/microsoft/blog/349202/
Вопрос может и небольшой, но важный.
По окончании настройки по Вашей статье и разворачивании 3-х уровневой модели Корневой УЦ (offline), подчиненный УЦ (online in AD) , выпускающий УЦ (online in AD) при генерации сертификатов для пользователей обработкой запросов, поданных через mmc (certmgr.msc) и выпуском занимается подчиненный УЦ, а не выпускающий.
Подумал перенастроить на выпускающий сервер и нашел в Default domain policy параметр "Клиент служб сертификации: политика регистрации сертификатов" в которой указан URI сервера регистрации "LDAP:" и при попытке вручную добавить свой сервер регистрации (https://server_slave.ad.local/certsrv/) жутко ругается и не хочет пускать на шаг добавления.
Что я делаю не так?
> https://server_slave.ad.local/certsrv/
конечно будет ругаться, это же веб-страницы, а не веб-сервис. Вам нужно установить веб-сервис и получить от него ссылку (через IIS, это в документе указано), которую уже вставляете в гпо.
Добрый день.
Спасибо за ответ на предыдущий вопрос. Разобрался.
Есть еще один насущный вопрос.
Как настроить включение в сертификат дополнительных полей из учетной записи пользователя кроме E, CN, DC. Например, добавить включение в subject поля адрес(STREET), организацию (О) и других полей? Если настроить ввод вручную этих полей (не брать из AD) в шаблоне неудобен.
Заранее спасибо
Адресуйте, пожалуйста, ваш вопрос на профильных форумах. Данная страница предназначена для обсуждения статьи по автоэнроллменту.
Hi Vadims,
What happens with a user certificate that is issued by a CA using a template that was configured for automatic renewal, adn the CA cert expires. Does Windows attempt renewal in this case?
> Does Windows attempt renewal in this case?
nope. At the point when CA certificate has expired, client certificate is expired too (because client certificate's validity cannot exceed issuer's validity). Expired and revoked certificates are not subjects for renewal. Only initial request is possible in this case.
Hi Vadims,
We have 2 internal CA's in our envitorment and one CA is going to expire soon and so we want to use the other CA which has more validity still. So we have a group policy created to auto generate the machine certificates. So currently it is using first CA to autogenerate. Now we have deployed second CA root certificate also to all users but machine certificate is still not auto generating using 2nd CA as the current machine certificate generated by using first CA still have validity of 10 days.
How to enforce to auto generate the machine certificate using the second CA server and overrite the current exisiting machine certificate whcih cwas generated by first CA.
Thanks
Jags
Just remove all templates from first CA and enable them on new CA. Clients will get new certs from new CA.
Thanks alot Vadmins Podans. Just to make sure, will that overrite the current machine certificate with new CA or will add one more machine certificate along wiht the old one.
Do i need to make any changes on AD for that CA’s pKIEnrollmentService object after removing the templates in old CA from certificate tempalte mmc?
I am facing an issue in the certificate enrollment from windows 10 client PC's
Usually , when the computer join to domain, the computer automatically gets the certificate from domain.
Now I noticed the certificates are not getting automatically when we join the computer on the domain.
I have manually tried to enroll the certificate using
MMC > Add Snap in > Certificates (Computer Certificates) > Request new certificate
I can see the Active Directory certificate enrollment option in this with proper GUID and when I click next , i am getting the "the certificate types are not available" message window and none of the templates are listed..
When I logged to the same computer with a domain admin account, the enrollment works fine and computer gets the certificate.
I have checked the permission on the templates > domain computers read and enroll and auto enroll permissions are in place.
Is this due to any kerberos issue as I am logging to the computer with local admin user.
Is there any known bug / any other permission issue..
Please advise the fixes if any one experienced similar issue .
https://social.technet.microsoft.com/Forums/windowsserver/en-US/ca54e0a7-d530-4851-b529-0a079e492091/quotthe-certificate-types-are-not-availablequot-windows-10-windows-2016-ca-server?forum=ws2019
Hi Vadims,
We are having issue with the Autoenrollment for couple of servers out of a large Domain controllers. Do you think i have to check from the replication view also and what do you recommend in case of Domain controllers in auto enrollment.
@Radhesh PS
If you have specific issues, ask them on TechNet forums.
Hi Vadims, two questions:
1. Under the section 'Automatic certificate renewal' one of the conditions is: 'Certificate template requires subject name to be supplied with request in the Subject Name tab'
This makes no mention of the 'Use Subject Information from existing certificates for autoenrollment renewal requests' checkbox. Is that checkbox option not relevant for renewal via the Autoenrollment process? I see this checkbox option is explicitly mentioned under the 'Renew manually enrolled certificates' section.
2. Under the section 'Renew manually enrolled certificates' one of the conditions is: 'Existing valid and non-expired certificate based on this certificate template is found'
I read this as saying only expired certificates will be renewed. However that makes no sense to me in the context of the first condition. There would be no point to the renewal interval period.
Great article btw, really helpful, thank you so much!
Regards
Gavin
1) Fair enough. I'll check this and update the document. Yes, that checkbox in Subject tab is intended for automatic certificate renewals with custom subject.
2) "I read this as saying only expired certificates will be renewed." -- no. Only valid and non-expired certificates are eligible for renewal. Existing certificate is used to sign renewal request, thus you cannot use expired certificate renewal request, because signing certificate will fail validation on CA side.
Thanks for the quick reply!
Regarding number 2, that's what I thought however the list of conditions is pre-faced with 'Manually enrolled certificate renewal if none of the following conditions are true'. So it's saying if the condition 'Existing valid and non-expired certificate based on this certificate template is found' is true then renewal will fail.
I understand that's not the case (it's the opposite), it's just the way it's written, or at least how I'm reading it. Sorry if this is coming accross as pedantic :)
> Sorry if this is coming accross as pedantic
It's ok. Since the article says about exact behavior, every piece should be clear to reader and should not allow veriant reading.
> Manually enrolled certificate renewal if none of the following conditions are true'. So it's saying if the condition 'Existing valid and non-expired certificate based on this certificate template is found' is true then renewal will fail.
I agree that this item is suspicious. I'll check this in next few days and will update the article if necessary. Thanks for reporting!
Hi Vadims,
I just completed some testing, the 'Renew manually enrolled certificates' process does appear to renew expired certificates (to my great surprise!).
My testing configuration:
Certificate Template
AutoEnroll GPO
Process
Can you confirm the request type used during renewal? It should be PKCS#10 and this will indicate that new request was sent instead of renewal. Renewal request will use PKCS#7 CMC request format. By viewing issued certificate you can't tell if the certificate was issued against new or renewal request.
"Can you confirm the request type used during renewal?"
How can I do that?
View request details from CA database. Add Binary Request column to view in Issued Certificates folder, right-click, select Export Binary Data and select Binary Request.
Exported with 'View formatted text version of data'. Pasted what I hope are the relevant fields below (I filtered it as I don't understand the various fields so can't make a judgement).
Looks like a PKCS10 certificate request nested inside a PKCS7 message?
PKCS7/CMS Message:
CMSG_SIGNED(2)
CMSG_SIGNED_DATA_CMS_VERSION(3)
Content Type: 1.3.6.1.5.5.7.12.2 CMC Data
PKCS7 Message Content:
================ Begin Nesting Level 1 ================
CMS Certificate Request:
Tagged Attributes: 1
...
...
User: 'test machine coomputer account'
Machine: 'test machine hostname'
Process: taskhost.exe
...
...
================ Begin Nesting Level 2 ================
Element 0:
PKCS10 Certificate Request:
Version: 1
...
...
User: 'test machine coomputer account'
Machine: 'test machine hostname'
Process: taskhost.exe
...
...
---------------- End Nesting Level 2 ----------------
Tagged Content Info: 0
Tagged Other Messages: 0
---------------- End Nesting Level 1 ----------------
I did a test and renewal for expired certificate works as expected: a new request is sent to CA. Expired certificate isn't used in renewal process.
Hi Vadims, quick question regarding Enrollment Agents: when using an enrollment agent, what is the effect of requiring 2 signatures? Do these signtures have to be from two different enrollment agents? do they have to be applied as part of the same certificate request (i.e. the 2 enrollment agents should be present at the same time)?
> Do these signtures have to be from two different enrollment agents?
yes.
> do they have to be applied as part of the same certificate request
yes.
> 2 enrollment agents should be present at the same time
not necessarily. If it is direct enrollment, then yes. But if this is an offline request, then enrollment agents can co-sign request at any time before submitting request to CA
Thanks Vadims, how is this done in Windows? If I use the certmgr console and select "All Tasks - Advanced Operations - Enroll on Behalf of" it only allows one RA signature, how do I get to use 2 RA signatures?
You mentioned "offline request" too, is that done uwing certreq?
Thanks in advance,
If more than one signature is required, then you have to go through CLI tools, such as certreq.exe or use CertEnroll COM interfaces. Certificates MMC snap-in supports only up to 1 signature.
Hi Vadims
How is load handled on your CA during enrollment/reenrollment ? So if you say have 1000 machines needing a new certificate. They all log on say within the standard 20 minute window first up will they all try and enroll at the same time ? We have had some issues with this in our environment with RPC on the CA being unresposive and was wondering if there was a way to stagger it.
On average hardware CA can handle 100+ incoming requests per second. In other words, 1000 requests in 20 minutes is not a problem for CA itself. I would suggest to collect and analyze performance metrics (using perfmon) for CA during stress-testing.
Thanks Vadims
We have a clustered CA it seems to be only issuing 6/7 a min which is what im trying to troubleshoot the lack of performance seems to be giving serious issues. I can see lots of connections coming in from machines on TCPView but then only seems to handle so many then stops responding. Under normal work load seems not too bad but when new requirements are implemented which might be several thousand new certs it starts to fall over.
Hi Vadims, quick question, if renewal fails does Windows archive the certificate or does it keep trying to renew until it expires and then it archives it?
Hello Vadims, I have an issue like hashir had 6 months ago. I have a workstation deployment which requires a certificate to continue to configure the WinRM listener using this certificates thumbprint.
I am joined to the domain, but still only logged on as local administrator, and all things look right, except for there is no certificate auto enrolled. I noticed a failed run of the schedueled task AikCertEnrollTask, but I managed to run it successfully, but nothing happens on my CA. No failed requests, no issued certificates. If I open a CMD using runas <domain account> with local admin rights on the workstation, from there I open certlm.msc and try a manual certificate request. I can see the template, but the request does not happen, its stuck on Enrolling... The template has Domain Computers with read enroll and auto enroll rights.
Any tips as to where I can look for info about errors?
Hi Vadims, quick question about odifying a certificate template: if I make a change (for example in the security settings or something like "require the following for reenrollment" setting in Issuance requirements), and then I click "apply" and "OK", this will change the Minr Version of teh template, soit will not cause re-enrollment of certificate holders, but will it affect renewal when the time comes?
@Miguel Rodriguez
yes, it will.
Hi Vadims,
I had created a workstation Authentication certificate template for auto enrollment. I have enabled auto enrollemnt using GPO. It all worked as expected. client computrers got certificates auto enrolled. Later I found that I am using a weaker encryption algorithm which is SHA1. In order for the application that requires this client certificate for signing, it requires SHA256. So I changed the encryption algorithm to SHA2 and regenerated the CA Root certificate.
Now I have created a new workstation Authentication certificate template to get SHA2 certificate. It works all as expected. Unfortunately I deleted the older workstation Authentication certificate template for SHA1. How can I clean up certificate repository in the client computers for older weaker certificates.
> How can I clean up certificate repository in the client computers for older weaker certificates.
you have to manually delete them. For example, run a script that will lookup for certificates based on old template and delete them.
Good to read this document...but still have issues with CES/CEP and KBR autorenewal. Have an issuing Root CA and one server with both CES/CEP installed as per below:
GPO assigned policyservers:
CES/CEP(prio 1) - certificate based authentication with KBR - should be used when triggering renewal AND certificate is present.
CES/CEP(prio2) - username/password with KBR enabled - should only be used on initial certificate deplyment
When I iniitially request a certificate I have to provide a username and password (since i dont have a cert yet) and request the certificate based on the prio2 policy. Once enrolled and directly renew with the same key (certmgr GUI), it provides me the option to renew the certificate without prompting for credentials whatsoever and renews (policycache is present). When I follow this up and do this scipted works as well and show that the certiifcate based authentication CEP is renewing the cert.
Then I purge the policycache by "certutil -f -policyserver * -policycache delete"....and run the script to renew the certificate again...ERROR...."content was acquired as silent" meaning there is some popup in the background? This is because the policycache is empty and no credentials are present. Would expect that the present valid client certificate is automatically used based on the prio1 policy and added to cache again, but no such!!! To correct the situation I need to start the GUI certmgr again, and perform the renew actions up to the point of selecting the certificate and cancel. Now the cache is populated again, because the certificate was used to authenticate (hence no popup for username/PW). Now when I run the script again it works, because there is a policycache again.
The script is a simple powershell that checks for expiring certificates within 2 days. When found the thumbprint is used to renew by:
"certreq -machine -q -enroll -cert $certificate.thumbprint renew reuse"
Since the policycache only lives for 8 hours this means that KBR breaks after 8 hours!!! This means that 1y valid certificates will fail renewal. This is driving me nuts!!!
If have seen more people with this problem but a clear solution was never found or posted..
Computer Certificate template default settings for certificate renewal is 6 weeks before certificate expiration.
How often client tries to renew certificate? For example, if local network is not available, or other connection issues. Does computer tries to renew certificate multiple days? Or once a week? How does it work?
Furieux
> How often client tries to renew certificate?
every time autoenrollment is triggered until it is renewed or expired.
Hi Vadims
We have a server (CA) that does our certitificates to computers, but for some reason the certitificate didn't auto-renew.
Is there a way we can renew the cert on the server and computers could get this new cert, when they request?
Many thanks
Allferry
You need to investigate it first why they don't renew. Go through the check list:
Thank you Vadims for the article. Accurate and detailed information how autoenrollment works.
HI Vadims,
I have a bunch of my computers that don't appear to attempt auto-enrollment despite inheriting the same GPO that forces other computers in different OUs to auto-enroll. There is clearly something conflicting in one of the other GPOs that are being applied in the sub-OU. I've checked that the reg keys for auto-enrollment are identical between a working computer and ones in this OU. The sub-OU has RDP disabled but if you enable RDP with a GPO directing the computer to get a cert from the CA, it immediately grabs a certificate. This RDP GPO is not a requirement on computers elsewhere that are happy to auto-enroll with the simple GPO telling it to do automatic certificate management.
I've enabled client logging and rebooted and nothing appears in the application log. Also, running wireshark at this point on the CA doesn't show anything connecting from the computer. So, it's as if the auto-enroll registry entries are being ignored.
Where else can I look to find out why these computers refuse to start the process of auto-enroll without further proding.
Thanks,
Bret
Hi Vadims
We do have a special setup with clients doing autoenrollment (renewing there existing certificate now) and we need to force them to do a New Request instead of a Renewal request. Is there any possibility on the Template?
Kind regards,
Hans
@Hans Ueli Blum, please check the "Forcing re-enrollment" section in this blog post.
Hi,
i do have a question regarding auto-enrollment. Does the client only use LDAP (389) for retriving the needed PKI information from AD ?
- Is LDAPs possible ?
- If a child domain existing and the PKI is placed above the client domain, will the Client always get information from his own domain, or will the client be sent to the domain controller where the CA is located in ?
HI Vadims, thanks for going through all these details. My question is: assume there is a new template that supersedes the original template. What happens with a client that does have autoenroll permission for the original template but not for the new one. Would it autoenroll for the original template? Or would it not autoenroll for neither?
4 years later, I just want to congratulate you on a great article and a awesome followup dicussion.
Regards,
Eder Pires
Hi Vadims,
Could you please explain the best method to remove old Auto-enrolled certificate from CA sevrer?
Is it safe in Certificate Template Console simply remove old Auto-enrolled certificate?
Best Regards,
Michael
> Could you please explain the best method to remove old Auto-enrolled certificate from CA sevrer?
remove it from CA assignment in CA management console.
Post your comment:
Comments: