Hey all Rob Greene again. Seems like I have been on this PKI kick lately, and today is not going to be any different.
Occasionally, I will get a customer who must get certificates issued for things like Web sites, and they must have custom Subject Alternative Name (SAN) DNS values on the issued certificate. They hate that their web server admins must submit the request, and then as Certificate Authority Managers, they must look in the Certification Authorities database and review the Pending Requests table.
The first question that they ask is if there is a way to not require them (the CA Manager) to approve the request as this slows down the process of getting the certificate issued. From a technical perspective most of you would know that the answer is YES, you can configure the certificate template to automatically issue. However, this is NOT a good thing to do, and is seen as a Microsoft CA vulnerability; if you have a CA audit happen you might fail the audit because you allowed this. This specific vulnerability is considered the ESC1 vulnerability.
ESC1 wants either an Enrollment Agent to cross sign the certificate request, a CA Manager to review the request, or both to validate the information in the Subject Alternative Name (SAN), when the certificate template’s Subject Name tab is set to “Supply in the request”, before allowing the certificate to be issued. This is recommended since the submitter is allowed to enter unvalidated information in the SAN, unlike when the certificate templates Subject Name tab is configured for “Build from this Active Directory information”.
Given this background information, you should already be thinking to yourself, “Rob is not going to tell me to break anything security wise.”, and you would be correct. Rather, I am going to tell you that any certificate template that you have configured for “Supply in the request”, should at a minimum be configured to require CA Manager approval.
Then for something like the certificate template that Network Device Enrollment Services (NDES) uses for its certificate, I would advise you to use the Enrollment Agent configuration. The Exchange Enrollment Agent (Offline request) template has the Enhanced Key Usage (EKU) of “Certificate Request Agent”, and this is the certificate NDES uses to sign the Certificate Service Request (CSR) that the SCEP client sends to the NDES Server.
Of course, I am just giving some good examples of real-world certificate templates that you are going to be using within the environment. The last part is that the security permissions SHOULD be locked down as to who can enroll for each of these certificate templates.
Specifically, enrollment for the two Certificate templates needed by the NDES services, it should be the CA Manager NDES Admin and the NDES Server. The Exchange Enrollment Agent (Offline request) and CEP Encryption certificate templates should be locked down as to who can request enrollments.
Just like the custom Adatam Web Server certificate template, only IIS (Internet Information Services) Admins, and IIS Web Servers should have access to this template to be able to enroll with it.
Let’s first discuss the scenario that I am going to cover in the blog. Although I would love to cover all the possible uses that all you lovely internetz users might have for certificate enrollment, this blog will have to end at some point.
IIS Admins are tired of remembering to go to all their web servers and request new certificates for them before they expire. The CA Manager is also tired of the IIS Admins always sending emails nagging that they need their certificate enrollment requests issued. Then always having to go to the Certification Authority snap-in to approve/issue the same certificates over and over each year because of rules that web server certificates can only be valid for 398 days. See (https://thehackernews.com/2020/09/ssl-tls-certificate-validity-398.html)
Side bar:
If you want to modify the settings of any default certificate template, it is best to duplicate the original certificate template and then make changes to it. This is recommended so that you always have the default templates available in case you must create a new template in the future that is based off the original template. If the original template is modified two to three years down the line, you may not remember what was changed so that it could be changed back to the original template configuration. As far as naming goes, we would recommend that you put your company name or initials in the template name and keep the original template name after that. In this blog you will see the template used is called Adatam Web Server. This is a customized template based off the Web Server template.
Keep in mind that this can be done for any certificate template that has the Subject Name tab configured for “Supply in the request”, this not limited to just web server certificates.
As you can imagine, there are several things that need to be configured to get this working:
The first two steps should be self-explanatory as to how to create groups and set up the group scopes. We are not going to cover group creation in this blog. I do want to point out one thing that happens often: Most Administrators seem to remember that if you add a user to a group, the user needs to log off and back on before the group can be added to their tokens. When adding a computer account to a new group it also needs to log off and back on before the group membership can be added to its token. Typically, the log off and back on for a computer will be a computer reboot; that needs to happen after the new group membership is added to its token.
The base template that you use to duplicate can of course be anything you would like, but in our example, we are just going to duplicate the good’ol faithful Web Server certificate template.
NOTE: Stay away from using anything higher than Windows Server 2012 R2/Windows 8.1 for your templates if you are using CEP and CES as these two web services have problems seeing templates with compatibility higher than this.
NOTE: It might make sense to set the checkbox “Renew with the same key”.
NOTE: I would strongly suggest NOT setting Use alternate signature format on the template either. This is a proprietary format that many applications will not understand. This check box will only be available when you are using a Key Storage Provider (KSP) provider type.
Next, we are not going to cover how to create a Group Policy Object, and things like GPO ordering, etc. We are going to discuss just the policy settings that are important for the discussion of this blog.
NOTE: To learn more about these two settings I would recommend going over to Vadims blog. He does a great job of explaining what each of these do: https://www.sysadmins.lv/blog-en/certificate-autoenrollment-in-windows-server-2016-part-3.aspx
Of course, with any of these things, you should always test things before relying on the solution in a production environment. I do want to caution you about setting up a test environment and then setting up the certificate for a short issuance period as this tends not to work out well for most customers, and they eventually end up calling stating that autoenrollment is not working.
There are few things to keep in mind about certificate automatic enrollment / automatic renewal process.
The first thing to remember is that certificate auto enrollment / renewal only happens on the following triggers:
To trigger auto-enrollment to run manually you have two options.
Certificate renewal WILL NOT happen until 90% of the Certificate lifetime has expired. Trying to use the template setting “Renewal period” does not change this fact.
Auto enrollment / renewal attempt MUST happen while the certificate is still valid, and after the start of the 10% certificate lifetime left and the expiration time of the certificate. (MUST NOT BE EXPIRED). Like being unable to re-animate something that is already dead, you cannot renew a certificate that has already expired.
The math that needs to be done is: (CertLifeTimeInDays * 24) * .10
The value from the above MUST be larger than 8 hours.
Here is an example: Set up a certificate that is valid for two days for testing and we will run through the exercise here:
This shows us that for one of these certificates to be renewed, the process that runs only every 8 hours would have to run within this 4.8 Hrs. window. This is going to tell us that sometimes you would get lucky with a certificate renewal attempt being done, but more than likely MOST of the time you would fail to renew the certificate because it would expire before the auto enrollment cycle happens.
Another example is a certificate that is valid for 4 days. Let us run through the exercise here.
This shows us that for at a 10% lifetime left it is still valid for over 8 hours. This certificate would always get at least one auto enrollment cycle to be run to renew the certificate. Assuming you don’t have anything else wrong, the renewal would happen successfully. This is the minimum lifetime that any certificate testing should be set to.
Well, now you got your test lab, issuing short lived certificates and getting them automatically renewed, but… Now you are noticing that your application is not using the new certificate.
Unfortunately, there are going to be some applications for which the automatic renewal might not work out well in your organization. However, the certificate could still be renewed manually by your IIS admins, and it would still not require the CA manager to be involved in the renewal process. The key thing is your IIS Admins would need to go through the manual certificate renewal process BEFORE the current certificate expires, as it is used to cross sign the renewal request.
UPDATE 5/30/2024:
After release of the blog it was brought to my attention of two different things to consider.
First unknown to me (as I am not an IIS support engineer) apparently there is a setting within the IIS Management console to help with updating the site binding configuration so that this automatic renewal behavior would work. This feature is called Certificate Rebind and was new in IIS 8.5. https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-85/certificate-rebind-in-iis85
Second, we recently has a case were the customer had several websites running on an IIS Web Server. These websites all used unique certificates and were all generated manually using the same certificate template. When one of the certificates were ready to be renewed, they found that all website certificates were archived, and only one of the website certificates were automatically renewed. This would be by design behavior. The only thing that we could really recommend in this situation is to use one certificate for all websites and make sure that all the websites DNS names were added to the certificates Subject Alternative Name (SAN) field.
Failure to do this will result in going through the entire manual issuance of the certificate all over again. And, going through the CA Manager approval process as well, since this would be a new certificate request.
Hopefully, you found some good nuggets of information about how to lockdown certificate templates to protect against ESC1 vulnerabilities and what some of those less often used tabs do. And of course, how the certificate renewal process works, especially around shot lived certificates.
Rob “I coulda been a Welder” Greene
Extra credit for those who can figure out where the saying came from.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.