TLS Integration Issue between PrivacyIDEA and Microsoft CA (OCSP/CRL Validation Failure)

Question
1

I have deployed a test environment to integrate PrivacyIDEA, Microsoft Active Directory Certificate Services (CA), and Active Directory, with the goal of enabling centralized certificate issuance and secure TLS-based authentication between systems.

The environment is based on Windows Server 2022 with Active Directory Domain Services and Enterprise Certification Authority roles installed. PrivacyIDEA is running in a Docker-based environment under WSL2 (Ubuntu 22.04). The container stack includes PrivacyIDEA (gpappsoft/privacyidea-docker:3.12), MariaDB, Nginx as a reverse proxy, FreeRADIUS for authentication tests, and OpenLDAP for isolated directory testing. PrivacyIDEA configuration and certificates are stored in persistent volumes and bind-mounted directories.

The PrivacyIDEA web interface is available via HTTPS on port 8443, and the system successfully issues TOTP tokens for Active Directory users. To enable certificate-based authentication, a dedicated certificate template named “PI-TLS-Client” was introduced on the Microsoft CA server. The CA successfully issues certificates based on this template. However, TLS communication between PrivacyIDEA and the CA (through the gRPC connector layer) fails during the handshake phase, and corresponding Schannel errors are recorded in the Windows event log.

Windows Schannel logs report REASON_OCSP_RESPONSE_RETRIEVAL_ERROR, with an empty OCSP URL and timestamp values set to 1601-01-01T00:00:00Z. Additionally, Active Directory Certificate Services logs show that DNS information could not be added to the Subject Alternative Name field (CERTSRV_E_SUBJECT_DNS_REQUIRED), referencing CN=lc.office.utel as the subject.

The certificate request was made using an INF configuration file (attached to this message). The certificate is generated correctly and includes both DNS and IP entries in the SAN field. The “PI-TLS-Client” template is based on the standard Web Server template and contains EKUs for TLS Server and TLS Client Authentication. Permissions for the template are granted to Domain Computers, Authenticated Users, and svc_ndes. The CA publishes CRLs and AIA only via LDAP; no HTTP publication is available.

The issue seems to arise because PrivacyIDEA or its gRPC integration component expects HTTP or OCSP endpoints for certificate validation. Since only LDAP-based AIA/CDP entries are available and Docker isolates the environment from Active Directory’s internal LDAP path, certificate chain validation fails, resulting in Schannel TLS handshake errors.

Update: After additional investigation, I found that PrivacyIDEA inside the container is actually trying to connect to localhost during the TLS handshake instead of the real CA host. This suggests the connector inside the container resolves the CA endpoint locally, meaning it never reaches the actual Windows Server instance.

At this point, I assume the handshake fails because the certificate presented by the CA doesn’t match localhost, and the TLS layer rejects it due to a hostname mismatch or failed chain validation.
I’d like to ask for clarification on where exactly I should focus next — whether the problem lies in PrivacyIDEA’s gRPC connector configuration, Docker name resolution, or the CA-side certificate publishing (AIA/CDP) method.
Also, what else should I know or test about how TLS operates when a containerized application like PrivacyIDEA initiates a connection to localhost? Specifically, are there any implications related to hostname resolution, certificate CN/SAN validation, or network namespace isolation in such cases?

I’ll keep posting updates in this thread as I test further, and once the integration works properly, I’ll definitely leave the full summary and closing notes.

2

Update.

Hello everyone!

After installing the CA connector on Windows, the situation has partially stabilized. The previous issue is currently not relevant, as I have temporarily bypassed the SSL/TLS connection, which allowed the system to operate without interruptions in component interaction.

However, the problem persists in another area: it is still impossible to properly issue a certificate to a smart card or upload a certificate from the smart card itself. There is an assumption that the CA connector is either incorrectly installed or misconfigured, or that the certificate rules (templates, EKUs, extensions) conflict with each other, causing the requests to fail.

On the server side, permissions and configurations have been verified — all parameters appear to be correct.

If anyone has any ideas or similar experience, please share them.

At this stage, the search for a stable solution is primarily aimed at ensuring the proper operation with key certificates. In the future, I plan to establish reliable TLS connections between the server components.
**See you soon!
**
[2025-10-14 07:46:55.852][WARNING] !!Log Entry Secured by SecureFormatter!! certification request could not be fulfilled! disposition: 2.dispositionMessage: “Denied by Policy Module”.requestId: 23.status {.}.

[2025-10-14 07:46:55.852][WARNING] !!Log Entry Secured by SecureFormatter!! certification request could not be fulfilled! disposition: 2.dispositionMessage: “Denied by Policy Module”.requestId: 23.status {.}.

[2025-10-14 07:46:55.852][ERROR] token create failed: ERR504: Denied by Policy Module

[2025-10-14 07:46:55.852][ERROR] token create failed: ERR504: Denied by Policy Module

3

Update: Hello guys,

I’ve identified that there is a problem somewhere along the communication path between the PrivacyIDEA server and the Windows Credential Authority. The Credential Authority Connector seems to lose the final certificate request, transmitting only the username for which the Credential Authority certificate should be issued, but not the actual request data.

After installation and service startup, the following logs are returned:

o CA=XX.[sensitive data]\[sensitive data], templateName=WebServerExportable
[2025-10-15 00:13:40.894 INF] Requester Name from CSR: test
[2025-10-15 00:13:40.896 INF] Looking up EnrollmentAgent cert in machine store.
[2025-10-15 00:13:40.989 ERR] SendCertificateRequest encountered an error:
CertEnroll::CSignerCertificate::Initialize: Invalid pointer 0x80004003 (-2147467261 E_POINTER)
   at CERTENROLLLib.ISignerCertificate.Initialize(Boolean MachineContext, X509PrivateKeyVerify VerifyType, EncodingType Encoding, String strCertificate)
   at CAService.CertOperations.CreateEOBOCMCRequest(String csr)
   at CAService.CertOperations.SendCertificateRequest(String caName, String certificateRequest, String templateName)
   at CAService.GrpcServer.SubmitCSR(SubmitCSRRequest request, ServerCallContext context)

During subsequent restarts, the logs show that the gRPC service loads successfully and listens on port 50051, but the connector still fails to process the CSR correctly.

This request was sent through the PrivacyIDEA “Certificate Request” form:

[valid full PKCS7/CMC request structure with nested PKCS10, client info, reg info, and two signers]

However, during communication, the server loses the CMC envelope and instead of forwarding the correct request, it sends only the following minimal PKCS#10 data to the CA:

PKCS10 Certificate Request:
Version: 1
Subject:
    CN=test
  Name Hash(sha1): 798d9f5c0e54dbc35d725fa78ffab0ab9210ce8a
  Name Hash(md5): 951ff58434cdc4298ecdef7e0b924f12
Public Key Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
    Algorithm Parameters:
    05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
[skipped]
Request Attributes: 0
  0 attributes:
Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00
Signature: UnusedBits=0
[skipped]
Signature matches Public Key
Key Id Hash(rfc-sha1): 9e342d0c40685b3d2cfef3ba4f120d8bd2188ece
Key Id Hash(sha1): 757c12ef465fee1f4470fbf0e6399a463ac681c2
Key Id Hash(bcrypt-sha1): 2141af2cf98bee799fbf8935359687cf2e2e504d
Key Id Hash(bcrypt-sha256): ea4d995e2e9261e5a7716a580102ca9c6ff1d992f49ad0ef4fdecaf121eb6546
CertUtil: -dump command completed successfully.

In summary, the CA Service starts correctly and can enumerate templates, but when receiving a CSR from PrivacyIDEA, it fails to wrap and forward the complete CMC request — instead, it passes only a plain PKCS#10 payload, which causes CertEnroll::CSignerCertificate::Initialize to fail with E_POINTER (0x80004003).

4

Hello, you are right, the CA Service currently just does a simple EOBO and does not use any additional data, just the username. Since there is not really a demand for this, we have not expanded the functionality.

5

Update

Nils, thank you for explanation. Guys, thank you — this is truly an outstanding product.
So far, I’ve had the chance to test some of the functionality, and I can confirm that two-factor authentication using YubiKey works out of the box on Windows without any issues.

While testing, I discovered that to implement two-factor authentication via PKCS#11 (i.e., when the certificate is stored directly on the hardware token), it seems necessary to correctly pass certain request parameters during certificate issuance or signing.

Could you please point me in the right direction — where should I look first if it turns out I need to extend or modify the CA Connector module to support this scenario?

6

Hi, it is possible to enroll login certificates to PIV devices with our tools:

and the ca service you already use.

If you want to extend the ca service, this might be the starting point:

1 Like