PKI-as-a-Service

PKI-as-a-Service

    Auto-Enrollment Errors

    Most auto-enrollment problems come from one of four areas: Kerberos (SPNs, delegation and time), network reachability of CEP and the gateway, the gateway configuration, and Group Policy. Each issue below describes the symptom, why it happens and how to resolve it.

    Access denied: 0x803d0005 (WS_E_ENDPOINT_ACCESS_DENIED)

    The client reaches CEP or the gateway but is refused. This almost always means that Kerberos cannot complete the request on behalf of the client: the HTTP SPN for the CEP web address is missing or registered on the wrong account, or constrained delegation from the CEP service account to the gateway is not configured.

    1. On a Domain Controller, run setspn -L <service account> and confirm that both HTTP/<cep-fqdn> and HTTP/<cep-short-name> are listed.
    2. If an SPN is missing, register it with setspn -S HTTP/<cep-fqdn> <DOMAIN>\<account>. If setspn reports a duplicate, remove the SPN from the other account first, because a duplicate SPN breaks Kerberos for both.
    3. Open the service account's Delegation tab and confirm Trust this user for delegation to specified services only, Use Kerberos only, and the HOST and rpcss services of the gateway computer.
    4. Run klist purge on the test client, then certutil -pulse again so a fresh ticket is requested.

    The client cannot reach the gateway on port 8443

    Enrollment requests time out, and Test-NetConnection gateway.example.com -Port 8443 fails. Port 8443 is blocked between the client and the gateway, or the local Windows Firewall rule on the gateway is missing.

    1. Check the network firewalls between the client subnets and the gateway, and allow TCP 8443.
    2. On the gateway, confirm that the Windows Firewall rule EC PKIaaS Gateway 8443 exists and is enabled.
    3. Confirm that gateway.example.com resolves to the gateway's IP address from the client.
    4. Test again with Test-NetConnection gateway.example.com -Port 8443; TcpTestSucceeded must be True.

    ECGatewayService is running but not listening on 8443

    The service shows as running, but nothing answers on port 8443. The gateway private key is protected by a passphrase and the passphrase was not entered during installation. A Windows service cannot ask for a passphrase at startup, so the TLS listener never starts.

    1. Open enrollment_gateway.log in C:\Program Files\Encryption Consulting\EC PKIaaS Gateway\logs and check the startup line for TLS=on and key-passphrase=set.
    2. Re-run the installer's Gateway Configuration page, enter the passphrase, and restart ECGatewayService.
    3. Run netstat -ano | findstr 8443 on the gateway to confirm that the port is listening.

    The GPO is not applied

    gpresult /r does not list the PKI-as-a-Service GPO, so the client never learns the CEP URL. The GPO is linked to the wrong OU, is blocked by security filtering or WMI filtering, or the client has not refreshed its policy yet.

    1. In Group Policy Management, confirm that the GPO is linked to the OU that contains the test computer and that the link is enabled.
    2. Check Security Filtering: the computer (or Authenticated Users / Domain Computers) must have Read and Apply group policy.
    3. Run gpupdate /force on the client and then gpresult /r again.

    The CEP URL fails validation in Group Policy

    When the CEP URI is added in the enrollment policy and Validate is selected, validation fails. CEP is not running, its SSL certificate is invalid or does not match the host name, or the URL was copied incorrectly.

    1. Browse to the CEP URL from the Domain Controller; a certificate warning or an error page shows where the problem is.
    2. In IIS Manager, confirm the HTTPS binding on port 443 uses the CEP certificate, and that the certificate subject or SAN matches the CEP host name.
    3. Confirm that the certificate chain (Root CA > Issuing CA > CEP certificate) is trusted on the Domain Controller.
    4. Copy the URI again from ADPolicyProvider_CEP_Kerberos > Application Settings.

    Kerberos errors in the event log

    The System or Security log shows Kerberos errors such as clock skew or ticket failures. Kerberos rejects tickets when the clocks of the client, server and Domain Controller differ by more than five minutes.

    1. Run w32tm /query /status on the client, CEP server and gateway and compare the time source and offset.
    2. Resynchronise with w32tm /resync, and make sure every machine follows the domain time hierarchy.

    The certificate is issued but not trusted

    The certificate appears in the store but shows a chain error, or authentication still fails. The EC CA certificates are missing from NTAuth or from the trust stores on the client.

    1. Run certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com" and confirm that both EC CA certificates are listed.
    2. Re-run the NTAuth publication from Activity 2: Publish EC CA Certificates to NTAuth if they are missing.
    3. Run gpupdate /force on the client and check the Trusted Root and Intermediate stores. See Add CA Certificates to the Client Trust Store.
    On this Page:
    Support Privacy Policy Terms of Service

    Copyright 2026 Encryption Consulting LLC. All rights reserved.