Certificate authentication against CES

Question

Dear community,

i have a question regarding the use of a CES instance in conjunction with certificate authentication.

In my test environment, i have already setup a two tier CA design. One offline root CA and one Enterprise CA. Additionally i have seperate servers for OCSP and CRL distribution. And last but not least a CEP server with certificate authentication. All mentioned services are working as intended. pkiview.msc gives me only "OK"s and non domain joined clients can use OCSP/CRL properly to check the revocation status of a certificate (checked additionally with certutil on the client side). And last but not least the CEP server returns the templates for the user, which authenticated itself via a certificate.

For the CES a seperate server ist used. The application pool for the CES is running under a gmsa with constrained delegation for the configured CA.
If i configure the CES instance, with named gmsa, using username/password authentication, the enrollment for a certificate works as intended.
If i configure the CES instance, with named gmsa, using certificate authentication, the enrollment for a certificate for a requesting client fails with the error message:

"-214348933 WS_E_ENDPOINT_FAULT_RECEIVED"

No errors are logged on the CES or CA.

The only errors i could get my hands on during the enrollment process have been loggend in the CAPI2 eventlog of the requesting client (and only on the client). Herein two erors are reported.

EventID 41 "Verify Revocation"
Result: "The revocation function was unable to check revocation because the revocation server was offline"
[value]: 80092013

EventID 11 "Build Chain" where the "CertGetCertificateCain" reports that:
RevocationResut: "The revocation function was unable to check revocation because the revocation server was offline"
[value]: 80092013

I cannot see if this error correlates with the issue of not being able to enroll for a certificate.
If it correlates, i cannot understand why certificate authentication works for CEP as intended without errors and fails for CES?

Has anyone come across a similar problem or does anyone have an idea where i could find additional logfiles/reports or alike?

Sincerely,
Peter

Answer 1

Hello @Pe ter ,

Thank you for posting here.

How did you set up CEP and CES? What documents did you refer?

For the CES a seperate server ist used. The application pool for the CES is running under a gmsa with constrained delegation for the configured CA.
If i configure the CES instance, with named gmsa, using username/password authentication, the enrollment for a certificate works as intended.
If i configure the CES instance, with named gmsa, using certificate authentication, the enrollment for a certificate for a requesting client fails with the error message:
"-214348933 WS_E_ENDPOINT_FAULT_RECEIVED"
No errors are logged on the CES or CA.

Maybe the following articles are helpful.
Configuring Certificate Enrollment Web Service for certificate key-based renewal on a custom port
https://learn.microsoft.com/en-us/windows-server/identity/solution-guides/certificate-enrollment-certificate-key-based-renewal

Certificate Enrollment Web Services
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/certificate-enrollment-web-services/ba-p/397385

Please check if PKIview.msc status including root CA entries and sub CA entries are all OK.

Should you have any question or concern, please feel free to let us know.

Best Regards,
Daisy Zhou

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.

Answer 2

I forgot to mention, that i do have an additonal error message on the CES side. The IIS Logfiles for the CES website report for every client enrollment query a "sc-status" with a value of 500 (HTTP 500 error code). But no other eventlog/logfiles seems to correlate on the CES to this error.
It seems I cannot find any additional information/logfiles which could point me into the right direction.

Answer 3

Hello DaisyZhou,

thank you for your reply.
Both links you are referring to have been respected during the setup of my environment. Additionally i incorporated the procedures, as applicable, from the following guides:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831822(v=ws.11)
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/hh831625(v=ws.11)
https://social.technet.microsoft.com/wiki/contents/articles/7734.certificate-enrollment-web-services-in-active-directory-certificate-services.aspx
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/enabling-cep-and-ces-for-enrolling-non-domain-joined-computers/ba-p/397821

The status of the root CA in PKIview.msc is OK. This is true for all entries of all CAs (AIA, CDP, OCSP, CA Certificate etc.).

Since all clients who are members of my AD Domain as well as non domain joined clients can succesfully check the status (AIA, CDP, OCSP) of my certificates using "certutil.exe -verify -urlfetch certName.cer" without any errors, i cannot understand why certificate chain building for CES certificate authentication seems to fail (if that is the problem for my clients accessing CES using a certificate) :-(

Best regards,
Peter

Answer 4

Hello community,
just wanted to report back, that the problem has been fixed. It turns out that it was not a certificate validation problem, but a "simple" misconfiguration on my side. With the help of Microsoft support, we tracked the error down to an IIS application pool of the CES server. Turns out that, even though i thought i interpreted the related documents correct, i assigned the wrong application pool the credentials needed.
I assigned the "DefaultApplicationPool" the configured group managed service account, but it should have been the "WSEnrollmentServer" application pool. Though i thought i tested it with this application pool too, i must have had a configuration error like forgetting the "$" sign behind the gMSA account while assigning it or something like that...

For those of you who want to for example use a group of servers with a gMSA, configured with constrained kerberos delegation against a certification authority, for certificate authentication on a Windows 2012r2 / Windows 2019 CES server, i have appended the general commands below. You could use the same commands to achieve kerberos authentication against the CES, yet you have to configure/add the SPNs for the service account.
Please note that you need "enterprise administration" and local administrative privileges to use the "Install-AdcsEnrollmentWebservice" command on the CES server.

New-ADServiceAccount -Name "gMSA.WebEnroll" -KerberosEncryptionType AES128,AES256 -Path "OU=ServiceAccounts,OU=......." -PrincipalsAllowedToRetrieveManagedPassword "GroupNameForCesServers" -DNSHostname Randomname.fqdn
Set-ADAccountControl -Identity "CN=gMSA.WebEnroll,OU=ServiceAccounts,OU=......" -TrustedForDelegation $false -TrustedToAuthForDelegation $true
$multivalue = @()
$multivalue += "HOST/CAName.FQDN"
$multivalue += "RPCSS/CAName.FQDN"
Set-ADObject -Identity "CN=gMSA.WebEnroll,OU=ServiceAccounts,OU=......" -Replace @{UserAccountControl=16781312;'msDS-AllowedToDelegateTo'=$multivalue}

On the CES server:
Install-ADServiceAccount -Identity gMSA.WebEnroll
Test-ADServiceAccount -Identity gMSA.WebEnroll
Add-WindowsFeature adcs-enroll-web-svc
certutil.exe | select-string "config:" #Use the desired output for ToDo1
get-childitem cert:\localmachine\my #Use the desired output for ToDo2
Install-AdcsEnrollmentWebservice -caconfig ToDo1 -sslcertthumbprint ToDo2 -authenticationtype certificate -applicationpoolidentity
Import-Module Webadministration
$AppPool = Get-Item IIS:\AppPools\WSEnrollmentServer
$AppPool.processmodel.Identitytype = 3
$AppPool.processmodel.Username = "$env:userdomain\gMSA.WebEnroll$"
$AppPool.processmodel.Password = ''
$AppPool | Set-Item

P.s.: If you find spelling errors, you can keep them ;-)

I accept Daisy Zhou's answer as correct, since contacting MS support did solve my problem.